Trusted Computing Systems.
Apostolos P. Fournaris
2
How can we improve things?
at a high-level
seriously looking at security requirements and threats
when (prior to) building systems
at a low-level
train programmers to be aware of pitfalls associated with
programming language, OS, platform improve these languages, OSs, platform
making them less error-prone
Can Software Be Made Completely Secure?
Probably not.
modern systems are incredibly complex (hundred thousand security bugs). Not all bugs can be fixed
compatibility requirements prohibit replacing all unsecure software code with secure one
likely impossible to detect malicious code presence in a system without hardware support.
What do we need?
Trusted system: a system that the user can trust that it will not fail (if it fails the whole security policy collapses)
Trustworthy system: a system that cannot fail. Trusted system —-?—-> Trustworthy system
Computer security
Mobile security
Smart card security
1970 1980
Cambridge CAP VAX/VMS Reference monitor
Simple smart cards
Protection rings
1990 2000 2010
Trusted Platform Javasecurity Module(TPM)
Second part
GP TEE standards
TPM 2.0
Intel SGX
Historical perspective
architecture
Late launch
ARM TrustZone TI M-Shield
On-board Credentials First part Mobile hardware security
architectures
Hardware-assisted
secure boot Mobile OS security
Java Card architectures platform
TPM Mobile Module (MTM)
Mobile Trusted
8
The notion of trust
Trust tries to formulate a good-faith relationship between computing machines as well as between their users.
The realization of trusting an entity B by an entity A is based on the belief that B will always behave honorably, reliably and securely under a specific context
must involve both the user and the computing device at hand
Trusted Systems
Policy based trust Establishment using a Trusted Computing Base (TCB) and Strong Isolation
Trusted Computing Base
(TCB)
TCB is a collection of hardware, firmware and/or software components critical for the reliable functionality of a computer system
it has the highest OS privilege level and is responsible for the system’s security policy enforcement
must be small
manageable and to efficiently checked
periodically for security compliance
Must also be protected from itselfNeeds Hardware Root of Trust
Isolation
Separation of resources through trust verification mechanisms
Can be used to create self-contained computation (and
communication) environments
System Separation in trusted and untrusted zones
handled by a specialized level consisting of a collection of software tools that use the TCB services
Trusted System technologies
TCB and hardware trust management:
Trusted Computing Group (TCG) approach Trusted Platform Module
GlobalPlatform Trusted Execution Environment (TEE) e.g. ARM TrustZone technology
Isolation:
Virtualization Technology
TEE
Intel/AMD hardware virtualization
Trusted computing principles and the trusted platform module (TPM)
Trusted Computing Problem
A trusted system is one that behaves in the expected manner for a particular purpose [TCG]
How can one report the system state to a third party?
Assumption:
It is much easier to manipulate software than hardware You can’t provide strong security without HARDWARE means
Core of TCG proposed Trusted Computing: Provide a trust anchor in hardware → TPM
Trusted Computing
Enforce Trust on a system by prohibiting the execution of malicious code or behavior.
Trust evaluation from computer boot through a root of trust mechanism.
Trust ensured by Hardware means through a Trusted Platform Module (TPM)
Applied to PC computers (desktop – laptop), embedded systems, mobile systems in near future.
Trusted Platform Module
protect security by ensuring the following:
Private keys cannot be stolen or given away.
The addition of malicious code is always detected.
Malicious code is prevented from using the private keys.
Encryption keys are not easily available to a physical thief.
TPM main functions:
Authenticated Secure Boot
Integrity measurement – Key Management Platform Remote Attestation
Secure Storage
Goals:
Trusted Platform Module (II)
TPM v1.2 uses:
Cryptographic operations (RSA, AES) Hashing (SHA1),
True Random Generator
TPM v2 uses:
Cryptographic operations (RSA, ECC, AES)
Hashing (SHA1, SHA256 SHA 512), HMAC
Policy hierarchy
Multiple Manufacturers:
Infineon, Atmel, ST Micro, Nuvoton, Broadcom, …
TCG’s TPM software structure
TSS Introduction
• TCG Software Stack (TSS) is the core software component for interaction with the TPM
• TSS design provided and standardized by the TCG
TSS design goals
• provide one single exclusive entry point to the TPM functions
• synchronize TPM access
• TPM resource management (key slots, sessions, …)
sending / receiving low-level command stream to/from TPM manage user secrets
• handle event log
• TSS is not a “trusted” component
TSS Layers
TSS is a stack of layers
with clearly defined interfaces
TSS Service Provider (TSP) standard API for applications shared library
TSS Core Services (TCS) system singleton service daemon
TSS Device Driver Library (TDDL)
Standard HW interface
TPM device driver kernel low-level portion
TPM Keys
Endorsement Key and Storage Root Key are the only keys permanently stored inside the TPM (NV-ram)
Endorsement key (EK)
unique platform identity
injected by manufacturer or created by platform owner
Storage Root Key (SRK)
is root element of TPM key hierarchy typically with known password
TPM Keys
Storage Keys
RSA keys used to wrap (encrypt) other elements in the TPM key hierarchy
Signature Keys
RSA keys used for signing operations must be a leaf in the TPM key hierarchy
Binding Keys
key used for binding operations (TPM_Bind, TPM_Unbind)
Legacy Keys
can be used for both, signing and binding usage of this type of key is not recommended
Platform Configuration Registers (PCRs)
A PCR is a 160 bit storage location
A set of at least 24 PCRs is in every TPM V1.2
A PCR can always be read from
A PCR can never be directly modified, but only extended with PCR t+1 [i] = SHA-1( PCR t [i] || newValue )
static PCRs (0-15):
reset only at boot time
dynamic PCRs (16 and higher):
reset can only be triggered by special mechanism (e.g. TXT SINIT)
Note: PCR extends are not commutative (i.e. measuring A then B does not result in the same PCR value as measuring B then A)
TPM PCRs
Platform Integrity but How?
By measuring the software configuration of the platform using a transitive trust model:
Root of trust mechanism: Static or Dynamic Chain of Trust
Start with some trustworthy component: Root-of-Trust the TPM
Measure before execution
Store results in a secure location: Again ….the TPM
Static Root-of-Trust
Libraries, Configuration, Application
78
ME Kernel Modules EX
A5 6E S OSKernel C
UR 3 4 UT E OSLoader E
12
Core Root-of-Trust for Measurement + BIOS
TPM
Platform Configuration Registers
OK
Compare
Fail:
Untrusted system
PCR
Hashing
Digitally signed
Dynamic Root of Trust (Trusted Virtualization)
Trusted App
Needs Hardware Virtualization Support:
Operating System
Secure Hypervisor
• •
Intel TXT AMD SVM
Ap Ap…Ap ppp
TVAM
Low Level Drivers
Bootloader – BIOS
Late Launch
TPM
Hardware
Bootloader
initramfs
Measure
Base System Linux Kernel with KVM
Unseal
Power
on BIOS AC MLE
M Measure
Chipset, CPU & TPM
t
Provided by D. Hein
Unseal
Measure
Trusted Execution
Environment
GlobalPlatform approach
TEE overview
REE
TEE
1. Platform integrity
2. Secure storage
3. Isolated execution
4. Device identification
5. Device authentication
App
App
Trusted app
Trusted app
Mobile OS
Trusted OS
device hardware
Verification root
Device certificate
Identity
Public device key
Device authentication
Boot sequence
Volatile memory
Device key
Non-volatile memory
Secure storage and isolated execution
Cryptographic mechanisms
Base identity
Device identification
Trusted application
TEE mgmt layer
Platform integrity
2 5
Mobile device hardware TCB
Verification root
Cryptographic mechanisms
Volatile memory
Device key
Non-volatile memory
Secure storage and isolated execution
Trusted application
Platform integrity
layer
Boot sequence
TEE mgmt
Base identity
Device identification
Device certificate
Identity
Public device key
Device authentication
Trust anchor (Code)
TEE code
Hardware security mechanisms (recap)
1. Platform integrity
2. 3.
Secure storage Isolated execution
– Trusted Execution Environment (TEE)
4. Device identification 5. Device authentication
– Secure boot
– Authenticated boot
– Remote attestation TA code certificate
Identity certificate
Base identity
Assigned identity
Boot code certificate
Boot code hash
TA code hash
External trust root
Legend
Trust anchor (Hardware)
External certificate
Launch boot code
TEE Entry from Rich Execution Environment
17
Device
TEE system architecture
Architectures with single TEE
• ARM TrustZone
• TI M-Shield
• Smart card
• Crypto co-processor • TPM
Architectures with multiple TEEs
• Intel SGX
• TPM (and “Late Launch”) • Hypervisor
Rich execution environment (REE)
App
App
Trusted execution environment (TEE)
TEE API
Trusted app
Trusted app
TEE management layer
Device OS
Device hardware and firmware with TEE support
TEE entry
Figure adapted from: Global Platform. TEE system architecture. 2011.
ARM TrustZone
architecture
System on chip (SoC)
Secure World and Normal World
TrustZone system architecture
On-chip memory
Modem
TrustZone hardware architecture
Boot ROM
Access control hardware
Main CPU
SoC internal bus
Normal world
Secure world
Access control hardware
Access control hardware
(carries status flag)
Memory controller
Memory controller
Off-chip/main memory (DDR)
Peripherals (touchscreen, USB, NFC…)
App
Trusted app
Trusted app
Mobile OS
App
Trusted OS
Device hardware
TEE entry
20
Normal World (NW)
Secure World (SW)
User mode Privileged mode
SCR.NS=1
User Supervisor
SCR.NS := 1
SCR.NS=0
User Supervisor
Boot sequence
TrustZone overview
Secure Monitor call (SMC)
Monitor
SW RW NW NA
On-chip ROM
Address space controllers TZ-aware MMU
SW RO SW RW NW WO NW RW
On-chip RAM physical address range
Main memory (DDR)
END of Presentation