Skip to content

Random Numbers

Linux provides applications with cryptographically secure random numbers. We aim to provide applications with cryptographically secure random numbers such that:

  • the application seems to use the standard Linux functionality, i.e., there is no need to rewrite applications, and
  • without needing to trust Linux (see adversary model 2).

Background

Wikipedia states: "In Unix-like operating systems, /dev/random and /dev/urandom are special files that serve as cryptographically secure pseudorandom number generators. They allow access to environmental noise collected from device drivers and other sources. /dev/random typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ), it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently. The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot. Not all operating systems implement the same methods for /dev/random and /dev/urandom.“

Approach

The threat model used by SCONE implies that we cannot trust the operating system. An adversary might have changed the behavior of Linux, or the adversary might intercept the system calls to read /dev/random, /dev/urandom, or a system call getrandom and returns numbers under the control of the adversary. The adversary might use this to predict keys generated with the help of these random numbers.

The SCONE runtime intercepts inside the enclave all accesses to devices /dev/random and /dev/urandom and system calls to getrandom:

  • the SCONE runtime maps these system calls to the CPU instruction rdrand, i.e., all randomness inside the enclave is derived from this CPU instruction. By default, the SCONE runtime prevents all access to paths rooted in the directory /dev.

  • rdrand is an instruction for returning random numbers from an Intel on-chip hardware random number generator. This generator is seeded with an on-chip entropy source. The random number generator complies with security and cryptographic standards FIPS 140-2, NIST SP 800-90A, and ANSI X9.82. (see Wikipedia)

Potential Vulnerabilities

  • rdrand can be virtualized, i.e., it can cause an enclave exit and a VM exit. The VMM can either execute a VMRESUME or can discontinue the execution of the VM. In the case of a VMRESUME, the CPU retries the instruction rdrand inside the enclave. This means that neither the operating system nor the VMM can modify the values returned by rdrand: inside the enclave, we can trust that the value returned by rdrand is unmodified.

  • rdrand has been affected by vulnerabilities. Recently, rdrand was affected by a side-channel vulnerability CVE-2020-0543 (aka Crosstalk, INTEL-SA-00320 / INTEL-SA-00615). This vulnerability affected Xeon E3 CPUs but no other Xeon CPUs. A CPU firmware patch has mitigated this vulnerability. (see Details).

Security Approach

Our general assumption is that we need to expect that hardware, firmware, and software can be affected by vulnerabilities. During the attestation of an application, we, therefore, need to check the vulnerabilities that affect the CPU and the software. SCONE prevents the execution of programs on CPUs affected by vulnerabilities, i.e., have no mitigations.

!!!note: "Tolerating vulnerabilities" By default, SCONE prevents the execution of programs on CPUs with vulnerabilities. To permit the execution of an application on a CPU with vulnerabilities, one must list all the CVEs that one wants to tolerate in the security section of the applications security policy ([see details] https://sconedocs.github.io/CAS_session_lang_0_3/#attestation-security). Note that the application owner controls access to the application policy.

Integration Testing

  • The SCONE platform test suite runs before each commit and each release of the SCONE runtime. As part of this suite, we run a test program that computes the entropy of the /dev/random and /dev/urandom: We test arrays of random bytes, each from /dev/random and /dev/urandom. The test fails if the entropy is below a given threshold.

  • We also benchmark the SCONE platform using the Criterion benchmark suite. As part of these benchmarks, we measure the performance of /dev/random and /dev/urandom as well as rdseed, rdrand, and getrandom instructions/functions. The criterion benchmarks run as part of the nightly and release tests of the SCONE platform. Code changes that would change the performance of the random number generation will result in performance regressions.