21st Century Cryptography - Galois, Inc.

21st Century CryptographyDaniel M. Zimmerman and William Koven DARPA ERI Summit 2019, Detroit, Michigan — 17 July 2019

This material is based upon work supported by the Defense Advanced Research Projects Agency (DARPA) under Contract No. HR0011-19-C-0070. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the Defense Advanced Research Projects Agency (DARPA).

APPROVED FOR PUBLIC RELEASE, DISTRIBUTION UNLIMITED

© 2018 Galois, Inc.‹#› © 2019 Galois, Inc.

Security Depends on Cryptography• data in transit

• personal communications• financial transactions• command and control systems

• data at rest• personnel records• equipment schematics• inventory data• operational reports

2


Everyone Does Cryptography• software libraries• dedicated hardware

instructions

3


Everyone Does Cryptography• software libraries• dedicated hardware

instructions• Trusted Platform Modules

(TPMs)• Hardware Security Modules

(HSMs)• secure enclaves

4


Not Everyone Does Good Cryptography!

• incorrect implementations• weak protocols• bad random number

generation• information leakage through

side channels

5


Incorrect Implementations

• “gotofail” – a single duplicate “goto” statement in Apple’s code disabled SSL/TLS certificate verification on iOS and macOS

6

staticOSStatusSSLVerifySignedServerKeyExchange(SSLContext*ctx,boolisRsa,SSLBuffersignedParams,uint8_t*signature,UInt16signatureLen){OSStatuserr;//codeomittedforbrevityif((err=SSLHashSHA1.update(&hashCtx,&serverRandom))!=0)gotofail;if((err=SSLHashSHA1.update(&hashCtx,&signedParams))!=0)gotofail;gotofail;if((err=SSLHashSHA1.final(&hashCtx,&hashOut))!=0)gotofail;//codeomittedforbrevityerr=sslRawVerify(ctx,ctx->peerPubKey,dataToSign,dataToSignLen,signature,signatureLen);if(err){sslErrorLog("SSLDecodeSignedServerKeyExchange:sslRawVerify""returned%d\n",(int)err);gotofail;}fail:SSLFreeBuffer(&signedHashes);SSLFreeBuffer(&hashCtx);returnerr;}

whoops!

now we don’t runthis…

so we always say “OK”even when we shouldn’t


Weak Protocols

• many implementations of WPA2 – the WiFi security protocol that you’re probably using right now – are vulnerable to a Key Reinstallation attACK (KRACK)

7


Weak Protocols / Bad Random Number Generation

• NXP’s MIFARE Classic – a system used for transit cards in many cities worldwide – had a proprietary “Crypto-1” cipher and a bad hardware random number generator

• reverse engineering the hardware exposed both and led to the ability to recover any secret key in a matter of minutes

8


Bad Random Number Generation

• Sony’s PlayStation 3 used “random” numbers for signing key generation that were actually fixed, enabling unauthorized distribution of arbitrary software

9

http://xkcd.com/221/


Bad Random Number Generation• a randomness flaw was revealed

last month in Yubikey FIPS-series security keys — widely used by government personnel

• an attacker can reconstruct a private key just by getting access to a few (public) signatures

10


Bad Random Number Generation• a randomness flaw was revealed

last month in Yubikey FIPS-series security keys — widely used by government personnel

• an attacker can reconstruct a private key just by getting access to a few (public) signatures

• we could talk all day about the havoc wreaked by bad random number generation…

11


Information Leakage through Side Channels

• Spectre and Meltdown and their offspring have brought side channels to the forefront recently

• security features like Intel’s SGX and ARM’s TrustZone can be compromised by these side channels too

12



13

• almost no deployed cryptography in the world today has formal assurance



• almost no deployed cryptography in the world today has formal assurance

• no one is certain that it is correct or secure!

14


Why is So Much Cryptography Bad?

15

• implementations are incredibly easy to get wrong




• validation and certification processes are expensive, slow, and don’t always work

16




• validation and certification processes are expensive, slow, and don’t always work

• in fact, they can hurt: the Yubikey randomness flaw was directly caused by FIPS power-on self-tests!

17


AES-256 State Space

The Universe

Milky Way

Good Cryptography is Hard• AES-256 has incomprehensibly

huge space of possible inputs: 2256 (keys) x 2128 (blocks) = 2384

• the high end of estimates for the number of atoms in the universe is 2272

• exhaustively testing even a fast AES-256 implementation using 1 million CPUs, 24 hours a day, would take over 1060 years!

18

diagram not (even close) to scale


Good Cryptography is Hard

• testing for correctness, even using sophisticated testing schemes, is insufficient

19

AES-256 State Space




20

AES-256 State Space




• testing for security is a whole other can of worms

• so what can we do?

21


Formal Assurance through Mathematical Proof

• characterize and assess correct/incorrect behavior and security for all inputs, in all environments, all at once

• analogy: you don’t show the Pythagorean Theorem by testing different triangles, you prove it!

22

a2 + b2 = c2

a

b

c


Formal Assurance through Mathematical Proof

• characterize and assess correct/incorrect behavior and security for all inputs, in all environments, all at once

• specifications are always mechanized and usually compositional

• resulting evidence of correctness/security can be independently evaluated

23

a2 + b2 = c2

a

b

c


Galois’s Tools

Cryptol: a domain-specific language for specifying cryptographic algorithms

24

SAW: a tool for proving correctness of software and hardware descriptions

they help us provide formal specifications and mathematical

proofs of correctness


Correct-by-Construction Synthesis• we synthesize cryptographic

circuits directly from Cryptol specifications

• not just a single instance of each, but an entire product line• variation based on

cryptographic parameters (e.g., key sizes)

• variation based on performance, pipelining, synchronous vs. asynchronous implementation…

25

Cryptol

SPECIFICATION


Correct-by-Construction Synthesis

• as part of our high-assurance implementations, we synthesize test benches, documentation, and more

• enables efficient certification• enables others to use the

implementations effectively

26


Correct-by-Construction Synthesis

• synthesizing a product line enables PPAS optimization: tradeoffs among power, performance, area, and security

• can pick the “right” (or “best”) circuit for the job at hand

27


Side Channels

• there’s another aspect to the S in PPAS…

• mathematical proofs and correct-by-construction synthesis let us rule out incorrect primitive/protocol implementations and algorithmic insecurities

• what about side channels?

2828


Side Channels: Timing

• timing side channels leak information by taking different amounts of time to process a 1 or 0 bit if(key_bit==0){do_something_simple}else{do_something_complex}

29


Side Channels: Power

• power side channels leak information• processing a 1 or a 0 can

consume different amounts of power

• different operations can consume different amounts of power

30


Side Channels: EM

• when power draw changes, current flow changes, and changing current generates EM fields

• constant current at the boundary of the chip can hide changing currents within the chip that still create distinct EM signatures

31


Side Channel Resistance

• lots of ongoing research on how to mitigate side channels

• some well-researched existing techniques:• logic masking• current smoothing• noise generation

32


Side Channel Resistance: Masking

• logic masking involves obfuscating the encryption algorithm to spread secret information across multiple stages

• can be implemented during logic design

• can also mask lower level logic functions down to gates

33


Side Channel Resistance: Smoothing

• current smoothing, lower SNR by reducing signal• duplicate logic using dual rail

gates or duplicate whole blocks of logic with inverse inputs

• tank capacitors that smooth current and aim to maintain current at a constant average level

• use current sources to swamp current draw changes from the logic

• can require analog design techniques

34


Side Channel Resistance: Noise

• noise generation, lower SNR by increasing noise• analog noise generators• additional logic that is

uncorrelated to the secret key (e.g. duplicate function with a fake key)

• logic at varying voltages

35


Mitigation Technique: Randomization

• randomization has appeared in some literature, but not extensively

• the idea: confuse alignment of power/EM traces and thereby hide/de-correlate signal

• expected to have lower cost than some other techniques ⇒ very good PPAS tradeoff

36


Timing Resilient Design

• timing resilience allows for random events (PVT, other transient events) to upset timing while maintaining correct operation

• requires an asynchronous approach

37

!" ! "

100 200120 220 300

!"

240


Timing Resilience Facilitates Randomization

• timing resilience to random voltage/delays/etc. opens additional avenues to side channel resistance

• timing resilient asynchronous design is a critical part of our low power side channel resistance strategy

38


Multiple Independent Voltage “Islands”

• asynchronous design enables multiple independent “islands” of varying voltages across a chip, not just one supply voltage

• essentially performs both randomization and noise generation

39


Low Power ⇒ Low Signal/Noise Ratio

• running critical components at low voltages enables much lower SNR, requiring much more work (trace gathering, processing time) for correlation

• pipelining can be used to maintain performance even with some slow components

40


Low Power ⇒ Low Signal/Noise Ratio

• running critical components at low voltages enables much lower SNR, requiring much more work (trace gathering, processing time) for correlation

• pipelining can be used to maintain performance even with some slow components

41

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4

ENER

GY (n

J)

VOLTAGE (V)

Energy Consumption of Encrypting 1 Block


Randomization & Others

• randomization techniques are orthogonal to many logical masking techniques and current smoothing techniques

• multiple mitigation techniques can be combined to achieve different PPAS tradeoffs

42

+

+


Summary

crypto is hard, and security depends on doing it right

43

correct by construction is part of the solution

we’re implementing crypto circuits with multiple side channel mitigation techniques

including new ones leveraging timing- and power-resilient asynchronous design

21st Century Cryptography - Galois, Inc.

Documents

Transcript of 21st Century Cryptography - Galois, Inc.