1 Lecture Embedded System Security Dynamic Root of Trust and Execution Prof. Dr.-Ing. Ahmad-Reza Sadeghi System Security Lab Technische Universität Darmstadt (CASED) Germany Summer Term 2014
Dynamic Root of Trust Problem of legacy Incompatible or sloppy BIOS Chain of trust is too long, too static AMD/Intel introduce Dynamic RTM (DRTM) CPU resets into clean state to load OS/App Essentially starting a new Chain of Trust Slide Nr. 2, Lecture Embedded System Security, SS 2014
Chain of Trust Chain of Trust Dynamic Root of Trust Reset Chain of Trust, cut out BIOS and boot loader Boots clean OS out of compromised system (!) App X App Y Operating System Operating System Boot Loader BIOS Authenticated Code (AC) CRTM CPU, Chipset, TPM Slide Nr. 4, Lecture Embedded System Security, SS 2014
TXT Reinitialization Process SENTER CPU instruction issues the process Resets CPU and Chipset Resets TPM PCRs 17-23 CPU executes Authenticated Code module (AC mod) AC mod is signed by vendor (Intel) AC mod is measured into PCR 17 AC mod reinitializes CPU and Chipset Payload is measured by AC mod Payload measurement stored in PCR 18 Slide Nr. 5, Lecture Embedded System Security, SS 2014
DRTM Security (1) System Management Mode (SMM, Ring -2 ) Runtime, low-level hardware management Arbitrary code execution while OS is suspended BIOS is expected to initialize SMM and then lock access Active Management Technology (AMT, Ring -3 ) RISC CPU inside the mainboard chipset Dedicated link to your RAM and network card Arbitrary code execution while OS is running Even if disabled in BIOS Slide Nr. 7, Lecture Embedded System Security, SS 2014
DRTM Security (2) SMM and AMT are not validated/supervised by TXT BIOS is supposed to secure access and lock registers App X App Y Operating System Boot Loader App A App B Operating System Compromised SMM or AMT can manipulate AC or TXT payload As of 2006, BIOS locks access to SM-RAM System Management Mode (SMM) Authenticated Code (AC) TXT needs secure BIOS! DRTM needs SRTM!? BIOS CRTM CPU, Chipset, TPM AMT Slide Nr. 8, Lecture Embedded System Security, SS 2014
TXT Example: GRUB GRUB Root of Trust is the CPU reset to TXT mode Chain of Trust: CPU GRUB boot loader (Hypervisor) Operating System... Simlilar problems as with Static Root of Trust Long chain of trust http://www.sirrix.com/content/pages/trustedgrub_en.htm Slide Nr. 9, Lecture Embedded System Security, SS 2014
Flicker: Execution Environment Execution Environment (TEE) at runtime Run only a small part in the TEE Leads to small TCB Must be isolated from other software Flicker Suspend operating system Switch to TXT mode Measure and execute code Resume operating system Slide Nr. 10, Lecture Embedded System Security, SS 2014
Chain of Trust Transaction Security (Flicker) (Flicker: McCune, Parno, Perrig, Reiter, Isozaki. An Execution Infrastructure for TCB Minimization, EuroSys 2008 Use TXT only for small critical functions like signature Output can be signed or otherwise bound to TPM App X App Y Operating System Boot Loader BIOS CRTM Secure App ret = func(input) Authenticated Code Strong isolation for legacy OS without virtualization overhead Simple and stable apps Integrity = Security CPU & Chipset PC-Hardware Slide Nr. 11, Lecture Embedded System Security, SS 2014
Transaction Security (Flicker) Flicker framework is available for Intel TXT, AMD SVM, Windows, Linux First prototype apps: Transaction confirmation, e.g., in online shopping Software-Smartcard Cryptographic operations executed in TXT-mode PKCS#11 Interface Usable with legacy software E.g., Mail signing with Thunderbird Slide Nr. 12, Lecture Embedded System Security, SS 2014
Disadvantages of TXT/SVM DRTM with TXT/SVM still contains huge software stack How to verify measuments Multiple open problems in cloud scenario Privider doesn t want to reveal software configuration Host machine identification through TPM keys Isolating only the security critical part is desirable Flicker never evolved to a practical solution Substantial modification of the OS required Switch to and from TXT/SVM is time consuming Execution stalls entire system (interrupts disabled) Slide Nr. 14, Lecture Embedded System Security, SS 2014
Intel Software Guard Extensions () [McKeen et al, Hoekstra et al., Anati et al., HASP 13] Security critical code isolated in enclave Only CPU is trusted Transparent memory encryption 17 new instructions Enclaves cannot harm the system Only unprivileged code (CPU ring3) Memory protection Designed for Multi-Core systems Multi-threaded execution of enclaves Parallel execution of enclaves and untrusted code Enclaves are interruptible Programming Reference available APP1 APP2 Enclave Security Service Operating System CPU Hardware Slide Nr. 15, Lecture Embedded System Security, SS 2014
Create Enclave 1 3 2 Loader Enclave 5 User space Client driver Operating system SK/PK Hardware 1. Create App 2. Create app certificate (includes HASH(App) and Client PK) 3. Upload App to Loader Slide Nr. 17, Lecture Embedded System Security, SS 2014
Create Enclave 1 3 2 4 Loader Enclave 5 User space Client driver 5 Operating system SK/PK 7 Hardware 1. Create App 2. Create app certificate (includes HASH(App) and Client PK) 3. Upload App to Loader 4. Create enclave 5. Allocate enclave pages Slide Nr. 18, Lecture Embedded System Security, SS 2014
Create Enclave 6 1 3 2 4 Loader Enclave 5 User space Client driver 5 Operating system SK/PK 7 Hardware 1. Create App 2. Create app certificate (includes HASH(App) and Client PK) 3. Upload App to Loader 4. Create enclave 5. Allocate enclave pages 6. Load & Measure App 7. Validate certificate and enclave integrity Slide Nr. 19, Lecture Embedded System Security, SS 2014
Create Enclave 6 1 3 2 4 Loader Enclave 5 User space Client driver 5 Operating system SK/PK 7 K 8 Hardware 1. Create App 2. Create app certificate (includes HASH(App) and Client PK) 3. Upload App to Loader 4. Create enclave 8. Generate enclave K key 5. Allocate enclave pages 6. Load & Measure App 7. Validate certificate and enclave integrity 9. Protect enclave Slide Nr. 20, Lecture Embedded System Security, SS 2014
SECS Enclave Enclave Creation Details Application 2a. ECREATE(SECS) 3a. EADD(*src, *dest) 3b. copy Encl. 4a. EEXTEND(*src) Code 5a. EINT 1b. Allocate EP to App 1a. Request Enclave Pages EPC list 4b. Hardware measures OS EPCM EPC 5b. Update HASH RAM M M U MEE CPU # Key ID n n+1 K PK 2b. Init SECS EPC: Enclave Page Cache EPCM: EPC Map MEE: Memory Encryption Engine MMU: Memory Management Unit SECS: Enclave Control Structure Slide Nr. 21, Lecture Embedded System Security, SS 2014
TCS Enclave Enclave Entry and Exit Details Application 1. EENTER(TCS, AEP) Stack AEP ISR EPC list OS M M U CPU EPCM EPC RAM MEE 2. Lock TCS, start Enclave AEP: Async Exit Point EPC: Encl. Page Cache EPCM: EPC Map ISR: Int. Service Routine MEE: Mem. Enc. Engine TCS: Thread Control Structure Slide Nr. 22, Lecture Embedded System Security, SS 2014
TCS Enclave Enclave Entry and Exit Details Application Stack AEP 1. EEXIT EPC list ISR OS 2. M M U CPU EPCM EPC RAM MEE AEP: Async Exit Point EPC: Encl. Page Cache EPCM: EPC Map ISR: Int. Service Routine MEE: Mem. Enc. Engine TCS: Thread Control Structure Slide Nr. 23, Lecture Embedded System Security, SS 2014
TCS Enclave Enclave Entry and Exit Details Application Stack AEP ISR 3. Switch to OS EPC list OS 1. Interrupt M M U CPU EPCM EPC RAM 2. Save context in Enclave MEE AEP: Async Exit Point EPC: Encl. Page Cache EPCM: EPC Map ISR: Int. Service Routine MEE: Mem. Enc. Engine TCS: Thread Control Structure Slide Nr. 24, Lecture Embedded System Security, SS 2014
TCS Enclave Enclave Entry and Exit Details Application Stack AEP 2. ERESUME 1. Return from Interrupt ISR EPC list OS M M U CPU EPCM EPC RAM MEE Slide Nr. 25, Lecture Embedded System Security, SS 2014 3. Resume Enclave AEP: Async Exit Point EPC: Encl. Page Cache EPCM: EPC Map ISR: Int. Service Routine MEE: Mem. Enc. Engine TCS: Thread Control Structure
Create Enclave Secure Channel 1 Shared memory Enclave1 Enclave2 User space 2 Operating system 3 1. Generate DH params 2. Request Report 3. Generate Report = (HASH(Enclave1), ID-Enclave2, DH-params) Slide Nr. 27, Lecture Embedded System Security, SS 2014
Create Enclave Secure Channel 1 Shared memory 5 Enclave1 Enclave2 User space 2 Operating system 3 1. Generate DH params 4. Authenticate Report using MAC with target enclave s shared key 6. Get enclave s share key 2. Request Report 3. Generate Report = (HASH(Enclave1), ID-Enclave2, DH-params) 7. Validate report 8. Repeat for other direction Slide Nr. 28, Lecture Embedded System Security, SS 2014 5. Pass Report (shared memory)
Create Enclave Secure Channel 1 Shared memory 5 7 Enclave1 Enclave2 User space 2 Operating system 3 1. Generate DH params 4. Authenticate Report using MAC with target enclave s shared key 6. Get enclave s share key 2. Request Report 3. Generate Report = (HASH(Enclave1), ID-Enclave2, DH-params) 7. Validate report Slide Nr. 29, Lecture Embedded System Security, SS 2014 5. Pass Report (shared memory)
Create Enclave Secure Channel 1 Shared memory 5 7 Enclave1 Enclave2 User space 2 Operating system 3 1. Generate DH params 4. Authenticate Report using MAC with target enclave s shared key 6. Get enclave s share key 2. Request Report 3. Generate Report = (HASH(Enclave1), ID-Enclave2, DH-params) 7. Validate report 8. Repeat for other direction Slide Nr. 30, Lecture Embedded System Security, SS 2014 5. Pass Report (shared memory)
Remote Attestation 1 nonce Enclave1 Quoting Enclave User space 2 Operating system 1. Verifier sends nonce 2. Generate Report = (HASH(Enclave1), ID-QuotingEnclave, nonce) Slide Nr. 31, Lecture Embedded System Security, SS 2014
Remote Attestation 1 nonce 3 Enclave1 Quoting Enclave User space 2 Operating system 1. Verifier sends nonce 3. Pass Report to Quoting Enclave 2. Generate Report = (HASH(Enclave1), ID-QuotingEnclave, nonce) Slide Nr. 32, Lecture Embedded System Security, SS 2014
Remote Attestation 1 nonce 3 4/5 Enclave1 Quoting Enclave User space 2 Operating system 1. Verifier sends nonce 3. Pass Report to Quoting Enclave 6. Signed Report is send to verifier 2. Generate Report = (HASH(Enclave1), ID-QuotingEnclave, nonce) 4. Quoting Enclave verifies Report 5. Signs Report with Platform Key Slide Nr. 33, Lecture Embedded System Security, SS 2014
Remote Attestation 6 1 nonce 3 4/5 Enclave1 Quoting Enclave User space 2 Operating system 1. Verifier sends nonce 3. Pass Report to Quoting Enclave 6. Signed Report is send to verifier 2. Generate Report = (HASH(Enclave1), ID-QuotingEnclave, nonce) 4. Quoting Enclave verifies Report 5. Signs Report with Platform Key Slide Nr. 34, Lecture Embedded System Security, SS 2014
Embedded Computing TC appears very suitable for embedded systems Less problems with legacy platforms No SMM and AMT, less complex BIOS Less bugs in Root of Trust Reduced code complexity and flexibility Special-purpose devices and use-cases Well-known code-base, longer release cycles Attestation of software stack becomes meaningful Slide Nr. 35, Lecture Embedded System Security, SS 2014
Embedded Infrastructures? Smart Grid Network relies on accurate measurements No real security concepts yet Vehicular Networks Components increasingly controlled by software, with desire for firmware updates How to trust tire pressure reports via WiFi? TPM & TXT everywhere? Slide Nr. 36, Lecture Embedded System Security, SS 2014
Software-based Attestation See, e.g., SWATT by Seshadri et al. (2004) or Pioneer by Seshadri et al. (2005) Exploits computational constraints of prover Only memory checksum can produce desired result in time! No security hardware or root of trust Prover (e.g., embedded device) Is the device in a trustworthy SW state? Remote Verifier Random challenge Memory Checksum Software Fingerprint (checksum of memory content)? = Reference Fingerprint Did device respond in expected time? Database
Software Attestation Problems Authentic channel between prover and verifier No cryptographic authentication due to compromise! No hardware security module available No actual remote attestation Hardware manipulation Simple overclocking or memory upgrades can enable prover to forge checksum Collusion attacks to forge checksum Prover can ask adversary to help computing the checksum