Trusted computing technologies

6.8Trusted computing technologies

6.8.1Background

Trusted computing technologies as defined by the Trusted Computing Group (TCG) [1] are slowly starting to become adopted within the IT and telecommunication industry. Trusted computing technologies are built around the usage of a dedicated hardware module, the Trusted Platform Module (TPM) [2], supported by the majority of laptops on the market. It is also starting to be a standard component on almost all x86 platforms. On the embedded side, TPM usage is still limited, but has great potential as an important SPD enabler.

The TPM allows a user to securely create and store secrets, identify itself towards external parties and to report platform configuration status etc. The TCG architecture encompasses several computing platform of different types and the TPM can be used to serve an end-user, IT infrastructure or platform manager security needs. In particular, according to the TCG architecture, the TPM can be used to assist in a so-called authenticated boot. In an authenticated boot process, a platforms state (the sum of its components) is reliably measured and stored, i.e., it is possible at a later point in time (after the boot occurred) to reliable verify the platform software configuration status. This slightly differs from a secure boot process and for managed platforms an authenticated boot is often not enough, but a secure boot process is actually required. Consequently, the TCG mobile phone working group has specified a modified version of the TPM called Mobile Trusted Module (MTM) [3]. Different from the TPM, the MTM and related specifications from the TCG mobile phone working groups defines mechanisms, formats and processes for secure boot. However, the MTM has not to any extent been adopted by the mobile industry and it is not an alternative for most platforms with TPM. An interesting issue then is to study is how well a standard TPM component can be used to implement a secure boot process for a managed nSHEILD platform. We have chosen to look into this issue and will design a secure boot process that only is built upon TPM compliant commands.

Secure boot and trusted boot are not exclusive boot features. The same platform can be configured to support both principles. In nSHIELD we will mainly focus on the secure boot process, but we briefly also discussed how secure and trusted boot can co-exist and be configured on the same platform.

In addition to support trusted/secure boot, the TPM is a hardware unit that supports secure identification, signing for non-repudiation, protection of secrets through the TPM “sealing” functionality and remote attestation. Hence, the TPM is a potential very powerful hardware unit which potentially can provide many of the requested nSHIELD SPD functions.

As part of task T3.5 we will investigate the applicability of TPM both as a cryptographic hardware enabler for secure boot as well as cryptographic module service provider.

6.8.2Attacks against TPM protected platforms

Considering the security of TPM when attacker has full access to the chip requires careful analysis of the threats which could arise due to the vulnerabilities of the chip design permitting hardware attacks. One such successful attack was recently reported by a security researcher Christopher Tarnovsky at the Black Hat conference. He subverted an Infineon SLE 66 microcontroller—a hardware component that implements the TPM specification. The SLE 66 is designed to protect against EM snooping, various kinds of side channel attacks, and pretty much any other conventional approach that one can think of [4]. The standpoint of the Trusted Computing Group on this has been that ―they have never claimed that a physical attack — given enough time, specialized equipment, know-how and money — was impossible [5].

Furthermore, there are other possible attacks which could be performed if the attacker has physical access of the nSHIELD node containing TPM. One such attack is the TPM reset attack [6][7] in which TPM is sent hardware reset by using the ground driven reset line of the Low Pin Count (LPC) bus. Such a reset initializes all Platform Configuration Register (PCR) values to zero and then the attacker can load malicious code before setting the trusted configuration in the PCR registers again. The remote verifier cannot identify the malicious code because it is not reported in the PCR. The author in [6] also point out the theoretical possibility of TPM timing attack.

This clearly implies that for an nSHIELD node with TPM as trust anchor, some considerations must be taken to achieve the desired level of security. For example, the microcontroller chip itself should have defences against physical attacks. Furthermore, other measures can also be taken to build trust in the TPM chip. These may include TPM certification to meet TCG specifications and certified to at least an augmented EAL 4 (Evaluation Assurance Level) against the international Common Criteria certification standards [8].

6.8.3Scenario for secure boot

In Task 3.1-3.3 we will make a boot design from a life cycle perspective, i.e., we will base our design taking into account the different phases that a typical IT product goes through during the lifetime of the product. When doing the design and analysis we will assume as generic product as possible although we recognize that not all life cycle phases are relevant for all types of products. The product phases we consider are:

• 
  Product hardware manufacture
  
• 
  Product configuration/customization
  
• 
  Product first time deployment
  
• 
  Product operation
  
• 
  Product software upgrade
  
• 
  Product recovery at major software failure
  

Some products also are subject to hardware upgrade. However, we will mainly focus on software upgrade and the connection to a secure boot based on TPM functionality.

The working assumption is that we will base the secure boot design using the TPM. Hence, the boot design will need to be closely aligned with the hardware design and the TPM usage and we expect a close co-operation between T3.5 and the node design task in this regard. In particular, the TPM interface requirements will be considered and also how exactly to use the TPM API to support the secure boot and secure software maintenance on the nodes.

6.8.4Scenario for TPM as cryptographic module

Current embedded systems typically do not have TPM support even if the previous mentioned MTM that was developed by TCG for the mobile market. The reason is that the adoption of the specification in the mobile industry has been very slow. As consequence, TCG recently formed the Trusted Mobility Solutions working group [9]. We share the main scenario with this working group, i.e.;

• 
  With the growing usage of networked embedded system there is a need for enhanced protection of these devices as well as controlling their access to networks
  
• 
  There is a large potential in using TPM/MTM functionality to protect device identity and device integrity
  
• 
  TPM/MTM can be used to provide secure storage on nSHIELD nodes.
  
• 
  TPM/MTM can function as an enabler for robust access control and application/data protection mechanisms to enable trusted connections to sensitive nSHIELD application systems
  

6.8.5nSHIELD technology challenges

As there is a lack of broad support for TPM in current embedded system, we will work with practical solutions to securely interface TPM modules on major embedded architectures such as ARM based systems. Carful, analysis with respect to the design of hardware interfaces must be done.

In order to provide a secure boot rooted in TPM functionality, we need to make sure that the product always is booted into a secure state with the correct software images. The goal with the design we provide is to give such guarantees while still allowing enough flexibility in terms of software upgrade and recovery. The ultimate goal is to provide a secure boot design that relies on already available standard TPM cryptographic primitives.

The nSHIELD security requirements will be carefully analysed and the feasibility of using TPM functionality to meet the requirements with respect to identification, authentication and protected storage will be evaluated. We will contribute to the nSHIELD SPD architecture framework with respect to the TPM-functionality.

Directory: images
images -> Pelan pentaksiran kursus
images -> Military callsign list as of dec 2010
images -> For Date: 02/01/2013 Friday Call Number Time Call Reason Action 13-768 0008 motor vehicle stop warning Issued
images -> Creating Buy-In – Building Relationships
images -> Deadline: Saturday, March 12th, 2016
images -> News items from Raising Our Voices
images -> Last year four of the best Afrikaans Christian singers joined forces to tour Down Under with the production ‘Manne wat Glo’
images -> World-renowned vocal ensemble sweet honey in the rock
images -> Peoples Voice Café History
images -> Simon Mckeown Artist C. V. DaDaFest International Artist of the Year 2010

Download 1.14 Mb.

Share with your friends: