Copker: Computing with Private Keys without RAM

Abstract

Cryptographic systems are essential for computer and communication security, for instance, RSA is used in PGP Email clients and AES is employed in full disk encryption. In practice, the cryptographic keys are loaded and stored in RAM as plain-text, and therefore vulnerable to physical memory attacks (e.g., cold-boot attacks). To tackle this problem, we propose Copker, which implements asymmetric cryptosystems entirely within the CPU, without storing plain-text private keys in the RAM. In its active mode, Copker stores kilobytes of sensitive data, including the private key and the intermediate states, only in onchip CPU caches (and registers). Decryption/signing operations are performed without storing sensitive information in system memory. In the suspend mode, Copker stores symmetrically encrypted private keys in memory, while employs existing solutions to keep the key-encryption key securely in CPU registers. Hence, Copker releases the system resources in the suspend mode. In this paper, we implement Copker with the most common asymmetric cryptosystem, RSA, with the support of multiple private keys. We show that Copker provides decryption/signing services that are secure against physical memory attacks. Meanwhile, with intensive experiments, we demonstrate that our implementation of Copker is secure and requires reasonable overhead.

One-Time Programs Made Practical

“…19 Goldwasser et al add an all-or-nothing transformation to the output of f (a, b): the output is masked by random bits that are only fully revealed once all of b is selected. 20 In the TXT-only variant, the output is provided at the end as enforced by the execution of the system.…”

“…This problem does not arise in garbled circuits since the oblivious transfer is completed prior to providing the circuit 20. This fixes the issue because the simulator can equivocate on the final masking value to program the random value, sitting wherever the circuit ends up, with the correct output value for the now-known input 21.…”

Protecting Suspended Devices from Memory Attacks

“…Some approaches focus exclusively on the protection of a specific encryption key stored in RAM, e.g., the FDE key, but leave all other data in main memory unprotected from memory attacks. Approaches for x86 [25,12,13,23], as well as for ARM [11] and hypervisors exist [26]. Their common idea is to store a key in the CPU/GPU registers or in the CPU cache and to implement the cipher associated with the key on-chip at the cost of system performance.…”

AdAttester

“…Existing approaches such as Prime-and-probe [40], Flush-and-reload [43] may be also feasible to stealing the device keys, though to our best knowledge, there are no such successful attacks on TrustZone. Defensive methods against such attacks include: using lock-down cache lines for key calculation in secure world, using hardware encrypt/decrypt engines on the SoC (most of mobile devices are equipped with this feature), flushes sensitive cache on world-switch or using cache or SoC internal RAM for private key computation [21,32].…”