Peter T. Breuer

Peter T. Breuer

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.

Peter T. Breuer

An `obfuscation' for encrypted computing is quantified exactly here, leading to an argument that security against polynomial-time attacks has been achieved for user data via the deliberately `chaotic' compilation required for security properties in that environment. Encrypted computing is the emerging science and technology of processors that take encrypted inputs to encrypted outputs via encrypted intermediate values (at nearly conventional speeds). The aim is to make user data in general-purpose computing secure against the operator and operating system as potential adversaries. A stumbling block has always been that memory addresses are data and good encryption means the encrypted value varies randomly, and that makes hitting any target in memory problematic without address decryption, yet decryption anywhere on the memory path would open up many easily exploitable vulnerabilities. This paper `solves (chaotic) compilation' for processors without address decryption, covering all of ANSI C while satisfying the required security properties and opening up the field for the standard software tool-chain and infrastructure. That produces the argument referred to above, which may also hold without encryption.

Peter T. Breuer

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.

Peter T. Breuer

Hardware aliasing occurs when the same logical address sporadically accesses different physical memory locations and is a problem encountered by systems programmers (the opposite, software aliasing, when different addresses access the same location, is more familiar to application programmers). This paper shows how to compile so code works in the presence of {\em hidden deterministic} hardware aliasing. That means that a copy of an address always accesses the same location, and recalculating it exactly the same way also always gives the same access, but otherwise access appears arbitrary and unpredictable. The technique is extended to cover the emerging technology of encrypted computing too.

Peter T. Breuer, Jonathan P. Bowen

This paper first describes an `obfuscating' compiler technology developed for encrypted computing, then examines if the trivial case without encryption produces much-sought indistinguishability obfuscation.

Peter T. Breuer, Jonathan P. Bowen

Since fully homomorphic encryption and homomorphically encrypted computing preserve algebraic identities such as 2*2=2+2, a natural question is whether this extremely utilitarian feature also sets up cryptographic attacks that use the encrypted arithmetic operators to generate or identify the encryptions of known constants. In particular, software or hardware might use encrypted addition and multiplication to do encrypted division and deliver the encryption of x/x=1. That can then be used to generate 1+1=2, etc, until a complete codebook is obtained. This paper shows that there is no formula or computation using 32-bit multiplication x*y and three-input addition x+y+z that yields a known constant from unknown inputs. We characterise what operations are similarly `safe' alone or in company, and show that 32-bit division is not safe in this sense, but there are trivial modifications that make it so.

Peter T. Breuer, Jonathan P. Bowen

We ask whether two or more images of arithmetic may inhabit the same space via different encodings. The answers have significance for a class of processor design that does all its computation in an encrypted form, without ever performing any decryption or encryption itself. Against the possibility of algebraic attacks against the arithmetic in a `crypto-processor' (KPU) we propose a defence called `ABC encryption' and show how this kind of encryption makes it impossible for observations of the arithmetic to be used by an attacker to discover the actual values. We also show how to construct such encrypted arithmetics.

Peter T. Breuer, Jonathan P. Bowen

Sometimes machine code turns out to be a better target for verification than source code. RISC machine code is especially advantaged with respect to source code in this regard because it has only two instructions that access memory. That architecture forms the basis here for an inference system that can prove machine code safe against `hardware aliasing', an effect that occurs in embedded systems. There are programming memes that ensure code is safe from hardware aliasing, but we want to certify that a given machine code is provably safe.