correctness of a secret computer (essos '13)

Correctness of a Secret Computer

Peter T. Breuer

University of Birmingham, UK

This talk is available athttp://birmingham.academia.edu/PeterBreuer/Talks/

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

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

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

Encrypteddata

Modified unit 1 Modified unit 2

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/

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!


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


What's up with 'aliasing'?● KPU programs must be address-alias -safe

Subroutine foo:

SP -= 32 # 8 local vars…code ...SP += 32 # destroy framereturn

Subroutine foo:GP = SPSP -= 32…code ...SP = GPreturn

● Left program returns different alias of SP to caller● Many different encrypted values of each plain value!

GoodBad

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

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

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

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

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

=/

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!

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

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 325 1-bit modules

● 325192 = 30720 bits FPGA

● 32-bit multiplication needs 32252 1-bit modules

● 32252192 = 4915200 bits FPGA

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!


correctness of a secret computer (essos '13)

Technology