By Nissan Aloni
In recent years, threat actors are becoming more and more sophisticated. There have been reports of supply chain attacks, even at manufacturing plants. Most recent and well known attack is “The big hack”.
Every system needs to have a Root of Trust (RoT), which is a source that can always be trusted. The RoT is responsible for securing the boot flow of the system, protecting the system flash memories, managing their update flows and cryptographic keys management. As explained in this earlier Kameleon blog , the current state of the art solution for RoT is to implement it on an isolated security chip, this is called hardware root of trust (HW-RoT). The isolated security chip provides very little visibility to would-be intruders and ensure the RoT cannot be manipulated.
Since the number of firmware attacks is growing significantly – how can you be sure that your HW-RoT is indeed the component you meant to integrate into your system? Can you really trust your HW-RoT? Will you know if it has been tampered throughout the supply chain? Even if it is an authentic component, can you trust the software and configurations running on it?
These are serious vulnerabilities and concerns for a secured system. If you can’t trust the HW RoT, who can you trust? Gladly, there is a solution that mitigates these threats, that is called platform attestation. Using platform attestation, which is a cryptographically secure flow, you can validate the authenticity of the HW RoT as well as its software and configuration.
OCP’s platform attestation protocol
The Open Compute Project (OCP) is a collaborative community focused on redesigning hardware technology to efficiently support the growing demands of compute infrastructure. As part of its goals and mission, it has defined an attestation protocol that should be used by all vendors who wish to provide high quality security solutions.
Attestation is the process, by which, a verifier can assess the trustworthiness of attesters within a platform (physically or logically). In systems that are based on HW-RoT (such as Kameleon ProSPU), the HW-RoT will act as the verifier for all the devices and peripherals in the system (as depicted in the system diagram below). Therefore, to ensure the full system authenticity and integrity, it will be sufficient to verify the HW-RoT (which will act as attester in this case).
The cryptographic realm is full of pitfalls and building a secure protocol should never be taken lightly. As can be seen in this example article, there might be various flavors of an authentication protocol. Most of them contain vulnerabilities which are sometimes easy to detect and sometimes extremely hard. Nonetheless, the vulnerabilities exist and can be used by threat actors.
Having an openly available protocol, such as the one that OCP defines, has many benefits. One of them is leveraging the community to find and fix vulnerabilities as the protocol is available for scrutiny of any potential user. Kameleon is an active participant of the OCP Security working group and is instrumental in contributing to the definition of the protocol. At Kameleon, we believe in security through transparency and clarity, therefore we chose to follow OCP’s attestation protocol in our ProSPU.
During the attestation process, an attester device reports its identity and its measurements to the verifier, which collects and verifies them against known manifests. The Kameleon ProSPU supports both DMTF’s SPDM and MSFT’s Cerberus attestation protocols and meets OCP attestation specification’s requirements.
Before we can dive into the attestation flow, we need to cover some cryptographic elements which are key components and used by the protocol.
Certificates and certificate chain validation
The first thing we need to understand is the concept of certificate chain and certificate chain validation.
OCP mandates the usage of X.509 certificates, which are an International Telecommunication Union (ITU) standard defining the format of public key certificates. Public key certificates are electronic documents used to prove the validity of a public key.
The diagram below depicts a public key certificate chain. Notice that each certificate holds a public key as the data element and this data element is signed by the private key of the previous entity in the chain.
The chain can be validated by following the flow from left to right:
- Root CA, which holds its own private key, can validate the left-most certificate. It signs the Root-CA public key and confirms that the signatures match. At this point the Root-CA public key is validated and can be used.
- The second certificate can be validated using the Root-CA public key from the previous step. The signature in the certificate can be verified using the Root-CA public key and then compared to a hash of the intermediate key which is calculated on the fly.
Once the entire chain is validated, at the end of the process, the alias public key is validated by the holder of full chain.
High-level platform attestation flow
The attestation flow uses the following steps to verify the identity of the attester:
- Establish the certificate chain by requesting relevant certificates from the attester. In this scenario, the attester is the PA-RoT, which is the platform active RoT. Basically this is the main RoT of the system (the RoT component in the peripherals is referred to as AC-RoT – active component RoT)
- Validate the certificate chain to get the Alias public key. The validation of the certificate chain proves that this is an authentic device (full explanation is beyond the scope of this blog).
- Issue a challenge to the PA-RoT.
- Receive a challenge response from the device and verify it is using the Alias public key (proving that the device holds the alias private key).
The following sequence diagram depicts the flow that was explained above:
Digests and certificates cache
The flow above uses SHA-256 of the certificates as digests, which can be used for time optimization. The verifier can hold a cache of certificates and corresponding digests (hash cache). If such a cache is used, then the verifier can ask for the digests from the PA-RoT and if the certificate is already stored in the cache, it will use it without asking for it. If the certificate is not in the cache, then the verifier will request the corresponding certificate from the PA-ROT.
Measurements reflect the system state and configuration. Measurements include everything that affects the security of the attester device, such as executable code, headers, security state and configuration data. The expected measurement for each device is a known value, and during the attestation process each attester device advertise its measurement. It is the responsibility of the verifier to verify the value.
The verifier issues a challenge to the attester device (PA-RoT in this case). The challenge commands include a nonce R1 (random value that was generated by the verifier). The attester device respond includes the nonce R2 generated by the attester along with a hash of R1, R2 and the measurements. The use of random numbers (R1 and R2) by the requester and the responder protects the flow from possible replay attack. In addition to the random numbers, the response includes measurement of the attester configuration.
The response of the attester device is signed by the alias private key.
By providing the nonces R1 and R2 with measurements that match the expected measurements, the attester device proves it’s running with the correct configurations. The attester (PA-RoT) also proves that it holds the alias private key.
The verifier validates that the attester holds the alias private key as a protection against spoofing. In such an attack, a rogue device, which might hold a valid certificate chain (obtained by sniffing an authentic HW-RoT), won’t be able to sign the device’s measurements without the alias private key.
The verifier can verify the following:
- The signature of the attester’s response (authenticate the challenge response message).
- R1 that was sent as part of the challenge request is indeed part of the challenge response from the attester.
- The reported measurements in the challenge response match the expected values, proving that the device is running with correct configurations and policies.
As discussed above, servers and appliances manufacturers, as well as Cloud Service Providers, should use HW-RoTs to secure their infrastructure. However, HW-RoT can only be trusted after its identity is verified using a proven, industry standard, attestation protocol. The OCP organization defines such an open, robust and highly secure protocol for device attestation.
Kameleon is leading the Hardware Security revolution and it’s the first to market with a fully compliant OCP RoT device (Kameleon ProSPU). This device complies with OCP’s attestation protocol and supports both, MSFT’s Cerberus and DMTF’s SPDM protocols.