SHIELDSTRAP: Making Secure Processors Truly Secure

1. SHIELDSTRAP: Making Secure Processors Truly Secure Siddhartha Chhabra, Brian Rogers, Yan Solihin Electrical and Computer Engineering North Carolina State University ICCD-2009

2. Outline • SHIELDSTRAP • Boot process in uniprocessors • Need for secure booting • Requirements of a Secure boot solution • Previous work • Assumed Attack Model • SHIELDSTRAP • Evaluation • Conclusions SHIELDSTRAP – ICCD 2009

3. Boot process in uniprocessors (PCs) OS Boot loader Boot Block Expansion ROMs BIOS BIOS POST (Power on Self Test) BIOS forms the root of the booting process….. SHIELDSTRAP – ICCD 2009

4. Need for Secure Booting In addition to software attacks, hardware attacks are emerging (e.g. Modchips) Software only protection vulnerable to hardware attacks Secure Processor Architectures proposed to defend against hardware attacks SHIELDSTRAP – ICCD 2009

5. Need for Secure Booting • Most Secure processor architectures assume that the system has booted up securely • The bootstrap process is assumed to be a part of the Trusted Computing Base (TCB) Is it safe to assume that the system boots up securely SHIELDSTRAP – ICCD 2009

6. A A A Steady state is secure OS Boot process still mine Boot loader Primary Boot block Expansion ROMs BIOS Section 2 SHIELDSTRAP – ICCD 2009

7. Modchips • Gaming systems verify the signature of a game DVD when inserted in the ROM • The BIOS is responsible for performing these checks • A modchip is a hardware device with a BIOS that is an exact replica of the original BIOS minus the checks for enforcing DRM SHIELDSTRAP – ICCD 2009

8. Modding attack Verify Digital signatures of the DVD Play the DVD no verification If signature valid then play the CD Original BIOS ModChip A major issue for the gaming industry, modchips available for all popular gaming systems (XBOX, XBOX360, PS2, PS3 Wii etc.) SHIELDSTRAP – ICCD 2009

9. Need for Secure Booting Without Secure booting no integrity and confidentiality guarantees can be made Hence, it is not safe to assume that the system has booted up securely Security of the system contingent on a secure bootstrap of the system SHIELDSTRAP – ICCD 2009

10. Requirements of a secure boot solution All boot components must be verified before passing control The root of trust should be located on-chip TOCTTOU attacks prevention (Vulnerability window attacks) SHIELDSTRAP – ICCD 2009

11. Previous Work ARM TrustZone High Security SHIELDSTRAP AEGIS (Arbaugh et al.) Aegis (Suh et al.) TCG, NGSCB, IBM Cell BE ARM TrustZone SHIELDSTRAP AEGIS (Arbaugh et al.) Aegis (Suh et al.) TCG, NGSCB, IBM Cell BE Low Security Low Cost High Cost SHIELDSTRAP – ICCD 2009

12. Attack model • Everything on chip is secure: The processor core, on-chip caches (L1, L2 and other caches introduced for the proposed scheme) • Code and data cannot be observed/modified by the attacker • Everything outside the chip is non-secure: BIOS, Memory bus, memory and the disk • Code and data can be observed/modified by the attacker • Attacker has physical access to the system • Software attacks on boot components equally likely User/owner of the system can be the attacker SHIELDSTRAP – ICCD 2009

13. SHIELDSTRAP in a nutshell • We do not make assumptions about the integrity of off-chip components • We use an On-chip SHIELDSTRAP-ROM (ST-ROM) to verify the boot components before starting the booting phase • The ST-ROM verifies the BIOS before passing control • Once the BIOS is successfully verified the control is passed to the BIOS which initiates the chained integrity verification phase where each component verifies the next one in the boot chain before passing control to it SHIELDSTRAP – ICCD 2009

14. SHIELDSTRAP OS BOOTING PHASE (TOU) On successful verification of the BIOS. pass control to BIOS to start the booting process VERIFICATION PHASE (TOC) Verify the BIOS before starting the boot process Boot loader Expansion ROMs Boot Block BIOS ST-ROM On-chip root of trust SHIELDSTRAP – ICCD 2009

15. SHIELDSTRAP • TOCTTOU attacks: The boot components come under the protection of the secure processor mechanisms • However, processors can read the boot components directly • Shadowing ROMs is made mandatory SHIELDSTRAP – ICCD 2009

16. ST-ROM • SHIELDSTRAP ROM is an on-chip Read-only memory and it stores the following • A key to verify BIOS: • Public key of BIOS manufacturer • Public key of Processor manufacturer • Group signature scheme • An implementation of digital signature verification algorithms • We chose RSA-1024 and SHA-256 as RSA is faster for the verifier • ST-Code: Code responsible for carrying out the verification phase Increasing Flexibility SHIELDSTRAP – ICCD 2009

17. ST-Code • //Verification Phase • //Verify the BIOS • biosSignature = read BIOS signature from BIOS; • publicKeyBIOS = read public key from ST-ROM • verified = verifySignature(BIOS, biosSignature, publicKeyBIOS) • If(verified == false) • { • BOOT FAILURE • } • else • { • //Pass control to the BIOS to start the booting phase • } SHIELDSTRAP – ICCD 2009

18. Requirements of other boot comp. • Each boot component stores the public key of the next boot component: Limits flexibility • Each boot component should be: • Signed by its manufacturer • Include the public key signed by a Certificate Authority • Include the public key of the Certificate Authority SHIELDSTRAP – ICCD 2009

19. SHIELDSTRAP: Architecture SHIELDSTRAP – ICCD 2009

20. Evaluation • Security analysis • Quantitative analysis SHIELDSTRAP – ICCD 2009

21. Security analysis • Case study 1: Pre-boot attacks (e.g. Modchip attacks) Prevents against Modding attacks ST-ROM Signature mismatch, Boot failure Verification successful Verfication Original BIOS Modchip SHIELDSTRAP – ICCD 2009

22. Security Analysis • Case Study 2: TSOP Flashing • In older versions of Xbox systems, the BIOS was stored on a flashable chip called TSOP with write access disabled • Re-enabled the write access by soldering few points on the board SHIELDSTRAP – ICCD 2009

23. Security Analysis SHIELDSTRAP – ICCD 2009

24. Security Analysis • SHIELDSTRAP defends against TSOP flashing by detecting it in the verification phase (signature failure) and prevents the system from booting Prevents against TSOP flashing attacks SHIELDSTRAP – ICCD 2009

25. Security Analysis • Case study 3: Possible TOCTTOU attack • SHIELDSTRAP verifies the boot components first and then passes control (vulnerability window) ST-ROM Verification OK Verification SHIELDSTRAP – ICCD 2009

26. Security Analysis • HOWEVER, once the boot component is loaded to memory for verification, it comes under the protection of the Merkle tree along with the other dynamic data produced by ST-Code and cannot be modified by the attacker without detection NO TOCTTOU Attacks possible SHIELDSTRAP – ICCD 2009

27. Security Analysis • Case study 4: Software attacks e.g. rootkits in MBR and expansion ROMS • Detected as a verification failure in booting phase SHIELDSTRAP – ICCD 2009

28. Evaluation • Security analysis • Quantitative analysis SHIELDSTRAP – ICCD 2009

29. Quantitative Analysis: Area • Area overhead • Cryptographic algorithms • Public key for signature verification • ST-Code Total area required: ~13KB Area estimate: 0.017 mm2 (0.012% overhead for a pentium 4 processor) SHIELDSTRAP – ICCD 2009

30. Quantitative analysis: Performance • Experimental setup SHIELDSTRAP – ICCD 2009

31. Quantitative analysis: Performance • The cryptographic operations in the boot process are modeled using an open source cryptographic library (Crypto++) SHIELDSTRAP – ICCD 2009

32. Quantitative analysis: Performance • SHIELDSTRAP adds 0.37 seconds to the boot process (measured on a real system) • 0.8% overhead on the modeled secure processor • OS comprises upto 80% of the overhead • Further reduced overheads for specialized systems (gaming and embedded) employing reduced kernels SHIELDSTRAP – ICCD 2009

33. Conclusions A A A Steady state is secure OS Boot process still mine + Boot loader SHIELDSTRAP Boot up is secure as well Primary Boot block Expansion ROMs Truly secure processor BIOS Section 2 SHIELDSTRAP – ICCD 2009

34. Conclusions • SHIELDSTRAP: Secure bootstrap mechanism • Bridges the gap between the vulnerable initialization and steady state operation of a secure processor • Security: Defends against hardware and software attacks • Low complexity: Lightweight additions to the processor in terms of area and performance • Flexibility: Allows for hardware and software re-configuration SHIELDSTRAP – ICCD 2009

35. Questions ? SHIELDSTRAP – ICCD 2009

36. Thank you SHIELDSTRAP – ICCD 2009

37. Backup Slides… SHIELDSTRAP – ICCD 2009

38. AEGIS (Arbaugh et al.) OS Compute Hash and verify signature Network host Boot Block(s) Expansion ROMs Compute Hash and verify signature Compute Hash and verify signature BIOS Section 2 Compute Hash and verify signature AEGIS ROM BIOS Section 1 TCB SHIELDSTRAP – ICCD 2009

39. Variant (Itoi et al.) A A A PIN based authentication OS Smart Card (MACs of kernel and apps) Grub Stage 2 Compute Hash and verify signature Expansion ROMs Grub Stage 1 Compute Hash and verify signature Compute Hash and verify signature BIOS Section 2 Compute Hash and verify signature BIOS Section 1 TCB SHIELDSTRAP – ICCD 2009

40. Trusted computing group approach Remote Attestation Microsoft proposed palladium which follows a similar approach and both schemes require non-trivial hardware changes and additions SHIELDSTRAP – ICCD 2009

41. Arbaugh et. al. • Does not prevent against hardware attacks: e.g. Modding attack • A BIOS upgrade will cause the system to bypass the secure booting mechanism as the BIOS forms the root of trust • The keys for verifying the boot components are stores in the BIOS or the AEGIS ROM. • Ties the system configuration (hardware and software) to the booting mechanism • i.e. any changes to the system configuration cause a boot failure SHIELDSTRAP – ICCD 2009

42. TCG and Palladium • It does allow for BIOS upgrades as the root of trust is part of the BIOS that does not change on upgrades (BIOS boot block) • Hardware attacks: Does not prevent against hardware attacks (e.g. Modding attack) • Requires non-trivial changes to the current hardware and addition of a Trusted Platform module, which is essentially a secure co-processor • These are Optional for the user, hence the attacks we discussed can still be easily carried out by the user by simply turning these features off. SHIELDSTRAP – ICCD 2009

43. ST-Code • VerifySignature(component, signature, publicKey) • { • verificationBlock = read first 512 bits from the component; • runningHash = hash(verificationBlock); • While(!endOfComponent) • { • verificationBlock = read next 512 bits from the component; • runningHash = updateHash(runningHash, verificationBlock); • } • expectedHash = obtain expected hash from the signature using the publicKey • if(expectedHash == runningHash) • { • return true • } • else • { • return false; • } • } SHIELDSTRAP – ICCD 2009

44. Quantitative analysis: ST overhead Adds 0.48 seconds to the boot process over a base machine with no security SHIELDSTRAP – ICCD 2009

45. Quantitative analysis: ST Miss rates Verification phase added is compute intensive and does not incur many misses other than the cold misses, hence secure processor with the software implementation does not add any significant overhead SHIELDSTRAP – ICCD 2009

46. The OS being the largest component contributes around 80% of the overhead, we have assumed a linux kernel, specialized kernels will be smaller in size and can therefore reduce the already insignificant overhead SHIELDSTRAP – ICCD 2009