Workshop 4

Let's talk about firmware security

Contents

  • Theory
    • The state of firmware security
    • Basics
      • Limited physical protection
      • Trust Anchor
      • Core Root of Trust
    • Chain of Trust
      • Verified/Secure Boot
      • Measured/Trusted Boot
      • Operating system handoff
    • Security by Isolation
      • Concept
      • Trusted Execution Environments
  • coreboot firmware security
    • ​Flash protection
      • TPM
    • VBoot
      • History
      • Concept
    • General Security
    • Secure/ing payloads
      • LinuxBoot with systemboot
      • SeaBIOS
      • TianoCore
    • Intel ME
      • ME cleaner
    • Pentesting and QA
      • CHIPSEC

Contents

  • Hands On
    • TPM
      • Mainboard integration
    • Google's Verified Boot
      • SoC Integration
      • Mainboard integration
      • OS Handoff and Deployment
    • PCR and TCPA log

The state of firmware securiy

The xx commandments of IT-security

  1. Keep the trusted computing base minimal.
  2. Adjust your threat model to a limited physical attack scope.
  3. Embed only one physical trust anchor.
  4. Layer security mechanisms in order to increase the attack costs.
  5. Distinguish between remote and local attack vector. 
  6. Use sane cryptography algorithms and protocols.
  7. Pentesting is a must for your product.
  8. Try to push for the highest level of your core root of trust.
  9. Less complexity matters.
  10. Make your product security open and reviewable by externals.

The xx commandments of IT-security

  1. Keep the trusted computing base minimal.
  2. Adjust your threat model to a limited physical attack scope.
  3. Embed only one physical trust anchor.
  4. Layer security mechanisms in order to increase the attack costs.
  5. Distinguish between remote and local attack vector. 
  6. Use sane cryptography algorithms and protocols.
  7. Pentesting is a must for your product.
  8. Try to push for the highest level of your core root of trust.
  9. Less complexity matters.
  10. Make your product security open and reviewable by externals.

The reality

SoC:

Microcode

IFWI

USB 3.0

EC

Intel GbE

TPM

Northbridge (CPU)

  • Microcode
  • USB 3.0 firmware
  • Graphics firmware
  • WiFi firmware
  • Ethernet firmware

Southbridge

  • Southbridge firmware (ME / AMT)
  • BIOS firmware

Intel x86 firmware spots

Nearly 100% of the firmware is a binary blob by default!

Mainboard

  • Audio DSP
  • TPM firmware
  • EC firmware

Intel x86 "multi" trust anchor architecture

CPU

SB

BIOS

1. Microcode

2. Intel TXT (DRTM)

3. Intel SGX

4. Intel Boot Guard

4. Intel ME/SPS/IFWI

5. Intel TXT

6. iTPM

7. SMM

8. TPM (SRTM)

Ring -3

Ring -2

Ring -1

x86 crypto FAILS

SMU / SB

HMAC
Key

https://www.youtube.com/watch?v=iYvhHey_dTk

ME / SB

https://github.com/corna/me_cleaner

Manifest

Code Module 1

Code Module 2

Code Module 3

Symmetric Cryptography

Key extracted via a bug.

Asymmetric Cryptography with signed modules but load order isn't verified

Growing TCB in BIOS firmware

1980

Today

64KB

512KB

2MB

8MB

512MB

Nor flash ROM
size increases over time!

Firmware Security Conclusion

Basics

Limited physical protection

There is no 100% secure physical protection.

Limited physical protection

PUF - Physical Unclonable Functions

  • Some kind of a protected enclosure
  • High security
  • High costs
  • No battery needed
  • Key is generated out of the enclosure, if the enclosure is modified then the key will change

Limited physical protection

Mesh

  • Some kind of a protected enclosure
  • Medium security
  • High costs
  • Battery needed
  • Wires inside of the enclosure which detect a breach by wire interruption
  • ORWL

source: orwl.org

Limited physical protection

Enclosure sensors

  • Sensors are spread all over the PCB
  • Medium/High Security
  • Low costs
  • Battery needed
  • If a breach is detected the trust anchor credentials are flushed
  • Open Cellular

Limited physical protection

No enclosure security

  • HW attacks way easier without a secure enclosure
  • A lot buses and IC's exposed
  • Side/Cover channel attacks
  • Power glitching
  • Direct access to the HW
  • SoC fuses may help but can be circumvented, see Playstation 4

Trust Anchor

  • Normally a physical device which is tamper proof/evident
  • Offers Authentication, Integrity and Secrecy capabilities
    • PKI
    • Secure cryptographic algorithms and protocols
  • Identification of the device itself is possible
  • Similar to a Hardware Security Module
  • Protects itself and the hardware platform where it's integrated
  • Ownership model exists and the hardware owner can own the trust anchor
  • Features
    • Secure crypto engine
    • RTC
    • Monotonic counters
    • APU
    • NVRAM
       

Trust Anchor

TPM 1.2

source: infineon.com

TPM 2.0

source: infineon.com

Trusted Computing Group

Trust Anchor

  • Trusted Platform Module
  • The only state of the art and public available in masses trust anchor 
  • Specification 1.2 and 2.0 are publicly available
  • TPM 1.2 was driven by IBM
  • TPM 2.0 was driven by Microsoft
  • Multiple vendors:
    • Infineon
    • Google (Titan)
    • Nuvoton
    • STM
    • Atmel
  • Closed source except Open Titan coming from Google in 1-2 years

Trust Anchor

TPM 1.2 vs TPM 2.0

TPM 1.2:

  • Ownership
  • Complex state handling
    • Enabled/Disabled
    • Activated/Deactivated
    • Owned/Unowned
  • SHA1 hashes
  • Up to RSA-2048 keys
  • No complexity in API and design
  • No protocol for bus security (mutual auth)
  • Better integration into Linux and firmware

TPM 2.0:

  • ​No ownership
  • No state handling
  • Dynamic/Modern cryptographic algorithms
  • Huge TCB and increased complexity on all layers
  • Mainly Microsoft driven development
  • Bus security protocol but often not used
  • Good integration into UEFI/Windows, bad integration in everything else

Trust Anchor

Special magic

  • Remote attestation
    • Makes platform identification possible
    • Remote verification of platform integrity
  • Platform Configuration Register
    • Containing platform hashes of SRTM and DRTM
    • On set to the factory values after a power cycle
    • Used for remote attestation and sealing
  • Sealing
    • Done with TPM owned keys
    • OAEP padding for adding PCR into the encryption operation

Core Root of Trust

  • Core Root of Trust for Measurement/Verification
  • First code executed in a Static Root of Trust
  • Must be protected from any sort of modification
  • Chain of Trust starts here
  • Normally implemented as part of the BIOS firmware
  • TCG specification recommends extra chip.

source: macronix.com

Core Root of Trust

  • New CRTM/V solutions like Intel Boot Guard or ARM Secure Boot provide a more platform dependent way of protecting the systems at a higher level
  • Integrated inside the SoC or Southbridge
  • Higher security level with stronger HW protection
  • Also rely on platform features
  • DRTM is possible, use of ACM

source: wikipedia.org

Chain of Trust

Chain of Trust

Verified Boot

  • Also known as "Secure Boot"
  • Principle is based on signature verification
  • Security is "enforced" before execution chain
  • Authenticity and Integrity can be verified
  • But no clear information about the loaded blob is available
  • Also rollback attacks work by default

 

Measured Boot

  • Also known as "Trusted Boot"
  • Principle is based on measurement of blobs into hashes
  • Security isn't "enforced" by the chain
  • Security must be enforced different entity
  • Authenticity and Integrity can be verified
  • Measurements allow detailed information about the chain
  • Rollbacks attacks are not possible

Operating system handoff

  • Handoff can be done as verified/measured boot
  • Later on, the operating system must be somehow checked on authentication and integrity, e.g. dm-verity, disk encryption
  • Always a critical point

Security by Isolation

Concept

  • Isolation on Software and Hardware layers
  • Secure I/O
  • Often used in conjunction with a hypervisor
  • Hypervisor must have hardware acceleration otherwise it is too slow
  • Information flow control mechanism is required
  • Think of Ring 3, 1, 0

Trusted Execution Environment

  • TEE is the implementation of the security by isolation
  • TEE's are always platform specific features
  • Kicking off a HW isolated enclave for running secure applications
  • Impossible to do that safetly without a root of trust
  • Often used for Digital Rights Management
  • Has limits!
  • Often implemented through Authenticated Code Modules

coreboot firmware security

Flash Protection

  • coreboot supports:
    • BIOS_CNTL
    • PRR
    • FPR
    • IFD lock
    • ....
  • Only Intel FSP 2.0 makes use of a generalized implementation
  • We could need help here

TPM

Overview

  • coreboot supports LPC, SPI and I2C TPM's
  • TPM Specification 1.2 and 2.0 is supported
  • TCPA log support for ACPI
  • Custom coreboot TCPA log is also available
    • Based on CBMEM
    • Populated into the coreboot tables
  • CR50 extensions for the Google HW

Integration

VBoot + TPM

TPM only

Integration

tpmtool

www.tpmtool.org

  • Supports TPM 1.2 and 2.0 with Go TSS.
  • Higher TPM abstraction layer (TSPI) is implemented.
  • Written in pure Go.
  • TPM states are derived by Linux sysfs.
  • Automatic TSS selection based on TPM version.
  • TPM1 & TPM2 event log parser
  • Currently only TSPI for TPM specification 1.2 is available.

tpmtool

www.tpmtool.org

  • Dumps Endorsement Key into a file and shows the fingerprint.
  • Shows the TPM status
  • TPM Manufacturer:          STMicroelectronics
TPM spec:                  1.2
TPM owned:                 true
TPM activated:             true
TPM enabled:               true
TPM temporary deactivated: false
  • Takes ownership of the TPM.
  • Clears ownership of the TPM.
  • Resets TPM lock in case of active bruteforce detection.
  • Sealing/Unsealing credentials with custom/current set of PCRs.
  • Resealing of credentials using a sealing configuration for PCR pre-calculation
  • List and read PCRs
  • Measures a file into given PCR index.
  • Dump TPM eventlog from OS or custom eventlog binary file input.
  • Cryptsetup:
    • Format device and seal credential.
    • Open device by sealed credential.
    • Close device.
    • Measure device luks header into a given PCR. 

VBoot

History

  • Designed by Randall Spangler
  • Written as external C library
  • Currently compiled into coreboot, u-boot and openBMC
  • Code is well written from the cryptographic point of view
  • Maintained by Google only
  • Offers the capabilities of a verified boot, secure updates and failure safety at once
  • Highly integrated into coreboot

Concept

  • Verified boot
  • Signature verification based on RSA 2048-8192
  • One read-only partition which never changes!
  • Requires hardware or software protection
  • Two writeable partitions A & B
  • VBoot can be run from bootblock or romstage depending on the platform capabilities
  • RW region only contain romstage/ramstage++
  • Boot flow
    • RO boots first and selects A or B
    • Verifies the RW region
    • Executes it and jumps into romstage/ramstage
    • If an errors appears
      • VBoot will store the error into the VBNV
      • Do a hard_reset
      • Try the next RW region until RO is left or boot process succeeds

Concept

Concept

  • Fallback on boot failure
  • Firmware updates from OS
  • Independent payloads possible
  • MRC_CACHE is optionally write protected after ramstage because of security reasons
  • Requires board specific FMAP
  • Requires SoC support
  • Requires mainboard support

Read Only

Platform Lockdown

  • Important to lock platform registers, otherwise the it can be exploited by the OS
  • Intel implements a generalized way in FSP 2.0
  • On some other platforms it is done inside the code
  • Future plan is to have a interface for all platforms with hooks

IOMMU

  • Protects against DMA attacks by giving PCI devices only access to specific memory they need
  • Not every CPU supports this feature
  • In coreboot sometimes it is implemented, sometimes not
  • ACPI DMAR tables required
  • SoC specific support is required
  • HW support is required

Intel SGX

  • Newest Trusted Execution Environment by Intel
  • Already broken by Spectre, CPU Microcode updates are needed
  • Intel FSP 2.0 implements support for it
  • Can be easily enabled through devicetree.cb
  • Intel Licensing Server required
  • Does not use the TPM

Intel TXT

  • Old Trusted Execution Environment by Intel
  • Intel independent, No licensing
  • No support in coreboot yet
  • Loads 2x ACM
  • TPM is required for the security model
  • TBOOT hypervisor

ARM TrustZone

  • Modern Trusted Execution Environment by ARM
  • Uses the ARM Trusted Firmware
  • Separates the world into secure and insecure
  • Makes use of TEE OS
  • Really complex compared to Intel SGX
  • TEE OS can have interfaces into the OS
  • Default on every more powerful ARM SoC
  • coreboot has full support loading the ATF + TEE OS

Secure/ing payloads

LinuxBoot with systemboot

LinuxBoot with systemboot

  • Currently implemented as branch of systemboot (verifiedbooter)
  • Offer verified/measured boot
  • Uses Boot Configurations
  • Boot Configurations are signed with ECC cryptography

SeaBIOS

  • No verified boot mechanism
  • Offers TPM 1.2 and 2.0 support
  • Has the capability of running a measured boot by default
  • But, overwrites existing TCPA log with measurements
  • SeaBIOS + TrustedGrub2 gives you a full measured boot environment
  • https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2

TianoCore

  • Full Secure/Trusted Boot
  • Not yet supported by coreboot
  • Additional code is necessary to set up the keys

Intel ME

Overview

  • Old versions are ARC4 32bit x86 architecture
  • New versions are SPARC architecture
  • Intel ME blob inside the IFD partition contains code+data sections
  • The whole is blob is encoded by huffman encoding
  • Tables was reverse engineered by some crazy guys
  • ME can be 1.5, 3 or 5 MB big with different use cases
  • Ring -2 permissions, higher privileges than SMM   

source: heise.de, ciw

ME cleaner

https://github.com/corna/me_cleaner

  • Tool by Nicola Corna
  • Disables the ME (HAP) bit or removes modules out of it
  • Works up to Intel coffeeclake platform
  • Nice documentation about Intel ME hacks
  • Currently not fully integrated into coreboot

Pentesting

CHIPSEC

  • Security platform assessment tool
  • Works on x86 only
  • Fully written in python with multiple execution ways in OSX, Linux, Windows
  • Gather information via a kernel driver and printing the results to the console
  • Plugins
  • Standard UEFI support, no coreboot support
  • Created and maintained by Intel

https://github.com/chipsec/chipsec

Hands-on: Add TPM support to Wedge100S

Hands-on: Add TPM support to Wedge100s

Task:

  • Select ocp > wedge100s as mainboard
  • Enable TPM support for Wedge100S
  • Choose SeaBIOS payload in SERCON mode
  • Compile and ship it
  • Check if TPM is shown in SeaBIOS menu

What you need:

  • coreboot firmware for the wedge100s

 

15min

Hands-on: Add TPM support to Wedge100s

Steps

  1. Add TPM support to mainboard kconfig
  2. Add TPM device to the devicetree.cb

Hands-on: Add support for VBoot on Wedge100s

Hands-on: Add VBoot support to Wedge100s

Task:

  • Select ocp > wedge100s as mainboard
  • Implement missing VBoot support in src/soc/intel/fsp_broadwell_de
  • Implement support into Wedge100s mainboard support
  • Enable "Mock secdata for firmware verification"
  • Compile and ship the image
  • Check vboot status in the coreboot log

What you need:

  • coreboot firmware for the wedge100s

 

60min

Steps

  1. Implement vbnv_cmos_failed in src/soc/intel/fsp_broadwell_de/pmutil.c and make it available
  2. Decide for a bootflow model of vboot
  3. Add the missing options to src/soc/intel/fsp_broadwell_de/Kconfig for vboot support
  4. Create your own FMAP for wedge100s called vboot.fmd
  5. Modify the wedge100s mainboard configuration
  6. Compile and boot it

Hands-on: Add VBoot support to Wedge100s

Hands-on: Print PCR and TCPA logs

Hands-on: Print PCR and TCPA logs

Steps:

  • Select ocp > wedge100s as mainboard
  • Enable TPM support for Wedge100S
  • Choose SeaBIOS payload in SERCON mode
  • Add a tpm_extend which extends a hash all zero in src/drivers/tpm/tpm.c
  • Compile and ship it
  • Boot into the operating system and check:
    • /sys/kernel/security/tpm0/ascii_bios_measurements
    • sudo util/cbmem/cbmem -L 

What you need:

  • coreboot firmware for the wedge100s

 

45min

Let's talk about firmware security

By 9elements Agency GmbH

Let's talk about firmware security

  • 1,026

More from 9elements Agency GmbH