Midterm Recap Misuse of Crypto and Future Work Clipper chip A - - PowerPoint PPT Presentation

▶
midterm recap misuse of crypto and future work clipper
SMART_READER_LITE
LIVE PREVIEW

Midterm Recap Misuse of Crypto and Future Work Clipper chip A - - PowerPoint PPT Presentation

Apr 04, 2024 49 likes •645 views

Midterm Recap Misuse of Crypto and Future Work Clipper chip A lesson in poorly designed protocols Clipper Clipper Goal: Support encrypted communication Confidentiality between devices Goal: Permit law enforcement

slide-1
SLIDE 1

Midterm Recap
 
 Misuse of Crypto
 
 and Future Work

slide-2
SLIDE 2

Clipper chip

A lesson in poorly designed protocols Goal:
 Confidentiality Support encrypted communication
 between devices Permit law enforcement to obtain
 “session keys” with a warrant Goal:
 Key escrow

Clipper Clipper

slide-3
SLIDE 3

Clipper chip: Design

Tamper-proof hardware Skipjack
 encryption algorithm

Hardware that is difficult to introspect (e.g., extract keys), alter (change the algorithms),

  • r impersonate

Diffie-Hellman
 key exchange LEAF generation & validation Skipjack Keys


Unit key
 Global family key

slide-4
SLIDE 4

Clipper chip: Design

Tamper-proof hardware Skipjack
 encryption algorithm

Block cipher designed by the
 NSA, originally classified
 SECRET. (Violates Kirchhoff’s principle) 
 Broken within one day of declassification. 80-bit key; similar algorithm to DES (also broken)

Diffie-Hellman
 key exchange LEAF generation & validation Skipjack Keys


Unit key
 Global family key

slide-5
SLIDE 5

Clipper chip: Design

Tamper-proof hardware Skipjack
 encryption algorithm

Assigned when the hardware
 is manufactured. Unit key is unique to this unit
 in particular (each Clipper chip
 also has a unit ID). Global family key is the same
 across many units.

Diffie-Hellman
 key exchange LEAF generation & validation Skipjack Keys


Unit key
 Global family key

slide-6
SLIDE 6

Clipper chip: Design

Tamper-proof hardware Skipjack
 encryption algorithm

Used for establishing a
 (symmetric) session key Session keys are ephemeral (e.g., last only for a given connection, transaction, etc.) General properties about session keys:

  • Compromising one session key


does not compromise others

  • Compromising a long-term key


should not compromise past
 session keys (forward secrecy)

Diffie-Hellman
 key exchange LEAF generation & validation Skipjack Keys


Unit key
 Global family key

slide-7
SLIDE 7

Clipper chip: Design

Tamper-proof hardware Skipjack
 encryption algorithm Diffie-Hellman
 key exchange LEAF generation & validation Skipjack Keys


Unit key
 Global family key

LEAF
 (Law Enforcement Access Field)

To permit wiretapping, law
 enforcement needs to be able
 to extract session keys, but


  • nly has access to what is sent


during communication Idea: send data that has enough
 info to allow law enforcement
 to extract keys (but not any


  • ther eavesdropper).
slide-8
SLIDE 8

LEAF protocol design

Clipper Clipper

  • 1. DH key exchange
  • 2. Each send LEAF packet

The Clipper chips will not decrypt until
 it has received a valid LEAF packet

  • 3. Send data encrypted


with the session key Law enforcement sees all packets.

  • Cannot infer key from DH key exchange
  • Can infer it from the LEAF packet
slide-9
SLIDE 9

LEAF message structure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables

slide-10
SLIDE 10

LEAF message structure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables The other Clipper chip also has the Global Family key => Can decrypt the LEAF to obtain this triple

slide-11
SLIDE 11

LEAF message structure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables The other Clipper chip “verifies” the LEAF by making sure that
 the hash is correct

slide-12
SLIDE 12

LEAF message structure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables Law enforcement also has the Global Family Key => Can decrypt the LEAF to obtain this triple

slide-13
SLIDE 13

LEAF message structure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables Law enforcement does not have direct access
 to all unit keys; needs a warrant to get them Unit keys are split across two locations (one location gets a OTP, the other gets the XOR)

slide-14
SLIDE 14

LEAF: failure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables To verify the LEAF,
 the otherClipper chip


  • nly checks the hash

Clipper chips also allow you to
 test a LEAF locally

slide-15
SLIDE 15

LEAF: failure

Session key 80 bits Skipjack Unit Key Hash algorithm 16 bits Encrypted session key Hash Unit ID Global family key Skipjack LEAF Other
 variables Encrypted session key Hash Unit ID Generate a random LEAF =>
 1/216 chance of a valid hash

Validates at the other
 Clipper chip (so it will
 decrypt messages) But law enforcement will just
 see random ID & key

slide-16
SLIDE 16

Misusing crypto

  • Do not roll your own cryptographic mechanisms
  • Takes peer review
  • Apply Kerkhoff’s principle
  • Do not misuse existing crypto
  • Do not even implement the underlying crypto

Avoid shooting yourself in the foot:

slide-17
SLIDE 17

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

slide-18
SLIDE 18

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
slide-19
SLIDE 19

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
  • 2. Do not use a non-random IV for CBC encryption.
slide-20
SLIDE 20

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
  • 2. Do not use a non-random IV for CBC encryption.
  • 3. Do not use constant encryption keys.
slide-21
SLIDE 21

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
  • 2. Do not use a non-random IV for CBC encryption.
  • 3. Do not use constant encryption keys.
  • 4. (see paper)
slide-22
SLIDE 22

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
  • 2. Do not use a non-random IV for CBC encryption.
  • 3. Do not use constant encryption keys.
  • 4. (see paper)
  • 5. (see paper)
slide-23
SLIDE 23

A paper from 2013 that looked at how Android
 apps use crypto, as a function of 6 “rules” that reflect
 the bare minimum a secure programmer should know:

  • 1. Do not use ECB mode for encryption. Period.
  • 2. Do not use a non-random IV for CBC encryption.
  • 3. Do not use constant encryption keys.
  • 4. (see paper)
  • 5. (see paper)
  • 6. Do not use static seeds to seed SecureRandom(.)
slide-24
SLIDE 24

Crypto misuse in Android apps

15,134 apps from Google play used crypto; Analyzed 11,748 of them

slide-25
SLIDE 25

48% 31% 17% 16% 14% 12%

Crypto misuse in Android apps

15,134 apps from Google play used crypto; Analyzed 11,748 of them

slide-26
SLIDE 26

48% 31% 17% 16% 14% 12%

Crypto misuse in Android apps

15,134 apps from Google play used crypto; Analyzed 11,748 of them

slide-27
SLIDE 27

BouncyCastle defaults

  • BouncyCastle is a library that conforms to Java’s

Cipher interface:

  • Java documentation specifies:

Cipher c =
 Cipher.getInstance(“AES/CBC/PKCS5Padding”); 
 // Ultimately end up wrapping a ByteArrayOutputStream
 // in a CipherOutputStream

slide-28
SLIDE 28
slide-29
SLIDE 29
slide-30
SLIDE 30

Crypto misuse in Android apps

15,134 apps from Google play used crypto; Analyzed 11,748 of them

48% 31% 17% 16% 14% 12%

slide-31
SLIDE 31

Crypto misuse in Android apps

15,134 apps from Google play used crypto; Analyzed 11,748 of them A failure of the programmers to know the tools they use A failure of library writers to provide safe defaults

48% 31% 17% 16% 14% 12%

slide-32
SLIDE 32

Misusing crypto

  • Do not roll your own cryptographic mechanisms
  • Takes peer review
  • Apply Kerkhoff’s principle
  • Do not misuse existing crypto
  • Do not even implement the underlying crypto

Avoid shooting yourself in the foot:

slide-33
SLIDE 33

Why not implement AES/RSA/etc. yourself?

  • Not talking about creating a brand new crypto

scheme, just implementing one that’s already widely accepted and used.

  • Kerkhoff’s principle: these are all open standards;

should be implementable.

  • Potentially buggy/incorrect code, but so might be
  • thers’ implementations (viz. OpenSSL bugs, poor

defaults in Bouncy castles, etc.)

  • So why not implement it yourself?
slide-34
SLIDE 34

Side-channel attacks

  • Cryptography concerns the theoretical difficulty in

breaking a cipher

Cryptographic processing
 (Encrypt/decrypt/sign/etc.) Secret keys

Input
 message Output
 message

slide-35
SLIDE 35

Side-channel attacks

  • Cryptography concerns the theoretical difficulty in

breaking a cipher

Cryptographic processing
 (Encrypt/decrypt/sign/etc.) Secret keys

Input
 message Output
 message

  • But what about the information that a particular

implementation could leak?

  • Attacks based on these are “side-channel attacks”
slide-36
SLIDE 36

Side-channel attacks

  • Cryptography concerns the theoretical difficulty in

breaking a cipher

Cryptographic processing
 (Encrypt/decrypt/sign/etc.) Secret keys

Input
 message Output
 message

Leaked information


  • Power consumption

  • Electromagnetic radiation
  • Other (Timing, errors, etc.)
  • But what about the information that a particular

implementation could leak?

  • Attacks based on these are “side-channel attacks”
slide-37
SLIDE 37

Simple Power Analysis (SPA)

  • Interpret power traces taken during a

cryptographic operation

  • Simple power analysis can reveal the sequence of

instructions executed

slide-38
SLIDE 38

SPA on DES

Overall operation clearly visible:
 Can identify the 16 rounds of DES

slide-39
SLIDE 39

SPA on DES

Overall operation clearly visible:
 Can identify the 16 rounds of DES

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

slide-40
SLIDE 40

SPA on DES

Specific instructions are also discernible

slide-41
SLIDE 41

SPA on DES

Specific instructions are also discernible Jump taken No jump taken

slide-42
SLIDE 42

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

slide-43
SLIDE 43

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t?

slide-44
SLIDE 44

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t? Implementation issue: If the execution path depends

  • n the inputs (key/data), then SPA can reveal keys
slide-45
SLIDE 45

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t? Implementation issue: If the execution path depends

  • n the inputs (key/data), then SPA can reveal keys

What if branch 0

slide-46
SLIDE 46

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t? Implementation issue: If the execution path depends

  • n the inputs (key/data), then SPA can reveal keys

What if branch 0

  • took longer? (timing attacks)
slide-47
SLIDE 47

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t? Implementation issue: If the execution path depends

  • n the inputs (key/data), then SPA can reveal keys

What if branch 0

  • took longer? (timing attacks)
  • gave off more heat?
slide-48
SLIDE 48

HypotheticalEncrypt(msg, key) { for(int i=0; i < key.len(); i++) {
 if(key[i] == 0) // branch 0 else // branch 1 } }

High-level idea

What if branch 0 had, e.g.,
 a jmp that brand 1 didn’t? Implementation issue: If the execution path depends

  • n the inputs (key/data), then SPA can reveal keys

What if branch 0

  • took longer? (timing attacks)
  • gave off more heat?
  • made more noise?

  • …
slide-49
SLIDE 49

Differential Power Analysis (DPA)

  • SPA just visually inspects a single run
  • DPA runs iteratively and reactively
  • Get multiple samples
  • Based on these, construct new plaintext messages

as inputs, and repeat

slide-50
SLIDE 50

Mitigating such attacks

  • Hide information by making the execution paths

depend on the inputs as little as possible

  • Have to give up some optimizations that depend on

particular bit values in keys

  • Some Chinese Remainder Theorem (CRT) optimizations

permitted remote timing attacks on SSL servers

  • The crypto community should seek to design

cryptosystems under the assumption that some information is going to leak

slide-51
SLIDE 51

Other side-channel attacks

  • Typical threat model: attacker doesn’t have root

access to a particular machine

  • So we safely store keys in memory
  • But what if the attacker had physical access to the

machine?

slide-52
SLIDE 52

Attack

  • Attacker’s goal: reboot the machine into an OS that

that he or she controls to look at memory contents

  • Challenge: memory loses state without power

5 sec 30 sec 60 sec 5 min

slide-53
SLIDE 53

Cold boot attack

Memory loses its state slower
 at really cold temperatures

slide-54
SLIDE 54

Cold boot attack

Memory loses its state slower
 at really cold temperatures

slide-55
SLIDE 55

Cold boot attack

Memory loses its state slower
 at really cold temperatures

slide-56
SLIDE 56

Cold boot attack

  • Launching the attack:
  • Cool down the memory & then power off/take it out
  • Boot into your own OS
  • Scan the memory image for keys (non-trivial but

doable, especially if the keys have a format that’s easy to detect)

  • Some defenses against the attack:
  • Encrypt all of memory (increased CPU support for this)
  • Use trusted hardware (Xbox does this)
  • TPM (Trusted Platform Module) stores keys in hardware that is

very difficult to inspect (some self-destruct)

  • Limit the amount of time keys live in memory
  • E.g., remove keys from memory when you enter Sleep mode
slide-57
SLIDE 57

Misusing crypto

  • Do not roll your own cryptographic mechanisms
  • Takes peer review
  • Apply Kerkhoff’s principle
  • Do not misuse existing crypto
  • Do not even implement the underlying crypto

Avoid shooting yourself in the foot:

slide-58
SLIDE 58

Ongoing work in crypto

  • Constantly attacking/defending crypto schemes
  • Must stay on top of best practices
  • Ideally, write your code so you can change easily
  • New mechanisms to permit new types of interactions
  • A style of interaction that’s been getting a lot of attention:
  • Alice has proprietary data
  • Bob has proprietary code (or computational resources)
  • Goal: Bob runs his code on Alice’s data without learning her

input or the output

slide-59
SLIDE 59

Some things to look for

  • Fully homomorphic encryption
  • Normal encryption: D(k, E(k, m)) = m
  • FHE: D(k, F( E(k, m))) = F(m)
  • Secure multiparty computation
  • Alice and Bob both have data and want to know the
  • utput of a function over their private data, without

having to reveal their data to each other

  • E.g., “which of us has more money” without having to

reveal exactly how much either has