Outline Email infrastructure security

I Email, the first widely available Internet service, has a very simple backbone. SMTP (Simple Mail Transport Protocol) Secure Email: PGP and S/MIME servers accept plain-text commands in a telnet session, with Email and Web Data Security little or no authentication. Computer Security Lecture 12 I This is the reason that email is trivially forgeable. Issues of trust I Because it is sent as plaintext, most email has absolutely David Aspinall no confidentiality. Secure web transport I There are server attacks, particularly sending spam through School of Informatics open relays also gaining access to systems. Most infamous University of Edinburgh is sendmail, which allowed command execution: exploited by X.509 16th February 2006 Morris Internet Worm in 1988. Solutions: run server in restricted environment; use application gateway at firewall.

I Client attacks. Plain text email poses no risks. Many virus warnings (e.g., “Good Times”) are hoaxes or themselves the virus. But macro languages and active content have lead to serious email-transmitted viruses and Trojans.

Secure Email S/MIME PGP Two good PK models supported by email applications: I Newer than PGP, but standardization began sooner, in RSA I Venerable history. Invented by Phil Zimmerman in 1991, S/MIME (Secure Multipurpose Internet Mail Extension) and I labs. Built into email clients of Netscape and Microsoft. strong belief in the right to privacy, made PGP available as PGP (). Many less-good mechanisms, freeware. Source code was published in book form in 1995 to I S/MIME uses X.509 personal certificates, signed by a e.g., weak secret-keys, or self-extracting exe’s with decryption circumvent US export restrictions: a team of people used OCR code that prompts for key. certification authority, using a trust hierarchy model. Usually certs cost £. to reconstruct an international version of the program, PGPI. I Same general technique: I PGP has plugins for Outlook Express and other email clients. I S/MIME uses the same PKI (Public Key Infrastructure) as A → B : { M } , { K } , S (h(M)) Crypto specs and formats now standardised in OpenPGP, a K Kb A SSL. This is why integrated email clients of web browsers were | {z } | {z } | {z } developer consortium and IETF Working Group [RFC 2440]. encrypted encrypted digital able to implement it hand-in-hand. OpenPGP public keys are hosted on a network of PGP message session key signature I Organisations can implement their own internal private, or I better, closed PKIs. keyservers, and can be countersigned, using PGP’s Alice makes a one-time session key K and encrypts the email web-of-trust model, without TTPs. M with it. She encrypts the session key with Bob’s public key I Pros: same infrastructure as SSL, hierarchical trust model more appropriate in some circumstances. Cons: I Formats in OpenPGP (ASCII-armoured) and PGP/MIME. Kb (this part is sometimes called a digital envelope, but usage of that term varies). Optionally, she includes a signature, by implementations less scrutinized than PGP; files larger. I PGP pros: open source code scrutinized for years; not limited signing a hash of the message h(M) and a timestamp T . I Open source implementation: the OpenSSL Project. to email. Some PGP products have NIST security certification. Cons: trust model not suited to commerical Sometimes { M, T }K is sent (prevent replay). Mozilla’s PKI page details other open source software, application. I For multiple recipients include multiple envelopes. http://www.mozilla.org/projects/security/pki/. Trust Structures Other points of trust SSL/TLS Hieararchy of trust I The SSL (Secure Sockets Layer) protocol provides security on I Original PEM (Privacy Enhanced Mail) project planned a top of the TCP/IP transport layer, below application-specific single hierarchy with the (Internet Policy Registration I Many interface issues. protocols. Each connection needs a dedicated TCP/IP socket. Authority) at its root. I Is your sent (or received) encrypted mail stored locally But each SSL session can allow multiple underlying I This didn’t work out. Instead, a forest of CAs has evolved. unencrypted or encrypted? (If the latter, you must be on the connections (reduces keying overhead). recipient list to be able to decrypt it!) I Browsers have certificates of many root CAs built-in. I Provides authentication, confidentiality, integrity. Also has I How are your private keys stored? Are they protected? Can built-in data compression. Layers: handshake protocol and I Revocation was by CA-supplied Certificate Revocation Lists they be extracted and shared with other applications? (CRLs), cf. credit card hot-lists. Replacement is Online record protocol. The Mail User Agent is critical: it’s trusted to invoke the Certificate Status Protocol (OCSP) for real-time checks. I Commonly used on web for secure communications with a crypto operations securely, as claimed. (A old Outlook PGP Web of Trust web server, in the http-over-SSL protocol. Usually Express bug resulted in supposedly encrypted mail sometimes TCP port 443 on the server. I Individuals assign trust values to public keys by signing them. being sent in the clear). I In https, everything is encrypted (URL requested, HTTP I Should users allow transitive trust? Maybe: global advantage I Revocation check: ideally, ought to allow CRL header, form contents, cookies, as well as web page itself). in trust spread widely, but risk as it gets further away. or key-server check to see if a public key has been revoked. Only thing undisguised is connection to particular server I PGP signing: the social contract and PGP “signing parties”. (some anonymizing proxies can do that).

I Revocation is by owner issuing a revocation certificate, to I Numerous other SSL-enhanced protocols now also take revoke a signature on a key. Mechanism for distribution? advantage of SSL (e.g., SSLtelnet, SSLftp, stunnel).

SSL History SSL cipher suites SSL handshake protocol outline

I Introduced 1994 by Netscape Navigator (major selling point). Client and server negotiate a cipher suite. Details of possibilities Three phases: hello, key agreement, authentication. Competing S-HTTP launched at same time by CommerceNet depend on version of SSL, as well as which suites supported by I 1. Client hello. A → S: A, A#, N , CipherPreferences group. S-HTTP designed to work with Web only. Initially had client or server. a 2. Server hello. S → A: S, S#, N , CipherChoice to be purchased in modified NCSA Mosaic. S-HTTP sunk. Authentication v2 RSA public keys & X.509 certificates s v3 anonymous Diffie-Hellman key-exchange 3. Server certificate. S → A: S, CS I Microsoft’s competing attempt PCT was introduced in first 4. Pre-master secret. A → S: { K0 }K version of Internet Explorer. MS backed down after release of v2 40-bit RC2, RC4 (“export grade”) s 5. Client finished. A → S: { Finished, MAC(K1, DataSoFar) }K SSLv3. v3 56-bit DES-CBC, 128-bit RC2, RC4, as 3DES CBC 168-bit 6. Server finished. S → A: { Finished, MAC(K1, DataSoFar) }Ksa Versions of SSL: I MAC v2 MD5 SSL v1 used internally in Netscape (flawed) Commentary: I v3 SHA I SSL v2 in Navigator 1.0–2.x. Had MIM attacks, buggy 1. Client hello: Alice sends name, session ID, nonce, cipher prefs. random number generators. 40-bit encryption was broken. Some browsers (e.g., Netscape 6/Mozilla) let you specify which of 2. Server hello: server choose best cipher suite, sends own data. I SSL v3, 1996. Navigator 3.0, IE 3.0. Added fixes and more features, including Diffie-Hellman anonymous key-exchange. their supported cipher suites you’re willing to use. 3. Server sends certificate CS with public key, which Alice can I TLS v1.0, 1999, RFC 2246. Close to SSLv3. The IETF working group are looking at future extensions for TLS, check. (Server may ask Alice for certificate here, or may I TLS v1.1, 2006 (probably). Fixes over 1.0, e.g. explicit IV to including supporting the use of OpenPGP keys as well as X.509 choose anonymity) prevent attack on CBC mode. certificates. SSL handshake protocol outline: cont’d X.509 Standard PKIX Distinguished names

I An X.500 distinguished name (DN) is a list of names each 4. Alice computes a 48-byte pre-master secret key K , which I X.509 is an ITU standard (International Telecoms Union, 0 with an attribute; specifies a path through an X.500 directory. sends to the server encrypted under the server’s public key. formerly the CCITT), part of the X.500 series which specifies X.500 presumed every subject in the world would have a 5,6. Alice and server each compute six shared secrets, 3 for each a directory service. I globally unique DN. Not practical in reality, e.g., there is no direction. First, K = h(K , N , N ) is the master secret. Recommendation X.509 1 0 a s single entity in the world trusted by everybody (one of the Then K and K are the symmetric cipher secret keys (e.g., OSI — The Directory: Authentication as sa reasons PEM failed). In PKIX, names have local scope (like DES keys) used for encryption thereafter. The second key is Framework. DNS names and IP numbers). used for the MAC. The third key is an IV used to initialize the X.509 specifies a PKI. Version 3 published 1997. symmetric cipher. I Standard attribute types have been defined in X.520, and I X.509 certificates have a specification in ASN.1, but it’s PKIX requires that implementations are prepared to handle The handshake protocol establishes an SSL session; alternatively, open to some interpretation. This has lead to various some of them: it allows resumption of an on-going session in the first step, if “profiles” which pin down some of the choices. common name Alice’s session id A# is non-zero and the server agrees to resume Examples of profiles: US Federal PKI, various other organizational unit I organization the session by responding with the same value. governments, and IETF PKIX. This allows both resuming an SSL communication and opening state or province name PKIX is used for S/MIME and SSL. See http: country another connection without undergoing key-exchange and I //www.ietf.org/html.charters/pkix-charter.html For example, I might be CN=David Aspinall, OU=School of authentication again. Informatics, O=University of Edinburgh, C=Scotland UK.

X.509 Certificates RSA PKCS Proto-Standards Future: Identifier-based PKs? PKIs of either trust model involve rather vast and unwieldy In an effort to foster interoperability of cryptographic software, and I chains of trust and certifications. Big expense to set up and X.509 certificates have 10 fields: push for standardizations, RSA Labs instigated their own series of maintain, effort to retrieve certificates before communications, “standards”, mostly concerned with file formats for cryptographic and verify trust chains. version v1, v2, or v3 information. Some of these are now internet drafts. Idea for future alternative is Identifier-based PKC. Here, a serial number unique amongst certificates issued by a CA PKCS #6 Extended Certificate Syntax Standard I public key is derived from a user’s identifying information: signature alg ID identifies signature algorithm a superset of X.509 format Bob’s public key is derived from his e-mail address, for issuer X.500 DN PKCS #7 Cryptographic Message Syntax Standard example. Certification is implicit. validity [start,end] times in UTC (2 digit yr) / generalised time. message formats including digitally signed ; subject X.500 DN derived from PEM and S/MIME. I To read messages, Bob must verify his identity (once) to an PK info algorithm, parameters and key material PKCS #10 Certification Request Syntax Standard authority, obtaining the private key for his public key. (v2+) bitstream to uniquify names (allows DN reuse) issuer ID PKCS #9 Selected Object Classes & Attribute Types I Big advantage: Alice and everyone else who talks to Bob subject ID ditto Lists the X.509 extensions used in PKCS #6, #10 don’t need to fetch his public key securely or check a trust extensions (v3+) various extra information chain. Relationship between public-private key pairs is based signature value the signature proper: signed hash of fields 1 to 10 These formats are widely used, e.g., for the interchange on a secret held by the authority that issues private keys. representations of certicates, ceritificate requests used by web I For more, see CESG’s ideas on ID-PKC at: browsers. http: // www. cesg. gov. uk/ site/ ast References

Jalal Feghhi, Jalil Feghhi, and Peter Williams. Digital Certificates — Applied Internet Security. Addison-Wesley, 1999. Aviel Rubin, Daniel Geer, and Marcus J Ranum. Web Security Sourcebook. John Wiley & Sons, 1997. Lincoln D Stein. Web Security — A Step-by-Step Reference Guide. Addison-Wesley, 1998.