Mobile Phone Work Group Mobile Trusted Module Specification
This document is an industry specification that adapts existing TCG technology for use in a mobile phone taking into account its embedded system nature. This specification also defines new commands and structures for enabling applications that the technology must enable in a mobile phone context.
Mobile Trusted Module FAQ
What is the status of TCG’s efforts on the Mobile Trusted Module (MTM)? Is the MTM v1.0 specification still valid for use today? What has been done in the developer or phone community to use the specification? What were the use cases for this?
Q. What is the status of TCG’s efforts on the Mobile Trusted Module (MTM)?
A: The most recent TCG MTM v1.0 publication is the Abstraction Layer. This is a description of a generic architecture that can be built using disparate platform resources, to help vendors who wish to use the concepts of trusted computing in mobile platforms and developers who wish to use facilities provided by trusted mobile platforms. With the already published MTM v1.0 Use Cases, Specification, and Reference Architecture, the Abstraction Layer completes the MTM v1.0 specification document set. The next phase of MTM standardization will reflect recent developments in the mobile security ecosystem.
Q. Is the MTM v1.0 specification still valid for use today?
A: Yes. The MTM v1.0 specification is still valid for use today (as are the MTM 1.0 use cases). It remains a safe fundamental building block for trusted mobile platforms, as although a weakness has been found in the SHA-1 hash algorithm, the use of the algorithm by the MTM is such that it is not susceptible to that attack vector.
Q. What has been done in the developer or phone community to use the specification?
A: MTM is used as a security foundation in some academic work (for example TU Graz, ETRI) and is defined to be the security enabler in the Terminal Mode standard. Nokia Research Center has developed MTM proofs of concept. ETRI and Samsung have also developed functional MTM proofs-of-concept. Codenomicon has utilised NRC’s MTM source code to successfully implement a MRTM fuzzer (test suite).
Q. What were the use cases for this?
A: MTM v1.0 use cases, in the context of the TPM 1.2 command subset, include platform integrity, device authentication, secure channel between device and UICC, secure software download, and mobile commerce use cases for Mobile banking and ticketing. Secure device boot (part of the platform integrity use case) is the main divergence from TPM v1.2.
Q. What is the next step for TCG for the MTM?
A: The changes to current MTM functions that are anticipated in future MTM specifications are for ease of use and flexibility. MTM v2.0 use cases and requirements are also being developed to ensure that the MTM remains relevant, and to identify requirements for additional specification to support new applications.
The mobile device ecosystem continues to evolve at a fast pace, driving the mobile business cases and security requirements. To address these evolving security needs, TCG intends to investigate the concept of a Trusted Execution Environment and related Application Programming Interfaces (APIs). The addition is needed for implementing legacy credentials in use especially in the domains of mobile payment, ticketing and rights management, but is also usable for some of the new use cases, such as for eWallet and eHealth.
Q. What are new use cases for the MTM?
The newest use cases introduce how MTM is utilized for hardening security of vehicular device interconnectivity, enterprise mobile authentication, media lending, and smart metering, amongst others. Mobile banking, payment and ticketing, still valid use cases described for MTM 1.0, are amalgamated under the notion of a wallet.
Q. Does the MTM, whether at present or in the future, have to be implemented in dedicated silicon? If not, how is it implemented?
A: The choice of MTM implementation is flexible. It can be implemented in hardware, in both hardware and software, or as software only. Implementation choice will depend on business objectives for the implementation. The definition of the roots of trust will continue to define the minimal (HW) platform binding, and hence the means to estimate e.g. the security level of a given MTM.
Q. Do you anticipate an entirely new MTM specification?
A: Yes, there will be a new MTM specification, with new commands and structures. However, the fundamental concepts of the MTM v1.0 (secure boot, trusted boot, small implementation footprint, plus the possibility of non-ASIC implementations) will remain.
Q. Would any work done to support the original MTM specification be compatible with a future specification?
A: MTM v1.0 knowledge and techniques would be reusable in v2.0. We estimate that the supporting documents, i.e. the Reference Architecture and Abstraction Layer will be relevant in a v2.0 specification also. We do not foresee that the contents of these supporting documents will significantly change from a conceptual standpoint, although an upgrade will be necessary to be compatible with MTM v2.0 functionality and to incorporate any new functionality needed by new use cases.
Q. What is your timeframe for a new specification?
A: The objective is to make available the first public release of the MTM v2.0 specification in a mid-2012 timeframe.
Development of MTM v2.0 use cases, requirements and internal specification drafts will lead to that anticipated timeframe.
Q. Who do you anticipate would most benefit from the specification?
A: The target business beneficiaries are the same as for MTM v1.0, with additional beneficiaries as outlined in the MTM v2.0 use cases.
Q. What is the anticipated cost of implementing a new MTM specification?
A: TCG is not in a position to comment on the cost of implementing specifications. Implementation costs depend on how a particular vendor would implement the specification according to their business requirements.
Q. What software is required to enable the security of the MTM specification?
A: The security of the MTM specification is based on trust roots, and the notion that the devices that implement the MTM specification use some legacy, HW-assisted security architecture, in many cases a processor mode with isolated execution. The binding between the legacy architecture and the MTM will be device-specific in accordance with the definitions of the MTM trust roots – there is no common bootstrap.
Q. It feels like the MTM original specification was stalled and never was widely implemented. How do you intend to change that with future MTM specifications?
A: It is true that mobile phone manufacturers have currently chosen to support the MTM use cases with legacy solutions rather than deployment of TCG specifications. To a large extent, MTM adoption will hinge upon advances in PC functionality because mobiles will require MTMs in order to deploy the same services as those enabled by those next generation trusted PCs.
Q. How can companies not involved in this effort become part of the initiative?
A: Companies having an interest in contributing to open mobile security standards development for embedded devices are encouraged to contact Trusted Computing Group.