1 / 37

Network Security: Email Security, PKI

Network Security: Email Security, PKI. Tuomas Aura T-110.5240 Network security Aalto University, Nov-Dec 2011. Outline. Email security Pretty Good Privacy (PGP) Certificates PGP web of trust X.509 public-key infrastructure (PKI)

venus
Télécharger la présentation

Network Security: Email Security, PKI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network Security: Email Security, PKI Tuomas Aura T-110.5240 Network securityAalto University, Nov-Dec 2011

  2. Outline • 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. • Key-oriented PKI

  3. Email security

  4. Security requirements • What kind of security is needed for email? • Confidentiality? • Authentication? • 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 PGP, S/MIME

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

  6. 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

  7. 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

  8. Pretty Good Privacy (PGP)

  9. Example: PGP-encrypted message • “Meet me in the park at 6 PM.” -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.8 Comment: Encrypted secret message. hQEOA1e+1x6YuUMCEAQAoST1l/obnXOB6fhIhmLnGVLhuxmsksKD+Efyk7ja9gOx U5X98/25ZVDQz0EiOkRjW2LChuZt9Kesh1DSIRwB/llXCm3pbNX/V+ajkL4Fzxlw jWCCedv527SUNTUP70lhLbh4O2kHHxMdEn41zVo9TPUgtQ1BIo32k/xP2RYtPCEE AJDhcyp+COLaI4idibfSrDDtYcT+hVVFVveIteTIcznoUoS1yVyipE4mBwa380c6 TiwImq63hOhs62c9BOQv7G9cnaqEZNg0nLiVZD+K/JeN00zILm+TzdWZxrW019nA +tsMwznUZ2V/kQZjS9xkPWjn7ZzPTyW6gLhjWQNlr93S0lcBT0CJy285ixFz9UrJ qjK2azsBdXRcVuXFdh84LW1E/8/8DwdLgSK9X/jPNv3/WGLA4Ez2xTFIUorVi5Xe M9dpriEQ0Jg2msnz2bjqRGZliXXo6m8ye/A= =YWDi -----END PGP MESSAGE-----

  10. Typical PGP message ASCII armor headersfor sending in text email -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.8 PK-encryptedsession key EB(SK) (may repeat for multiple recipients) Recipient key id Session key SK EB Random block (IV)+ 2 repeating bytes For quick check of successful decryption Signature type Unix time (seconds since 1 Jan 1970 UTC) Signing time Radix-64 Signer key id Zip ESK 2 bytes of hash For quick checkof the hash Hash &SignA RSA/DSA signature Data EncryptedMessageESK(…) =ojUK -----END PGP MESSAGE----- ASCII armor checksum

  11. Radix-64 encoding • Use safe ASCII characters to represent values 0..63: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv xyz0123456789+/ • 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|7 6 5 4 3 2 1 0| +-----------+---+-------+-------+---+-----------+ |5 4 3 2 1 0|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

  12. 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 → Base64 encoding

  13. 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?

  14. Certificates

  15. 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: CertA = A, PKA, Texpiry, Sissuer(A, PKA, Texpiry) • To verify message TA, M, SA(TA, M), CertA: • 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?

  16. PGP web of trust

  17. 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

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

  19. 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

  20. X.509 public-key infrastructure (PKI)

  21. X.509 certificate example • Save certificate into a file and pretty print: • % openssl x509 -in cert.pem -noout -text Issuer info Validity dates Subject name Subject public key Revocation list URL Key usage Certificate: Data: Version: 3 (0x2) Serial Number: d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c Signature Algorithm: sha1WithRSAEncryption Issuer: C=FI, O=Sonera, CN=Sonera Class2 CA Validity Not Before: Nov 19 12:02:09 2009 GMT Not After : Nov 19 12:02:09 2010 GMT Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin.tkk.fi/emailAddress=webmaster@tkk.fi Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c7:94:9b:49:29:6f:2d:6d:32:70:97:73:39:1e: 04:20:89:ea:05:89:02:01:1a:d7:2d:ad:86:f6:99: 69:7e:13:19:f2:09:d0:e6:05:ca:93:13:a7:e2:7b: 3b:b6:68:e7:49:c7:3b:53:fd:b5:c1:bc:64:65:6c: 4d:89:37:ab:b5:6b:2a:38:2b:45:82:f6:99:97:21: 57:fc:ac:26:9b:04:3b:ad:13:26:8e:85:ff:44:ba: 4f:1e:27:cc:f2:fd:c1:47:c4:de:b6:d2:6c:2c:48: 6e:a3:cc:cd:0c:ed:75:4b:a2:c7:f0:c2:e1:9b:e9: d3:0c:1b:90:35:c8:ee:e7:01 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:4A:A0:AA:58:84:D3:5E:3C X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.271.2.3.1.1.2 X509v3 CRL Distribution Points: URI:ldap://194.252.124.241:389/cn=Sonera%20Class2%20CA,o=Sonera,c=FI?certificaterevocationlist;binary X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7 Signature Algorithm: sha1WithRSAEncryption 50:c3:94:71:b3:d2:1d:7f:be:71:5e:fe:ff:ec:09:50:68:f0: 27:54:cd:e8:f2:17:90:3e:ea:6c:e2:81:12:bf:e2:73:72:9e: 02:d3:b4:03:88:2a:6a:b1:00:ca:70:24:1b:3f:da:d6:30:46: 0e:db:99:af:65:7d:d9:58:dc:ed:47:36:04:63:c4:f8:c1:22: e6:ab:f6:63:b8:d4:bf:68:a4:13:73:82:4c:94:b1:9c:1f:fb: e8:87:c5:f1:12:e1:73:e0:ef:71:af:8b:85:cf:e3:9e:6e:dd: d1:0b:11:29:ca:ec:24:37:eb:23:df:63:35:f7:9d:b8:13:47: bf:4a:93:c1:a5:0c:b7:1d:8d:1a:61:22:06:56:17:07:f4:f8: 7d:41:92:04:83:f7:6c:f9:9b:94:27:35:11:c5:d2:e6:95:1d: 71:8a:01:bb:f5:2b:c0:21:e3:7c:5a:0a:44:66:98:38:de:b7: 2f:b7:9d:1f:35:95:05:21:03:a2:d3:ba:7d:e2:4e:87:0f:ad: e1:68:cd:b9:c9:d2:21:67:85:32:6f:0b:d0:26:b2:2d:dd:10: 4e:88:30:e3:d7:52:73:f6:eb:ca:4b:28:56:9f:06:25:a8:91: 45:b5:26:93:01:ab:8b:aa:7d:2e:bd:96:5f:39:50:cc:2a:11: f0:69:4d:ff CA signature…

  22. 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 = UserAccounts, 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

  23. ASN.1 • 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 light-weight bit-field or text-based syntax and manually encoded parsers • X.509 certificates are encoded in ANS.1 DER

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

  25. 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 serverauthentication iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) • 1. 2.840.113549.1.1 = RSA algorithm (PKCS#1)iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)  

  26. 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

  27. 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 SubjectAltName • 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

  28. 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 • Strongidentity • Does knowing the name imply trust? • Should I order a second-hand camera from buycam.fi? • Should they post the camera to Tuomas Aura?

  29. Key-oriented PKIs

  30. 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

  31. 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 fileA • Authorization certificate: PK delegates to PK2 the right to read fileA • PolicyMaker: • Certificates are programs. They are evaluated by letting them run with the access request and each other as input • Later version called KeyNote is more constrained and similar to SPKI

  32. 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

  33. Example of SDSI name resolution • ACL in file server: SalesDept’s Salesman can read fileA • Local policy in server: my SalesDept is Contoso’sSalesDept my Contoso is PKContoso • Head office issues a name certificate: PKContoso’sSalesDept 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 fileA from the server. He signs the request with PKB. • Server resolves the name in the ACL: SalesDept’s Salesman = Contoso’sSalesDept’s Salesman = PKContoso’sSalesDept’s Salesman = PKsales’s Salesman = {PKA, PKB} → access allowed • SPKI and SDSI were merged into one system that is not so simple any more

  34. 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

  35. 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, NA1 “Hi, I’m A and would like to talk with B.” 2. T → A: ETA(NA1, B, Kses, ticketAB) 3. A → B: ticketAB, Eses(NA2) 4. B → A: Eses(NA2-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 NA1, NA2, 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 , ETA , Eses= encryption with the master or session key ticketAB = 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 70s. For example: EK(M) = AES-CBCK(M, HMAC-SHA-1K(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.

  36. Related reading • William Stallings, Network security essentials: applications and standards, 3rd ed.: chapters 4.2-4.3, 5 • William Stallings, Cryptography and Network Security, 4th ed.: chapters 14.2-14.3, 15 • Kaufmann, Perlman, Speciner, Networksecurity, 2nd ed.: chapters 15, 20-22

  37. 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 OpenPGP 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 OpenSSL 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)?

More Related