Mobile phone TPM/SE integration

In the context of mobile devices we have to consider that Flash-memories can not be trusted. Unauthorized access or data manipulation by third party applications is a major security threat for security-critical systems. One attempt to overcome this issue is to use secure hardware to safely store security-critical applications and data. The secure element enables such an environment, where the hardware-based implementation gives protection for unauthorized access.

In this research work we will investigate technical variants and analyze trade-offs of integrating TPM/SE functionality into current and next-generation mobile phones. As a first step, TPM/SE chips can be integrated as SIM or Micro-SD cards for compatibility with current hardware; the next step will be a tight integration of cryptographic methods and secure, tamper-resistant key storage on the actual CPUs or auxiliary processors (e.g. NFC) for better security and power efficiency and reduced number of components in a mobile device.

Expected outcome of this work is an integration of APIs for secure access and communication to the secure element in off-the-shelf mobile phones. The add-on should provide TPM (Trusted Platform Module) functionalities for security-critical applications and implement crypto protocols for secure communication. Finally, applications inside the secure element will perform as show case to our concept of an end-to-end security between hardware and user.

Goals

• API for secure access to the secure element
• Add TPM (Trusted Platform Module) functionalities
• Implementation of crypto protocols for secure communication with secure element
• Develop several secure applications inside SE
• End-to-end security

Password-authenticated secure channel

While the communication between such dedicated hardware and back-end management systems usually uses strong cryptography, the data transfer between these apps and the
dedicated hardware is often either unencrypted (and interceptable by malicious software) or encrypted with static keys stored in applications. To address this issue we presented a solution for fine-grained secure application-to-applet communication based on Secure Remote Password. By exploiting the Java Card cryptographic API and minor adaptations to the protocol, which do not affect the security, we were able to implement this scheme on Java Cards with reasonable computation time.

In an extension of this work, we were then able to implement an SRP variant that uses elliptic curve cryptogryphy (ECC). The major advantage of ECC is that smaller key sizes are required for the same security level as in non-ECC public-key cryptography, which also results into faster computation times. Compared to the discrete logarithm variant with an equivalent security level, the median protocol handshake duration could be significantly lowered (approx. 1 second less for a microSD-based SE and approx. 550 milliseconds less for a standalone JCOP 2.4.1 smart card).

For our implementation of the discrete logarithm variant, with a 2048 bit prime modulus, the complete protocol runs in less than 2 seconds for the standalone smart card and less than 4 seconds for the secure element tests. However, since the time intensive key agreement phase runs simultaneously with the password/PIN entry, the time a user actually has to wait for the verification is less than 100 ms for the standalone smart card and 400 ms for the secure element. With the elliptic curve variant of the protocol we even achieved a complete protocol run within 600 ms for the standalone smart card variant and 1700 ms for the secure element (user waiting time is below 70 and 350 ms, respectively). Finally, we also implemented an applet level implementation for the ISO/IEC 7816-4 secure messaging standard.

Secure boot

Within the context of this work package, we designed a novel concept for a certified boot process which uses the SE as trust anchor. The solution we propose enables providers of services or applications with security concerns to use a specific OS that meets their particular security requirements (we refer to this as certified OS). Creating a certified OS could mean to restrict the installation of applications, restrict network access, restrict access to hardware, etc. By allowing users to exchange the OS that can be certified, we enable services and organizations to establish restrictions concerning the software that interacts with their systems, while preserving the user’s freedom to choose – and certify – the software handling their personal information.

TPM 2.0 on Java Card

This open source project is available on GitHub and aims to implement TPM 2.0 functionality for Java Card smart cards (and specifically secure elements). It is a direct result of our research on novel secure boot processes for mobile devices, where the essential goal is to allow running applications and service providers to verify the environment they run in (OS, etc). While the TPM specification already provides these capabilities, there was no publicly available implementation for that purpose. Hence, we started an open source project to integrate these features within a Java Card applet with the goal to grow an open source community that continues on top of our implementation. At this stage, the applet supports basic functionality to support software attestation (TPM_Startup, TPM_StartAuthSession, TPM_PCR_Extend, TPM_PCR_Read, TPM_PCR_Reset, TPM_ReadPublic, TPM_GetRandom).