Towards a working fully homomorpic crypto-processor“how to” do all your computing encrypted

Peter T. Breuer, Jonathan P. Bowen

University of BirminghamBirmingham City University

Peter.T.Breuer@gmail.com

A CPU

1

1

2

An encrypted CPU

781568

781568

9878711

K

8720 331

291733

This text has appeared so you can remind me to do something special here

Encrypted CPU = “KPU”

● A KPU works on encrypted inputs, produces encrypted outputs, maintains encrypted values in registers and memory throughout.

● The register + memory states obtained by an encrypted program running in a KPU are encryptions of the states obtained by running the unencrypted program in an ordinary CPU.

How may one build a KPU?

● A result of mine in 2011 reduced the problem to building an Arithmetic Logic Unitwith special properties.

Build an “encrypted ALU” ...

● … and you get an encrypted CPU – a KPU– Good for doing private computations in the

cloud in full public view– Good for you doing the bank's calculations

on your account held privately by you● mathematical trick allows one encryption to

be converted to another without revealing key or plain-text

– No risk of NSA snooping your images

Relation to Gentry's Fully Homomorphic Encryption

● Craig Gentry in 2009 produced an encryption E with full homomorphism E(x+y)=E(x)+E(y) E(x*y) =E(x)*E(y)

– safe to hand out the red operations to consumers for DIY application

– they do not reveal key or plaintext

● ALU in a KPU is also safe to hand out– hides key, plaintext in hardware

– same fully homomorphic property

If KPU uses Gentry's encryption...

● … it operates keylessly– hardware hides no keys (and no plaintext)

– but currently need words million bits wide– Not practical!

● Not only way of running without keys– ALU can use lookup tables: 32bit is too big

– AES 64bit encryption uses 16bit arithmetic● 16-bit encrypted arithmetic table = 8GB● need one table for each operation site● Run AES codec encrypted, keys encrypted

Being Practical Today ..

● KPU implementation– Places codecs around standard ALU

2 2

4

+

43781 43781

30976

● Keys protected by hardware

Issues

● KPU has horrible memory aliasing problems– Encrypted memory addresses fall all over 64-

bit address space– Only some addresses backed by real memory

● MMU must remap all addressing on-the-fly at word granularity

● Technology available - just

– Same address with different encryptions● Program may not read from where just wrote● Solved by software discipline

– Always calculate same address same way– Compiler: pass data in registers, not on stack– Machine code verifier

Where are the industrialists?● Not here?

– Should have taken up this simple security option already!

● Cryptographers needed– Investigate security of

encrypted arithmetic

● Hardware designers needed– Architecture, instruction sets

● Software designers needed– compilers

Conclusion

● I've avoided real technical details● Can make a KPU processor that does all

its work on encrypted data, without ever decrypting it

● Only needs real industrial engagement to be real, now (conference too academic?)

● Protects your data from other eyes, hands– Some implementations are keyless

– Others store/use encrypted keys ● “fully homomorphic encryption magic”

PS

● Offline discussion in the last two days ..– has developed a typing discipline that

– lets an encrypted ALU deliberately calculate incorrectly any result whose value is known beforehand no matter the input

– Deliberately gets wrong “x – x” (= 0, known)

● Security against ALU capture by baddies– Goody (compilers) can program around this

● The paper briefly documents an (imperfect) attempt at such a scheme