Investigating the Application of One Instruction Set Computing for Encrypted Data Computation

Tsoutsos, Nektarios Georgios; Maniatakos, Michail

doi:10.1007/978-3-642-41224-0_2

Cited by 10 publications

(8 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It is missing longjmp and efficient strings (char and short are the same size as int). It is intended for use in encrypted computing [13], [14], [15], [16], [17], [18], an emerging processor technology in which inputs, outputs, and all intermediate values in registers and memory are in encrypted form. Because good encryption is one-to-many, and addresses are data like any other, many physically different bit sequences (the 'ciphertext') represent the address intended by the programmer (the 'plaintext'), and platforms exhibit hardware aliasing at every memory access, providing a testbed for theory and practice.…”

Section: Methodsmentioning

confidence: 99%

“…It occupies two words on the stack at displacements k and k ′ (the value k+1) respectively from the stack pointer. The compiler generates accesses to the fields x.a and x.b just as it would for any local variables situated there, by calling lw r k(sp) # load from x.a (15) to read from x.a, for example. The effective address passed to memory is sp+k.…”

Section: Data Typesmentioning

confidence: 99%

“…Hardware aliasing arises nowadays notably in the context of encrypted computing [7,8,9,10,11,12,13]. That emerging technology is based on a processor in which inputs, outputs, and all intermediate values exist only in encrypted form.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Safe Compilation for Hidden Deterministic Hardware Aliasing

Breuer¹,

Bowen

2019

2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)

View full text Add to dashboard Cite

Hardware aliasing occurs when the same logical address can access different physical memory locations. This is a problem for software on some embedded systems and more generally when hardware becomes faulty in irretrievable locations, such as on a Mars Lander. We show how to work around the hardware problem with software logic, compiling code so it works on any platform with hardware aliasing with hidden determinism. That is: (i) a copy of an address accesses the same location, and (ii) repeating an address calculation exactly will repeat the same access again. Stuck bits can mean that even adding zero to an address can make a difference in that environment so nothing but a systematic approach has a chance of working. The technique is extended to generate aliasing as well as compensate for it, in so-called chaotic compilation, and a sketch proof is included to show it may produce object code that is secure against discovery of the programmer's intention. A prototype compiler implementing the technology covers all of ANSI C except longjmp/setjmp.

show abstract

Section: Methodsmentioning

confidence: 99%

Section: Data Typesmentioning

confidence: 99%

See 1 more Smart Citation

Safe Compilation for Hidden Deterministic Hardware Aliasing

Breuer¹,

Bowen

2019

2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)

View full text Add to dashboard Cite

show abstract

“…In using the Paillier encryption we follow (Tsoutsos and Maniatakos, 2013;Tsoutsos and Maniatakos, 2015), where a 'one instruction' stack machine architecture ('HEROIC') for encrypted computing embedding a 16-bit Paillier encryption is prototyped. In conjunction with a lookup table for the signs (positive/negative) of encrypted data, the Paillier addition is computationally complete (any computable function can be implemented using addition, the table, an encrypted 1, and recursion), and addition, subtraction, and comparison machine code instructions suffice to write software routines for the rest.…”

Section: Overview and Related Workmentioning

confidence: 99%

A Practical Encrypted Microprocessor

Breuer¹,

Bowen

Palomar

et al. 2016

Proceedings of the 13th International Joint Conference on E-Business and Telecommunications

View full text Add to dashboard Cite

Abstract:This paper explores a new approach to encrypted microprocessing, potentiating new trade-offs in security versus performance engineering. The coprocessor prototype described runs standard machine code (32-bit OpenRISC v1.1) with encrypted data in registers, on buses, and in memory. The architecture is 'superscalar', executing multiple instructions simultaneously, and is sophisticated enough that it achieves speeds approaching that of contemporary off-the-shelf processor cores. The aim of the design is to protect user data against the operator or owner of the processor, and so-called 'Iago' attacks in general, for those paradigms that require trust in data-heavy computations in remote locations and/or overseen by untrusted operators. A single idea underlies the architecture, its performance and security properties: it is that a modified arithmetic is enough to cause all program execution to be encrypted. The privileged operator, running unencrypted with the standard arithmetic, can see and try their luck at modifying encrypted data, but has no special access to the information in it, as proven here. We test the issues, reporting performance in particular for 64-bit Rijndael and 72-bit Paillier encryptions, the latter running keylessly.

show abstract

“…Several fast processors for encrypted computing are described in [14]. Those include the 32-bit KPU [15] with 128bit AES encryption [16], which benchmarks at approximately the speed of a 433 MHz classic Pentium, and the slightly older 16-bit HEROIC [17], [18] with 2048-bit Paillier encryption [19], which runs like a 25 KHz Pentium, as well as the recently announced CryptoBlaze [20], 10× faster.…”

Section: Introductionmentioning

confidence: 99%

Compiled Obfuscation for Data Structures in Encrypted Computing

Breuer

2019

Preprint

View full text Add to dashboard Cite

Encrypted computing is an emerging technology based on a processor that 'works encrypted', taking encrypted inputs to encrypted outputs while data remains in encrypted form throughout. It aims to secure user data against possible insider attacks by the operator and operating system (who do not know the user's encryption key and cannot access it in the processor). Formally 'obfuscating' compilation for encrypted computing is such that on each recompilation of the source code, machine code of the same structure is emitted for which runtime traces also all have the same structure but each word beneath the encryption differs from nominal with maximal possible entropy across recompilations. That generates classic cryptographic semantic security for data, relative to the security of the encryption, but it guarantees only single words and an adversary has more than that on which to base decryption attempts. This paper extends the existing integer-based technology to doubles, floats, arrays, structs and unions as data structures, covering ANSI C. A single principle drives compiler design and improves the existing security theory to quantitative results: every arithmetic instruction that writes must vary to the maximal extent possible.

show abstract

Investigating the Application of One Instruction Set Computing for Encrypted Data Computation

Cited by 10 publications

References 20 publications

Safe Compilation for Hidden Deterministic Hardware Aliasing

Safe Compilation for Hidden Deterministic Hardware Aliasing

A Practical Encrypted Microprocessor

Compiled Obfuscation for Data Structures in Encrypted Computing

Contact Info

Product

Resources

About