search

dmcilvaney / optee_os

Other
0 stars 0 forks source link

OPTEE Draft #1

Open dmcilvaney opened 5 years ago

dmcilvaney commented 5 years ago

Hey everyone,

Sorry for the long post (I've tried to keep it interesting).

Feel free to comment/ask questions about anything here (some specific questions at the bottom).

I've been going through the process of updating our OP-TEE to 3.6.0 in preparation for some pull requests with features we have been working on. While I'm working on them, I figured I would touch base and get some feedback before polishing everything up.

This is sort of a RFC, but mostly I want to start a bit of dialogue with you and some of our security experts.

The Goal (Attestation)

We currently implementing attestation (something I've seen a few questions about here before) and firmware resiliency. Specifically, allowing a TA to provide a certificate chain rooted all the way down to a hardware root of trust.

i.e. SoC/ROM <- SPL <- OP-TEE <- User TA

This work is in service of a Trusted Computing Group specification: Hardware Requirements for a Device Identifier Composition Engine

See also: Cyber Resilient Technologies group

Some use cases

Basic Attestation

Obviously knowing if a device has been compromised with unknown firmware is very useful. If there is malicious firmware on the device the certificates will not match any known good versions and external systems can refuse to communicate with the TA.

TA Policy

A future feature we are very interested in: TA policy. In a large scale deployment of IoT devices it is important to have control of which TAs are allowed to run on a given device:

The computer controlling a robot arm should only run the robot arm TA, nothing else... but the factory has hundreds of identical devices. Safety critical systems should be locked down to only expected TAs, even if they all have the same owning entity as other devices on site.

The policy can also be included in the attestation, allowing the device to attest to its own current policy.

Secure Communications

The certificate chains can be used to setup secure communication channels with external devices or the cloud.

Boot Flow

The 30,000-foot view of the process is:

Note: Each loading stage is secured either with NXP's HAB, or a signing mechanism built into the previous firmware.

SPL Runs

  1. The ROM code loads an immutable boot loader (currently SPL, would be nice to offload some of this in the future so we can patch SPL as well)
  2. SPL acquires a secure, unique HW ID (We are working on NXP devices with a CAAM, so the OTPMK is our choice).
  3. SPL hides that ID, obscuring it from all future firmware (requires hardware support)
  4. SPL generates an identity based on this ID + the measurement of itself: --> Compound Device ID (CDI)
  5. SPL generates a key pair based on the CDI: --> SPLPub/Pri
  6. SPL starts a certificate chain somewhere in memory and signs its own certificate with SPLPri

OP-TEE Loading

  1. SPL verifies and loads the OP-TEE binary, measuring it as it does so.
  2. SPL creates a certificate describing the OP-TEE binary and signs it with SPLPri
  3. SPL takes its private identity (CDI), and hashes it together with the OP-TEE measurement. It then generates a new key-pair for OP-TEE: --> OP-TEEPub/Pri
  4. SPL destroys the CDI and SPLPri
  5. SPL boots OP-TEE, passing OP-TEEPub/Pri in a secure manner Would like some feedback here, see below

OP-TEE Runs

  1. OP-TEE now has its own key-pair OP-TEEPub/Pri. Each time a TA is loaded a hash is generated by hashing the TA binary and each of its dependencies
  2. A PTA is made available which can take that measurement, and sign it with OP-TEEPri (OP-TEE is unique, it must keep its private key to allow it to sign additional TA certificates)
  3. The PTA can also provide the entire certificate chain back to the rich OS for general purpose attestation of the system state

Manufacturing

For production devices the root of the certificate chain needs to be recorded by a trustworthy entity in a secure environment (i.e. manufacturer like NXP), and then cross-signed. This allows a 3rd party to determine if a certificate chain is valid or not.

More reading

Trusted Cyber-Physical Systems (TCPS) - High level goals Cyber Resilient Platforms/Systems (CyReP/CyRes) See especially Device Identity with DICE and RIoT - Technical details on identity derivation etc. NIST 800-193 - Guidelines we are trying to meet for resiliency

Our changes / Questions

Our initial implementation was based on 3.4.0, and there have been some significant updates to the TA loading processes since then. As I had to re-work the flow a bit, I figured now was a good time to get some input.

Measurement

I put together a commit with just the measurement portion here: https://github.com/dmcilvaney/optee_os/commit/6d5168ae169818901af8b3013b8f67e4ac724f60 Currently it only targets user TAs loaded from the REE FS since that was our primary use case. I had to re-work it to mesh with the new ldelf changes, but it looks like its running fine with QEMU for both buffered and normal loads now.

  1. Does this approach seems scalable/maintainable going forward? We would like to upstream as much as possible.
  2. @jforissier I noticed https://github.com/OP-TEE/optee_os/pull/3181 is in the works, I think ideally we would like the fingerprint of the TA to include any shared libraries it's using. Do you see any issues with that?

Certificate Chain

We also have a certificate chain management PTA which is responsible for consuming the measurements and providing the attestation information when requested. You can see the old 3.4.0 version here: https://github.com/ms-iot/optee_os/blob/ms-iot-security/core/arch/arm/pta/pta_cyres.c It requires an external dependency and I'm not sure how well received that would be (RIoT identity derivation and crypto package). I haven't gone through to clean it up yet, but I can try and answer any questions about it.

  1. How should we pass secret data to OP-TEE from SPL? Currently we set an address with a CFG flag. We were thinking of having the device tree point to a memory address which OP-TEE could check for its keys, then clear.
  2. Is there a strong pushback against external dependencies in OP-TEE? The RIoT repo does the ECC crypto and x509 certificate handling needed to generate the attestation. We use it across multiple firmwares to avoid code duplication.
  3. With a supplicant available in U-Boot it might be interesting to use OP-TEE to do the heavy lifting for attestation across all firmware layers (with the exception of SPL), thoughts?

RPC

We have some additional RPC features, but I'll leave that for another day.

dmcilvaney commented 5 years ago

updated: Links to TCG spec More detail on robot arm example misc cleanup