Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

EuskalHack 2017 - Secure initialization of TEEs: when secure boot falls short

900 visualizaciones

Publicado el

Our presentation focuses on the critical role of secure initialization in the establishment of a Trusted Execution Environment.
The concepts are discussed in the light of the ARM TrustZone technology, although the considerations made may be valid for a wider range of TEEs.
We analyze past public attacks related to TEE initialization and we show how its security foundations go beyond the mere implementation of a Secure Boot chain of trust.
Security models used for TEE discussions often encompass a CPU-centric perspective at runtime.
We provide indications that such models should be augmented by including TEE lifecycle stages (e.g. Secure Cold/Warm Boot) and by considering the whole SoC as part of the security model.
We conclude that an holistic, system-level, view is required, along with careful design and implementation for establishing a secure TEE.

Publicado en: Dispositivos y hardware
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

EuskalHack 2017 - Secure initialization of TEEs: when secure boot falls short

  1. 1. Cristofaro Mune (@pulsoid) Eloi Sanfelix (@esanfelix) when secure boot falls short… Secure Initialization of TEEs EuskalHack 2017
  2. 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. 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…
  4. 4. TEEs: Fundamentals
  5. 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)
  6. 6. System overview 1 2 3 source: globalplatform.org
  7. 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. 8. HW & SW roles Hardware protecting Software Software protecting secrets
  9. 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. 10. ARM TrustZone
  11. 11. Example SoC: CPU
  12. 12. CPU Security State NS=1 NS=0
  13. 13. Security State propagation ARM TZ core AMBA AXI3 bus DDR Flash GPU... AxPROT[1] indicates if transaction Secure or Non-Secure
  14. 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. 15. Example SoC: protection enforcement
  16. 16. Example: Protecting DDR memory
  17. 17. Example: Protecting peripherals
  18. 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. 19. Secure Boot
  20. 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. 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. 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. 23. Any problems? Untrusted  Arbitrary memory corruption Source: Azimuth Security, Exploiting Samsung Galaxy S4 Secure Boot
  24. 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. 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. 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!
  27. 27. “Time”: TEE initialization
  28. 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. 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. 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. 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. 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. 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. 34. Example: ARM Trusted Firmware
  35. 35. • One of TEE security foundations − Is it Secure or Non-Secure Memory? Range checks How difficult can it be?
  36. 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. 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. 38. “Space” dimension: Not just the ARM CPU
  39. 39. Remember?
  40. 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. 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. 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. 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. 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. 45. “Time and Space”: TEE Warm Boot
  46. 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. 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. 48. Conclusion
  49. 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. 50. Thank you!! Cristofaro Mune (@pulsoid) pulsoid@icysilence.org Eloi Sanfelix (@esanfelix) eloi@riscure.com

×