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).
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.“
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/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/urandom and system calls to
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
rdrandis 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)
rdrandcan be virtualized, i.e., it can cause an enclave exit and a
VM exit. The
VMMcan either execute a
VMRESUMEor can discontinue the execution of the VM. In the case of a
VMRESUME, the CPU retries the instruction
rdrandinside the enclave. This means that neither the operating system nor the
VMMcan modify the values returned by
rdrand: inside the enclave, we can trust that the value returned by
rdrandhas been affected by vulnerabilities. Recently,
rdrandwas 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).
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.
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/urandom: We test arrays of random bytes, each from
/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/urandomas well as
getrandominstructions/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.