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
-
Flash protection
Contents
- Hands On
- TPM
- Mainboard integration
- Google's Verified Boot
- SoC Integration
- Mainboard integration
- OS Handoff and Deployment
- PCR and TCPA log
- TPM
The state of firmware securiy
The xx commandments of IT-security
- Keep the trusted computing base minimal.
- Adjust your threat model to a limited physical attack scope.
- Embed only one physical trust anchor.
- Layer security mechanisms in order to increase the attack costs.
- Distinguish between remote and local attack vector.
- Use sane cryptography algorithms and protocols.
- Pentesting is a must for your product.
- Try to push for the highest level of your core root of trust.
- Less complexity matters.
- Make your product security open and reviewable by externals.
The xx commandments of IT-security
- Keep the trusted computing base minimal.
- Adjust your threat model to a limited physical attack scope.
- Embed only one physical trust anchor.
- Layer security mechanisms in order to increase the attack costs.
- Distinguish between remote and local attack vector.
- Use sane cryptography algorithms and protocols.
- Pentesting is a must for your product.
- Try to push for the highest level of your core root of trust.
- Less complexity matters.
- 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 ofsystemboot (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,
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
- Add TPM support to mainboard kconfig
- 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
- Implement vbnv_cmos_failed in src/soc/intel/fsp_broadwell_de/pmutil.c and make it available
- Decide for a bootflow model of vboot
- Add the missing options to src/soc/intel/fsp_broadwell_de/Kconfig for vboot support
- Create your own FMAP for wedge100s called vboot.fmd
- Modify the wedge100s mainboard configuration
- 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,011