Correctness of a Secret Computer (ESSoS '13)

198 views
140 views

Published on

Slides accompanying my talk on "A fully homomorphic crypto-processor design: Correctness of a secret computer" at ESSoS in Versailles, Paris, FR in Feb 2013. Full reference to paper is at http://link.springer.com/chapter/10.1007/978-3-642-36563-8_9 with DOI 10.1007/978-3-642-36563-8_9 and preprint from http://www.academia.edu/2489994/A_Fully_Homomorphic_Crypto-Processor_Design_Correctness_of_a_Secret_Computer .

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
198
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Correctness of a Secret Computer (ESSoS '13)

  1. 1. Correctness of a Secret Computer Peter T. Breuer University of Birmingham, UK This talk is available at http://birmingham.academia.edu/PeterBreuer/Talks/
  2. 2. A 'fully homomorpic crypto- processor' design ● Paper is about a general purpose crypto-processor ● Computer that works on encrypted data ● The design in the paper is called a KPU ● Never encrypts or decrypts anything at all Observer sees ... Garbage inGarbage out
  3. 3. How does it work? ● KPU has one changed component wrt CPU: – `arithmetic/logic unit' (ALU) ⇒ Arithmetic and logic is encrypted ● 4587898 '+' 4587898  97999 (2) (2) (4) ● Implementation? For this paper, we don't care! ● Paper shows it does work, whatever the technology  Control flow is still observable
  4. 4. Why should this trick not work? ● You can imagine inserting codecs ● in internal CPU data paths ● That works as an encrypted CPU design procedure ● But just changing the arithmetic works instead! ● That's unexpected - a KPU contains no codecs Unit 1 Unit 2 Encrypted data Modified unit 1 Modified unit 2
  5. 5. In fact it does not work universally ● Only certain programs work in KPU – Those maintain separation between ● Program addresses (not encrypted) ● Data and data addesses (encrypted) ● This property is called crypto-safe for a KPU – Example of not crypto-safe: ● Jump to suboutine whose address is Elvis's birthdate written backwards – If think `obvious it will work,' need to reconsider! http://birmingham.academia.edu/PeterBreuer/Talks/
  6. 6. What the paper says 1.Defines the model-theoretic notion: crypto-safety 2.Proves crypto-safe programs run correctly in KPU where correct means 'gets the same states as in a normal CPU, but encrypted' You don't need to read the paper now! http://birmingham.academia.edu/PeterBreuer/Talks/
  7. 7. Erratum ● Mea culpa – A program is crypto-safe if at runtime every instruction that expects encrypted data gets encrypted data and every instruction that expects unencrypted data gets unencrypted data and every read from an encrypted address is from the exact same encryption of the underlying address value that was last written to. ● I forgot to include the “aliasing-safe” bit in paper http://birmingham.academia.edu/PeterBreuer/Talks/
  8. 8. What's up with 'aliasing'? ● KPU programs must be address-alias -safe Subroutine foo: SP -= 32 # 8 local vars …code ... SP += 32 # destroy frame return Subroutine foo: GP = SP SP -= 32 …code ... SP = GP return ● Left program returns different alias of SP to caller ● Many different encrypted values of each plain value! GoodBad
  9. 9. You can imagine ... ● Values have invisible extra bits ● 42.1101101 ● Represent different encryptions of '42' ● Arithmetic ignores but mutates the extra bits ● 42.1101101 + 42.1100001 = 84.0110110 ● Memory unit is sensitive to the extra bits ● Can't see just '42'. It's not privvy to own decryption ● KPU needs loving care from programmer
  10. 10. What's with the FHE connection? ● What exactly is fully homomorphic encryption? ● Encrypt(2) '+' encrypt(2)  encrypt(4) ● Likewise for multiplication, division … ● Good news: bank keeps a/c in your own FHE ● Does addition, interest, etc. as required ● Bank never finds out how much money you have ● Gentry (2009) discovered a feasible FHE ● IBM has implementation in 106 -bit cipherspace ● Seconds per 1-bit addition; vector acceleration ...
  11. 11. It turns out that ... ● The single design principle of a KPU is that its altered ALU does arithmetic encrypted: 1. encrypt(2) '+' encrypt(2)  encrypt(4) 2. '-' encrypt(2)  encrypt(-2) 3. encrypt(2) '<' encrypt(4) = (2 < 4) ● “The chosen encryption is a homomorphism be- tween primitive arithmetic functions & KPU ALU” ● Supplying a KPU is supplying the 'FHE operations' ● Constructing a KPU given the encryption is easy
  12. 12. What is a KPU good for? ● Classic answer .. anything FHE is good for: ● Run private computations in the cloud ● Nobody else can understand your data ● Configure encrypted processor safely in the clear ● DoD ought to like it! ● Different answer for KPU: ● Bank gives away KPU on smartcard ● Customers exchange $$$ offline; doing bank's work ● Don't need full 32-bit arithmetic, 1-bit logic suffices
  13. 13. While a KPU is a FHE ... ● You can give the bank your KPU ● Just copy its configuration to them – we're digital! ● Implements your FHE operations for the bank's use ● A FHE is not a KPU ● FHE: 'f'(encrypt(x))  encrypt(f(x)), any formula f ● KPU: 'f'(encrypt(state))  encrypt(f(state)), any computation f =/
  14. 14. How secure is a KPU? ● Big weakness: branch test circuitry leaks info! ● encrypted(x) '<' encrypted(y) = x < y {1,0} ● x<0 reveals top bit of x ● x+x <0 reveals second from top bit ... ● Defense: attacker can't tell + from *,/,>>,... ● And no constants are known ● So attacker doesn't really know how to decrypt! ● Why isn't the code for zero obvious? ● 0=0-0=1-1=2-2=3-3=... can't be recognized ● Always are multiple codes for each plain value!
  15. 15. Security news ● For theoreticians ... ● Believe KPU can run emulation of a CPU in its encrypted arithmetic subsytem, without branching ● Result is a … KPU again ● This bootstrapped KPU is better ● Does not reveal branch test results in plain sight ● Fully encrypted instructions and data, addresses ... ● Not even its control flow is visible ● Sets theoretical limit on how secure KPU may be ● Major concern is signalling via repeat memory access
  16. 16. Size: Back-of-Envelope Calculation ● 3 ciperspace bits = 1 plain bit ● 1-bit encrypted arithmetic ● + = ( 26  3 = 192 bits of info) ● 8!/4!4! = 70 ciphers with 4 codings each of 0,1 ● Use different cipher for each bit ● 7032 different ciphers of 32-bit words ● 32-bit addition needs 325 1-bit modules ● 325192 = 30720 bits FPGA ● 32-bit multiplication needs 322 52 1-bit modules ● 322 52 192 = 4915200 bits FPGA
  17. 17. Summary ● Homomophic and Fully Homomorphic Encryptions are 'holy grail' of cryptography for their possibilities ● E.g. RSA is homomorphic wrt multiplication ● Enables digital money security features ● KPU represents a new class of FHE technology ● Instead of making an E that is an H wrt the A... ● Implements the A[rithmetic] that makes the E a H ● Many open questions!Need to build one to answer! http://birmingham.academia.edu/PeterBreuer/Talks/

×