Trusted Computing Functionalities based on TPM · Trusted Computing Functionalities based on TPM ... and operating system ... SYSTEM SECURITY Chapter 5: Mobile Trusted Platform LAB

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


Authenticated boot

Binding and sealing


Direct anonymous attestation

Some background information

The DAA protocols

Case study: IBM Integrity Measurement Architecture



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


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


Authenticated boot

Binding and sealing




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)


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


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


Implementation examples

Overview

Chapter 5: Mobile Trusted Platform



Motivation



Overview



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?



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



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



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



Motivation



Overview



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



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



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



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



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



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




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



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.)



Trusted Engine: Communication

Device Owner’s mandatory domain

Device Owner’s discretionary domain

Device Manufacturer’s mandatory domain

…

…

…

Engine

Engine

Engine

Engine

Engine

Engine




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



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



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



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)



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)



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.



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)



Motivation



Overview



Approach 1: Software Daemon

Device OS

MTM Daemon Application Application

(Ekberg and Kylänpää, 2008)



Approach 2: Kernel Module

Device OS


(Nauman et. al., 2010)

MTM: Kernel Extension



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



Approach 3: Java Card

Device OS


JavaCard

(Dietrich, 2008)

MLTM Applet

MRTM Applet

Abstraction

Layer

Card OS



Approach 4: ARM TrustZone

Device OS


TrustZone

Secure World OS

VM

Su

perviso

r

MTM VM 1

…

MTM VM n

Secure Monitor

(Winter, 2009)

Management

Layer



Approach 5: TI M-Shield

Device OS


Secure Execution Environment

Device Key

MTM PA Database

MTM State Database

MTM Execution

(Ekberg and Bugiel, 2009)

Management

Layer

Secure Monitor



Approach 6: Security Kernel

OKL4

Device OS VM MTM VM

Management

Layer

MTM Daemon Application Application Application

(Selhorst et al., 2010)

Documents

Trusted Computing Functionalities based on TPM · Trusted Computing Functionalities based on TPM ... and operating system ... SYSTEM SECURITY Chapter 5: Mobile Trusted Platform LAB