network security: email security, pki
DESCRIPTION
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) - PowerPoint PPT PresentationTRANSCRIPT
Network Security: Email Security, PKI
Tuomas AuraT-110.5240 Network security
Aalto University, Nov-Dec 2011
2
Outline1. Email security2. Pretty Good Privacy (PGP)3. Certificates4. PGP web of trust5. 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
Email security
4
Security requirementsWhat 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 [email protected] are the security vulnerabilities?
Serverexchange.example.com
Servermail.contoso.com
Internet
Receiver [email protected]
Sender [email protected]
SMTP or proprietary
protocol
IMAP, POP3, webmail, or proprietary
protocolSMTP
DNSQuery for
MX record of contoso.com /
Response: mail.contoso.com
8
Order of signing, compression and encryption
Opinions?Observations:
Signing without seeing content is dangerous → sign the plaintextSigning an encrypted message does not prove that the signer knows the content → sign the plaintextEncryption only protects secrecy; in theory, ciphertext might decrypt to multiple different plaintexts → sign the plaintextSignature or MAC might reveal something about message contents → encrypt also the signature or MACCiphertext does not compress → compress before encryptionDecompression might not guarantee unambiguous output in the presence of a malicious influence → sign the uncompressed plaintextForwarding 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, encryptExceptions common but need a good justification
10
Sign, compress, encrypt
Sender and receiver need to know each other’s public keysOptions to encrypt only or to sign only:
Possible to sign without knowing receiver’s public key, or when sending to a mailing listPossible to encrypt without identifying sender
Hash
M
Alice’s private
key PK-1A
Insecurenetwork
Sender Alice Receiver Bob
Sign
ESK(Z(M, SignA(M))), EB(SK)Encrypt
(symm.)
Encrypt (asymm.)
Bob’spublic
Key PKB
h(M)
SignA(M) EB(SK)
Fresh random session key SK
Authentication Encryption
Hash
Alice’s public
key PKA
Verify
Decrypt (symm.)
Decrypt (asymm.)
Bob’sprivate
Key PK-1B
SK
AuthenticationDecryption
EB(SK)
h(M)
M
SignA(M)
|| || split split MCompress De-compress
Ok?
Pretty Good Privacy (PGP)
11
13
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-----
Random block (IV)+ 2 repeating bytes
Signing time
14
Typical PGP message
Recipient key idSession key SK
2 bytes of hash
Data
PK-encryptedsession key EB(SK)
(may repeat for multiple recipients)
ESKZip
EB
Radix-64
=ojUK-----END PGP MESSAGE-----
-----BEGIN PGP MESSAGE-----Version: GnuPG v1.4.8
EncryptedMessage
ESK(…)
Signature type
Signer key id
RSA/DSA signature
For quick checkof the hash
For quick check of successful decryption
Hash &SignA
ASCII armor headersfor sending in text email
ASCII armor checksum
Unix time (seconds since 1 Jan 1970 UTC)
17
Radix-64 encodingUse safe ASCII characters to represent values 0..63:ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvxyz0123456789+/
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
18
S/MIMEPGP is mainly used by private persons and academiaS/MIME is a similar standard used primarily by enterprises, e.g. OutlookMessage structure based on the MIME standards Envelopes and signatures are new MIME types→ Base64 encoding
19
Non-repudiationProof 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 decisionThe public key must be somehow registered to bind it to the person signing
Uses:Accountability for sent messagesContract 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 messagesAre business contracts signed using secure email?
Certificates
21
22
Public-key certificatesSignature 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?
PGP web of trust
25
PGP key distributionPGP 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 trustMeaning: 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-dutyMeaning: 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
26
PGP web of trust
Which keys should I use for sending confidential mail, for authenticating received mail, for contract signing?
Me, PKme
Alice, PKA
Gab, PKG
David, PKD
Bob, PKB
Eve, PKE
Foo, PKF
Henry, PKH
Iris, PKI
Strong assurance, complete trust
Strong assurance, parial trust
Strong assurance, no trust
30
RevocationCertificate revocation:
Anyone who signed a certificate can revoke itSimilar to a certificate but assurance level “revocation”
Key revocation:Key can revoke itself (private key needed for this)Used when private key compromisedRecommendation: 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 revocationsCertificates may have a validity period, after which revocations can be discarded
Unfortunately, infinite validity is common PGP practice → need to store revocations foreverCommon practice to revoke PGP keys when they are replaced with a new ones → many unnecessary revocations
X.509 public-key infrastructure (PKI)
33
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/[email protected] 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
X.509 certificate exampleSave certificate into a file and pretty print:% openssl x509 -in cert.pem -noout -text
Subject name
Subject public key
Issuer infoValidity dates
Key usage
CA signature…
Revocation list URL
34
X.500 namesISO X.500 standard defines hierarchical directory
More advanced than DNS but not widely usedHierarchical 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 = USCN = Tuomas Aura, OU = UserAccounts, DC = europe, DC = microsoft, DC = comCN = 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
35
ASN.1ASN.1 standard for defining protocol messages
Abstract notation for data structures, protocol messagesBER/DER encoding rules → standardized binary encoding with recursive TLV (type tag, length, value) structureUnambiguous parsing of binary messagesASN.1 specification of protocol messages is directly compiled into C-code for encoding and decoding themEncoded data unreadable to humansMost 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
36
ASN.1 exampleASN.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
37
OIDOne 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 authenticationiso(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)
42
Commercial CAs and web sitesWeb 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 reasonsSecurity issues of unconstrained delegation
Wildcard names allow multiple servers to share one certificate
E.g. *.contoso.com for www.contoso.com, mail.contoso.comCompromise for cost reasonsNot standard, supported by browsers
VeriSign Class 3 Public Primary CA
VeriSign International Server CA - Class 3
www.bankofamerica.com PKA
GTE CyberTrust Global Root
Microsoft Internet Authority
www.update.microsoft.com
Microsoft Secure Server Authority
43
Constrained delegationImportant concept but not widely usedName constraints:
Constrain the authority of a sub-CA to specific subtrees of the name hierarchyExamples: “.microsoft.com” = all MS hosts, “microsoft.com” = one host or all email addresses on that hostPermitted and excluded subtreesName constraints apply to Subject and SubjectAltName
Path length constraints limit the depth of the CA hierarchyPolicy constraints control policies of sub-CAsImportant idea but no agreement on which constraints to implement
GTE CyberTrust Global Root
Microsoft Internet Authority
www.update.microsoft.com
Microsoft Secure Server Authority
Name and identityWith 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.fiGeorge Bush, George W. Bush, George H. W. [email protected], [email protected], [email protected], [email protected], [email protected]
Who decides who owns the name?aalto.firecent 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 databaseExtended validation certificatesStrong 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 PKIsIn communication, principals are always represented by their public keys→ let’s redefine: principal = public signature keyX.509 puts too much emphasis on names. What does a name mean anyway? What matters is access controlOrange 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 meaningSince the local authority is a principal, which is a key, all names are relative to a key
54
Key-oriented PKIsInfluential research ideas, but no standards yetSimple distributed security infrastructure (SDSI):
Linked local name spaces: my doctor’s secretary, PKB’s AliceName 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 keysAlgebra 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 fileAAuthorization 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 inputLater version called KeyNote is more constrained and similar to SPKI
55
Example of SPKI authorizationACL 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
56
Example of SDSI name resolutionACL in file server: SalesDept’s Salesman can read fileA
Local policy in server: my SalesDept is Contoso’s SalesDeptmy Contoso is PKContoso
Head office issues a name certificate: PKContoso’s SalesDept 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’s SalesDept’s Salesman = PKContoso’s SalesDept’s Salesman = PKsales’s Salesman = {PKA, PKB}→ access allowed
SPKI and SDSI were merged into one system that is not so simple any more
57
Alternatives to PKINot all authentication is based on a PKI. Other “trust roots”:
Manual key distribution, e.g. for permanent IPsec tunnel or RADIUSPassword authentication of human usersOnline authentication servers, e.g. KerberosPseudonymity — create new id created for each service and authenticate returning usersLeap of faith -– assume there is no attacker on the first time, e.g. SSHSelf-certifying identifiers — public key as identifier
58
Puzzle of the dayNeedham-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 namesKTA, 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 BKses = 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 otherCan you see anything wrong with this protocol? All the messages are sent through the insecure network.
59
Related readingWilliam Stallings, Network security essentials: applications and standards, 3rd ed.: chapters 4.2-4.3, 5William Stallings, Cryptography and Network Security, 4th ed.: chapters 14.2-14.3, 15Kaufmann, Perlman, Speciner, Network security, 2nd ed.: chapters 15, 20-22
60
ExercisesHow 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)?