report / technical document

18 downloads 0 Views 1MB Size Report
secure remote updates minimizing down-times; and ... has a single owner, a single Storage Root Key and password, one Endorsement Key, and a single set of Platform ..... 8 The protocol for TPM provisioning is excluded from this specification.
RESEARCH & TECHNOLOGY Campus Polytechnique 1, avenue Augustin Fresnel 91767 Palaiseau cedex France Tel : +33 (0)1 69 41 55 00 Fax : +33 (0)1 69 41 59 69 www.thalesgroup.com

REPORT / TECHNICAL DOCUMENT

HARDWARE-ROOTED SECURITY for VIRTUALISED EMBEDDED SYSTEMS: a brief STATE OF THE ART REVIEW

OPEN GROUP / LABORATORY

GRSTI/LSEC

DOCUMENT NUMBER

REVISION

PAGE

62 441 879-179/8

draft

1/19

This document is not to be reproduced, modified, adapted, published, translated in any material form in whole or in part nor disclosed to any third party without the prior written permission of Thales ©THALES 2015 Modèle trtrapor version 2.1.0

REPORT / TECHNICAL DOCUMENT

DOCUMENT CONTROL

- : 23/11/2015 Written by

A:

B:

C:

D:

Stéphane Paul

Signature

Approved by

Philippe Bonnot

Signature

Approved by

Benoit Bruyère

Signature

Revision index

Modifications

A B C D

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

2/19

REPORT / TECHNICAL DOCUMENT

CONTENTS Pages 1.

INTRODUCTION................................................................................................................................................. 4

1.1. CONTEXT .......................................................................................................................................................... 4 1.2. PURPOSE .......................................................................................................................................................... 5 1.3. DOCUMENT STRUCTURE ............................................................................................................................... 5 2.

REFERENCED DOCUMENTS ........................................................................................................................... 6

3.

SYNTHESIS ........................................................................................................................................................ 7

4.

FULL VIRTUALISATION APPROACHES ......................................................................................................... 8

4.1. VIRTUALIZED TRUSTED PLATFORM ARCHITECTURE SPECIFICATION ................................................... 8 4.2. VIRTUAL TRUSTED PLATFORM MODULE (VTPM) ....................................................................................... 9 4.3. THE SYSGO / PIKEOS APPROACH .............................................................................................................. 11 4.4. FURTHER READING....................................................................................................................................... 12 5.

PARA-VIRTUALISATION APPROACHES ...................................................................................................... 13

5.1. PARA-VIRTUALIZED TPM SHARING............................................................................................................. 13 6.

ENHANCED HARDWARE TPM APPROACHES TO NATIVELY SUPPORT VMs ........................................ 15

6.1. HARDWARE MULTI-CONTEXT TRUSTED PLATFORM MODULE .............................................................. 15 6.2. SECURING VIRTUALISATION ON NEW EMBEDDED HYBRIDS (CORE + FPGA) ..................................... 16 7.

OTHER RELATED TECHNIQUES ................................................................................................................... 18

7.1. IMPROVING BOOT SECURITY BY USING A TPM AT BIOS LEVEL ............................................................ 18 7.2. IMPROVING BOOT SECURITY BY BYPASSING THE BIOS ........................................................................ 18

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

3/19

REPORT / TECHNICAL DOCUMENT 1.

INTRODUCTION

1.1. Context Hardware virtualization has become the state-of-the-art and efficient solution to reduce the total cost of ownership of computer systems, even in embedded systems. Hardware virtualization is the approach selected by Thales to design its interoperability Gateway. As defined in [1], a Gateway is an inter-network processor, i.e., a special-purpose processor, which aids in the interconnection of networks; the duties of a Gateway are usually much more complex than those of switches or routers. The cost benefits provided by hardware virtualization come with new security concerns, in particular in relation to mixed-criticality, comprising cases of multiple levels of security, and cases of trade-offs between safety and security concerns. The use of a hypervisor, a.k.a. a Virtual Machine Manager (VMM), based on the MILS approach is known to provide an adequate answer to data isolation, information flow control, damage limitation, and periods processing. The provision of a safe and secure interoperability Gateway, based on the PikeOS hypervisor [2], is currently central in the Thales R&D strategy for securing embedded critical systems (cf. S3P project). However, because operating system and antivirus software vendors have been hardening their code and limiting security attack vectors, malware developers have increased their attempts to attack the pre-boot environment. Malware in the firmware has direct access to hardware components and can use Virtual Machine (VM) technology to compromise a system without the knowledge of the user or detection by the operating systems. The two primary types of attacks in the firmware space are known as rootkits1 and bootkits2. Given this context, a combined hardware / software approach is required to ensure an acceptable level of security. More precisely, the combination of:  a secure boot framework, whether static, e.g. the Unified Extensible Firmware Interface (UEFI) [3], or dynamic, e.g. , including a non-writable3 Core Root of Trust for Measurement (CRTM) and Verification (CRTV);  a hardware-based Root of Trust for Storage (RTS) and Root of Trust for Reporting (RTR), such as the Trusted Platform Module (TPM) [4],  and a MILS Virtual Machine Manager (VMM), seems well suited to satisfy the new security requirements related to secure virtualised embedded systems. But, because the TPM is intended to securely link software to the underlying hardware, and because the TPM was not initially designed to be used in virtual environments4, an architecture combining both TPM and VMs is not straightforward. Combining both technologies to ensure:  a secure and measured boot of the hypervisor, its guest operating systems (OS) and secure start-up of their applications;  secure remote updates minimizing down-times; and  a virtualised access to the TPM for all running applications in the virtual machines (VMs) poses two main challenges:  challenge n°1: maintain the valuable TPM security properties (i.e. isolated execution and storage environment) whilst still enabling the TPM’s features to be shared yet isolated;  challenge n°2: allow the (cold and hot) migration a VM with its attached TPM to other physical systems.

1 Firmware rootkits inject exploit code into the system, either by patching or replacing the default firmware image. 2 Bootkits inject malicious code at the point where the firmware hands control over to the operating system, typically by modifying the operating system bootloader software. 3 According to [11], as long as the CRTM is implemented in writable firmware, ticks and fleas will mean that static root of trust for measurement (SRTM) cannot be trusted. 4 Indeed, a TPM has a single owner, a single Storage Root Key and password, one Endorsement Key, and a single set of Platform Configuration Registers (PCRs) of which some registers have been reserved for a dedicated purpose. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

4/19

REPORT / TECHNICAL DOCUMENT

Figure 1: Schematics illustrating extensions of the trusted software stack into the setting of a virtual machine [5]

These challenges have been extensively studied by both the academy and industry. As described in [5] and illustrated in Figure 1, the approaches found in the literature can be classified in three types: a) the hypervisor creates a virtual TPM (vTPM) for each guest, with guests that do not have direct access to the hardware TPM; b) the hypervisor provides para-virtualized hardware TPM access for each guest; c) the hardware TPM is enhanced to support virtual machines.

1.2. Purpose Because TRT is considering working on the measured boot (by contrast with secure boot5, which is already mastered by Sysgo [6]) and secure maintenance of PikeOs for interoperability gateways [7], this report has been written to provide:  a short academic state of the art on the subject of combining a secure boot framework, a hardware-based root of trust and a MILS virtual machine manager (as expressed above); and  the current position of PikeOs with respect to this state of the art.

1.3. Document Structure The document is structured as follows. Chapters ‎4 to ‎6 report on the main published solutions and specifications for combining both TPM and VMs. The chapters are organised according to the approach classification presented above (cf. Figure 1). Since these chapters are somehow long, a synthesis is provided in chapter ‎3. Chapter ‎7 provides complementary information on related techniques.

1.4. Prerequisites This document discusses the use of a TPM in a virtualised environment. It supposes the reader has minimal knowledge about both TPM and VMs taken individually.

5 As explained in [16], in a secure boot chain starting from the Root of Trust, each step in the boot process checks a cryptographic signature on the executable of the next step before it is launched. A signature error results in a boot abortion. In a Measured Boot chain, also starting from the Root of Trust, each step in the boot process measures the next object in the chain, and stores the hash in a way that the hashes can be securely retrieved later to find out what objects were encountered. Measured Boot does not make an implicit value judgement as to good or bad, and it does not stop the platform from running. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

5/19

REPORT / TECHNICAL DOCUMENT 2.

REFERENCED DOCUMENTS

[1] Trusted Computing Group, “TCG TPM 2.0 Automotive Thin Profile,” 2015. [2] Sysgo, “PikeOS Hypervisor,” 2014. [Online]. Available: http://www.sysgo.com/products/pikeos-rtos-andvirtualization-concept/. [Accessed 16 12 2014]. [3] R. Wilkins and B. Richardson, “UEFI Secure Boot in Modern Computer Security Solutions,” Unified Extensible Firmware Interface (UEFI) Forum, 2013. [4] Trusted Computing Group, “TPM Main Specification,” 01 03 2011. [Online]. Available: http://www.trustedcomputinggroup.org/resources/tpm_main_specification. [Accessed 23 10 2015]. [5] P. England and J. Loeser, “Para-Virtualized TPM Sharing,” in First International Conference on Trusted Computing and Trust in Information Technologies (Trust), Villach, Austria, 2008. [6] S. Tverdyshev, “PikeOS Secure Boot,” Safety And Security By Design For Interconnected Mixed-Critical Cyber-Physical Systems (SAFURE), Barcelona, 2015. [7] A. Yorulmaz, “ITEA3 Personal dAta pRotection FrAmework for IoT (PARFAIT) Project Outline,” 2015. [8] P. Sangster, L. Wilson and D. Liberty, “Virtualized Platform Architecture Specification, version 1.0,” Trusted Computing Group, 2011. [9] XenProject, “Virtual Trusted Platform Module (vTPM),” 12 10 2015. [Online]. Available: http://wiki.xenproject.org/wiki/Virtual_Trusted_Platform_Module_%28vTPM%29. [Accessed 20 11 2015]. [10] OpenStack, “Hyper-V vTPM Devices,” 19 11 2015. [Online]. Available: https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/hyper-v-vtpm-devices.html. [Accessed 20 11 2015]. [11] A.-R. Sadeghi, C. Stüble and M. Winandy, “Property-Based TPM Virtualization,” in 11th International Security Conference (ISC), Taipei, Taiwan, 2008. [12] S. Berger, R. Caceres, K. A. Goldman, R. Perez, R. Sailer and L. v. Doorn, “vTPM: Virtualizing the Trusted Platform Module,” in 15th conference on USENIX Security Symposium (USENIX-SS), Berkeley, CA, USA, 2006. [13] K. Goldman and S. Berger, “TPM Main, Part 3 IBM Commands,” IBM, 2008. [14] D. Adam, S. Tverdyshev, C. Rolfes and T. Sandmann, “Two Architecture Approaches for MILS Systems in Mobility,” in International Workshop on MILS: Architecture and Assurance for Secure Systems, Amsterdam, The Netherlands, 2015. [15] F. Stumpf and C. Eckert, “Enhancing Trusted Platform Modules with Hardware-Based Virtualization Techniques,” in Second International Conference on Emerging Security Information, Systems and Technologies (SECURWARE), Cap Esterel, 2008. [16] B. Danev, R. J. Masti, G. O. Karame and S. Capkun, “Enabling secure VM-vTPM migration in private clouds,” in 27th Annual Computer Security Applications Conference (ACSAC), New York, NY, USA, 2011. [17] M. Peinado, Y. Chen, P. England and J. Manferdelli, “NGSCB: A Trusted Open System,” in Information Security and Privacy, 9th Australasian Conference on Information Security and Privacy (ACISP), Lecture Notes in Computer Science, vol. 3108, Sydney, Springer Berlin Heidelberg, 2004, pp. 86-97. [18] P. England, B. Lampson, J. Manferdelli, M. Peinado and B. Willman, “A trusted open platform,” in Computer, vol. 36, IEEE, 2003, p. 55–62. [19] F. Bucheron, A. Tisseran and L. Rilling, “Hardware/Software Support for Securing Virtualization in Embedded Systems,” in 1st Symposium on Digital Trust in Auvergne, Clermont-Ferrand, France, 2014. [20] K.-J. Lin and C.-Y. Wang, “Using TPM to improve boot security at BIOS layer,” in International Conference on Consumer Electronics(ICCE), Las Vegas, NV, USA, 2012. [21] M. Lorenz, “TPM-based Secure Boot for embedded Hypervisors,” Technische Universität München, 2012. [22] J. Butterworth, C. Kallenberg, X. Kovah and A. Herzog, “BIOS Chronomancy: Fixing the Core Root of Trust for Measurement,” The MITRE Corporation, 2013. [23] G. Fedorkow, “What’s the Difference between Secure Boot and Measured Boot?,” Juniper Networks, 17 09 2015. [Online]. Available: http://forums.juniper.net/t5/Security-Now/What-s-the-Difference-between-SecureBoot-and-Measured-Boot/ba-p/281251. [Accessed 06 11 2015].

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

6/19

REPORT / TECHNICAL DOCUMENT 3.

SYNTHESIS

This state of the art presents three ways of sharing a Trusted Platform Module (TPM) capability between virtual machines (VMs): full virtualisation, para-virtualisation and enhanced hardware approaches. Following this state of the art, it is difficult to recommend an approach, as we could find neither performance figures, which are important for time-critical applications, nor security level evaluations. We have however summarized some pros and cons of the different approaches in Table 1. Table 1: Pros and cons of the three main approaches to TPM support for VMs

Pros

Cons

Comments

Full virtualisation approaches

 Existing specifications [8]  Available open-source implementations for TPM versions 1.2 and 2.0, e.g. [9], [10]

 Complexity of the hypervisor and the TPM implementation6, typically more than 20KLoC  Weak protection of keys during runtime  Possibly, no true random number generator (if full software)  Possibly, no damage limitation (if secrets not stored in hardware)

 Choice of Sysgo for PikeOS  Performance of computation and context switch unknown7, especially for hardwarebased vTPMs

Paravirtualisation approaches

 Contained software complexity, typically around 7KLoc  Security protection similar to original hardware TPM  No proprietary hardware design and implementation costs

 Non-standard API to TPM

 Performance of context switch unknown

Enhanced hardware TPM approaches

 Security protection identical to original TPM  API similar to native one  Minimal software complexity added to the hypervisor

 No component-off-theshelf available  Cost of proprietary hardware design and implementation  Cost of TPM upgrades



6 With the resulting probability of exploitable bugs. 7 We have not found any relevant publications with performance figures. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

7/19

REPORT / TECHNICAL DOCUMENT 4.

FULL VIRTUALISATION APPROACHES

A fully virtualised TPM (vTPM) is software that provides an interface very close to a real hardware TPM. Some fully virtualised TPM implementations rely on TPM hardware to secure their own secrets or provide trusted reporting, but other vTPM implementations are pure software. In this chapter, we present the Virtualized Trusted Platform Architecture Specification by the Trusted Computing Group (cf. §‎4.1) and two implementations, one prior and one posterior to the TCG specifications.

4.1. Virtualized Trusted Platform Architecture Specification Published in 2011 by the Trusted Computing Group (TCG), the Virtualized Trusted Platform Architecture Specification [8] provides a high-level architectural view of a virtualized trusted platform, identifying and describing each of the primary components required to support virtualized trusted platforms, whilst minimizing the number of changes to existing TCG technologies. In the context of this specification, the partitioning of a physical TPM considers sharing of a TPM, which stands in contrast to virtualizing the TPM. The sharing of a TPM by multiple virtual machines has consequences on the usage model8 of that TPM, and on how applications running inside of these virtual machines can use the TPM and its resources. As mentioned in §‎1, the two central challenges addressed by this specification are:  how to maintain the TPM’s valuable security properties (i.e. isolated execution and storage environment) while still enabling the TPM’s features to be shared;  how to handle VM migration. The standard specifies one base model, called the 3-layer architecture with privileged VM (cf. Figure 2), and some possible alterations to that architecture, which still deliver consistent reference models. The top layer of the model is where the Virtual Machines reside. The second layer of the model includes the Virtual Machine Manager (VMM), which is extended by a special privileged VM that is capable of performing more complex or risky services on behalf of the VMM. The lowest layer includes the physical hardware, i.e. CPU, memory, interface boards/chips, disks and physical Root of Trust for Storage (RTS) and a Root of Trust for Reporting (RTR) embodied in a TPM chip (pTPM), and a physical Core Root of Trust for Measurement (CRTM), typically housed in a chipset involved in booting the system (pRTM).

Figure 2: Three layer architecture with privileged VM [8] 8 The protocol for TPM provisioning is excluded from this specification. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

8/19

REPORT / TECHNICAL DOCUMENT Typical services provided by the special privileged VM are:  the Deep Attestation Service9;  a Migration Controller, for performing authorized management operations for the VMs such as a migration or shutdown request. In addition to providing the usual virtualization services that enable the VMs to execute in isolated environments, the VMM provides each VM with services such as Virtual Trusted Platform Module (vTPM) and Virtual Root of Trust for Measurement (vRTM) Virtual trusted Platform (vPlatform) services. Within the VMM, the vPlatform Manager is responsible for the creation, instantiation (if migrated or restarted), removal, clean-up and management of the virtual platforms associated with each VM, in support of the services defined in the special privileged VM. A first variation of the above model is the 3-layer architecture without privileged VM (i.e. monolithic approach). st A second variation consists in nested virtualisation, i.e. a VMM running as guest OS of the 1 VMM (i.e. 4layered architecture). Both variations offer the same core features. The challenges posed by these architectures that are particularly important for Thales are:  protecting vTPM storage10 during runtime, including when the VMM layer is corrupted;  ensuring the survival of persistent TPM data, whilst ensuring the resetting of non-persistent TPM data, through power events and VM reboots;  securing and storing vTPM non-volatile state on persistent storage when the VM is quiesced or shutdown;  deleting a vTPM instance state when a VM is removed or migrated to another system;  allowing remote attestation using a standard attestation protocol, whilst still informing the challenger that the machine is running on a virtual trusted platform and allowing the challenger to challenge layer N-1; this challenge must include verifiable evidence that the VM’s attestation is from the same physical platform as the N-1 (VMM) attestation, and is particularly complex when it covers the VM migration case;  allowing vTPM migration, whilst  disallowing vTPM instance duplication,  allowing relying parties to attest the destination platform after the migration,  managing the impacts on credentials. The TCG specifications document also lists other challenges, which can be considered less important for Thales businesses:  allowing field updates of a vTPM, whilst correctly managing the stale certificates related to the Endorsement Key (EK) and Attestation Identity Keys (AIKs);  supporting simultaneously multiple versions of vTPMs, and this independently from the physical TPM (pTPM);  backing-up and restoring vTPMs. The TCG’s Virtualized Trusted Platform Architecture Specification then proceeds with a set of detailed requirements for the architecture components, attestation components, migration components: this represents an excellent requirements baseline when implementing a virtualised TPM. The document also provides a list of threats & countermeasures that are specific to vTPM, thus allowing for some form of security assessment of the vTPM implementation.

4.2. Virtual Trusted Platform Module (vTPM) In 2006, Berger et al. [12] of IBM proposed the Virtual Trusted Platform Module (vTPM), a full TPM specification in software, and added functions to create and destroy vTPM instances. The authors integrated their softwareTPM into a hypervisor environment to make TPM functions available to Virtual Machines (VMs); the association

9 The concept of iteratively attesting each individual lower virtualization layer in order to establish the trustworthiness of a VM (and its underlying trusted platforms) is known as a Deep Attestation. 10 This may obviously be done by sealing, if performance is not an issue. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

9/19

REPORT / TECHNICAL DOCUMENT is made possible by having the vTPM driver prepend a 4-byte vTPM instance identifier to each packet carrying a TPM command (cf. Figure 3, which shows two variants of the architecture).

Figure 3: Two vTPM architecture variants [12]

The virtual TPM supports suspend and resume operations, as well as the migration of a virtual TPM instance, with its respective virtual machine, across platforms. To support migration, the authors introduced the concept of a privileged vTPM instance, which can spawn and manage child vTPM instances, and which uses the virtual TPM’s ability to migrate keys to another virtual TPM to exchange encrypted data between virtual TPMs. Additionally, the vTPM’s command set is extended, and each vTPM has its own Endorsement Key (EK) and Storage Root Key (SRK). The detailed vTPM migration protocol is provided, involving the use of a nonce to prevent a vTPM from being migrated to multiple destinations.

Figure 4: Mapping of Virtual TPM PCRs to Hardware TPM PCRs [12]

To allow a challenger to establish trust in an environment that consists of more than the content of the virtual machine, the lower set of PCR registers of a vTPM show the values of the hardware TPM and the upper ones reflect the values specific to that vTPM (cf. Figure 4). Finally, the authors present four designs for chaining certificates, and discuss their merits with respect to vTPM migration. Proof of the overall vTPM concept was demonstrated by layering an existing integrity measurement application on top of a vTPM facility. For interested readers, detailed specifications of IBM vTPM hardware commands are available in [13]. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

10/19

REPORT / TECHNICAL DOCUMENT 4.3. The Sysgo / PikeOS approach In 2015, Adam and al. [14] presented two architecture approaches for MILS systems, of which one is based on a TPM emulator (cf. Figure 5). Here the TPM emulator is implemented on a LEON3 softcore (FPGA), whilst the applications run on an i.MX6 quad processor. The HSM acts as an Inter-Integrated Circuit (I2C) slave, whilst the multicore application processor acts as I2C master. Through its Virtual Machine Manager (VMM), which performs the secure TPM context switching and scheduling, the HSM is capable of handling multiple 11 contexts. The TPM context data for every specific virtual machine is stored in an external embedded flash memory. The TPM emulator makes use of a hardware accelerator for True Random Number Generation (TRNG); all other cryptographic modules and the VMM are implemented in firmware.

Figure 5: Detailed architecture [14]

In addition to the VMM implemented on the softcore, the proposed solution includes a partition running on the i.MX board for the multi-context TPM driver. This partition holds the VM ID table 12. The driver is the mandatory interface between the application partitions and the multi-context TPM for all TPM commands. It is responsible for framing the multi-context commands. Communication is ensured through inter-process communication and shared memory. A central issue raised by the authors is related to the performance of the context switch. With respect to the Virtualized Trusted Platform Architecture Specification [8] of the TCG (see above), this architecture conforms to the 3-layer architecture with privileged VM. By contrast with Berger et al. [12], this

11 Up to six in this implementation. 12 The VM ID table is normally part of the (PikeOS) hypervisor. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

11/19

REPORT / TECHNICAL DOCUMENT paper does not discuss migration, deep attestation, and other important details, such as the TPM provisioning (incl. EK establishment).

4.4. Further reading Sadeghi et al. [11] proposes an alternative, property-based, approach for measuring the platform's state, as well as other vTPM improvements to facilitate deployment and migration of vTPMs. In short, instead of attesting hash values of binaries, the authors propose that the PCRs attest abstract properties describing the behaviour of a program or system. When a PCR of the TPM is going to be extended with a measurement value, a translation function looks for a matching certificate, and extends the vPCR with the a bit string representation of the corresponding property. The advantage is that properties can remain the same even if the binaries change. The overall orchestration is defined by user-defined vTPM policies, allowing for flexibility and specific behaviours per individual vTPM. The authors also propose a “trusted channel” procedure to improve the migration of vTPM with respect to the approach proposed by Berger et al. [12]. Boris Danev et al. [16] consider the problem of enabling secure migration of vTPM-based virtual machines in private clouds. Virtual TPM implementation support for Xen and Microsoft Hyper-V Server can be found respectively in [9] and [10].

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

12/19

REPORT / TECHNICAL DOCUMENT 5.

PARA-VIRTUALISATION APPROACHES

Para-virtualised TPMs mediate guest accesses by a software component that enables safe and fair hardware device sharing. We have found only one paper related to para-virtualisation.

5.1. Para-Virtualised TPM Sharing In 2008, England and al. [5] presented a typology of approaches to combine TPM capabilities and virtual machines. The authors claimed that the para-virtualisation approach, even though it has some limitations, provides the best compromise in terms of cost and security, between full virtualisation and full hardware implementations. In particular, with this approach, the additional code is limited (i.e. 7 KLoC), and can thus be safely included directly into the hypervisor.

Figure 6: TPM Support in the Hypervisor [5]

The paper discusses para-virtualisation for each of the TPM resources that need to be shared or virtualised, i.e.:          

Platform Configuration Registers (PCRs); The TPM owner; The Endorsement Key (EK); The Storage Root Key (SRK); Other keys in protected storage; Monotonic counters; The delegation table; Authorization and transport sessions; Non-volatile storage; The random number generator. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

13/19

REPORT / TECHNICAL DOCUMENT

Figure 7: vPCR support example inside the hypervisor [5]

According to the authors, all TPM resources, except the PCRs, can be safely multiplexed or partitioned without significant loss of capability. Thus, the proposed architecture is the one shown in Figure 6, in which the paravirtualisation of the PCRs represents the main difficulty of the approach. In short, the approach proposed for the PCRs is to define virtual PCRs (vPCRs) that are mapped to resettable hardware PCRs, as illustrated in Figure 7. This approach is interesting in that it even allows for recursive vPCR virtualisation.

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

14/19

REPORT / TECHNICAL DOCUMENT 6.

ENHANCED HARDWARE TPM APPROACHES TO NATIVELY SUPPORT VMs

Enhanced hardware TPMs provide separate contexts for each virtual machine. To provide TPM access to an unlimited number of guests, the hypervisor transparently load and save the guest contexts. This chapter presents two such approaches.

6.1. Hardware Multi-Context Trusted Platform Module In 2008, Stumpf et al. [15] of the Tech. Univ. of Darmstadt, recalled that:  Microsoft’s Next-Generation Secure Computing Base (NGSCB13) [17] [18] provides only one TPMenhanced virtual machine (VM), and is thus inapplicable when there is a need for multiple secure VMs;  IBM’s virtual Trusted Platform Module (vTPM) [12], which provides an emulated TPM that uses the underlying hardware TPM only for some operations, cannot provide the same protection as hardware, especially when evaluated against the Common Criteria. To overcome these issues, the authors proposed14 a multi-context TPM that is completely realized in hardware, whose requirements were: to ensure equivalent security and performance as standard TPMs, instruction compatibility with standard TPMs, simplicity of the Virtual Machine Monitor (VMM), and minimal design modifications with respect to the standard TCG specifications for the TPM.

Figure 8: Layout of a multi-context TPM [15]

The multi-context TPM operates on a Control Structure that encapsulates all the information needed to capture the state of a TPM or to resume a TPM (cf. Figure 8). A VMM is responsible for providing an abstract interface to the underlying hardware TPM, for isolating the different TPM instances, for scheduling operations and for mapping each VM to its specific TPM context. If a VM wants to issue a command to the hardware TPM, the VMM loads the corresponding TPM Control Structure (TPMCS) into the TPM (if not already loaded) and the TPM then operates on this structure (cf. Figure 9). This approach enables the direct execution of the TPM instructions from a VM on a TPM. To provide a hardware protection mechanism, the authors introduced another privilege level to the TPM. A virtual machine runs in a lower TPM privilege level and thus can only operate on its own TPMCS. Operations on other TPMCSs can only be done by management commands issued by a VMM. The issuing of such a command by the VM is intercepted and thus results in a controlled context switch to the VMM. The transition of the TPM contexts is synchronized with the transitions between the different modes of execution on the Intel VTX/I architecture, in order to support direct native execution on the TPM. To ensure consistency between all the VMs, the tick counter and the PCRs [0..15], which hold the data from the bootstrap procedure and the VMM’s integrity, are stored in a special region of the TPM. Every VM is able to read the values stored in these registers. 13 This technology is not detailed herein, as it does not address embedded systems, but a mass-market operating system (namely Ms. Windows) running on the desktop. 14 In 2008, the implementation had not yet been realised. To date, we have not found further publications by the same authors showing the results of the implementation. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

15/19

REPORT / TECHNICAL DOCUMENT

Figure 9: Transition between different TPM contexts

To realize the management features of the TPM, the authors extended the TCG specification with a number of additional TPM commands. The TPM also supports a number of instructions that allow a TPM context of being migrated to another TPM, with a mechanism that prevents a TPMCS from being migrated to multiple contexts or an old TPMCS’s from being replayed into the system. With respect to credentials, a certificate chain is established with the Endorsement Key (EK) which is held in the root-TPM structure as a root node. For every TPM context, the TPM generates its own EK, which then becomes certified by the root EK.

6.2. Securing Virtualisation on New Embedded Hybrids (core + FPGA) In 2014, Bucheron et al. [19] provided an overview of the threats on SoCs and hypervisors in general, and virtualised trusted computing approaches in particular. Notable highlights included the following:  ARM Trustzone vulnerabilities were published at Hack In Paris in 2013 and Black Hat USA in 2014;  when one codes an application in the ARM TrustZone, one must send the package to the motherboard provider to be signed for it to be installed at boot, so, in other words, the keys are lawfully given away15;  in some TPM implementations, communication channels (buses) between TPM, RAM and microprocessor are unprotected. Based on the aforementioned analysis, the authors asserted that, to counter side-channel attacks on virtualised embedded systems, the only viable solution requires a combined hardware / software approach. The authors proposed a trusted virtualised architecture based on:  a Zynq-7000 platform, i.e. ARM Cortex-A9 dual-core processor and an Artix-7 FPGA,  a minimal set of Hardware Intellectual Properties (HW IPs),  EmbeddedXen, a derived version of the Xen hypervisor. The overall proposed architecture is given in Figure 10, in which the TCG Software Stack (TSS) has some of its parts split between multiple partitions, to avoid the enlargement of the Trusted Computing Base (TCB) and avoid compromising the management VM (Dom0). The DomT VM manages the demand/response to/from the TPM. It provides services like checking the validity of a command, avoiding Denial of Service (DoS) attacks, software attestation of the source, adding a predefined ID of the callling VM to the command, etc. The DomT VM implements two distinct parts: one in kernel mode, called TCG Device Driver (TDD), and one in user-mode, called TCG Core Services (TCS). The TDD is the only link between the TPM and the rest of the platform. In the other VMs, the TCG Service Provider (TSP) is the only access point for TPM/vTPM requests. The paper discusses each IP, in particular the TPM / vTPM FPGA implementation.

15 Obviously, when Thales is the motherboard provider, this obligation is not an issue for Thales. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

16/19

REPORT / TECHNICAL DOCUMENT

Figure 10: Overview of the proposed solution [19]

The proposed approach rests upon a classical measured boot process (cf. Figure 11), however, the selected Zynq-7000 board does not offer the possibility to modify its BIOS to make a Core Root of Trust for Measurement (CRTM). Thus, due to implementation constraints, the CRTM is the Zynq-7000 stage 0 (i.e. the BIOS), and the proposed approach really starts with the Zynq-7000 First Stage Boot Loader (FSBL).

Figure 11: Measured boot: measuring, launching, reporting [19]

PCR and key management is similar to the management proposed in [12]. And similarly to [12], implementation is said to be on going. However, we have not been able to access more recent publications providing new insights into the progress made with respect to the challenges raised in conclusion of the paper, i.e. system latencies and size of the hardware IPs.

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

17/19

REPORT / TECHNICAL DOCUMENT 7.

OTHER RELATED TECHNIQUES

The following publications do not directly relate to the combination of a hardware-based root of trust and virtual machines for embedded systems. However, they offer approaches that can also be used in that context, so we have thought useful to annex them to the above state of the art.

7.1. Improving boot security by using a TPM at BIOS level Because a TPM does not prohibit booting into an insecure OS or using an insecure boot loader, Lin et al. [20] propose two techniques to improve the boot security by exploiting the TPM at BIOS level:  firstly, the BIOS always executes BIOS-password authentication before reading the Master Boot Record (MBR), cf. Figure 12; if no such pre-boot authentication is performed, an attacker can use function key F7 to change the boot priority sequence to run an insecure OS in some device;

Figure 12: Pre-boot authentication flow using the extended BIOS interrupt calls (left) and secure boot sequence before passing control to the OS boot-loader (right) [20]

 secondly, before passing control to the OS boot-loader, the integrity of the full MBR using the TMP Hashing function is verified; the correct digest is stored in the TPM NVRAM; if the MBR is altered, the boot process is stopped, cf. Figure 12. To support these two techniques, the TPM BIOS interrupt calls need to be extended to allow:  performing RSA encryption and decryption, and  accessing the NVRAM. Furthermore, the following techniques were implemented in the BIOS to improve boot security: (1) enhancing the security of the encrypted BIOS password using TPM RSA engine instead of conventional encryption techniques, (2) storing the encrypted password to TPM NVRAM such that an attacker cannot clear it by removing the battery, (3) always authenticating BIOS password before passing control to OS boot-loader and (4) using TPM SHA-1 engine to verify data integrity of the full MBR and determine if the booting continues.

7.2. Improving boot security by bypassing the BIOS Under the hypothesis that a platform’s BIOS cannot be easily modified (contrary to the hypothesis made in [20] above), Lorenz [21] uses the vulnerability related to the Beagleboard’s capability of booting on various devices to force boot on a Write Once Read Many (WORM) Secure Digital (SD) card, accessed through the Multimedia Card (MMC) adapter. Assuming that hardware attacks are not feasible 16, this allows for the use of a proprietary trusted boot loader. The next steps are simply compliant to the Trusted Computing (TC) approach to secure 16 Or else, the boot sequence can be modified. OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

18/19

REPORT / TECHNICAL DOCUMENT boot using a TPM (cf. Figure 13): the Core Root of Trust for Measurement (CRTM) measures the following binary (i.e. the U-Boot), extends the measured value into the TPM's PCR, loads the reference value from local storage and checks if those values match; if the values equal, integrity of the measured binary is assured and the binary can be executed; this process continues accordingly with the next pieces of binary code. Ultimately, the secure boot allows booting only into known platform configurations.

Figure 13: Secure boot normal operations [21]

In addition, the report describes the initialisation routines and the process for software updates.

OPEN

Research & Technology

62 441 879-179/8 ©THALES 2015

Modèle trtrapor version 2.1.0

-

19/19