1. Milestone 6 contains openmoko rootfs along with all the required libraries, Flash it to your device or Copy it to the memory card.

2. Milestone 5 contains the kernel (uImage.bin), Flash it to your device or Copy it to the First (FAT partition) partition of your memory card.

3. Milestone 3 contains the Userspace libraries and binaries for selinux, copy the contents of lib to /usr/lib folder of device and contents of bin to /usr/bin of device.

4. Milestone 8 contains MTM emulator and required utilities, use the Following method to install MTM emulator on openmoko.

a. Extract tpm-binaries.tar.bz2

i. Copy *.h files to /usr/include folder of Device

ii. *.so, *.l and *.la to /usr/lib folder of Device

iii. The rest of Binaries to /usr/bin folder folder of Device

iv. Copy tpmd_dev.ko from milestone 5 to /lib/modules/<kernel_version>/kernel/drivers/char/tpm on device

b. Install the IPKs using the following command

$opkg install tpm-tools-1.2.5.1_0.1_armv4t.ipk

$opkg install trousers-0.3.4_0.1_armv4t.ipk

5. Milestone 10 contains ucon, the verifier module and the tpm’s pcr read utility, use the following method to make it operational on Mobile device

a. Copy UCON_Final.tar.bz2 and verification_jar.tar.bz2 and pcr_reader_java.zip to your home folder on device.

b. Extract them

c. To run ucon, change your directory to ucon_final and run the following command

$java -jar ucon.jar

Note:

It will execute and will take some time, it will produce two types of logs, the more detail xml log (meta/log/usage_log.xml) and the log containing hashes (/var/ucon_hashes)

d. Run the verifier, change the directory to verification and run the following command

$java -jar verifier.jar

It will execute and recalculate the hashes from the ucon_hashes file in /var/ and it will give u a final hash.

e. Now we have to compare this hash store in PCR 11 of the TPM, to see that, change your directory to pcr_reader_java and run the following command

$java -jar pcr_reader_java.jar

Read the value of PCR11 and compare it with hash produced by verifier, if they are the same means that the log isn’t tampered.

Any typical information system is by nature a distributed application/system. Therefore we have a client side, a server side and a means of communication. As an information security professional you have to consider how to isolate different trust engines from being affected in a way that causes failure in security objectives of the trust engine and still provide sufficient interfaces to the engine so that business integrations can evolve without starting from scratch!

Trust Engine: Technically it is a protected logical unit of a set of activities that can be classified by its purpose/services, stakeholders, resources and the software stack it uses. Its classical meaning is associated with trust management for authorizing cross domain subjects.

In widely distributed systems where the computation or usage is done by systems that are beyond the authoritative domain of more then one stakeholder. Such application frameworks and systems need to provide something more than the conventional ACL used inside protected or closed systems. Cryptography is used with an equivalence mechanism to map subject attributes to certificates (X.509). This gets complicated as more and more applications and tiers are involved.

In part 2 of this article we will look closer at different end points with respect to the integration of security mechanisms. There might be some ambiguity when considering the word platform. Platform literally means a base for some particular activities. Normally it would be associated with hardware and operating system. For a distributed application it would include the application framework that spans one machine. A framework is conceptualization and and organization for a middleware (abstracting the OS and device) in this case.

Note that security modules like TPMs have additional protected capabilities that can be emulated with software modules if needed. Consider the use of vTPMs in cloud computing scenarios over Xen hypervisor.

Software tokens are easy to handle and are more flexible then the hardware counterparts and roots of trust!

For more details:

http://en.wikipedia.org/wiki/Software_token

The policy is now being developed further to suite our solutions in permissive mode. Check out http://www.facebook.com/group.php?gid=72016920562

The paper deals with the issue of differences between security enforcement on the operating system level and within applications. It describes a mechanism through which security labels of a MAC mechanism from the OS can be communicated to the application; the application provides assurance that it enforces the security policies within its logic; the output of information from the application is also communicated to the OS MAC mechanism to ensure that these outputs get the correct labels.

Things to notice:

• The architecture relies on security typed languages (Jif to be specific) to ensure that no illegal information flow can occur within the application
• The architecture provides an interface through which OS policies can be communicated to and from the application
• It provides a mechanism which provides assurance that the policies of the OS are being implemented correctly and
• It uses a high level policy to describe “declassifiers” — interfaces which are allowed to move information from high level of security to a lower level.

I found the last point of particular importance because it explained to me exactly what PRIMA meant by ‘interfaces which convert data of low integrity to high integrity’.

Another important point to note is that the information flow analysis to and from the application is not static (as in Jif – which uses compile time checks only, as far as I know) but dynamic in that the lattice of principals is created at runtime (meaning that mappings of labels to and from the OS would occur at runtime thus depending on the OS policy at runtime).

The developer does not have to know these mappings either. They are defined in a separate high-level policy so that they can be defined by the system administrator on the target machine.

The concept of mappings is particularly clarified through Figure 6 and the fifth paragraph in Section 4.3. The policy within the appplication allows pub -> siic -> sec. pub is mapped to security level s0 of the OS and sec to s1. Information can thus from from s0 to s1 (but only if this is allowed by the OS!) The Jif Runtime takes care of this sort of information flow.

Future directions of my interest:

1. policy compliance analysis between application policy and OS policy.
2. declassifier generalization (although the authors themselves have pointed out a few works in this direction).
3. issues of attestation of the architecture. (I believe this is not so straight forward due to the inter-linkages between different modules of the architecture but then, attestation is never easy anyway. )

Embedded.com – ARM links with Trusted Logic for secure mobiles, set tops:

amin.

1. In Application: Where flow control of application is controled by labeling the data of the application. Current research is limited to MLS becuase its simple. And because the security type languages are not mature enough to handle the granularity. I have seen two framworks at this level, which make use of these languages. One of them has been partially integerated with selinux by using the application layer API to selinuxfs. I am curious why they are so interested in JAVA! There is no C extension.
2. On Application Layer: This is achieved for applications that do not use TCP/IP directly. They use RPCs so the common network controls cannot handle properly. The reason is that port to application mapping is done by portmapper daemon. Thus the rpc headers carry the security contexts. Such applications are NFS and NIS.
3. At TCP/IP Layer: Here the ports are labeled for the associated applications on both sides. I a hostile environment this would not prove useful so encryption would also be required. This is achieved by IPSEC associations being labeled. I am not fully satisfied by the mechanisms at this level because at one extreme we have lack of security and on the other hand manageability issues.

LDAP is on the todo list but nothing is currently being done about it upto my knowledge. The todo list also wants more granularity and API at TCP/IP layer.

Policy distribution being a great issue has no solid solutions yet. The only possibility to till now is a tranlation server, which would provide an equivalence mehanism for internode security contexts. But this is has been left as an idea and no progress is being made. IPSEC associations were provided only for subjects but currently they are working for providing object support but the work is hidden yet. They are thinking for CIFS support as well. Ephimeral ports can be handled with standard SELinux API for applications.

The biggest problem with distributed policy is the type enforcement, which is part of the security model/context. Leaving it out would be a solution but will affect greatly because code bindings will be lost, which will result in loss of integrity control. The context has three main models. User identity, role and TE. If one is lost it will affect the others because they are tied together to help each other. I am figuring out how much affect will be made. At the same time integrity can be measured with IMA and alike. I would like comments on what you ppl think about the differences in the integrity model of TE and IMA.

If anyone can come up with other ideas of network needs plz brainstorm so I figure out the requirements. There are others which I have’nt mentioned because they are trusted applications by SELinux. I find a gap over here because trusting applications is not a good idea. Information flows can work here. More on this when I get a solid insight on them.

What do you guys think should be my next target. Amin is sorting out to integerate his study with all this. So give ideas of possibilities. Any of you who thinks their work can have relevance plz share your findings so that we can be more useful to each other.

amin.
]]> http://imsciences.edu.pk/serg/2007/08/tpm-hacks-controversial-security-paper-nixed-from-black-hat/feed/ 0