Entropy as a Service EaaS

Reference Architectures

Base EaaS Architecture Without A Decentralized Root Of Trust

In this example, the client system is equipped with a Hardware Root of Trust (HRT) device. Examples of HRT devices are the Trusted Platform Module, Intel® Identity Protection Technology, and the ARM® TrustZone technology. The client system runs a dedicated software application capable of interfacing with the local HRT device on the one end and with the EaaS on the other end. The application communicates with the entropy server using standard plaintext protocols, such as HTTP.

1. The dedicated application initiates the procedure for obtaining entropy from the EaaS server by turning first to the HRT device and fetching its public key.
2. The dedicated application requests a timestamp from a time server using NTP.
3. The application then sends the HRT device public key to the EaaS server via an HTTP GET call.
4. The EaaS server receives the requester’s public key, reads the next available random value R(si), signs it with the EaaS’ private key, stamps with the current time, and sends the encrypted value back to the client.
5. The application on the client receives the result over HTTP and sends it to the HRT device.
6. The HRT device verifies the signature using the EaaS public key, checks the data timestamp for freshness, decrypts the result using the client’s private key. If the signature is correct, the random data is accepted and the HRT device issues a ticket to allow the client system to prove at later time it has obtained strong entropy data from EaaS.

WARNING:The resulting from Step 6 of the protocol random data shall not be used directly for constructing cryptographic keys with it or as a seed to a DRBG. Instead, known cryptographic mechanisms for combining multiple random data sources shall be used to mix random data obtained from multiple remote EaaS instances with local, with respect to the client system and the HRT device, randomness to create a seed for a NIST approved DRBG. Such cryptographic mechanisms are known in the trade as entropy/randomness extraction.

It is strongly recommended at a minimum two independent EaaS instances located in different geopolitical locales be used as remote sources. The resulting data from the randomness extraction process shall be provided as a seed to a NIST approved DRBG. The seeded NIST approved DRBG on the client system or inside the HRT device shall then be used for generating cryptographic keys using NIST approved methods. 

This construction ensures that an attacker would not have any meaningful advantage to gain insight into the cryptographic keys generated locally on the client system.