Architectural support for copy and tamper resistant software

Non-malleable codes, introduced as a relaxation of error-correcting codes by Dziembowski, Pietrzak and Wichs (ICS '10), provide the security guarantee that the message contained in a tampered codeword is either the same as the original message or is set to an unrelated value. Various applications of non-malleable codes have been discovered, and one of the most significant applications among these is the connection with tamper-resilient cryptography. There is a large body of work considering security against various classes of tampering functions, as well as non-malleable codes with enhanced features such as leakage resilience.In this work, we propose combining the concepts of non-malleability, leakage resilience, and locality in a coding scheme. The contribution of this work is three-fold:1. As a conceptual contribution, we define a new notion of locally decodable and updatable non-malleable code that combines the above properties.2. We present two simple and efficient constructions achieving our new notion with different levels of security.3. We present an important application of our new tool -securing RAM computation against memory tampering and leakage attacks. This is analogous to the usage of traditional non-malleable codes to secure implementations in the circuit model against memory tampering and leakage attacks.

show abstract

“…Some partial results can be found in previous work [43,49,36,45,35,22,46,28,17,31,37,27,19,20,14,48,32,50,40,15,18].…”

Section: Related Workmentioning

confidence: 64%

Locally Decodable and Updatable Non-malleable Codes and Their Applications

Dachman-Soled

Liu

Shi

et al. 2015

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…Other types of attacks have also been considered by researchers which we briefly discuss next. Work has been carried out to detect tampering of information stored in off-chip memory [7,5]. The hardware cost of detecting tampering is very high.…”

Section: Related Workmentioning

confidence: 99%

Compiler-Assisted Memory Encryption for Embedded Processors

Nagarajan

Gupta

Krishnaswamy

2009

Transactions on High-Performance Embedded Architectures and Compilers II

View full text Add to dashboard Cite

Abstract. A critical component in the design of secure processors is memory encryption which provides protection for the privacy of code and data stored in off-chip memory. The overhead of the decryption operation that must precede a load requiring an off-chip memory access, decryption being on the critical path, can significantly degrade performance. Recently hardware counter-based one-time pad encryption techniques [11,13,9] have been proposed to reduce this overhead. For highend processors the performance impact of decryption has been successfully limited due to: presence of fairly large on-chip L1 and L2 caches that reduce off-chip accesses; and additional hardware support proposed in [13,9] to reduce decryption latency. However, for low-to medium-end embedded processors the performance degradation is high because first they only support small (if any) on-chip L1 caches thus leading to significant off-chip accesses and second the hardware cost of decryption latency reduction solutions in [13,9] is too high making them unattractive for embedded processors. In this paper we present a compiler-assisted strategy that uses minimal hardware support to reduce the overhead of memory encryption in low-to medium-end embedded processors. Our experiments show that the proposed technique reduces average execution time overhead of memory encryption for low-end (medium-end) embedded processor with 0 KB (32 KB) L1 cache from 60% (13.1%), with single counter, to 12.5% (2.1%) by additionally using only 8 hardware counter-registers.

show abstract

“…Most previous secure processors-including Intel TXT [16], eXecute Only Memory (XOM) [17], [18], [19] and Aegis [20], [21]-do not prevent leakage from memory access patterns. Ascend [22] is a recently-proposed secure processor that uses recursive Path ORAM to conceal the memory access pattern.…”

Section: Introductionmentioning

confidence: 99%