程序代写代做代考 chain Java graph kernel C arm Trusted Computing Systems.

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 itselfNeeds 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