This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Currently, from the perspective of users and vendors, we see that mobile phones have been increasing and are also used for basic computing tasks such as banking services, mobile commerce and many others. All these mobile activities require increased trust and security functionality. The concept of Mobile Trusted Module (MTM) was generated by Trusted Computing Group (TCG), as part of its mission to complement existing mobile phone security components such as the mobile device's operating system, platform and application level functionalities should interact in a secure trusted manner. MTM is conceptually a Trusted Platform Module (TPMv1.2) as defined in the Trusted Computing Group (TCG) specifications.
MTM differs from TPM in various ways. MTM introduces the concept of Secure Boot. In contrast to an authenticated boot, a secure boot aborts execution of the software - or more restrictive: the boot of the device - if the integrity check on the software that is currently being loaded fails. The major components involved in the secure boot of MTM are the Reference Integrity Metric (RIM) certificates and their enforcements. These certificates will be used in order to validate the measurements before they are extended to Platform Configuration Registers (PCR).
Secondly, it introduces two types of MTMs. One known as Mobile Remote Owner Trusted Module (MRTM) and other being Mobile Local Owner Trusted Module (MLTM). Manufacturers and providers want to get secure remote access to the mobile phone by using features of the MRTM. On the other hand, the phone's user or owner, who has physical access to the device and its applications, uses the MLTM.
The difference between them is that the MRTM must support mobile-specific commands defined in the MTM specification as well as a subset of the TPM 1.2 commands. Typically, phone manufacturers and network service providers use an MRTM. These parties only have remote access to the MTM whereas the MLTM is used by the user who has physical access to the device and his applications.
Secure Boot should be done as part of activating the MTMs. For that 2 states have to be passed - Engine Reset and Engine Root-of-Trust Initialization. Different Root of Trusts criteria's have to be passed as part of the initialization. First, Root of Trust for Enforcement includes the execution environment of MTM and also has the mechanisms to guarantee the integrity and authenticity of MTM code. Some form of device secret will be needed to establish a Root of Trust for Storage (RTS), and some immutable or similarly protected code will constitute the Root of Trust for Verification (RTV) - creates the initial measurements to be added to the MTM. Finally, Root of Trust for Reporting (RTR) will be used to store the secrets to sign PCR measurements for the attestation purposes.
Architecture and implementation of MRTM on an ARM 9 processor platform with TI M-Shield
1. ROM to store the program code or a mechanism by which the integrity of code uploaded to the secure environment can be validated (code signing).
2. A shielded location (secure RAM) for the loaded state, as well as for run-time data.
3. An isolated execution environment (TrEE) for the program code with access to the shielded data location.
4. A device-specific, persistent secret to seed the RTS. The confidentiality (access control) of the secret can e.g. be bound to the secure environment itself.
5. A simple (I/O) library for use in the isolated environment, including cryptographic primitives and random number generation necessary for a MTM.1
There are a number of implementation possibilities, such as :
A specialized MTM chip
A TPM 1.1 or 1.2 chips and some extra layer in software to implement extra commands.
Another HW chip bound to the platform and running an MTM application amongst others.
SW MTM running in a virtualized engine with the virtualization environment protected by an underlying HW MTM
SW MTM running in a CPU chip.
On the other hand, the size and cost of a separate MTM chip may be higher than what is affordable in a typical mobile or embedded device. A cost-effective alternative to a discrete MTM chip is to implement trusted computing functionalities in software and execute them on the embedded processor itself . Such a software-based MTM essentially works in the same way as its hardware counterpart and uses the same logical interface (i.e. the commands specified in ) to offer its services.
Code integrity: The integrity of the MRTM is governed by the RTV.
Data integrity and confidentiality: In the MRTM implementation, the state is protected either by authenticated encryption (AES-EAX) with a platform specific key and a 16-byte random IV, or alternatively with an AES-CBC encryption with a random IV, integrity protected with an embedded SHA-1 in prefix-suffix mode 4.
Data state freshness: An MRTM-specific vector of latest-used random IVs is maintained within the secure environment.
On implementing MRTM on an M-shield architecture, it can be observed that the code has to be run in an interleaved manner on System-On-Chip (SoC) secure memory, of which around 7kB (for code and data) is available at a given instance. For this reason, the implementation of the MRTM is divided into parts (collections), individually minimized in terms of code and data size which in turn helps to improve the performance.
The measurements also indicate that the TPM/MTM logic itself is not the bottleneck in terms of performance, rather communication channels and I/O design approaches are the likely causes for slow MTM/TPM interaction. On the Nokia N96 platform, it is seen that the use of MTM is not prohibitively expensive, when used as part of secure boot.
4.7 SECURITY FLAWS
Implementation of MTM functionality -
The first problem arises from the fact that the TCG concepts are geared towards a monolithic MTM implementation in the form of a separate module which provides access to its services via a set of well-defined commands. It seems that the TCG favours a clear separation between MTM functionality and the rest of the system. However, the fact that MTM functions alongside untrusted applications are executed on the same processor calls for measures to protect security-critical code and data from tampering and unauthorized access, respectively. One possibility is to execute the trusted code base in isolated or protected execution domains that are provided by a number of embedded processors (e.g. ARM TrustZone ). Of course, this raises the question of which features a processor must possess to guarantee the secure execution of MTM operations.
Concern on selection of cryptographic algorithm MTM must support -
Version 1.2 of the TCG specifications [32, 33] defines a minimum set of cryptographic algorithms and operations that a TPM must support. This set includes RSA (for both encryption and digital signatures) for key sizes of up to 2048 bits, the SHA-1 hash algorithm as defined in the FIPS-180-1 standard, and an HMAC according to RFC 2104. A TPM manufacturer may choose to implement additional cryptographic algorithms, but the support of RSA, SHA-1, and HMAC is mandatory to meet the TCG specifications. Also recommended is the addition of AES, Diffie-Hellman and Elliptical Curve Cryptography (ECC) in the crypto-suite. Latest advances in analysis of cryptographic algorithms have showed that
RSA, MD4, MD5 and SHA-0 are weak functions. Also researchers have been against use of RSA for trusted computing in embedded systems due to performance issues. Collisions for the full 80-round SHA-1 can be found with a complexity of 269 hash operations, which is approximately 2,000 times faster than a brute-force attack . Very recent research indicates that the complexity of finding collisions for SHA-1 can be further reduced to 260 hash operations. Therefore, it is no surprise that many cryptographers doubt the security of SHA-1 and recommend against using SHA-1 in new designs. Two good alternatives to SHA-1 are the hash functions SHA-2 and Whirlpool.
A particular advantage of Whirlpool is its high degree of flexibility, which allows for many implementation options in both hardware and software. On the other hand, SHA-2 is a NIST-approved algorithm, which is important for the deployment in certain markets.
Lack of algorithm agility in the current version -
The lack of algorithm agility in the TCG specifications is most likely due to the (dated) assumption that the support of different crypto algorithms would significantly increase the cost of a TPM or MTM since each algorithm requires its own hardware implementation. Algorithm agility can be achieved in a very flexible and cost-effective way by integrating custom instructions into a general-purpose processor. Also a multitude of cryptographic algorithms can be implemented in a very cost-effective and flexible way through instruction set extensions.
During the initial implementation of MRTM, a few logical inconsistencies in the MTM v.1.0 specification were encountered.
Firstly, when the MTM IncrementBootstrapCounter command is called with a RIM certificate, whose integrityCheck- Data verifies successfully, but whose counter reference is not consistent with the platform, the specified return value is TPM Success, even though CounterBootstrap has not been incremented. A more logical return error value would be, for example, TPM BadCounter.
Secondly, the MTM VerifyRIMCert computes the reference value for the integrityCheckData of a RIM certificate in a different way than the command MTM InstallRIM - the former creates the integrityCheckData with integrityCheckSize set to zero and the latter does not. As a consequence, a RIM certificate created with MTM InstallRIM cannot be verified with MTM VerifyRIMCert. Consistency can be achieved by setting the value to zero in both commands. The findings have been reported back to the TCG MPWG.