Network Security Email Security PKI Tuomas Aura T110

Network Security: Email Security, PKI Tuomas Aura T-110. 5240 Network security Aalto University, Nov-Dec 2011

Outline 1. 2. 3. 4. 5. Email security Pretty Good Privacy (PGP) Certificates PGP web of trust X. 509 public-key infrastructure (PKI) Only a quick look at advanced aspects. Students are assumed to be familiar with X. 509. 6. Key-oriented PKI 2

Email security

Security requirements What kind of security is needed for email? Confidentiality? Authentication? PGP, S/MIME Non-repudiation? Mandatory access control, DRM? Spam control? Phishing prevention? Anonymity? We use email security as the first example because it is a fairly straightforward application of crypto and allows us to introduce many basic concepts Crypto does not solve all email security problems 4

Internet email architecture Alice sends mail to bob@contoso. com Where are the security vulnerabilities? 5

Order of signing, compression and encryption Opinions? Observations: Signing without seeing content is dangerous → sign the plaintext Signing an encrypted message does not prove that the signer knows the content → sign the plaintext Encryption only protects secrecy; in theory, ciphertext might decrypt to multiple different plaintexts → sign the plaintext Signature or MAC might reveal something about message contents → encrypt also the signature or MAC Ciphertext does not compress → compress before encryption Decompression might not guarantee unambiguous output in the presence of a malicious influence → sign the uncompressed plaintext Forwarding email → encrypt outside signing Receiver might want to decompress or recompress the signed data for storage; authentication of compressed messages prevents that → compress email after authentication Typical order: sign, compress, encrypt Exceptions common but need a good justification 8

Sign, compress, encrypt Sender and receiver need to know each other’s public keys Options to encrypt only or to sign only: Possible to sign without knowing receiver’s public key, or when sending to a mailing list Possible to encrypt without identifying sender 10

Pretty Good Privacy (PGP) 11

Example: PGP-encrypted message -----BEGIN PGP MESSAGE----Version: Gnu. PG v 1. 4. 8 Comment: Encrypted secret message. h. QEOA 1 e+1 x 6 Yu. UMCEAQAo. ST 1 l/obn. XOB 6 fh. Ihm. Ln. GVLhuxmsks. KD+Efyk 7 ja 9 g. Ox U 5 X 98/25 ZVDQz 0 Ei. Ok. Rj. W 2 LChu. Zt 9 Kesh 1 DSIRw. B/ll. XCm 3 pb. NX/V+ajk. L 4 Fzxlw j. WCCedv 527 SUNTUP 70 lh. Lbh 4 O 2 k. HHx. Md. En 41 z. Vo 9 TPUgt. Q 1 BIo 32 k/x. P 2 RYt. PCEE AJDhcyp+COLa. I 4 idibf. Sr. DDt. Yc. T+h. VVFVve. Ite. TIczno. Uo. S 1 y. Vyip. E 4 m. Bwa 380 c 6 Tiw. Imq 63 h. Ohs 62 c 9 BOQv 7 G 9 cnaq. EZNg 0 n. Li. VZD+K/Je. N 00 z. ILm+Tzd. WZxr. W 019 n. A +ts. Mwzn. UZ 2 V/k. QZj. S 9 xk. PWjn 7 Zz. PTy. W 6 g. Lhj. WQNlr 93 S 0 lc. BT 0 CJy 285 ix. Fz 9 Ur. J qj. K 2 azs. Bd. XRc. Vu. XFdh 84 LW 1 E/8/8 Dwd. Lg. SK 9 X/j. PNv 3/WGLA 4 Ez 2 x. TFIUor. Vi 5 Xe M 9 dpri. EQ 0 Jg 2 msnz 2 bjq. RGZli. XXo 6 m 8 ye/A= =YWDi -----END PGP MESSAGE----- “Meet me in the park at 6 PM. ” 13

ASCII armor headers for sending in text email PK-encrypted session key EB(SK) (may repeat for multiple recipients) For quick check of successful decryption Unix time (seconds since 1 Jan 1970 UTC) For quick check of the hash Encrypted Message ESK(…) ASCII armor checksum Typical PGP message -----BEGIN PGP MESSAGE----Version: Gnu. PG v 1. 4. 8 Recipient key id Session key SK EB Random block (IV) + 2 repeating bytes Signature type Signing time Signer key id 2 bytes of hash RSA/DSA signature Radix-64 Hash &Sign. A Zip ESK Data =oj. UK -----END PGP MESSAGE----- 14

Radix-64 encoding Use safe ASCII characters to represent values 0. . 63: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv xyz 0123456789+/ Encode each 3 bytes as 4 characters: +--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +------+-------+---+------+ |5 4 3 2 1 0|5 4 3 2 1 0| +--1. char---+--2. char---+--3. cahr---+--4. char---+ If the data length is not divisible by 3, pad with one or two = characters to indicate actual length 17

S/MIME PGP is mainly used by private persons and academia S/MIME is a similar standard used primarily by enterprises, e. g. Outlook Message structure based on the MIME standards Envelopes and signatures are new MIME types → Base 64 encoding 18

Non-repudiation Proof of authenticity to third parties Email sender cannot later deny sending the message (i. e. cannot repudiate the message) Third party, such as a judge, is needed to make the decision The public key must be somehow registered to bind it to the person signing Uses: Accountability for sent messages Contract signing Questions: Does the sender of an email want to go do extra work in order to be accountable for the emails he sends? → Little motivation to sign messages Are business contracts signed using secure email? 19

Certificates 21

Public-key certificates Signature verifier must know the signer’s public key. For example, how to verify TA, M, SA(TA, M) ? Identity certificate is a signed message issued by a trusted entity, which binds a name and a public key to each other: Cert. A = A, PKA, Texpiry, Sissuer(A, PKA, Texpiry) To verify message TA, M, SA(TA, M), Cert. A : Verify signature SA with PKA Check freshness of the timestamp TA Verify the certificate, and check TA < Texpiry Security protocols often assume that the protocol participants have certificates, but who issues them? 22

PGP web of trust

PGP key distribution PGP users need to know each other’s public keys. But how to verify they are authentic? Need to verify only the key fingerprint (hash value) Personal verification: ask the person, print on business cards, etc. PGP key ring signed by someone you trust PGP key ring contains public key, trust level, user id or name and one or more signatures. Each signature includes assurance level Meaning: signers say that the public key belongs to the user Trust levels: none, partial trust, complete trust Meaning: level of belief that entity tells the truth when it signs key rings Signer can use this parameter to recommend the key owner as a person of high integrity to sign keys for others Assurance levels: unspecified, no, casual, heavy-duty Meaning: how carefully did signer check that the key belongs to the user Idea: assurance of key-person binding and trusting that person to tell the truth (sign keys of others) are separate issues 25

PGP web of trust Which keys should I use for sending confidential mail, for authenticating received mail, for contract signing? 26

Revocation Certificate revocation: Anyone who signed a certificate can revoke it Similar to a certificate but assurance level “revocation” Key revocation: Key can revoke itself (private key needed for this) Used when private key compromised Recommendation: sign a key revocation message for your key and store it in a safe place just in case PGP key servers are email and ftp-based repositories for key rings, including revocations Certificates may have a validity period, after which revocations can be discarded Unfortunately, infinite validity is common PGP practice → need to store revocations forever Common practice to revoke PGP keys when they are replaced with a new ones → many unnecessary revocations 30

X. 509 public-key infrastructure (PKI)

X. 509 certificate example Certificate: Data: Version: 3 (0 x 2) Serial Number: d 1: 32: 5 b: f 8: d 7: 09: 02: 37: 50: 57: 93: 55: 84: c 9: b 2: 4 c Signature Algorithm: sha 1 With. RSAEncryption Save certificate into a file and pretty print: Issuer: C=FI, O=Sonera, CN=Sonera Class 2 CA % openssl x 509 -in cert. pem -noout -text Validity Not Before: Nov 19 12: 09 2009 GMT Not After : Nov 19 12: 09 2010 GMT Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin. tkk. fi/email. Address=webmaster@tkk. fi Subject Public Key Info: Public Key Algorithm: rsa. Encryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00: c 7: 94: 9 b: 49: 29: 6 f: 2 d: 6 d: 32: 70: 97: 73: 39: 1 e: 04: 20: 89: ea: 05: 89: 02: 01: 1 a: d 7: 2 d: ad: 86: f 6: 99: 69: 7 e: 13: 19: f 2: 09: d 0: e 6: 05: ca: 93: 13: a 7: e 2: 7 b: 3 b: b 6: 68: e 7: 49: c 7: 3 b: 53: fd: b 5: c 1: bc: 64: 65: 6 c: 4 d: 89: 37: ab: b 5: 6 b: 2 a: 38: 2 b: 45: 82: f 6: 99: 97: 21: 57: fc: ac: 26: 9 b: 04: 3 b: ad: 13: 26: 8 e: 85: ff: 44: ba: 4 f: 1 e: 27: cc: f 2: fd: c 1: 47: c 4: de: b 6: d 2: 6 c: 2 c: 48: 6 e: a 3: cc: cd: 0 c: ed: 75: 4 b: a 2: c 7: f 0: c 2: e 1: 9 b: e 9: d 3: 0 c: 1 b: 90: 35: c 8: ee: e 7: 01 Exponent: 65537 (0 x 10001) X 509 v 3 extensions: X 509 v 3 Authority Key Identifier: keyid: 4 A: A 0: AA: 58: 84: D 3: 5 E: 3 C X 509 v 3 Certificate Policies: Policy: 1. 3. 6. 1. 4. 1. 271. 2. 3. 1. 1. 2 X 509 v 3 CRL Distribution Points: URI: ldap: //194. 252. 124. 241: 389/cn=Sonera%20 Class 2%20 CA, o=Sonera, c=FI? certificaterevocationlist; binary X 509 v 3 Key Usage: Digital Signature, Key Encipherment X 509 v 3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X 509 v 3 Subject Key Identifier: 86: 4 C: D 0: 93: 1 A: A 4: C 4: 7 C: 94: A 0: 28: 04: F 3: DA: 17: 12: 18: FF: 23: D 7 Signature Algorithm: sha 1 With. RSAEncryption 50: c 3: 94: 71: b 3: d 2: 1 d: 7 f: be: 71: 5 e: ff: ec: 09: 50: 68: f 0: 33 27: 54: cd: e 8: f 2: 17: 90: 3 e: ea: 6 c: e 2: 81: 12: bf: e 2: 73: 72: 9 e: Issuer info Validity dates Subject name Subject public key Revocation list URL Key usage CA signature…

X. 500 names ISO X. 500 standard defines hierarchical directory More advanced than DNS but not widely used Hierarchical names used in X. 509 certificates X. 500 names: C = country, S = state, L = locality, O = organization, OU = organization unit, CN = common name Names used in practice: CN = Tuomas Aura, O = Microsoft Corporation, L = Redmond, S = Washington, C = US CN = Tuomas Aura, OU = User. Accounts, DC = europe, DC = microsoft, DC = com CN = www. bankofamerica. com, OU = DMZUNIXAPPS, O = Bank of America Corporation, L = Charlotte, S = North Carolina, C = US Hierarchical naming should ensure a 1 -to-1 mapping between names and principals (unlike in PGP web of trust); such names are called distinguished names 34

ASN. 1 standard for defining protocol messages Abstract notation for data structures, protocol messages BER/DER encoding rules → standardized binary encoding with recursive TLV (type tag, length, value) structure Unambiguous parsing of binary messages ASN. 1 specification of protocol messages is directly compiled into C-code for encoding and decoding them Encoded data unreadable to humans Most Internet standards defined in RFCs use more lightweight bit-field or text-based syntax and manually encoded parsers X. 509 certificates are encoded in ANS. 1 DER 35

ASN. 1 example ASN. 1 (from RFC 3280) Personal. Name : : = SET { surname [0] IMPLICIT Printable. String (SIZE (1. . ub-surname-length)), given-name [1] IMPLICIT Printable. String (SIZE (1. . ub-given-name-length)) OPTIONAL, initials [2] IMPLICIT Printable. String (SIZE (1. . ub-initials-length)) OPTIONAL, generation-qualifier [3] IMPLICIT Printable. String (SIZE (1. . ub-generation-qualifier-length)) OPTIONAL } Compare with RFC-style packet diagrams: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ST | 0 | TYPE | Reserved | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix. Length | Prefix byte 1 | Prefix byte 2 |. . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |. . . | Prefix. Length | Prefix byte 1 | Prefix byte 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |. . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36

OID One ASN. 1 type is object identifier (OID) Globally unique identifiers (similar to const or enum but on global scale) Variable length; each organization can get its own prefix Examples: 1. 3. 6. 1. 5. 5. 7. 3. 1 = TLS server authentication iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) key. Purpose(3) 1. 2. 840. 113549. 1. 1 = RSA algorithm (PKCS#1) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 37

Commercial CAs and web sites Web browsers and OSs have a pre-configured list of root CAs Multiple roots! Being on the list enables business of selling certificates Some commercial CAs certify customers’ CAs, some only end entities Business reasons Security issues of unconstrained delegation Wildcard names allow multiple servers to share one certificate E. g. *. contoso. com for www. contoso. com, mail. contoso. com Compromise for cost reasons Not standard, supported by browsers 42

Constrained delegation Important concept but not widely used Name constraints: Constrain the authority of a sub-CA to specific subtrees of the name hierarchy Examples: “. microsoft. com” = all MS hosts, “microsoft. com” = one host or all email addresses on that host Permitted and excluded subtrees Name constraints apply to Subject and Subject. Alt. Name Path length constraints limit the depth of the CA hierarchy Policy constraints control policies of sub. CAs Important idea but no agreement on which constraints to implement 43

Name and identity With certificates, it is possible to authenticate the name or identifier of an entity e. g. person, computer, web server, email address What is the right name anyway? wwwlogin. tkk. fi, security. tkk. fi, leakybox. cse. tkk. fi George Bush, George W. Bush, George H. W. Bush tuomas. aura@aalto. fi, aura@cs. hut. fi, aaura@hut. fi, taura@cse. tkk. fi, aura@cse. tkk. fi Who decides who owns the name? aalto. fi recent case: Ville Valo on Facebook Identity proofing is the process with which CA verifies the name of the subject before issuing the certificate Email to an address from the WHOIS database Extended validation certificates Strong identity Does knowing the name imply trust? Should I order a second-hand camera from buycam. fi? Should they post the camera to Tuomas Aura? 50

Key-oriented PKIs 52

Observations about PKIs In communication, principals are always represented by their public keys → let’s redefine: principal = public signature key X. 509 puts too much emphasis on names. What does a name mean anyway? What matters is access control Orange Book definition: access control = authentication + authorization. But authentication of public keys is easy → focus on authorization No global X. 509 CA hierarchy exists must live with local CAs → names have only local meaning Since the local authority is a principal, which is a key, all names are relative to a key

Key-oriented PKIs Influential research ideas, but no standards yet Simple distributed security infrastructure (SDSI): Linked local name spaces: my doctor’s secretary, PKB’s Alice Name certificates: PK says PK’s doctor is PKD , PKB says PKB’s Alice is PKA Algebra of names and name certificates Simple public-key infrastructure (SPKI): Focus on delegation of access rights between public keys Algebra of authorization certificates (5 -tuples of <issuer, subject, authority, validity, delegation>) ACL in a server is the root of all authority: PK is allowed to read file. A Authorization certificate: PK delegates to PK 2 the right to read file. A Policy. Maker: Certificates are programs. They are evaluated by letting them run with the access request and each other as input Later version called Key. Note is more constrained and similar to SPKI 54

Example of SPKI authorization ACL on a web page: <me, PKsales, read/write, “always”, delegate=yes> Sales department delegates to Alice: <PKsales, PKA, read, “this week”, delegate=yes> Alice delegates Bob: <PKA, PKB, read/write, “this week”, delegate=no> Who can access the web page and how? Delegation path me→PKsales→PKA→PKB Constrains accumulate along the path → PKA (Alice’s key) can read the page this week, and can delegate further → PKB (Bob’s key) can read this week but not delegate further 55

Example of SDSI name resolution ACL in file server: Sales. Dept’s Salesman can read file. A Local policy in server: my Sales. Dept is Contoso’s Sales. Dept my Contoso is PKContoso Head office issues a name certificate: PKContoso’s Sales. Dept is PKsales (signed by PKContoso) Sales department issues name certificates: PKsales’s Salesman is PKA (signed by PKsales) PKsales’s Salesman is PKB (any name can be a group!) Bob requests file. A from the server. He signs the request with PKB. Server resolves the name in the ACL: Sales. Dept’s Salesman = Contoso’s Sales. Dept’s Salesman = PKsales’s Salesman = {PKA, PKB} → access allowed SPKI and SDSI were merged into one system that is not so simple any more 56

Alternatives to PKI Not all authentication is based on a PKI. Other “trust roots”: Manual key distribution, e. g. for permanent IPsec tunnel or RADIUS Password authentication of human users Online authentication servers, e. g. Kerberos Pseudonymity — create new id created for each service and authenticate returning users Leap of faith -– assume there is no attacker on the first time, e. g. SSH Self-certifying identifiers — public key as identifier 57

Puzzle of the day Needham-Schroeder key distribution protocol (1978): Trusted server T shares a secret master key with each user. T distributes a fresh session using the master keys: 1. A → T: A, B, NA 1 “Hi, I’m A and would like to talk with B. ” 2. T → A: ETA(NA 1, B, Kses, ticket. AB) 3. A → B: ticket. AB, Eses(NA 2) 4. B → A: Eses(NA 2 -1, NB) 5. A → B: Eses(NB-1) A, B, T = entity names KTA, KTB = A’s and B’s master keys shared with T NA 1, NA 2, NB = A’s and B’s nonces i. e. fresh random bit string generated by A and B Kses = session key selected by T (fresh random bit string) ETA , Eses = encryption with the master or session key ticket. AB = ETB(Kses, A) “Here is a session key between you and A. ” Encryption is assumed to also protect integrity. Nowadays, we would use standard MACs but they did not exist in the 70 s. For example: EK(M) = AES-CBCK(M, HMAC-SHA-1 K(M)) Goal: A and B agree on a session key and authenticate each other Can you see anything wrong with this protocol? All the messages are sent through the insecure network. 58

Related reading William Stallings, Network security essentials: applications and standards, 3 rd ed. : chapters 4. 24. 3, 5 William Stallings, Cryptography and Network Security, 4 th ed. : chapters 14. 2 -14. 3, 15 Kaufmann, Perlman, Speciner, Network security, 2 nd ed. : chapters 15, 20 -22 59

Exercises How to prevent SMTP spoofing without end-to-end cryptography? What can be filtered at SMTP servers and what cannot? Does signing of emails help spam control? Install an Open. PGP implementation (e. g. GPG). How do you check that the binary or source code has not been tampered with? Would you use PGP itself to verify the signature or fingerprint on the installation package? Set up your own CA e. g. using Open. SSL and issue certificates to your own web server or some other service that uses TLS/SSL authentication. What decisions did you have to make on the way? What open questions do you have after the experience? Consider setting up a PKI in a place where you have worked/studied. How would you distribute the root key and organize certificate enrolment? How would you implement access control in a distributed file system with SPKI (with SDSI)? 60