1. Lecture 18: Security Reading: Chapter 8 (Some material thanks to William Perrizo) ? CMSC 23300/33300 Computer Networks http://dsl.cs.uchicago.edu/Courses/CMSC33300

2. 2 Taxonomy of Network Security l Privacy: prevent unauthorized release of information l Authentication: verify identity of a remote participant l Integrity: assure message is unaltered l All based on encryption l Key distribution is a cross-cutting problem Security Cryptography algorithms Public key (e.g., RSA) Secret key (e.g., DES, AES, IDEA) Message digest (e.g., MD5) Security services AuthenticationPrivacyMessage integrity

3. 3 Need for Security Some people who cause security problems and why

4. 4 The Encryption Model (for a Symmetric-key Cipher)

5. 5 Cryptographic Algorithms l Secret key u DES: Data Encryption Standard u Other more recent variations: AES-Advanced Encryption Standard; IDEA-Int’l Data Encryption Alg) l Public key u RSA method (Rivest, Shamir, Adleman) l Message Digest (keyless) u MMD5: based on cryptographic checksum

6. 6 Cryptographic Functions l Cryptography algorithms can be used to implement a number of functions, including u Privacy: prevent unauthorized release of information u Authentication: verify identity of a remote participant (including service to which a request is to be sent) u Integrity: assure message is unaltered l Other functions are also of interest, e.g. u Nonrepudiation u Authorization u …

7. 7 DES (Data Encryption Standard) l Key needs to be secret but not the algorithm itself l DES makes the algorithm so complex that none of the structure of the plaintext remains in the ciphertext (attacker must get key) l Derives its security from complexity (not completely secure these days) l Can be broken if the attacker finds the factors of a number which is the product of two large primes l Computationally costly – at least it was! l With a Beowulf cluster of 3000 high end PCs, could be cracked in ~ 6 months

8. 8 Plaintext Encrypt with secret key Ciphertext Plaintext Decrypt with secret key Initial bit permutation Rnd 1 Rnd 2 Rnd 16 56-bit key Final Permutation (inverse of original) … 64-bit key (56 + 8-bit parity) 64-bit block of plaintext Block 1 IV DES Cipher 1 Block 2 DES Block 3 DES Block 4 DES + Cipher 2 3 4 ++ + CBC: cipher block chaining Repeat for large messages Initialization Vector + F L i – 1 R i – 1 R i K i L i Different subkey each round  = XOR L i = R i-1 R i = Li-1  F(R i-1, K i ) Combiner Function (a mess) DES

9. 9 Encrypt using public key and Decrypt using private key, both 512-bit keys. Encryption: c = m e mod n Decryption: m = c d mod n n= p*q, (p and q large prime numbers - each roughly 256 bits). e is relatively prime to (p - 1) x (q - 1) (encryption key) d = e -1 mod ((p - 1) x (q - 1)) (decryption key) public key= (e, n) private key= (d, n) Ignoring the mod functions, subsituting c=m e into c d gives m ed = m ee -1 =m So it remains to show that the same arithmetic holds under the mod functions. Why? Plaintext Encrypt with Ciphertext Plaintext Decrypt with Public key c = m e mod n Private key m = c d mod n RSA is too slow to be very useful in encrypting data messages (n ~ 2 512 ~ 10 51 ) It’s used to encrypt small things, e.g., secret keys, hash values. RSA

10. 10 Hash Functions l Hash functions always map a data space, S, into a fixed-size hash space, H u E.g., size M at right l In DBMSs the goal is to reduce size and to provide a fast look up function u E.g., mod functions l In Security the goal is to produce a functional value that does not reveal the domain data value from which it was computed u I.e., inverse function is uncomputable data-value (from S) hash fctn hash-value space, H 2 0 M-1

11. 11 Cryptographic Checksums or Message Digests l Complex hash functions that compute a fixed length checksum from arbitrarily long messages u Regular checksums protect the receiver from accidental changes to the message. u Cryptographic checksums protect the receiver from malicious changes to the message l One-way function u Given a cryptographic checksum for a message, it is virtually impossible to figure out what message produced that checksum; it is not computationally feasible to find two messages that hash to the same cryptographic checksum  If you have checksum of a message and you can compute same checksum from that message, then it is highly likely this message produced the checksum you were given

12. 12 MD5 Roughly MD5 goes like this: u Pad message to multiple of 512B u 1st pass: 512B segments digested  u 2nd pass: similar but uses different fctn u 3rd pass: yet another fctn (XOR based) u 4th pass: another fctn (XOR,OR,NOT based) u Resulting in a mangled digest which is: u added to digest from previous stage! u…u… Transform Initial“digest“ (constant) Message (padded) Transform Message digest 512 bits ■ ■ ■

13. 13 3-way handshake (DES based) Assume secret key, sk, has been exchanged Client: select a random number x, encrypts (using sk) it and sends it Client Server C-id, DES(x,sk) DES(x+1,sk) DES(y,sk) DES(y+1,sk) DES(sk,SessKey) Server: decrypt (with sk); add 1; encrypt (with sk). Gen random number y, encrypt; send both Client: decrypt 1 st part to verify x+1 (client now has authenticated server). Decrypt 2 nd part; add 1; encrypt; send. Server: Send client a Session Key (sk encrypted) to be used for all data messages (so sk will be less vulnerable) Server: Decrypt to verify y+1 (server now has authenticated client). Authentication: Method 1

14. 14 Assume A shares secret key, ska, with AS; B shares secret key, skb, with AS A (unencrypted) identifies itself and B to AS AS B DES((T,L,SK,A),skb) DES((A,T),SK) A,B DES((T,L,SK,B),ska) DES((T,L,SK,A),skb DES(T+1,SK) A AS sends a 2-part message to A: DES((TimeStamp, LifeTime, SessKey, B), ska) DES((TimeStamp, LifeTime, SessKey, A), skb) B, upon seeing that A and T are the same in both (decrypts passed-along message 1 st to get SessionKey, SK, to decrypt other part), replies with DES(T+1, SessKey) A decrypts 1 st part with its secret key, ska; passes 2 nd part, with DES((A, T), SessKey) to B When is B authenticated to A? Vice versa? A variation of T3P is used in Kerberos (MIT developed TCP/IP-based security system) Authentication: Method 2 Trusted 3rd Party (Auth. Server, AS)

15. 15 Authentication: Method 3 Public Key Authentication (uses RSA) A B RSA(x, BPubKey) x A generates random number, x Sends RSA((x, BPublicKey) to B B decrypts with BPrivateKey. Sends x back to A. A can authenticate itself to B in the same way.

16. 16 Message Integrity Protocols l Sometimes two participants do not care whether an eavesdropper is able to read the message, l but they are worried about an imposter claiming to be one of them (i.e., they want to ensure the integrity of their messages) l One way: encrypt using DES and cipher block chaining, l then use CBC residue (last CBC block) as a hash or checksum or message integrity code (MIC) l If the receiver cannot reproduce the attached MIC using the secret key then either the message was not sent by sender or it was modified since it was transmitted

17. 17 Message Integrity Protocols #1 of 3: Digital Signature using RSA l Participant is the only one with the private key so he uses this key to produce the signature u Any other participant can verify this signature using the public key l Thus, to send a message, encrypt with private key u To verify a signature, you decrypt using public key of purported sender l RSA is ~3 orders of magnitude slower than DES l Observe that this use of RSA keys is just the opposite of its use in privacy u For integrity, sender encrypts with its private key (rather than with receiver’s public key) u Receiver decrypts with sender’s public key (rather than with receiver private key)

18. 18 Message Integrity Protocols using MD5 l Keyed MD5 u Assumes sender and receiver already share a secret key, k l Sender u runs MD5 over the concatenation of the message, m, and key, k u transmits m + MD5(m+k) (+ means concatenation) l Receiver u runs MD5 on m (all but final 64 bits of what was received) concatenated with k – i.e., MD5(m+k). l If result matches (the last 64-bits of what was received) then m was sent by key holder l There are many variations of this protocol!

19. 19 2nd MD5 Message Integrity Protocol: MD5 with RSA Signature l m + RSA[MD5(m), PrivateKey] is sent u (where m is message it wants to protect integrity of) u I.e., sender doesn’t sign entire message, just checksum l The receiver verifies the message by u Running MD5 algorithm on the received message u Decrypting the signed checksum with the sender’s public key u Comparing the two checksums l If they match, the message was not modified since the time the sender computed the MD5 checksum and signed it

20. 20 Public Key Distribution (X.509) l Key Distribution: get keys to people so they can be sure the key is legitimate u I.e., it belongs to the entity it’s purported to belong to l Can’t just use email or use a bulletin board u Without A’s public key B has no way to authenticate the key as having come from A l Can exchange public keys in person u Has limitations too – have to be together in person l Basic solution is to use Digital Certificates (DC) u A document, digitally signed by X, that says “I certify that public key in this document belongs to entity Y” l X = anyone with the public key of the entity named

21. 21 Public Key Distribution, contd. l Usually X=Certification Authority u Administrative entity in business of issuing certificates l DCs are only useful to participant already holding X’s public key (to decrypt the signature) l Thus, DCs do not solve the key distribution problem entirely l Once you have a public key for one entity, you can start to accumulate more public keys from participants who have DCs from X

22. 22 Digital Certificate Chain of Trust l If X certifies that a public key belongs to Y, and then Y goes on to certify that another public key belongs to Z, then a chain of certificates from X to Z exists even though X and Z may never have met l Z can provide his public key to A, and the complete chain of certificates (the certificate for Ys PK issued by X and the certificate for Zs PK issued by Y) l If A has PK for X he can use the chain to verify that they are legitimate l A popular way to build chains of trust is to arrange them in a tree structure

23. 23 Digital Certificate Chain of Trust IPRA (Internet Policy Registration Authority) PCA-1 CA / \ user user CA | user CA | user PCA-n CA user l What is being certified? Binding between identity and public key (Is Jon Smith a well-defined identity?) l Certificates must be used in a well-defined name space (e.g., email names) u E.g., the Domain Name Space (DNS)

24. 24 Certificate Standards l E.g., X.509, which specifies components such as u The name of the entity u The public key of the entity u The name of the certificate authority u A digital signature (many different digital signature algs) u Expiration time l Possession of a certificate says nothing about your identity: certificates can and must be freely copied and distributed to be useful l To prove that you are the entity named in the certificate you need to show you have the private key corresponding to the public key contained in that certificate: the authentication problem

25. 25 Certificate Revocation l If your Private Key is stolen you need to revoke your certificate u There may be many certificates asserting that you are the owner of the public key corresponding to that private key l Person who has your private key has everything he needs to impersonate you l CAs issue certificate revocation lists (CRL), a digitally signed list of revoked certificates u Periodically updated and made public

26. 26 Example Systems l Components required to build a secure system include cryptographic algorithms, authentication protocols, and key distribution mechanisms. l Some systems that use these components are: u IP Security (IPSEC) operates at the network layer (IP layer) u Transport Layer Security (TLS) (built from the older - Secure Socket Layer or SSL) u Secure Shell (SSH) application-level secure remote login facility

27. 27 Secure Shell (SSH) l Secure remote login and file transfer u Provides strong client/server authentication u Also supports message integrity and confidentiality l SSH version 2 has 3 protocols u E.g., SSH-TRANS provides encrypted channel on top of TCP as follows: l Upon remote login, Client authenticates server using RSA l Client and Server establish session key to encrypt data l Client authenticates itself to Server l Supports other TCP applications (e.g., Xwindows, IMAP mail reader...) through SSH tunnels

28. 28 IETF Transport Layer Security (TLS) l Looks to the user just like TCP, except that it provides privacy, integrity and authentication. l When HTTP is used over TLS, it is known as HTTPS (secure HTTP) u In fact, HTTPS is just exactly HTTP over TLS instead of TCP (port=443 instead of 80) l TLS is broken down into two parts (handshake & record protocols) l Handshake protocol to negotiate parameters u Crypto algorithms, certificate, session keys, init vectors…) u Two RTTs ClientServer Hello Hello[Certificate,Keys, CertificateRequest]HelloDone Finish Data

29. 29 TLS, contd. l Record protocol defines set of formats/procs by which app messages are fragmented or coalesced into the right sized blocks for: u optimal compression u integrity protection using a hash such as MD5 u encryption u passing to lower layer (TCP) for transmission l TLS offers “resume session” feature - very useful for HTTP. l TLS does not specify key infrastructure. l TLS uses a single CA, whose public key is included in web browsers l Therefore it is popular for credit card applications.

30. 30 Taxonomy of Network Security l Privacy: prevent unauthorized release of information l Authentication: verify identity of a remote participant l Integrity: assure message is unaltered l All based on encryption l Key distribution is a cross-cutting problem Security Cryptography algorithms Public key (e.g., RSA) Secret key (e.g., DES, AES, IDEA) Message digest (e.g., MD5) Security services AuthenticationPrivacyMessage integrity

31. 31 Caveat l “If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology." — Bruce Schneier

32. 32 Further Reading l Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson l Security: Secret & Lies, Digital Security in a Networked World, by Bruce Schneier