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 .

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/