![Security State propagation
ARM TZ
core
AMBA AXI3 bus
DDR Flash GPU...
AxPROT[1] indicates if transaction
Secure or Non-Secure](https://image.slidesharecdn.com/euskalhack2017-secureinitializationofteeswhensecurebootfallsshort-170703083352/85/EuskalHack-2017-Secure-initialization-of-TEEs-when-secure-boot-falls-short-13-320.jpg)
![• All AXI slaves are memory mapped
− Including DDR, HW registers, etc.
− Page Table Entries include an NS-bit
• AxPROT[1] depends on CPU and PTE NS bits
How is AxPROT[1] determined?
CPU NS PTE NS AxPROT[1]
0 0 0
0 1 1
1 x 1](https://image.slidesharecdn.com/euskalhack2017-secureinitializationofteeswhensecurebootfallsshort-170703083352/85/EuskalHack-2017-Secure-initialization-of-TEEs-when-secure-boot-falls-short-14-320.jpg)
EuskalHack 2017 - Secure initialization of TEEs: when secure boot falls short
- 1. Cristofaro Mune (@pulsoid) Eloi Sanfelix (@esanfelix) when secure boot falls short… Secure Initialization of TEEs EuskalHack 2017
- 2. • Cristofaro Mune − Embedded Security Consultant (Independent) − Keywords: TEEs, IoT, Embedded SW & HW, Fault Injection − Previous work: WBC, IoT, Embedded Exploitation, Mobile • Eloi Sanfelix − Principal Security Analyst @Riscure − Keywords: Software security, TEE, RE, Exploiting, SCA/FI, CTF − Previous work: WBC, DRM, PayTV, Smart Cards Who?
- 3. • TEEs Increasingly relevant in security solutions …Basically everywhere • Research: • Interesting but limited in amount and scope • Lack of a generic TEE security modeling • Components and Mechanisms • Attack surfaces • Attack vectors What and why…
- 5. • Aimed at providing a secure environment for execution of security critical tasks: − Payment applications − DRM applications − … • Separated from Rich execution environment (REE) − Non-secure, untrusted environment • Support for Trusted Application (TAs): − Separated from each other − Typically implementing one single use case Trusted Execution Environment (TEE)
- 7. 1. TEE separations: 1. Separation from the Rich Execution Environment (REE) 2. Separation between TAs and the TEE OS 3. Separation between TAs TEE Critical items Strong cooperation between HW & SW We focus on this… …but concepts also apply to these.
- 8. HW & SW roles Hardware protecting Software Software protecting secrets
- 9. A TEE reference frame (runtime) H/W Platform TEE OS Drivers SDK TA System TAs 1 2 3 4 6 5 REE TEE Execution Memory I/O Inter-process (MMU) HW primitives for separations TEE Trusted Code Base (TCB): Can remove any protection
- 10. ARM TrustZone
- 11. Example SoC: CPU
- 12. CPU Security State NS=1 NS=0
- 13. Security State propagation ARM TZ core AMBA AXI3 bus DDR Flash GPU... AxPROT[1] indicates if transaction Secure or Non-Secure
- 14. • All AXI slaves are memory mapped − Including DDR, HW registers, etc. − Page Table Entries include an NS-bit • AxPROT[1] depends on CPU and PTE NS bits How is AxPROT[1] determined? CPU NS PTE NS AxPROT[1] 0 0 0 0 1 1 1 x 1
- 15. Example SoC: protection enforcement
- 16. Example: Protecting DDR memory
- 18. • AXI slaves in charge of enforcing transaction security • Can be done with: − Controllers (TZASC, TZPC, etc) − Hardcoded logic in bus matrix • Controllers MUST be configured by SW What about other slaves?
- 19. Secure Boot
- 20. Why Secure Boot? − Integrity and confidentiality of flash contents not assured • TEE security is not established! − Secure Boot provides this assurance CPU FLASH DDR ROM OTP Debug BL1.2 … BL1.1 SRAM BL1.1 STACK BL1.2 … Generic Embedded System
- 21. Typical Secure Boot implementation Internal ROM Bootloader 1 (BL1) RSA key signature … − Assures integrity (and confidentiality) of flash contents − Root of trust composed of immutable code and data
- 22. SB vulnerability: Samsung Galaxy S4 1. aboot copies header, then kernel 2. Signature is verified and kernel booted if OK. CPU FLASH DDR ROM OTP Debug Generic Embedded System Header … aboot SRAM aboot STACK Header … Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot Kernel Kernel
- 23. Any problems? Untrusted Arbitrary memory corruption Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot
- 24. So what? − aboot smashes its own code with attacker-supplied code! − Alternatively, attacker could target return address on stack Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot CPU FLASH DDR ROM OTP Debug Header … aboot SRAM aboot STACK Header Kernel Kernel Generic Embedded System
- 25. SB vulnerability: AMLogic S905 SoC Source: http://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html Untrusted data used to determine whether signature check is enabled!
- 26. • Secure Boot makes sure code is authentic − You still need to set up the REE and TEE! • In particular: − Initialize separations (TZASC, TZPC, … ) − Load TEE OS into Secure World − Initialize other SoC components Beyond Secure Boot The TEE needs to be securely initialized before running any REE code!
- 28. • TEE initialization is based on Secure Boot. • TEE initialization must also protect, load, verify, initialize and configure the TEE. • Then demote to REE. TEE initialization
- 29. A TEE reference frame (full) H/W Platform Root of Trust Boot stages TEE OS Drivers SDK TA System TAs 1 2 3 4 6 5 7 8 REE TEE Execution Memory I/O Inter-process (MMU) HW primitives for separations TEE Trusted Code Base (TCB): Can remove any protection
- 30. • Demotion point: − The point (in time & code) in a boot process, where ALL the privileges for configuring a TEE are given up − …and REE is started. • Critical path(s): − The set of all the code paths that can be executed before the Demotion point − Parts of the TEE attack surface Some definitions
- 31. How it works: Old Samsung phone iROM BL1 BL2 PBL TZSW Signed/encrypted Signed Signed Android SECKEYRestricted External Load + Exec Exec Load Signed REE execution Critical paths Demotion to REE
- 32. • The following must be executed before Demotion point • For each TEE-related boot stage: − Identify WHERE to load the stage in memory − Protect memory from REE - E.G. configure TZASC − Load and Verify. − Run any stage initialization code • Configure (…more to come…) − Other IPs − Other Protection Controllers Just “Secure Boot”?
- 33. • Reference implementation for trusted TEE initialization − ARMv8-A architecture − ATF v1.3 now released - Security improvements over v1.2 • Customizations needed: − Highly dependent on memory layout (and design) − Examples: - Configuration of TZASC and TZPC …or equivalent controllers - Initialization routines for BL31 and BL32 ARM Trusted Firmware
- 34. Example: ARM Trusted Firmware
- 35. • One of TEE security foundations − Is it Secure or Non-Secure Memory? Range checks How difficult can it be?
- 36. • TEE ranges can be dynamic (and scattered) − Hardcoded values may be difficult to handle • Logical mistakes may happen…. Real world example https://atredispartners.blogspot.com.mt/2014/08/here-be-dragons-vulnerabilities-in.html
- 37. • Multiple memories: − Not everything is DDR • Layout can be dynamic: − Example: Video Memory • Proper check location and API design are fundamental • System-level consistency of view is needed for proper enforcement: − Across every SW runtime component − Across the whole SoC HW. Range checks not so easy…
- 38. “Space” dimension: Not just the ARM CPU
- 39. Remember?
- 40. • SoC much more than the ARM CPU • DMA engines − Crypto accelerators − PCI/PCIe devices • Other processing engines − Audio/Video CPUs − Modem and WiFi controllers − Power management MCUs Potential attack surface Any IP with access to the bus MUST be considered!
- 41. • Most masters are also slaves − DMA transactions configured through the bus − Auxiliary CPUs expose APIs through the bus − … • Need to take care of configuration − Secure bus masters should not be driven by non-secure processing engines − Firmware running on secure bus masters should be authenticated and secured! Buses, masters and slaves
- 42. Example: HW crypto engine DDR REE Apps Secure DDR REE Code/Data HW AES Engine Encrypted content TEE Code/Data Decrypted content REE OS TAs TEE OS “Decrypt from A to B” SecureNon-secure
- 43. What if… ? DDR REE Apps Secure DDR REE Code/Data HW AES Engine Encrypted content TEE Code/Data REE OS TAs TEE OS “Decrypt from A to B” SecureNon-secure
- 44. • Some use cases might require isolating peripherals − Secure display to show mobile payment data − Secure touch sensor for PIN entry − Secure fingerprint sensor • But some peripherals need to be available to both worlds Runtime configuration required Securing peripherals State transitions must be carefully considered
- 45. “Time and Space”: TEE Warm Boot
- 46. • Simply put: Boot after “Suspend-To-RAM” − Typically requested from REE • Only some parts of the SoC are powered down: − DDR in self-refresh mode − Some limited parts always-on for restore • Restore/reuse saved execution contexts − E.g: Entry points Warm Boot
- 47. • Contexts are not fully stored in TEE memory? • Protection controllers are shutdown as well? • Contexts are stored in non-DDR memory? − E.G. some on-chip SRAM • Remaining execution cores are non-secure? − Do they have access to memory storing contexts? What if…
- 48. Conclusion
- 49. • TEE security can be complex: − Full HW & SW cooperation continuously required • TEE initialization is critical • HW can also be an attacker… • More accurate TEE security model needed: − Properly frame attacks, discussions and design choices • Holistic view required Conclusion TEE is an environment… …not “just” a feature.
- 50. Thank you!! Cristofaro Mune (@pulsoid) pulsoid@icysilence.org Eloi Sanfelix (@esanfelix) eloi@riscure.com