Hardware Security Trusted Execution Environments (TEEs) & Trusted Computing Erik Poll Digital Security Radboud University Nijmegen
• Classic hardware-backed security solutions smartcard for users HSM (Hardware Security Module) in the back-end • Today: more modern & flexible alternatives esp. for users 2
Trusted Computing & TEE Trusted Computing • – initiative in early 2000s to ‘secure’ PCs & laptops running a standard OS on a standard processor – using additional piece of hardware, the Trusted Platform Module (TPM) – led by industry alliance Trusted Computing Group (TCG) Trusted Execution Environments (TEEs) • – environment to run some code with drastically reduced TCB – using special hardware features of processor – very different architectures to do this: • ARM Trustzone provides 1 secure world and 1 insecure world • Intel SGX provides many secure enclaves 3
Goals of this lecture Understanding Security objectives • Technologies / architectures / techniques to reach these • objectives Attacker models aka threat models • Trusted Computing Base (TCB) • In other words: – What are the security properties ? – How are these properties guaranteed ? – How good are these guarantees ? 4
Understanding TEE techologies & impact Complex mechanisms involving entire execution stack: • • HW, I/O, OS, application layer Understanding security goals (what it achieves) • given the mechanisms (how it does that) can be tricky Sometimes obscured by marketing blurb • Potentially big impact on • – trustworthiness of computing infrastructure we use every day – privacy – openness – economics & monopolies 5
Beware the dreaded T-word... TEE = Trusted Execution Environment S tatements involving the word ‘trust’ are likely to be bullshit • often wrong or vacuously true • Do you think that “ trusted execution environments” exist? Can you give examples? 6
example trusted execution environments 7
Beware the dreaded T-word... All execution enviroments are trusted (if they are used) • by some party, for some purpose The T in TEE probably means highly trustworthy • for some guarantees, for some attacker model Who is trusting what or whom, and for which properties? • At least three parties are involved • user • software / service provider • device manufacturer (OEM) and often more: certifiers, TTPs, CAs, ... 8
Trust vs Trustworthiness Someone or something is trusted if they potentially can • compromise your security. Someone or something is trustworthy if they will not • compromise your security. Trustworthiness comes in many levels • Trust is a binary property • But – Trust is a binary property for some particular property • Eg you might have to trust X for the confidentiality of some data, but not for the availability of that data – Defence in depth (eg having detection as well as prevention) provides different degrees of trust 9
Trustworthiness & TCB Size & complexity of the Trusted Computing Base (TCB) is • the crucial ‘measure’ of trustworthiness Ideally, TCB should be • – small • esp. limited amount of software – simple – well-understood – well-analysed & maybe certified • ideally verified using formal methods 10
Motivating example: the SIM card What are the security advantages for the telco? The phone hardware & software are not in the TCB for • authentication The telco does not have to trust the phone to keep crypto • keys for authentication confidential The telco only has to trust the SIM • for confidentiality of keys and integrity of code Limitation: user has to type in the PIN code to unlock the SIM, so some phone hw & sw in TCB for confidentiality of the PIN app Goal of TEEs: Can we get such security guarantees without a separate processor? OS And hence: without the limited resources such a of separate processor has TEE 11
Attacker Models for TEE 12
Attacker models: for crypto, protocols, software 1. Crypto attacker wants to extract keys Encrypt K AES 2. Dolev-Yao attacker wants to break security guarantees of a protocol Alice Bob 3. I/O attacker wants to create any unwanted behaviour App with malicious input – broader objectives than 1 & 2 • eg including DoS, RCE – lower abstraction level: looking at the code, not abstract algorithm or protocol • eg including buffer overflows 13
More powerful I/O attacker models for TEEs malware attacker • App access to the same platform incl. common I/O channels platform (OS, hw, I/O) and persistent storage (eg spoofing/phishing) code attacker • App controls (some) code used by victim app (eg code injection attack via buffer overflow, or with malicious library) platform attacker • App eg malware attacker that managed to compromise the OS platform TEEs also aim to protect against code & platform attacks! 14
Defending against code/platform attacker? You might think that defending against code or platform attacker is hopeless. App App platform But all is not lost! Possible defences: runtime integrity checks on code, eg • – stack canaries, CFI (Control Flow Integrity), ... against buffer overflows – TPM reporting a hash of the software stack sandboxing aka compartementalisation, eg • – software-based Java (Card) sandboxing – hardware-based Flicker sessions & Intel SGX enclaves Of course, such mechanisms do come with a TCB. 15
Physical attacks? Irrelevant for online attacks but possibly relevant in some situations App platform Two very different scenarios: Attacker with physical access • eg removing a hard disk from stolen laptop to access raw data (by-passing OS security) User is not trusted • by service provider or device manufacturer, eg DRM (Digital Rights Management) Note: user now included in the attacker model 16
Security Goals 17
Goals of TEE - conceptually isolated execution trusted path and for trusted I/O secure storage app data + + integrity & integrity & confidentiality confidentiality of code & data of user I/O even if OS is even if OS is compromised compromised 18
First attempt at defining TEE Platform that provides applications with the security guarantee of isolation integrity of behaviour • integrity & confidentiality of data, at rest & during execution • against very powerful attacker HARDWARE malware on the same platform • and even (partial) compromise of the application or platform • with a high level of trustworthiness minimal TCB • ultimately relying on hardware • and mechanisms to attest to the integrity of the system as basis for others to trust it • 19
TEE security goals (1) – ‘isolation’ Isolated Execution • Execution of an application cannot be compromised. Integrity & confidentiality of code and of data in use. Secure Storage • Integrity, confidentiality and freshness of data at rest. Trusted Path: a secure path to and from the user • Integrity & confidentiality of communication • secure attention sequence, eg. Ctrl-Alt-Delete on Windows, or Home button on iOs & Android, is a special case of Trusted Path This is nothing new! Any OS aims to provide these properties. 20
These security goals in a picture app app c 1 app storage 2 platform Spoofing remains a tricky concern an app can know it has exclusive use of display or keyboard, • but how can the human user know who it is talking to? 21
TEE security goals (2) – ‘assurance’ Who & what are we dealing with? Can we trust this? from perspective of an app, remote party, or local human user Platform Integrity • – Can we trust or verify platform integrity? (Remote) Attestation • – Can a (remote) party verify integrity of platform or app? Identification & Authentication • – Can we authenticate the identity of a platform or app? – Ultimately, this requires some device identity Secure Provisioning • – Mechanism to send data to specific software module on a specific device • eg for DRM, updating, or sync-ing apps across devices 22
How to provide 'isolation'? use different physical devices • – very secure and provides Trusted Path – but costly & cumbersome classic OS • – huge TCB hypervisor • – smaller TCB (multi-application) smartcard • – even smaller TCB – also some protection against physical attacks – limited resources , no I/O to user , let alone Trusted Path TPM & TEE hardware-based solutions ?? • 23
SIM card as TEE? Phone OS not in TCB Phone OS for authentication to is in TCB for network I/O with user App Phone OS Baseband Main chip CPU Phone 24
SIM card as TEE? What is in the TCB when you • unlock you SIM card? Upon booting the phone, the main phone OS may still be partly excluded from TCB? In any case, malware on the • phone could phish this! – by faking this display 26
TEE vs smartcard Unlike a separate smartcard, ideally a TEE should offer fast & full memory access • running at full CPU speed • interacting with normal I/O • 27
TEE technologies 28
Recommend
More recommend
