Making secure processors OS- and performance-friendly

Abstract

In today's digital world, computer security issues have become increasingly important. In particular, researchers have proposed designs for secure processors that utilize hardware-based memory encryption and integrity verification to protect the privacy and integrity of computation even from sophisticated physical attacks. However, currently proposed schemes remain hampered by problems that make them impractical for use in today's computer systems: lack of virtual memory and Inter-Process Communication support as well as excessive storage and performance overheads. In this article, we propose (1) address independent seed encryption (AISE), a counter-mode-based memory encryption scheme using a novel seed composition, and (2) bonsai Merkle trees (BMT), a novel Merkle tree-based memory integrity verification technique, to eliminate these system and performance issues associated with prior counter-mode memory encryption and Merkle tree integrity verification schemes. We present both a qualitative discussion and a quantitative analysis to illustrate the advantages of our techniques over previously proposed approaches in terms of complexity, feasibility, performance, and storage. Our results show that AISE+BMT reduces the overhead of prior memory encryption and integrity verification schemes from 12% to 2% on average for single-threaded benchmarks on uniprocessor systems, and from 15% to 4% for coscheduled benchmarks on multicore systems while eliminating critical system-level problems.

Improving privacy and lifetime of PCM-based main memory

“…Given the privacy issues with PRAM, we opt to use the counter mode encryption for its proved security and high performance [3] and assume that the secret keys are inside processors. Figure 1 shows the counter-mode encryption proposed for secure processors [3]. The counter data block is composed of a counter, two address offsets and a logical page identifier (LPID).…”

“…As a result, when a counter overflows, a new unique LPID is generated and the whole page would be re-encrypted to ensure uniqueness of counter data blocks [3]. The performance advantage of the counter-mode encryption is that the block cipher (i.e., encryption) latency can be overlapped with the latency of fetching the encrypted data block.…”

“…In the counter-mode encryption described in [3], there already is a local counter (LC) for each line in a page. In addition, there is a 64-bit logical page identifier (LPID) assigned for each memory page when it is allocated.…”

“…When a local counter overflows, GC would be incremented by one and all the local counters in the same page would be reset to zero. In this case, as discussed in Section 2.1, a new unique LPID is generated and the page would be re-encrypted to ensure security [3]. Such a combined two-level global and local counters are much more accurate than one global counter and have much less space overhead than the local counter scheme.…”

“…As the counters are stored along with the ciphertext data in the PRAM, directly accessing them will postpone the seed generation process and expose the block cipher latency. To overcome this performance issue and overlap this latency with PRAM access latency, a counter cache is included as in the previous work [3]. Here, note that if the counter scheme proposed in Section 3.2 is used, each local counter (LC) will be appended with a few small block-level counters.…”