trusted computing functionalities based on tpm · trusted computing functionalities based on tpm...
TRANSCRIPT
Lecture Embedded System Security
Trusted Computing Functionalities based on TPM
Prof. Dr.-Ing. Ahmad-Reza Sadeghi
System Security Lab
Technische Universität Darmstadt (CASED)
Germany
Summer Term 2013
1
SYSTEM SECURITY LAB Slide Nr. 2, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Authenticated boot
Binding and sealing
Integrity reporting / attestation
Roadmap: TC Functionalities
Bootstrap Architecture on PC
execution sequence
boot loader provides a link between hardware and operating system
Hardware
Application Application Application
CPU
BIOS
Boot Loader
Operating System
Bootstrap and Integrity Measurement
PC-Hardware
Trusted components
PCR[0]
PCR[1]
…
PCR[14]
PCR[15]
CRTM measures BIOS
BIOS measures BL
BL measures OS
OS measures Applications
mBIOS
mBL
mOS
mApp
Measurement
Execution
Application
Operating System (OS)
CPU
Boot Loader (BL)
CRTM
BIOS Ch
ain
of
Tru
st
Trusted Channel
CRTM Core Root of Trust for Measurement TPM Trusted Platform Module
Remote Party
TPM
SYSTEM SECURITY LAB Slide Nr. 6, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Authenticated boot
Binding and sealing
Integrity reporting / attestation
Direct anonymous attestation
Some background information
The DAA protocols
Case study: IBM Integrity Measurement Architecture
Roadmap: TC Functionalities
SYSTEM SECURITY LAB Slide Nr. 7, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Conventional asymmetric encryption
May be used to bind data to a specific TPM/platform
Data encrypted with non-migratable binding key can only be recovered by TPM that knows corresponding secret (un)binding key
Usually no platform binding
Since binding can also be used with migratable keys
No interaction with TPM required
Encryption can be done outside the TPM
Binding
SYSTEM SECURITY LAB Slide Nr. 8, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Always binds data to a specific TPM/platform
Sealing can only be used with non-migratable storage keys
Configuration of encrypting platform can be verified
Ciphertext includes platform’s state at the time of encryption
May bind data to a specific platform configuration
Data can be decrypted only if platform is in a pre-defined (probably trusted) state
Sealing
SYSTEM SECURITY LAB Slide Nr. 14, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Authenticated boot
Binding and sealing
Integrity reporting / attestation
Roadmap: TC Functionalities
SYSTEM SECURITY LAB Slide Nr. 15, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Attestation
Authentic report of a platform’s state to a (remote) verifier Local or remote verifier (challenger) is interested in
platform configuration (e.g., hard- and software environment)
Verifier is able to decide whether it trusts the attested configuration E.g., an online-banking client checks whether the bank’s server is
in a known secure configuration (e.g., has not been tampered with)
TPM and CRTM act as Root of Trust for Reporting (RTR) TPM can generate authentic reports of current integrity
measurement values (current PCR content)
SYSTEM SECURITY LAB Slide Nr. 16, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Requirements on Attestation
Attestation must include the states of all entities (machines) capable of affecting the behavior of the entity being attested
E.g., hard- and software environment of the attesting platform including history of all executed program code
Attestation vector (platform’s state report)
Integrity, confidentiality, freshness
Authenticity of attestor
Privacy
Minimal/zero information disclosure on system configuration and platform identity
Simplified TCG Attestation Concept
NV σTPM
Attestor (TPM)
AIK ← genkey(l)
σTPM ← signAIK( NV , m )
Trusted Platform Verifier V • Local or remote • Interested in configuration CH of host H • Decides whether CH is trustworthy (e.g., does not violate V’s security requirements)
Verify σTPM
Host H • Has configuration CH
• RTR authentically reports CH to TPM
NV
σTPM
NV Nonce (anti-replay value) chosen by the verifier CH current configuration of host H
m ← Hash( CH )
Configuration List • List of trusted configurations
… , ( m , CH ) , …
PCRs:
More Details about TCG Attestation
Attestor (TPM)
Trusted Platform Verifier V
Attestation System Service
PCR[ ]
Request( SPCR , Iver , NV )
TPM_Quote( hAIK , AAIK , SPCR , Iver , NV )
PCR[ SPCR ] , verTPM , σTPM
σTPM ← signAIK( PCR[ SPCR ] , verTPM , NV)
verTPM , σTPM , log , certAIK certAIK
• Verify cred
• Verify σTPM using verTPM and by re-computing PCR[ SPCR ] from log
• Decide whether the events listed in log violate V’s security requirements
SPCR Selection of PCR values V is interested in Iver Indicator whether V is interested in TPM version information NV Nonce (anti-replay value) chosen by the verifier hAIK Pointer (handle) to the AIK to be used AAIK Authentication secret required to use AIK
verTPM TPM version information
certAIK Attestation Credential (e.g., from Privacy CA) log TPM Event Log
Attestation using Privacy CA
TPM Owner
• Prove to third parties that it’s platform is in a trustable state • E.g., by reporting platform
integrity measurements signed with a certified key
• Colluding third parties should not be able to track platform’s transactions • E.g., by signing every integrity
measurement report with a (ideally) different AIK for each transaction
Privacy CA
• Trusted Third Party
• Attests that an AIK belongs to a valid TPM (Attestation Credential) • Protocol for certification of an
AIK requires disclosure of public EK to Privacy CA
• Must be trusted not to reveal any information that might enable correlation of AIKs with the corresponding platform identity (EK)
AIK Creation with Privacy CA I
1. AO , ASRK , AAIK , Tspi_TPM_CollateIdentityRequest(
idAIK , parAIK , idCA , pkCA , parCA )
2. TPM_MakeIdentity( AO , ASRK , AAIK , parAIK , hash( idAIK , pkCA ) ) 3. AIK , σAIK
4. parCA , encCA( respTSS )
1. Verify that parAIK is conform to TPM Spec. 2. Create AIK according to parAIK
3. Compute σAIK ← signAIK( hash( idAIK , pkCA ) )
5. parCA , encCA( respTSS )
TPM Owner
1. Collect all credentials cred • Endorsement Credential • Platform Credential • Conformance Credential
2. respTSS = ( pkAIK , idAIK , σAIK , cred )
1. Parse TPM command
Privacy CA
TPM
TSS
AO Authentication secret required to create a new AIK ASRK Authentication data required to use the SRK AAIK Authentication data required for using the new AIK idAIK Identity label (e.g., name) for new AIK AIK Key object storing the (public and private) AIK
parAIK Parameters for the new AIK (e.g., key size and type) idCA Identity label (e.g., name) of the Privacy CA parCA Parameters for encrypted communication with CA pkCA Public verification key of the Privacy CA
AIK Creation with Privacy CA II
TPM Owner Privacy CA
TPM
TSS
parAIK Parameters for the new AIK (e.g., key size and type) idCA Identity label (e.g., name) of the Privacy CA parCA Parameters for encrypted communication with CA pkCA Public verification key of the Privacy CA
1. Verify cred
2. Verify σAIK
3. If o.k. issue digital certificate certAIK
4. Create symmetric encryption key K
5. respCA ← encpkEK( K , hash( pkAIK ) )
5. respCA , encK( certAIK )
6. AO , AAIK , Tspi_TPM_ActivateIdentity(
AIK , respCA , encK( certAIK ) )
7. TPM_ActivateIdentity( AO , AAIK , AIK , respCA )
1. Parse TPM command
1. Decrypt respCA using private EK 2. Verify decrypted hash( pkAIK ) 3. If o.k., return K
6. K
1. Decrypt encK( certAIK ) using K
7. certAIK
Only the claimed valid TPM is able to
recover K
AO Authentication secret required to create a new AIK ASRK Authentication data required to use the SRK AAIK Authentication data required for using the new AIK idAIK Identity label (e.g., name) for new AIK AIK Key object storing the (public and private) AIK
SYSTEM SECURITY LAB Slide Nr. 24, Lecture Embedded System Security, SS 2013 A.-R. Sadeghi ©TU Darmstadt, 2007-2013 Trusted Computing Functionalities
Problems of Attestation with Privacy CA
No anonymity
Collusion of Privacy CAs and verifiers enables tracking of platforms
Availability
Certification of AIKs requires interaction with Privacy CA
A TPM may have a large number of AIKs Worst case: One for each connection
Privacy CA may encounter heavy load serving certification requests of a huge number of TPMs
Solution: Direct Anonymous Attestation (DAA)
Lecture Embedded System Security
Prof. Dr.-Ing. Ahmad-Reza Sadeghi
System Security Lab
Technische Universität Darmstadt (CASED)
Germany
Summer Term 2012
38
Mobile Trusted Platform
Slide Nr. 39, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Motivation
Mobile Trusted Platform
Implementation examples
Overview
Chapter 5: Mobile Trusted Platform
Slide Nr. 40, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Motivation
Mobile Trusted Platform
Implementation examples
Overview
Slide Nr. 41, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Protection of platform integrity
Proof of platform and/or application integrity
Secure device authentication
User data protection and privacy
Secure software download/update
SIMLock/device personalization (branding)
Secure channel between device and UICC (SIM card)
Trusted mobile ticketing/payment
…
Why is Mobile TC Important?
Slide Nr. 42, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
1. “Traditional” threats: Based on software-based attacks, e.g. malware
2. New threats for mobile devices: Attacker with physical access to the device, e.g.
Attacker tries to extract credentials from a stolen device
User wants to break a DRM mechanism on or jailbreak his mobile phone
Threat Classification
Slide Nr. 43, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Electronic ticket seen as “access token” by provider for an event or usage of a resource
Case 1: Token stored on provider’s server
Requires strong authentication of user/platform
Case 2: Token stored on mobile platform
Authenticity, freshness and integrity of token have to be ensured. Possible threats: User or rogue SW might try replay/duplicate ticket
Man-in-the-middle attack to use another user’s ticket
Rogue provider sends invalid ticket, but charges user
Selected Use Case 1: Mobile Ticketing
Slide Nr. 44, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Personal (or professional) data stored on mobile platform
Confidentiality and integrity of the data has to be protected against illegitimate users or malware
Mobile platform used to access protected intranets
Trustworthiness of mobile platform has to be ensured upon access to protect the network
Plethora of applications make use of services
User’s privacy must be protected against linkage of those performed actions
Selected Use Case 2: User Data Protection and Privacy
Slide Nr. 45, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Motivation
Mobile Trusted Platform
Implementation examples
Overview
Slide Nr. 46, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Architecturally a TPM v1.2 with modifications for mobile use cases:
Adapted command set consisting of a subset of TPM commands and new MTM-specific commands
Two interleaving MTM profiles depending on the owner entity (remote owner/local owner)
Support for several parallel software-based MTMs on one platform, each with a different owner
Definition of requirements for the MTM resources (“Roots-of-Trust”) to guarantee the required trustworthiness
Introduction of Remote Integrity Metrics (RIM) to define approved platform states and to verify these states
Specification of Secure Boot to enforce boot into a trusted platform state (based on RIM)
Mobile Trusted Module in a Nutshell
Slide Nr. 47, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Generalizes “Trusted Platform” to mean a set of conventional, isolated TCG-enabled platforms, denoted “Trusted Engines”
MTM Reference Architecture
Service Provider 1 Engine
Communication Carrier Engine
Service Provider 2 Engine
User Engine
Device Manufacturer Engine
Applications
Network access
Device services
Slide Nr. 48, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Each engine has a separate owner, called “stakeholder”
Engines have some protected capabilities of the TPM
specifications (e.g., remote attestation) and provide
protected storage
Each engine is classified as mandatory or discretionary based
on the services its implements
Engines consume/export services of/to other engines
Engines use trusted or measured resources provided by the
HW or other engines, which can be dedicated or allocated
Trusted Engine
Slide Nr. 49, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Users Physically present (local)
Store their personal/professional data in the platform
Service Providers Physically absent (remote)
E.g., corporate services, content distribution, or address book
Communication Carriers Remote
Specialist service provider for cellular radio access
Device Manufacturer Remote
Single provider of all hardware resources and internal communication within the platform
Trusted Engine: Principle Stakeholders
Slide Nr. 50, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Mobile Remote owner Trusted Module (MRTM)
Owner has no physical access to platform after shipping/deployment
Local operators cannot remove the remote owner
Requires secure boot to ensure integrity of MRTM (e.g., prevent tampering by a local attacker)
EK optional, if at least one AIK plus corresponding credentials are deployed
Mobile Local owner Trusted Module (MLTM)
Owner has physical access (most likely the user)
Permits removal of owner (same as TPM)
Does not require secure boot
Trusted Engine: MTM Profiles
Slide Nr. 51, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Mandatory engines
Always resident in a platform
Must be supported by MRTM
Particularly useful for remote stakeholders
Provide critical and indispensable services, including those subject to regulatory enforcement
Discretionary engines
May or may not be resident in a platform
Must be supported by MLTM
Provide non-critical services
Device owner
Exclusive control over the presence of discretionary and mandatory engines in the platform that are not subject to regulatory enforcement
Device manufacturer
Exclusive control over the presence of mandatory engines that are subject to regulatory enforcement
Trusted Engine: Domains
Slide Nr. 52, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Device Manufacturer Engine
Mandatory engine
Controls basic HW and interfaces; might do all baseband and application processor functions
Responsible for integrity and configuration of a device, including the presence of mandatory and specified discretionary engines
Coordinates communication between the other engines
Controls access to protected platform resources
Trusted Engine: Types
Slide Nr. 53, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Communication Carrier Engine
Mandatory engine
Performs action currently executed by the baseband processor (e.g., radio protocols for cellular radio access)
Service Provider Engine
Mandatory engine
Performs user-visible functions currently executed by the application processor (e.g., music player, web browser,…)
User engine
Discretionary engine
Provides security services for user (e.g., data protection, authentication,…)
Trusted Engine: Types (cont.)
Slide Nr. 54, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Trusted Engine: Communication
Device Owner’s mandatory domain
Device Owner’s discretionary domain
Device Manufacturer’s mandatory domain
…
…
…
Engine
Engine
Engine
Engine
Engine
Engine
Device Manufacturer Engine
Slide Nr. 55, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Establishing trust into a resource:
1. Trusted Resources
Also denoted as “Roots-of-Trust” (RoTs)
Contains a confidential EK and/or AIK
A trusted entity vouches for the resource instantiation
2. Measured Resources
Measured by a RoTs
Trusted party vouches for the resource (e.g., based on a reference measurement)
3. Normal resources
Resources without an EK/AIK
Trusted Engine: Resources
Slide Nr. 57, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Dedicated Root-of-Trust
A dedicated RoT is not described in terms of measurements and therefore must have an EK and/or AIK (plus associated credentials like certificate)
Allocated Root-of-Trust
An allocated RoT must be described in terms of measurements made by a trusted building entity
An allocated RoT and its trusted builder can together be described as a dedicated RoT
Roots-of-Trust: Implementation
Slide Nr. 58, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Root-of-Trust-for-Measurement (RTM) Performs the measurement functionality as defined in the TPM specifications.
Root-of-Trust-for-Storage (RTS) Provides PCRs and Protected Storage for an engine. Stores measurements made by RTM, cryptographic keys, and security sensitive data.
Root-of-Trust-for-Verification (RTV) Reliably verifies measurements against reference integrity metrics (RIM) before they are extended into the PCRs. The RTV may verify the measurements of the current state of other engines.
Root-of-Trust-for-Enforcement (RTE) Responsible for building all RoTs in its own engine which are based on allocated resources.
Roots-of-Trust: Types
Slide Nr. 59, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
RIM Certificate
Describes an approved platform state (monotonic counter value and/or PCR values)
Integrity and authenticity protected by a third party with a symmetric or asymmetric Verification Key (e.g., PKCS#1 RSA signature or 3DES-CBC-MAC)
Verification Keys
Form a key hierarchy
Root of this hierarchy is the Root Verification Authority Identifier (RVAI), which is either embedded into RTS of the engine or loaded into the RTS upon system boot
Dedicated PCRs
Can only be extended in context of a RIM certificate verification
Reliably attest a RIM certificate verification chain (e.g., during secure boot based on RIM)
Remote Integrity Metrics (RIM)
Slide Nr. 60, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Remote Integrity Metrics (cont.)
RVAI
Verification Key Verification Key
Verification Key RIM Certificate RIM Certificate
Valid measurement value of the software image to be verified
Platform state in which the cert. is valid:
PCR values
Monotonic Counter values
Dedicated PCR(s) to be extended with the measurement
Integrity Checksum (symmetric/asymmetric)
Slide Nr. 61, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Secure Boot: Basic Concept
Ver. Key RIM Certificate
MTM
Trusted Verification
Service
Software Image
Trusted Engine
1. Load Verification Key into MTM and verify the key’s authenticity/integrity (i.e., traverse key hierarchy down from RVAI)
2. Measure Software Image (=Hash) 3. Call MTM_VerifyRIMCert /
MTM_RIMCertAndExtend function of MTM to verify the RIM Cert:
a. Verify that the measurement equals the reference value in the RIM Certificate; otherwise return FALSE
b. Verify that the platform state (=PCR values and monotonic counter values) in the RIM Cert. is fulfilled by the current platform state; otherwise return FALSE
c. Verify the checksum of the RIM Cert. with the loaded Verification Key (=authenticity/integrity of the Cert.); otherwise return FALSE
d. Optional: Extend the dedicated PCRs defined in the RIM Cert. with the measurement of the Software Image
e. Return TRUE
Example: Verify Software Image before execution
1.
2.
3.
3.
Slide Nr. 62, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Secure Boot (Simplified Version)
MRTM
Mobile Specific Commands
Subset of TPM v1.2 (RTS + RTR)
RTV + RTM
Measurement and Verification
Agent
Device OS
1.
2.
3. 5.
6.
4.
1. RTV and RTM first executables running and recording diagnostic measurement of their implementation.
2. RTV+RTM measure and verify (based on RIM Cert.) the “Measurement and Verification Agent” (MVA) using the MRTM. The measurement is extended into a dedicated PCR.
3. If the MVA is verified, control is passed to MVA otherwise the boot procedure is aborted.
4. The MVA measures the device OS. 5. The MVA verifies (based on RIM Cert.) the device
OS image using the MRTM. The measurement is extended into a dedicated PCR.
6. If the verification succeeds, control is passed to the OS, otherwise the boot procedure is aborted
After the secure boot procedure: • Dedicated PCRs reflect the verified and loaded
software of the secure boot (e.g., used for remote attestation)
• Secure boot could be extended into application layer by measuring and verifying applications before their execution (e.g., prevent malware or outdated software from executing)
Slide Nr. 63, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Motivation
Mobile Trusted Platform
Implementation examples
Overview
Slide Nr. 64, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 1: Software Daemon
Device OS
MTM Daemon Application Application
(Ekberg and Kylänpää, 2008)
Slide Nr. 65, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 2: Kernel Module
Device OS
Application Application Application
(Nauman et. al., 2010)
MTM: Kernel Extension
Slide Nr. 66, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
ARM Trust Zone
Security extension to ARM processors
Two virtual processors on one physical (“secure world” and “non-secure world” isolated by HW means)
Secure monitor mode for interfacing between the two worlds
Texas Instruments M-Shield
Builds on top of TrustZone
Provides secure ROM for crypto keys and a secure execution environment (secure world)
Only small applications, denoted Protected Applications (PAs), signed with a secret key embedded in a secure ROM are allowed to execute in secure world (firewalled entry)
Only PAs have access to secrets in the secure world
Provides vendor-specific secure boot (not MTM secure boot!) for firmware and device OS
JavaCard
SmartCard with capability to protect cryptographic keys
Provides secure execution environment for small Java Applets (subset of Java language)
Short Excursion: Secure Execution Environments
Slide Nr. 67, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 3: Java Card
Device OS
Application Application Application
JavaCard
(Dietrich, 2008)
MLTM Applet
MRTM Applet
Abstraction
Layer
Card OS
Slide Nr. 68, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 4: ARM TrustZone
Device OS
Application Application Application
TrustZone
Secure World OS
VM
Su
perviso
r
MTM VM 1
…
MTM VM n
Secure Monitor
(Winter, 2009)
Management
Layer
Slide Nr. 69, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 5: TI M-Shield
Device OS
Application Application Application
Secure Execution Environment
Device Key
MTM PA Database
MTM State Database
MTM Execution
(Ekberg and Bugiel, 2009)
Management
Layer
Secure Monitor
Slide Nr. 70, Lecture Embedded System Security, SS 2012 A.-R. Sadeghi ©TU Darmstadt, 2007-2011
SYSTEM SECURITY LAB Chapter 5: Mobile Trusted Platform
Approach 6: Security Kernel
OKL4
Device OS VM MTM VM
Management
Layer
MTM Daemon Application Application Application
(Selhorst et al., 2010)