UMSSIA DAY V: SECRETS OF THE CRYPT…

The goal of cryptography is to provide a “” between Alice and Bob.

Alice Bob Eve A secure channel: 1. Leaks NO information about its contents 2. Delivers only messages from Alice and Bob 3. Delivers messages in order or not at all CRYPTOGRAPHY

The goal of cryptography is to provide a “secure channel” between Alice and Bob.

Alice Bob Eve The channel should remain secure even though Eve can inspect, modify or drop any message, and control all but one bit of the channel contents. KEYS

There exist some physically “hard to break” channels.

Symmetric cryptography uses a temporary or slow secure channel to establish a secret .

Alice Eve Bob

Knowing the key is what lets Alice and Bob keep secrets from Eve. CAESAR’S CIPHER

To write a secret message,

1) Write down each plaintext letter

ATTACK AT DAWN 2) Count ahead t h rKe e lleetttteerrss ffrroomm eeaacchh plaintext letter to get a letter. A T T A C K A T D A W N B U U B D L B U E B X O C V V C E M C V F C Y P D W WD F N D W G D Z Q SUBSTITUTION

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z O L Y M P I C S K A T E R Z X W V U Q N J H G F D B

MICHELLE KWAN ! RKYS PEEP TGOZ

NSOU MKZC ! T HARDING

GSDG SDDD ! WHY WHYYY

How many possible keys? 26 £ 25 £ 24 £ … = 4.03 £ 1026 BREAKING SUBSTITUTION

MOST COMMON I T IS NO T WH A T H E HA S ENGLISH LETTERS:

OR E V E N WHA T H E DO ES ETAOINSHR…

WH I C H E X PR E SS E S THE

WO R T H O F A MAN B UT

WHA T H E I S

FREQUENCY ANALYSIS: GUESS MOST COMMON LETTER = E, T, A, O, I, N, S, H, R… POLYALPHABETIC ROTATION

… uses a different rotation for each letter. Plaintext: A T T A C K A T D A W N Key: CYA Ciphtertext: C R T C A K C R D C U N

How would you break polyalphabetic rotation?

“Modern” variant: the Vigenere cipher uses XOR.

Special case: The One Time Pad has |key|=|msg| Any plaintext can encrypt to any ciphertext! STREAM CIPHERS

… are computerized approximations to the OTP. A combines a short key and IV to make a long, pseudorandom keystream.

If no one can tell the stream apart from random without the key, Eve can’t read the ciphertext. Keystream

Key Stream 0xA6C2777014777EE9813 IV Generator © 0xDEADBEEF45AlE218400 Plaintext = 0x786FC99F51D69CF1C13 EXAMPLES

RC4 is a popular stream cipher because its code is short. RC4 has distinguishing attacks for 64MB files. There are many ways to use RC4 insecurely, e.g. WEP.

LFSRs are popular in hardware crypto, due to low gate count. They are usually trivial to break.

NESSIE: No approved stream ciphers

(Figures from Wikipedia) BLOCK CIPHERS P … take as input a key and a block of bits. The output is Key a random-looking block of Encrypt bits. C With the key, it is easy to invert the cipher. Key Decrypt Without guessing the key, it is impossible to tell the inputs and outputs apart P from random bits. Block Width MODES

… build encryption schemes for any input length out of block ciphers for fixed input lengths.

Example: Electronic Codebook Mode

ECB-Encrypt (Block[] P, Block[] C) : for(i = 0; i < P.len; i++) C[i] = Encrypt(P[i]);

ECB-Decrypt (Block[] P, Block[] C) : for(i = 0; i < C.len; i++) P[i] = Decrypt(C[i]);

If you see a product using ECB, run - don’t walk - away! SECURE MODES CBC-Encrypt (Block[] P, Block[] C) : C[0] = RandomBlock(); for(i = 0; i < P.len; i++) C[i+1] = Encrypt(P[i] XOR C[i]);

CBC-Decrypt (Block[] P, Block[] C) : for(i = 1; i < C.len; i++) P[i-1] = C[i-1] XOR Decrypt(C[i]); CTR-Encrypt (Block[] P, Block[] C) : C[0] = RandomBlock(); for(i = 0; i < P.len; i++) C[i+1] = Encrypt(C[0]+i) XOR P[i];

CTR-Decrypt (Block[] P, Block[] C) : for(i = 1; i < C.len; i++) P[i] = Encrypt(C[0]+i) XOR C[i]; THE

The Advanced Encryption Standard, or AES, was chosen as the result of a five-year competition.

AES has security proofs against most known attacks on block ciphers.

AES is fast in hardware, fast in software, and friendly to embedded processors. CRYPTOGRAPHY

The goal of cryptography is to provide a “secure channel” between Alice and Bob.

Alice Bob Eve A secure channel: 1. Leaks NO information about its contents 2. Delivers only messages from Alice and Bob 3. Delivers messages in order or not at all INTEGRITY … Is the property that a message has not been modified by anyone but the sender.

Alice Eve Bob

A channel provides integrity if Eve cannot make new, valid messages even after seeing Alice and Bob send many of them. HASH FUNCTIONS

... map long input strings to short output strings.

e.g. H(x,y,z) = x + y + z H(x) = x mod 65537

Hash functions may have a key, e.g.:

Ha,b,p(x) = ax + b mod p

When (a,b,p) are used only once, Ha,b,p(x) can be appended to x to prevent modification. CRYPTO HASH FUNCTIONS

… Are fixed hash functions with outputs that “look random” to an adversary. A cryptographic hash function should resist the following attacks: 1. “inversion” or preimage: given y, find any x so that H(x)=y.

2. Targeted collisions: given x, H(x), find x’≠ x where H(x’) = H(x).

3. Free collisions: find x’ ≠ x where H(x)=H(x’). HASH FUNCTION STRENGTH

For any function H with k-bit outputs, how long (at most) does it take to find:

1. Preimages? 2k hashes.

2. Targeted Collisions? 2k hashes.

3. Free Collisions? 2k/2 hashes.

Because of this birthday attack a k-bit hash function has at most “k/2 bits of security” against free collisions. HASH FUNCTION WEAKNESS We know some good hash functions (SHA-256, Whirlpool) and there is work on others.

… but sending (m, H(m)) does not create a channel with integrity against adversaries.

For that, we need something with a key: a Message Code, or MAC. MACs

A MAC takes a key and message and outputs a Key Tag M random- looking “tag” of fixed length.

The verification function T checks that a tag matches a message and key. Verify It should be hard to find a new correct tag without knowing the key. YES/NO

Even if the adversary gets to see many messages and tags. BUILDING MACs

CBC-MAC builds a MAC out of a block cipher in CBC mode.

It is only secure if all messages use the same number of blocks.

HMAC builds a MAC out of a crypto hash function.

HMACK(m) = H(0x5c © K, H(0x36© K, m)) Breaking HMAC involves finding collisions in the Hash function. SECURE CHANNELS A secure channel: 1. Leaks NO information about its contents 2. Delivers only messages from Alice and Bob 3. Delivers messages in order or not at all

Alice Eve Bob

To send Mi, do C = Encrypt(M); T = Tag(C, i). Send (i, C, T). WHY INTEGRITY? Without integrity protection, chosen ciphertext attacks become a threat.

Alice sends C = RC4-EncryptK(8CharPassword).

Bob checks that strlen(password) is exactly 8. If not, replies with warning: “8 letters only!” Else, does expensive password check.

Eve sends C©0x0100000000000000 – quick response means first char = 0x01! Else try 0x02, 0x03… 0xFF.

Integrity protects such attacks – Eve can’t make new to try! CHEAP INTEGRITY

One objection to MACing ciphertexts is that the cost of encryption doubles.

To circumvent this limitation, there exist authenticated encryption modes that encrypt N blocks with less than 2N block cipher calls.

The new NIST standard for such modes is Galois Counter Mode (GCM). GCM is fast and free. CRYPTOGRAPHY

Alice Eve Bob

Given a we can build a channel that: 1. Leaks NO information about its contents 2. Delivers only messages from Alice and Bob 3. Delivers messages in order or not at all

WHAT IF NO SHARED SECRET IS AVAILABLE? PUBLIC-KEY CRYPTO

Bob publishes public (encryption) key PK keeps secret secret (decryption) key SK Eve c

Alice Bob Get Bob’s Public Key Compute p = D(SK,c) compute c = E(PK,m) Even though Eve knows PK and all but one bit about m, she should not learn the contents of p. PUBLIC KEY SCHEMES

• “Vanilla” or “Textbook” RSA: –Keys: choose p, q prime. N = pq e £ d mod (p-1)(q-1) = 1 PK = (N, e); SK = (N,d) –Encrypt: c = me mod N –Decrypt:p = cd mod N • Vanilla RSA is insecure! PUBLIC KEY SCHEMES

• El Gamal: Let p, q be prime and p = 2q+1 – Keys: pick x mod q. SK = x; PK = y = gx mod p – Encrypt(m q, set m = p-m. • El Gamal is secure if Eve can’t modify or inject packets. HYBRID ENCRYPTION

• AES encryption is fast. (~1Gbps in Software; ~10Gbps in Hardware) • RSA and El Gamal are slow. – Software: ~100Kbps (RSA encrypt ~1Mbps) – Hardware: ~1Mbps (RSA encrypt ~10Mbps) – Elliptic curves: £ 10 • Hybrid Encryption schemes get public key properties with private key speed: – Pick random K – encrypt K with PK scheme, – Encrypt m with symmetric key K SECURE HYBRID RSA RSA-KEM: • Keys: choose p, q prime; N = pq e £ d mod (p-1)(q-1) = 1 PK = (N, e); SK = (N,d) • Encrypt: pick r mod N K = H(r) e c1 = r mod N c2 = E(K,m) d • Decrypt: K = H(c1 mod N) p = D(K,c2) • (E,D) must be integrity-aware secure symmetric scheme • Also: RSA-OAEP, RSA-PKCS2 SECURE HYBRID ELGAMAL

• Keys: pick x mod q SK = x; PK = y = gx mod p • Encrypt: pick r mod q r r z = y mod p; c1 = g mod p K1 = HMAC(z,1)

c2 = E(K1, m) c3 = HMAC(z, 0||c1||c2) • Also ECDHIES, Cramer-Shoup IDENTITY-BASED ENCRYPTION

TRENT publishes MASTER key MPK and keeps secret master secret key MSK

c

Alice BSK Bob p = D(BSK,c) c=EMPK(“Bob”, m)

Trent DIFFIE HELLMAN Problem: Hard to find a given A, p A=ga mod p

B=gb mod p

K=Ba mod p K=Ab mod p

Shared key: K=gab mod p MAN IN THE MIDDLE

A=ga A’=ga’

B’=gb’ B=gb

K=B’a mod p K’=A’b mod p

K’ ≠ K but Alice & Bob think they are! STATIC DIFFIE HELLMAN

Official Public Keys Alice………………….A Bob…………………..B Carol…………………C Dave…………………D SK = a M SK = b a b Kab=B Kab=A

ab Shared key: Kab=g mod p ULTIMATE DIFFIE HELLMAN

• Alice and Bob have public keys A=ga,B=gb • Want to exchange “session” key K so that: – K will be secret even if a and b leak. – Prevent Man in the middle: Only Alice and Bob know K; Mallory can’t force K ≠ K’ – If Mallory learns K, can’t figure out a or b. – If Mallory learns a, he can’t fool Alice • The “state of the art” protocol is HMQV http://eprint.iacr.org/2005/176.pdf • But how do we know that A and B are really Alice and Bob’s public keys? DIGITAL SIGNATURES

Alice publishes verification key VK keeps secret signing key SK

m,s

Alice Anyone

Computes signature on m Verify: what’s VKAlice? s = S(SK,m) Verify: is s valid on m? V(VK,m,s) = YES/NO Signatures provide nonrepudiation: only Alice (or whoever knows SK) could have said m. IMPORTANT Digital signatures are NOT “encryption with the private key” SCHEMES

• DSA: prime p = 2q+1 – Keys: pick x mod p. SK = x mod p; VK = y = gx mod p – Sign: pick k mod q. let r = gk, w = (h(m)+xr)/k mod q s = r,w – Verify: gh(m)yr mod p = rw mod p • Also: ECDSA, KCDSA, Schnorr, BLS… DIGITAL SIGNATURE SCHEMES

• RSA-FDH: let H output n-1 bits – Keys: choose p, q prime. 2n > N = pq > 2n-1 v £ s mod (p-1)(q-1) = 1 VK = (N, v); SK = (N,s) – Sign: S = H(m)s mod N – Verify: Sv mod N = H(m) ? • “Vanilla RSA” and RSA-PKCS#1 are not secure. • Also: RSA-FDH, RSA-PSS, RSA-KW CERTIFICATES

• Digitally signed: Oct 5, 2005 – Encryption PK – Signature VK I hereby certify that – “Identity” the hash of the public – (opt) Signer key of Name [email protected] – (opt) Expiry Date Is:

– Cert. Type 0x15fd06ee754b36697c524c21fae25d1f • How do we verify Signed, the cert? MacroSquash Corp. CERTIFICATE CHAINS

Oct 5, 2005 Oct 5, 2005 I hereby certify that the hash of the public key of I hereby certify that [email protected] the cert-signing key Is: 0x15fd06ee754b36697c524c21fae25d1f Signed, Of MacroSquash Corp. MacroSquash Corp Is:

0xcbb7ccaddbe7692cb7a4290244479c3c Signed, Squash Group Intl CERTIFICATE CHAINS

Oct 5, 2005 Oct 5, 2005 Oct 5, 2005 I hereby certify that I hereby certify that the cert-signing key the hash of the public I hereby certify that Of key of MacroSquash Corp [email protected] the cert-signing key Is: Is:

0xcbb7ccaddbe7692cb7a4290244479c3c 0x15fd06ee754b36697c524c21fae25d1f Of Signed, Signed, Squash Group Intl MacroSquash Corp. Squash Group Intl Is:

0x33666c857616c7f5afdbfc525b9d68e8 Signed, Squash Group Intl PUBLIC KEY INFRASTRUCTURE

PKI a generic term for any method of binding PKs and VKs to names.

PKI is also used as a reference to a specific, hierarchical approach: – Public Key Certificates are signed by Certification Authorities (CAs) – CAs themselves have certificates that specify their authority (eg *.cs.umn.edu) and are signed by “Parent CAs” (eg *.umn.edu) – There are a few “Root CAs” (self-certified), whose signing keys are “well-known” and ship with OSes, are published in newspapers, etc. – CAs are trusted. Are they trustworthy? PLATONIC PKI

Root CA (Verisign) … Microsoft

Windows Email Web server

Driver Critical Marketing Signing Updates Research REAL-WORLD PKI

Root CA (Verisign) umn.edu cmu.edu …

Web Web Mechant1 MerchantN

Root certification is expensive and not entirely trustworthy. Many organizations self-sign and include certificate in local installations. PGP AND THE WEB OF TRUST

• PGP is a program and standard for email encryption with no CAs. • Each user has a keyring of trusted keys – Some are personally verified (e.g. face to face) – Some are pre-trusted keys • Public Keys are published on PGP key servers • Users sign each other’s keys, including a level of “confidence” in the correctness of the binding. • The decision whether to accept a PK : Name binding is local. For example, PGP recommends counting the number of disjoint key sig. paths from your keyring to PK. WEB OF TRUST

• Decisions about public key bindings can be made by any local policy: eg length of paths, number of paths, minimum cert level along paths… • Keyservers help by doing path computations. • E.g. Find paths from Wietse Venema to Phil Zimmerman: 7 paths; max length 4, min length 2. REVOCATION • One big problem for PKI is what to do when a Certificate is wrong: – Secret Keys may be compromised, lost or destroyed – Bindings may become invalid (employees leave companies, get new positions, etc.) • One solution is to revoke or invalidate the certificate. • The most common mechanism is via Certificate Revocation Lists: – Every Cert includes a “revocation server” – Lists of revoked keys are published by Root CAs – PGP pushes revocations to Key Servers. – Validating certificates requires contacting revocation servers. CRYPTO FAILURES

• Good crypto algorithms are hard to design but easy to find on the web. • Building robust security protocols, even from secure algorithms, is also hard. • Subtle bugs can be found 10+ years after public scrutiny. Anderson and Needham compare crypto protocol design to “Programming Satan’s Computer.” WARMUP

ACCT#, EK(PIN)

MN,, EEPP , PIN

$$ Ã Acct. NM If EK(PIN) = EP WOO-LAM 1. Alice

2. NB, a Nonce.

3. CA = EKas(NB)

4. EKbs(A,CA)

5. EKbs(NB) ON THE WOO-LAM

1. Alice 2. Eve

3. NBA 4. NBE 5. CA = JUNK 6. CE = EKes(NBA)

7. EKbs(A,CA) 9. EKbs(NBA) 8. EKbs(E,CB) WOO-LAM FIX? 1. Alice

2. NB, a Nonce.

3. CA = EKas(NB)

4. EKbs(A,CA)

5. EKbs(A,NB) WOO-LAM FIX?

1. Alice 2. Alice

3. NB 4. NB 5. C = E (N ) A Kas B 6. CA

7. EKbs(A,CA)

8. EKbs(A,NB) WOO-LAM FIX II 1. Alice

2. NB

3. CA = EKas(B,NB)

4. EKbs(A,CA)

5. EKbs(A,NB) X.509

MA = (TS,SN,B,EncB(X)) SA = SignA(MA)

EncA(X) X.509

MA = (TS,SN,B,EncB(X)) SA = SignA(MA)

EncA(X) Enc (X) MA,SignE(MA) E DENNING-SACCO

3. CA,CB,EncB(TS, KAB, SignA(TS,KAB))

1. 2. CA = VKa, SignS(A,VKa) A,B CB = PKb, SignS(B,PKb)

Published 1982. DENNING-SACCO DISASTER

3. CA,CE,EncE(TS, KAE, SignA(TS,KAE))

4. CA,CB, Enc (TS, K , σ) 1. B AE A,E 2. CA = VKa, SignS(A,VKa) CE = PKe, SignS(E,PKe)

Broken 1994. 12 years later! NEEDHAM-SCHROEDER

Needham & Schroeder, “Using encryption for auth- entication in large networks of computers,” 1978.

A,B,EB(Na)

A,B,EA(Na,Nb)

A,B,EB(Nb)

Shared Key: H(Na,Nb) NEEDHAM-SCHROEDER

Lowe, 1995, “Breaking and Fixing the Needham- Schroeder public key protocol”

A,M,EM(Na) A,B,EB(Na)

A,B,EA(Na,Nb) A,M,EA(Na,Nb)

A,M,EM(Nb) A,B,EB(Nb)

It took 17 years to find Shared Key: H(Na,Nb) this bug! Bob thinks it is Alice, not Mallory! WIDE-MOUTHED FROG

2. E (T+ ,A,K ) 1. EKas(T,B,Kab) Kbs δ ab

3. EKbs(T+δ,A,Kab)

4. EKas(T+2δ,B,Kab)

Share key Kab TMN

r 3 mod N 3 B S rA mod NS

rA© rB

Shared key is rB. TMN

r 3 r 3 mod N 3 B C S rD mod NS

MCD = rB rC© rD

rB = (rD © MCD)/rC OTHER BUGS

Many fail due to poor “key management” practices: Using passwords or Hash(pw) as keys

Choosing “random” numbers that aren’t. (e.g. C rand(); java math.Random… )

Reuse of passwords and keys

Unintentional “leaking” of plaintexts, keys NETSCAPE SSL BUG

In SSL, the client (e.g. netscape) picks a secret key and encrypts it to the server’s Public Key.

Subsequent messages are encrypted with the client’s chosen key.

Netscape 1.1 keys: H(time_µsec, pid, ppid)

Problem: TCP gives away time in ms, ppid=1, pid is only 16 bits, and other programs leak current pids! SIDE-CHANNEL ATTACKS

Most crypto assumes computers are “black boxes” that compute functions instantaneously.

Real computers take time to compute and interact with their environments.

Simple example: TEMPEST equipment reads monitors from their EM radiation.

TIMING ATTACKS

Time between keystrokes depends on keys. SSH clients send packets on keystrokes. www.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf

Time to compute xy mod N depends on x,y. Given many (p,c) pairs and compute times, we can recover RSA private keys. www.cryptography.com/timingattack/

The fastest implementations of AES use four 1024-byte tables. Cache misses leak key bits. cr.yp.to/antiforgery/cachetiming-20050414.pdf www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf HELPFUL DEBUGGING ATTACKS

Well-known bug: “incorrect password” vs. “user not found” leaks account names.

RSA-OAEP attack: “integer too large” vs. “decoding error” leaks plaintext bits! http://www.springerlink.com/content/tw5tuqb3hxbn9grq/

SSL CBC attack: “decryption failed” vs “bad record MAC” can leak plaintext bits. lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps PHYSICAL SIDE CHANNELS

“Smart cards” can have variable power use, EM emissions, and temperatures.

Clock frequency can vary by temperature and workload.

Optical emissions can leak temperature etc… SSH OVERVIEW

client server

TCP connection setup

SSH version string exchange

SSH key exchange (includes algorithm negotiation)

SSH Authentication

SSH data exchange

termination of TCP connection SSH KEY EXCHANGE

X=gx

Client Server VKS, Y, S=SignS(h) Y = gy K = Xy = gxy x K’ = Y , h = H(VKS|X|Y|K ) h = H(VKS|X|Y|K’) use K’ if Verify(VKS,h,S) SSH AUTHENTICATION

The server is authenticated by S and VKS – Client has a local database (ssh_known_keys) that associates each server S with VKS. st – On 1 exchange, VKS is added to ssh_known_keys. – May also use PKI, certificates The client may be authenticated in several ways: – Password: entered by user and sent over encrypted connection. – Public Key: the user signs a challenge from the server to be verified using her public key – Trusted Host: the user’s host signs a challenge to be verified with its public key. SSH PACKET FORMAT

packet length (4) –packet length: • length of the packet not padding length (1) including the MAC and the packet length field –payload: payload • useful contents of the packet • May be compressed • max payload size is 32768 –random padding: random padding • 4 – 255 bytes • total length of packet must be MAC multiple of 16 –MAC: encryption • computed over clear packet and sequence number TLS PROTOCOL LAYER

http ftp telnet Application nntp

SSL/TLS

Transport (TCP)

Internet (IP) Network interface Physical layer SSL/TLS

ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone [Certificate], C ClientKeyExchange, S [CertificateVerify]

switch to negotiated cipher

Finished switch to negotiated cipher Finished KEY SSL IDEAS

• Authentication is handled using certificate authorities (PKI) – CAs have “widely known” verification keys, e.g. Verisign, AT&T, MCI, Keywitness Corp Canada – CA supplies a signed certificate with site’s public key • Session integrity based on MAC of history – e.g. Client & server communicate as follows: Hi Client Hello Server How are you?

– Client and server compare MACs of all messages • Server computes MAC(hi,hello,howareyou?) locally • Client sends MAC value under encryption – If intervention is detected, the session is aborted. SSL HANDSHAKE

ClientHello C → S C, VersionC, SuiteC, NC

ServerHello S → C VersionS, SuiteS, NS, SigCA{ S, KS }

ClientVerify C → S SigCA{ C, VC },

E(KS,{ VerC, KC } )

(compute K = Master(NC,NS, KC))

E(K, SigC { Hash(K||Hash(Msgs||C||K)})

(Change to negotiated cipher) ServerFinished S → C E(K, Hash(K || Hash( Msgs || S || K)))

ClientFinished C → S E(K, Hash(K || Hash( Msgs || C || K ))) IPSEC : IP-LEVEL SECURITY

IPsec provides standards to encrypt and authenticate traffic at the IP level. It has three primary security functions: – Authentication, via “Authentication Headers” (AH) – Confidentiality, via “Encapsulated Security Payloads” (ESP) – Key management via Internet Key Exchange. (IKE) As a network layer protocol IPsec offers several advantages over application layer protocols: – IPsec is implemented at a gateway, not necessarily the desktop – It is transparent to application programs and users (except when it’s not!) IPsec is based on Security Associations, a pair of hosts plus algorithms, parameters, and keys. IPSEC USAGE SCENARIOS IPSEC MODES

IPSEC supports two modes: –Transport mode protects only the data payload of an IP packet. It is used for end- to-end encryption between two hosts (client/server) –Tunnel mode protects for the entire IP packet (including IP address) it is used for connections between gateways. Tunnel mode works by encapsulating IP packets in IPsec packets; it protects host addresses behind gateways. IKE 2.0

a Initiator Hdr, SAI, g , NI Responder

b Hdr, SAR, g , NR

Hdr, ESKi(I,CI,SigI(M1),R,TSI)

Hdr, ESKr(R,CR,SigR(M2),I,TSR)

ab ab SKi=H(I, g ) SKr = H(R,g ) If secret-key SA, replace cert+sig with MAC. BGP REVIEW

Org-X ISP-2 ISP-1 DSP-A

NAP Org-Z ISP-3 ISP-4

DSP-C DSP-B BGP Router non-BGP Router Org-Y

- BGP “speakers” advertise AS paths to address blocks. - UPDATEs are generated in response to loss of connectivity or receipt of an UPDATE from a peer router BGP SECURITY REQUIREMENTS

• Address space “ownership” verification: Prove that I own IP 0.1.2.3 • Autonomous System (AS) authentication: Prove that I am AS 7. • Router authentication and authorization: Prove that router 3.14.15.9 belongs to AS 7 • Route/address advertisement authorization: Prove that AS 7 has a path to 42.*.*.* • Route withdrawal authorization • Integrity and authenticity of BGP traffic SBGP PKI

Current (hierarchical) address allocation procedure: ICANN/IANA

ISP-1 ARIN/RIPE/APNIC ORG-X DSP-A

DSP-C ISP-2 ORG-Y DSP-B ORG-Z

ORG-YY DSP-D ORG-XX

ORG-ZZ Key idea: current organizations are already trusted: PKI based on this structure assumes no additional trust. SBGP ATTESTATIONS

SBGP uses special certificates called attestations to certify correctness of routes. – Address Attestations are to prove that a destination address is being originated by an authorized AS. They are based on signatures and certificates from the PKI – Route Attestations prove that an AS is authorized to use an AS Path. The basic idea is that a router “signs the path over” to the next hop. Each UPDATE includes one or more Address Attestations and a set of Route Attestations SBGP UPDATE PROPAGATION

# seq:4321 nlri:a,b % seq:321 nlri:a,b Hdr $ seq:21 nlri:a,b seq:4321 Hdr = seq:1 nlri:a,b RA:r7 as5 # seq:321 Hdr RA:r5 as4 % RA:r5 as4 % seq:21 Hdr RA:r3 as3 $ RA:r3 as3 $ RA:r3 as3 $ seq:1 RA:as1 as2 = RA:as1 as2 = RA:as1 as2 = RA:as1 as2 = AA:orga 1 a AA:orga 1 a AA:orga 1 a AA:orga 1 a AA:orgb 1 b AA:orgb 1 b AA:orgb 1 b AA:orgb 1 b NLRI:a,b NLRI: a,b NLRI: a,b NLRI: a,b

a r8 r7 r6 r5 r4 r3 r2 r1 b

AS 5 AS 4 AS 3 AS 2 AS 1 DNS RESOLUTION

root & edu u n.ed www.cs.umn.edu .um DNS server w.cs ww .edu umn NS umn.edu Local NS cs Client .umn.edu DNS server DNS recursive w ww resolver =I Pa cs.umn.edu dd r DNS server DNS DATA FLOW

Cache impersonation Cache pollution by Data spoofing

Zone admin Master NS resolver

Backup NS Impersonating master stub resolver Unauthorized updates DNSSEC • DNSSEC Attempts to address these issues cryptographically. • In the “Ideal DNSSEC Deployment”: – There is a public key for the “root” domain. – This is used to sign certificates for the administrators of top-level domains – These admins sign certificates for subdomains • DNSSEC has three new kinds of records – Signatures on results, uploaded by zone admins – Certificates, to allow verification – NSEC records, to prove negative results DNSSEC RESOLUTION root & edu u d .e DNS server n m .u s u .c d w .e w n w m u S N www.cs.umn.edu umn.edu NS cs.umn.edu DNS server Sig (UMN,VM ) Client edu UMN

S ww ig w= CS ( IP ww ad w dr =I , Sig Pa U dd MN (C r) cs.umn.edu S, VK DNS server CS )