towards a working fully homomorpic crypto-processor (essos 2014)
DESCRIPTION
Presentation delivered at ESSoS 2014, Munuch, Germany. See full paper at https://www.academia.edu/4512089/Towards_a_working_fully_homomorphic_crypto-processor_Practice_and_the_secret_computer .TRANSCRIPT
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
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