Outline Internet Security Protocols Bart Preneel June 2003 With thanks to Joris Claessens and Walter Fumy Preliminaries: Internet protocols, PKI, X.509, Encoding Application layer security (email) PGP, S/MIME Transport layer security SSL / TLS Network layer security IPSec, VPN, SSH 2 Internet Evolution Internet Standardization Number of Internet Users in Millions 1.000 100 10 1 0,1 e-mail TCP/IP HTML WWW WAP mobile business XML Electronic e-commerce Business Experts Armed Forces Universities 1960 1970 1980 1990 2000 2010 2020 3 ISOC/IAB/IESG/IETF Internet Engineering Task Force (IETF) IETF Working Groups Mailing List Information Scope of the Working Group Goals and Milestones Current Internet Drafts & RFCs http://www.ietf.org/html.charters/wg-dir.html RFCs http://www.rfc-editor.org ftp://ftp.isi.edu/in-notes/ IETF Standards IETF Intermediate documents Proposed Standard (PS) stable spec lowest level of standards track Draft Standard (DS) at least two independent and interoperable implementations Standard (STD) widely, successfully used Experimental Proposed Draft std Standard Historic Request for Comments (RFCs) with different maturity levels Experimental (E) Informational (I) Historic (H) Best Current Practice (BCP) Internet-Drafts (I-D) are working documents of the working groups and have no formal status Protocol Status (requirement level) "required", "recommended", "elective", "limited use", or "not recommended must and should 1
IETF Security Area (1) Area Directors: Jeffrey Schiller & Marcus Leech An Open Specification for Pretty Good Privacy (openpgp) Authenticated Firewall Traversal (aft) Common Authentication Technology (cat) IP Security Policy (ipsp) IP Security Protocol (ipsec) IP Security Remote Access (ipsra) Intrusion Detection Exchange Format (idwg) Kerberized Internet Negotiation of Keys (kink) Kerberos WG (krb-wg) Multicast Security (msec) IETF Security Area (2) Area Directors: Jeffrey Schiller & Marcus Leech One Time Password Authentication (otp) Public-Key Infrastructure (X.509) (pkix) S/MIME Mail Security (smime) Secure Network Time Protocol (stime) Secure Shell (secsh) Securely Available Credentials (sacred) Security Issues in Network Event Logging (syslog) Simple Public Key Infrastructure (spki) Transport Layer Security (tls) Web Transaction Security (wts) XML Digital Signatures (xmldsig) SMTP HTTP TCP/UDP IP Link... Internet Protocols Application Transport Network SMTP HTTP TCP/UDP Network Layer Internet Protocol (IP) Transport Layer Transmission Control Protocol (TCP), User Datagram Protocol (UDP) IP Link... Security Protocols & Services Cryptographic techniques typically utilized by a Security Protocol (unilateral or mutual) entity authentication mechanisms symmetric encipherment message authentication mechanisms key establishment mechanisms (e.g., combined with entity authentication) SP hdr data SP tlr MAC confidentiality integrity 10 Internet Security Protocols Electronic Commerce Layer SET, Ecash,... SP Architecture II: Session (Association) Establishment S-HTTP PGP PEM S/MIME PKIX Host A SP hdr encrypted data MAC Host B Transport Layer Security (SSH, SSL, TLS) SPKI Transmission Control Protocol User Datagram Protocol (UDP) (TCP) IP/ IPSec (Internet Protocol Security) Public -Key Infrastructure Security Associations (Security Parameters incl. Shared Keys) security services depend on the layer of integration: the mechanisms can only protect the payload and/or header information available at this layer Key Management and Security Association Establishment Protocols header information of lower layers is not protected!! 12 2
Note on export restrictions Public Key Infrastructure cryptography is weapon or dual use good thus should be export -controlled allow only short keys Until 1997: 40-bit: symmetric encryption 512-bit: asymmetric encryption Since September 2000 less restrictions, evolution towards no restrictions X.509: ITU/T standard basis for the IETF PKIX working group latest major release in 95 (v3) Certification Authorities (CA) = Trusted Third Parties (TTP), that warrant the link between a person and their public key Alternatives: SPKI/SDSI (IETF) PGP between civilized nations 13 14 X.509 certificate v1 X.509 certificate v2 Version number Serial number Signature algorithm Issuer name Validity period Subject name Subject public key Signature of the CA 15 Idem + Issuer unique identifier Subject unique identifier Directory Access Control 16 X.509 certificate v3 Typical X.509 solution Idem + Extensions (each one can be critical): Alternative naming More info about the key Other identification data CRL location information Directory System Card Issuing System Registration Authority Certification Authority Key Recovery Authority Server Components Local Registration Authority Notarization Authority Administration Components PKI User Agent Client Timestamping Authority 17 18 3
Encoding Abstract Syntax Notation.1 (ASN.1) Distinguished Encoding Rules (DER) ftp://ftp.rsa.com/pub/pkcs/ascii/layman.asc Also Basic Encoding Rules (BER) Base64 format (also PEM format) ASN.1 definition certificate Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueidentifier [1] IMPLICIT UniqueIdentifier OPTIONAL, -- if present, version must be v2 or v3 subjectuniqueidentifier [2] IMPLICIT UniqueIdentifier OPTIONAL -- if present, version must be v2 or v3 extensions [3] Extensions OPTIONAL -- If present, version must be v3 }} Version ::= INTEGER { v1(0), v2(1), v3(2) } CertificateSerialNumber ::= INTEGER AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id ({SupportedAlgorithms}), parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm}) OPTIONAL } Validity ::= SEQUENCE { notbefore Time, notafter Time } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectpublickey BIT STRING } (etc) 19 20 DER encoded certificate 00000 30 82 02 ee 30 82 02 57 02 02 12 cf 30 0d 06 09 0...0..W...0... 00010 2a 86 48 86 f7 0d 01 01 04 05 00 30 81 c4 31 0b *.H...0..1. 00020 30 09 06 03 55 04 06 13 02 5a 41 31 15 30 13 06 0...U...ZA1.0.. 00030 03 55 04 08 13 0c 57 65 73 74 65 72 6e 20 43 61.U...Western Ca 00040 70 65 31 12 30 10 06 03 55 04 07 13 09 43 61 70 pe1.0...u...cap 00050 65 20 54 6f 77 6e 31 1d 30 1b 06 03 55 04 0a 13 e Town1.0...U... 00060 14 54 68 61 77 74 65 20 43 6f 6e 73 75 6c 74 69.Thawte Consulti 00070 6e 67 20 63 63 31 28 30 26 06 03 55 04 0b 13 1f ng cc1(0&..u... 00080 43 65 72 74 69 66 69 63 61 74 69 6f 6e 20 53 65 Certification Se 00090 72 76 69 63 65 73 20 44 69 76 69 73 69 6f 6e 31 rvices Division1 000a0 19 30 17 06 03 55 04 03 13 10 54 68 61 77 74 65.0...U...Thawte 000b0 20 53 65 72 76 65 72 20 43 41 31 26 30 24 06 09 Server CA1&0$.. 000c0 2a 86 48 86 f7 0d 01 09 01 16 17 73 65 72 76 65 *.H...serve 000d0 72 2d 63 65 72 74 73 40 74 68 61 77 74 65 2e 63 r-certs@thawte.c 000e0 6f 6d 30 1e 17 0d 39 38 30 33 32 33 30 37 34 30 om0...9803230740 000f0 30 39 5a 17 0d 39 39 30 33 32 33 30 37 34 30 30 09Z..99032307400 00100 39 5a 30 81 b8 31 0b 30 09 06 03 55 04 06 13 02 9Z0..1.0...U... 00110 42 45 31 10 30 0e 06 03 55 04 08 13 07 42 72 61 BE1.0...U...Bra 00120 62 61 6e 74 31 0f 30 0d 06 03 55 04 07 13 06 4c bant1.0...u...l 00130 65 75 76 65 6e 31 13 30 11 06 03 55 04 0a 13 0a euven1.0...u... 00140 4b 2e 55 2e 4c 65 75 76 65 6e 31 13 30 11 06 03 K.U.Leuven1.0... 00150 55 04 0b 13 0a 45 53 41 54 2f 43 4f 53 49 43 31 U...ESAT/COSIC1 00160 26 30 24 06 03 55 04 03 13 1d 77 77 77 2e 63 6f &0$..U...www.co 00170 73 69 63 2e 65 73 61 74 2e 6b 75 6c 65 75 76 65 sic.esat.kuleuve 00180 6e 2e 61 63 2e 62 65 31 34 30 32 06 09 2a 86 48 n.ac.be1402..*.h 00190 86 f7 0d 01 09 01 16 25 6d 61 72 6b 2e 76 61 6e...%mark.van 001a0 64 65 6e 77 61 75 76 65 72 40 65 73 61 74 2e 6b denwauver@esat.k 001b0 75 6c 65 75 76 65 6e 2e 61 63 2e 62 65 30 81 9f uleuven.ac.be0.. 001c0 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 0...*.H... (only first part of certifcate fits on 1 slide ) 00 A 17 R 34 i 51 z Base64 01 B 18 S 35 j 52 0 02 C 19 T 36 k 53 1 03 D 20 U 37 l 54 2 04 E 21 V 38 m 55 3 05 F 22 W 39 n 56 4 06 G 23 X 40 o 57 5 07 H 24 Y 41 p 58 6 08 I 25 Z 42 q 59 7 09 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y (1) * 0x30 0x82 0x02 0 0 1 1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 12 M 08 I 08 I 02 C 21 22 Base64 encoded certificate -----BEGIN CERTIFICATE----- MIIC7jCCAlcCAhLPMA0GCSqGSIb3DQEBBAUAMIHEMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xHTAbBgNVBAoT FFRoYXd0ZSBDb25zdWx0aW5nIGNjMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl cnzpy2vzierpdmlzaw9umrkwfwydvqqdexbuagf3dgugu2vydmvyienbmsywjayj KoZIhvcNAQkBFhdzZXJ2ZXItY2VydHNAdGhhd3RlLmNvbTAeFw05ODAzMjMwNzQw MDlaFw05OTAzMjMwNzQwMDlaMIG4MQswCQYDVQQGEwJCRTEQMA4GA1UECBMHQnJh YmFudDEPMA0GA1UEBxMGTGV1dmVuMRMwEQYDVQQKEwpLLlUuTGV1dmVuMRMwEQYD VQQLEwpFU0FUL0NPU0lDMSYwJAYDVQQDEx13d3cuY29zaWMuZXNhdC5rdWxldXZl bi5hyy5izte0mdigcsqgsib3dqejarylbwfyay52yw5kzw53yxv2zxjazxnhdc5r dwxldxzlbi5hyy5iztcbnzanbgkqhkig9w0baqefaaobjqawgykcgyear98du8rd w84vqs1ey77visp1cjfpno6vakno9xlqx5fyfopay2eykkdsciur+g5ghc6xnjj8 ukfzqnpa3+cdswniszhhs+khnygbnydvcrmsd5mltczz13fgt6jzvfqxf59ftx5u /D0NKn0TulgOGBNCopNqvj3tkaSyR6f2NsUCAwEAATANBgkqhkiG9w0BAQQFAAOB gqat6tly6zdsptmhhbh+ogh7ytcehi2gixi7wko04w6vn5pb6mannf7hwcbtyafq 2BcTnO0j/ci6bN7alHh9xSPVaKYGFPx9sRg6tIGrGORvK3arN5RbfFJRO7yNbyFQ SaI4iSgS+Qr6sNtgFqM0TksHD6021G58uPLzrojAM8Pdbg== -----END CERTIFICATE----- Application layer security PGP and S/MIME 23 4
Secure email: general model message sign verify Alice PrivKey A PubKey A encrypt decrypt Bob PGP or Pretty Good Privacy (Phil Zimmerman) A remarkable phenomenon Strong cryptographic algorithms General purpose application Available for many platforms Open source SS AB encrypt decrypt PubKey B PrivKey B 25 26 PGP (ctd) PGP - Algorithms Freely available package for noncommercial use (www.pgpi.com) Commercial version Patent issues resolved Grass-root: not developed by, nor controlled by any governmental or standards organization Digital signature: Message digest: Key exchange Message encryption: Key management: Compression: Encoding: DSA, RSA SHA-1 DH (ElGamal), RSA CAST, IDEA, 3DES web of trust ZIP (defined) + Radix 64 27 28 PGP - Components A PGP Message Authentication using digital signatures Confidentiality: one key per message; public-key encryption Compression: order is important! Compatible with email: radix-64 Segmentation and reassembly Key generation 29 Session key Signature Message Key ID Bob s PK Ks Timestamp Key ID Alice s PK 2 Leading bytes of H(M) H(M) Filename Timestamp DATA E PKB S SKA ZIP E Ks R64 30 5
PGP - Key identifier Do not transmit public key with message save space Assign a Key ID to each public key public key s least significant 64 bits One or more User IDs per public key Private key: private keyring, encrypted using key derived from passphrase PGP - Correct public key? Directly from owner physically get the key from B (practical limitations) verify a key by phone (fingerprint) Via introducer of public key obtain B s key from a mutual trusted individual D = PGP approach obtain B s key from a trusted CA = X.509, S/MIME approach 31 32 PGP - Public and Private key ring PGP - Trust Model Timestamp Key ID: 64 bits Public Key Owner Trust User ID Key Legitimacy Signatures Signature Trust Timestamp Key ID: 64 bits Public Key Encrypted private key User ID Trust flag byte owner trust field (assigned by user) signature trust field ( = owner trust field, if corresponding public key is in ring) key legitimacy field (computed) Revocation done by user him/herself 33 34 PGP Trust Model S/MIME Trusted to sign A bit trusted to sign Not trusted to sign Alice Trusted key 35 Secure MIME Multipurpose Internet Mail Extensions IETF initiative Initiated by companies Integrates the MIME messaging standard with PKCS #7 (originally, now CMS) 36 6
Old email: SMTP/RFC 822 MIME (RFC 2045-9) Header: From, To Subject, Date, Message-ID SMTP no binaries no national language characters sometimes size limits not all implementations conform to standard 37 New header fields (5) MIME-Version Content -Type Content -Transfer-Encoding Content -ID Content -Description Content formats (15): text, multipart, message, image, video, audio, application multipart: mixed, parallel, alternative, digest 38 MIME (RFC 2045-9) Transfer encodings (6) 7bit 8bit binary quoted-printable base64 x-token Canonical form versus Native form 39 Public Key Cryptographic Standards (PKCS) Initiative of RSA Data Security PKCS #7: specifies how to apply public-key cryptography to obtain the desired security services types of messages: Data EnvelopedData SignedData SignedandEnvelopedData DigestedData (Clear-signed data) EncryptedData (-) 40 S/MIME Version 2 RFC 2311-2312 (March 1998) Uses PKCS#7 Defines new MIME-Types, e.g. multipart/signed application/x-pkcs7-mime S/MIME Version 3 RFC 2630-2634 (June 1999) Cryptographic Message Syntax (CMS) derived from PKCS#7 Security extensions signed receipts security labels (e.g., for authorization) secure mailing lists signing certificate attribute 41 42 7
S/MIME - Algorithms S/MIME Content types Digital signature: Message digest: Key exchange: Message encryption: Key management: Compression: Encoding: DSA, RSA MD5, SHA-1 DH (ElGamal), RSA RC2, 3DES PKIX [X.509] / ASN.1/DER + Radix 64 43 Enveloped data: RecipientInfo Signed data (can be combined with previous) more than one signer ``Signerinfo : certificate Clear Signing also readable without S/MIME capability Registration request Certificates-Only message 44 From: Joris Claessens <joris.claessens@esat.kuleuven.ac.be> Subject: example S/MIME message Date: Mon, 6 Mar 2000 15:56:59 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----=_nextpart_000_0005_01bf8784.9be915c0" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF8784.9BE915C0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable This is an example of a message that is digitally signed using the S/MIME standard. ------=_NextPart_000_0005_01BF8784.9BE915C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDDCCAr8w ggiooamcaqicawgxhtanbgkqhkig9w0baqqfadcbldelmakga1uebhmcwkexftatbgnvbagtdfdl c3rlcm4gq2fwzteumbiga1uebxmlrhvyymfudmlsbguxdzanbgnvbaotblroyxd0ztedmbsga1ue... ------=_NextPart_000_0005_01BF8784.9BE915C0-- PGP versus S/MIME general model + compression (orig.) completely independent freely available application (stand-alone; plug-ins exist) web of trust revocation by user key ID personal use general model, no compression standardized, company driven integrated in for example Netscape and Microsoft hierarchical trust revocation by CA whole certificate is included commercial/organizational use 45 46 SSL / TLS Transport layer security SSL / TLS Mainly in context of WWW security, i.e., to secure the HyperText Transfer Protocol (HTTP) But, in between application layer and TCP, thus can be used to secure other applications than HTTP too (IMAP, telnet, ftp, ) 48 8
Other WWW security protocols PCT: Microsoft s alternative to SSL S-HTTP: S/MIME-like protocol SET: for credit card transactions XML-Signature: PKCS#7-based signature on XML documents... 49 SSL / TLS Secure Sockets Layer (Netscape) SSL 2.0: security flaws! SSL 3.0: still widely used Transport Layer Security (IETF) TLS 1.0: adopted SSL 3.0 with minor changes RFC 2246, 01/99 (PS) TLS: security at the transport layer can be used (and is intended) for other applications too end-to-end secure channel, but nothing more... data is only protected during communication no non-repudiation! 50 Application e.g., http, telnet,... SSL/TLS in more detail Handshake Protocol Client Hello Server Hello... Change Cipher Spec Protocol Change Cipher Spec Record Layer Protocol SSL record Transport layer TCP/IP Alert Protocol Alert Application Data Application Protocol Application Data Record layer protocol fragmentation compression (not in practice) cryptographic security: encryption? data confidentiality MAC? data authentication [no digital signatures!] Handshake protocol client and server authentication establish cryptographic keys (for encryption and MAC) negotiation of cryptographic algorithms 51 52 Handshake: overview CLIENT SERVER Hello Request Client Hello Server Hello Certificate Certificate Client Key Exchange Server Key Exchange Certificate Verify Certificate Request [changecipherspec] Server Hello Done Finished [changecipherspec] Finished? start handshake, protocol version, algorithms? authentication server + exchange (pre)master secret? client authentication? end handshake, integrity verification 53 Cryptographic algorithms [as supported in TLS 1.0, RFC 2246; TLS cipher suite style naming] Server/client authentication RSA DSS Key establishment RSA, RSA_EXPORT DH_DSS, DH_RSA, DH_RSA_EXPORT DHE_DSS, DHE_RSA, DHE_RSA_EXPORT DH_anon Encryption algorithms RC4_128, RC4_40 RC2_CBC_40 IDEA_CBC DES_CBC 3DES_EDE_CBC DES40_CBC Hash algorithms? HMAC MD5 SHA (=SHA-1) 54 9
More IETF TLS Usage of TLS in HTTP: upgrade to TLS within HTTP/1.1 (RFC 2817, 05/00) HTTP over TLS (RFC 2818, May 2000) Addition of ciphers: Kerberos cipher suites (RFC 2712, 10/99; 11/00) ECC cipher suites (03/01) AES (01/01) misc. ciphers: MISTY1 (03/01), Camellia (10/00) extensions for OpenPGP keys (03/01) Other: wireless extensions (11/00) TLS Delegation (02/01) SRP for TLS authentication (02/01) 55 TLS 1.1/2.0? TLS in the future (1) Some possible TLS enhancements, discussed within the IETF TLS WG: RSA-OAEP identity protection [note that this is already indirectly possible by authenticating within a DH_anon session] cipher suites for compression missing cipher suites (not all combinations possible) Backward compatibility remains very important! 56 TLS in the future (2) TLS 1.1 Internet Draft, October 2002 security fixes and clarifications SSL/TLS is still in evolution! Enhancements currently considered within IETF new cipher suites: e.g., AES wireless support (see WAP-WTLS) and other extensions password-based authentication and key exchange (SRP) Other enhancements proposed in literature performance improvements: batching [ShachamBoneh 01] and fast-track [ShachamBoneh 02] user (identity) privacy [PersianoVisconti 00] client puzzles [DeanStubblefield 01] to counter denial-of-service attacks SSL/TLS: security services SSL/TLS only provides: entity authentication data confidentiality data authentication SSL/TLS does not provide: non-repudiation unobservability (identity privacy) protection against traffic analysis secure many-to-many communications (multicast) security of the end-points (but relies on it!) trust negotiation [Hess et al 02] 57 58 SSL/TLS: security? TLS 1.0 is the result of a public reviewing process: several problems have been identified in earlier versions (SSL 2.0/3.0) and have been solved SSL/TLS is practically secure Some caveats (in order of importance): bad implementation; e.g., random number generation PKCS#1 attack (use other padding scheme: OAEP; server error messages should contain less information) version / cipher suite roll back attempts (due to backward compatibility; disable export algorithms if possible) traffic analysis: e.g., length of ciphertext might reveal useful info plenty of known plaintext (both SSL/TLS and HTTP 59 related) SSL/TLS: evaluation TLS 1.0 provides a good level of security result of a public reviewing process: several problems have been identified in earlier versions (SSL 2.0/3.0) and have been addressed Some remaining security problems though: downgrade attacks cryptographic attacks PKI related problems web spoofing platform and users 60 10
SSL/TLS: security problems (1) Downgrade attacks [WagnerSchneier 96]? ciphersuite downgrade (U.S. export restrictions!)? version rollback (serious security flaws in SSL 2.0)? insecure default configuration of browser and web server Cryptographic attacks? better encrypt-then-authenticate instead of authenticate-then-encrypt?? too detailed error messages (combined with cryptographic weaknesses)? oracle attacks e.g., PKCS#1 RSA encryption [Bleichenbacher 98] SSL/TLS: security problems (2) PKI related problems? root certificates are distributed via browser authenticity of root certificates?? secure update of existing root certificates? secure addition of new root certificates?? wrong browser trust model (which root certificate?) attacker may easily add extra root certificates!? manual verifications: certificate chain and fingerprint? compromise of private keys? certificate revocation through CRLs or OCSP (Online)?!? CAs must be trusted to issue certificates to right entities? danger of spoofed certificates (e.g., www.micr0soft.com)? implementation: e.g., bad randomnumber generation 61 62 SSL/TLS: security problems (3) Web spoofing [Feltenet al 97] [YuanYeSmith 01]? limited visual indications? no clear distinction between content and status information? user is easily fooled by attacker: (secure) connection with attacker instead of intended site? attacker may be able to impersonate user! (e.g., replay of username/password) should not be possible with SSL/TLS client authentication Platform and user? lack of trusted operating system? most users are not educated / security-aware 63 Strong cryptography Server Gated Cryptography browser s security is automatically upgraded if server certificate contains specific extension Fortify, http://www.fortify.net/ small program with which crippled Netscape browser can be upgraded Other solutions install secure proxy at client side applet does all crypto (cfr. e-banking solutions) 64 TLS for the end-user (WWW) Indication of a secure session: URL: http://? https:// graphics: open lock? closed lock Configuration browser: certificate and trust management choice of cipher suites Security in transport layer Transparent for application Pro: can be used for all TCP-based applications, without modifying them Con: authentication is one, but who/what to trust, is important Non-repudiation? In practice: (partially) integrated in application 65 66 11
Non-repudiation Legally only if in application, thus not provided by SSL/TLS SSL/TLS secures the communication channel, but not the exchanged messages SSL/TLS does not use digital signatures in the first place (except for client authentication) For electronic business, more advanced security protocols are needed... 67 User authentication First authentication, then authorization! SSL/TLS client authentication: during handshake, client digitally signs a specific message that depends on all relevant parameters of secure session with server software devices, smart cards or USB tokens can be deployed through standardized cryptographic interfaces supported by browsers (Netscape: PKCS#11; MSIE: PC/SC) PKCS#12 key container provides software mobility Usually another mechanism on top of SSL/TLS 68 Network address based Authenticate (groups of) users based on (ranges of) IP addresses, host names, and/or domain names Issues: Mapping of users to limited set of network addresses is not possible in many (open) applications Vulnerable to TCP/IP network problems: IP spoofing, DNS attacks,... Problem of web proxies 69 Fixed passwords HTTP/1.0 Basic Authentication password is sent at each request Form based fixed password scheme session authenticator in cookie various schemes exist, which are not always secure e.g., Microsoft Passport single sign-on service Inherent weaknesses brute-force and dictionary attacks password guessing and social engineering SSL/TLS needed to protect password and authenticator Still widely used: very easy and cheap; works with standard browser Password managers! 70 Dynamic passwords Passwords that are only used once passwords cannot be replayed or re-used when compromised SSL/TLS still needed for authentication of web server List of independent random one-time passwords difficult to (securely) maintain for the user Chain of dependent one-time passwords extra software needed at client side or with hardware token 71 Challenge/response User proves his identity to the server by demonstrating knowledge of a secret, not by just sending this secret to the server, but by producing the proper response to a challenge of the server, using this secret Symmetric schemes: e.g., MAC on time or random challenge HTTP/1.1 Digest Authentication Asymmetric schemes: e.g., digital signature on random challenge SSL/TLS Client Authentication Often implemented with hardware tokens 72 12
Hardware tokens Special-purpose tokens e.g., Digipass: can perform challenge/response authentication, and can calculate MACs e.g., SecurID: response to current time General-purpose tokens mobile phone: user authentication via mobile network PDAs or other programmable devices Smart cards and USB tokens can be deployed for SSL/TLS Client Authentication through standardized interfaces supported by browsers Bank cards and electronic purses 73 Network layer security IPsec, VPN, SSH IPsec Security Architecture for the Internet Protocol RFC 2401 (PS), 11/98 IP Authentication Header (AH) RFC 2402 (PS), 11/98 IP Encapsulating Security Payload (ESP) RFC 2406 (PS), 11/98 Internet Key Exchange (IKE) RFC 2409 (PS), 11/98 Application layer protocol for negotiation of Security Associations (SA) and Key Establishment Large and complex (48 documents) Mandatory for IPv6, optional for IPv4 75 IPsec - Security services Access control Connectionless integrity Data origin authentication Rejection of replayed packets (a form of partial sequence integrity) Confidentiality Limited traffic flow confidentiality 76 IPsec - Concepts IPsec - Parameters Security features are added as extension headers that follow the main IP header Authentication header (AH) Encapsulating Security Payload (ESP) header Security Association (SA) Security Parameter Index (SPI) IP destination address Security Protocol Identifier (AH or ESP) 77 sequence number counter sequence counter overflow anti-replay window AH info (algorithm, keys, lifetimes,...) ESP info (algorithms, keys, IVs, lifetimes,...) lifetime IPSec protocol mode (tunnel or transport) path MTU (maximum transmission unit) 78 13
IPsec: Cryptographic techniques AH: HMAC-MD5-96, HMAC-SHA1-96 ESP:DES-CBC, NULL encryption, HMAC-MD5-96, HMAC-SHA1-96 (recommended: 3DES-CBC) RFC 2403 (PS), November 1998 HMAC-MD5-96 (mandatory) RFC 2404 (PS), November 1998 HMAC-SHA-1-96 (mandatory) RFC 2104 (I), February 1997 HMAC: ICV = hash( K? opad hash( K? ipad data )) with ipad = 0x363636... ; opad = 0x5C5C5C... 79 IPsec - Modes Transport (host-to-host) ESP: encrypts and optionally authenticates IP payload, but not IP header AH: authenticates IP payload and selected portions of IP header Tunnel (between security gateways) after AH or ESP fields are added, the entire packet is treated as payload of new outer IP packet with new outer header used for VPN 80 IPsec - AH Transport mode IPsec - AH Tunnel mode Security Parameters Index: identifies SA Sequence number: anti-replay Integrity Check Value: data authentication using HMAC-SHA-1-96 or HMAC-MD5-96 IP hdr upper layer data IP hdr upper layer data New IP hdr AH (..., Seq. Num., ICV) IP hdr upper layer data Integrity (only header fields that are not changed or are changed in a predictable manner)) IP hdr AH (..., Seq. Num., ICV) upper layer data Integrity (only header fields that are not changed or are changed in a predictable manner) 81 82 IPsec - ESP header IPsec - ESP Transport mode Security Parameters Index: identifies SA Sequence number: anti-replay Encrypted payload data: data confidentiality using DES, 3DES, RC5, IDEA, CAST, Blowfish Padding: required by encryption algorithm (additional padding to provide traffic flow confidentiality) Integrity Check Value : data authentication using HMAC-SHA-1-96 or HMAC-MD5-96 IP hdr IP hdr upper layer data ESP hdr upper layer data ESP tlr ICV Confidentiality Integrity 83 84 14
IPsec - ESP Tunnel mode IPsec - Key management IP hdr upper layer data new IP hdr ESP hdr IP hdr upper layer data ESP tlr ICV Confidentiality Integrity Manual Automated procedure / framework Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408 (PS) key exchange mechanism: Internet Key Exchange (IKE) Oakley: DH + cookie mechanism to thwart clogging attacks SKEME 85 86 IPsec: Key management IPsec: Key management IKE defines 5 exchanges Phase 1: establish a secure channel Main mode Aggressive mode Phase 2: negotiate IPSEC security association Quick mode (only hashes, PRFs) Informational exchanges: status, new DH group Based on 5 generic exchanges defined in ISAKMP protection suite (negotiated) encryption algorithm hash algorithm authentication method: preshared keys, DSA, RSA, encrypted nonces Diffie Hellman group: 5 possibilities cookies for anti-clogging 87 88 IKE - Main Mode with Digital Signatures IKE - Main Mode with Digital Signatures K derived from Initiator master = prf( N i N r, g xy ) SIG i = Signature on H( master, g x g y... ID i ) proposed attributes selected attributes g x, N i g y, N r E(K, ID i, [Cert(i)], SIG i ) E(K, ID r, [Cert(r)], SIG r ) H is equal to prf or the hash function tied to the signature algorithm (all inputs are concatenated) Responder SIG r = Signature on H( master, g y g x... ID r ) mutual entity authentication mutual implicit and explicit key authentication mutual key confirmation joint key control identity protection freshness of keying material perfect forward secrecy of keying material non-repudiation of communication 90 15
IPsec Overview Much better than previous alternatives IPsec documents hard to read Committee design: too complex ESP in Tunnel mode probably sufficient Simplify key management Clarify cryptographic requirements and thus difficult to implement (securely) VPN? Virtual Private Network Connects a private network over a public network. Connection is secured by tunneling protocols. The nature of the public network is irrelevant to the user. It appears as if the data is being sent over the private network. 91 92 VPN - Common use Transit Internetwork Remote user access over the Internet Virtual Private Network Connecting networks over the Internet Connection computers over an intranet Logical Equivalent 93 94 Remote user access over the Internet Connecting networks over the Internet Virtual Private Network Virtual Private Network Internet Internet Branch Office Corporate Hub ISP Dedicated Link to ISP Dedicated Link to ISP Corporate Hub Dedicated or Dial-Up Link to ISP Dedicated Link to ISP You can use existing local Internet connections. No need for long distance connections You can use existing local Internet connections. No need for long distance connections or leased lines 95 96 16
Connecting computers over an intranet Virtual Private Network Corporate Internetwork VPN Server Secured or Hidden Network Provides easy client access to secured or hidden networks within the corporate network 97 VPN - Basic requirements User authentication and user authorization Data authentication and data confidentiality Key management Encapsulation data of private network is encapsulated in packets suited for transmission over the public network. (tunneling protocol) Address management assign a client s address on the private net 98 Tunneling Tunneling protocols Payload Tunnel Endpoints Transit Internetwork Header Transit Internetwork Tunnel Payload Layer 2, data link layer, PPP frames PPTP: Point -to-point Tunneling Protocol (Microsoft) L2TP: Layer 2 Tunneling Protocol Layer 3, network layer, IP packets IPSec, tunnel mode Tunneled Payload 99 100 PPTP: Point-to-Point Tunneling Protocol L2TP: Layer 2 Tunneling Protocol MPPE: Microsoft Point -to-point Encryption Encapsulation: PPP in GRE (Generic Routing Encapsulation) header and IP header. 101 102 17
SSH - General Tatu Ylonen, Helsinki University, 1990. Also IETF working group (SecSH) Version 2: several Internet Drafts available SSH - Goals Allow secure communication over insecure networks: secure replacements for the r-tools secure X11 sessions arbitrary TCP/IP port forwarding over encrypted channels? can be used for setting up VPN 103 104 SSH - Protocols SSH Secure login Transport layer protocol: server authentication (host public key + server public key) key exchange cryptographic data protection User authentication protocol: username/password public-key authentication of the user public-key authentication of the user s host Connection protocol: interactive login sessions remote execution of commands... 105 Example: logging in from MS Windows to a machine running Linux with Putty 19:58:42 Looking up host "lagrange.esat.kuleuven.ac.be" 19:58:42 Connecting to 134.58.189.104 port 22 19:58:45 Server version: SSH-1.99 -OpenSSH_3.4p1 Debian 1:3.4p1-1 19:58:45 We claim version: SSH-2.0 -PuTTY-Release-0.53b 19:58:45 Using SSH protocol version 2 19:58:45 Doing Diffie-Hellman group exchange 19:58:45 Doing Diffie-Hellman key exchange 19:58:46 Host key fingerprint is: 19:58:46 ssh-rsa 1024 bf:7d:02:8d:4c:84:9f:fb:6b:e1:cd:cb:6a:49:5a:c5 19:58:46 Initialised AES-256 client->server encryption 19:58:46 Initialised AES-256 server ->client encryption 19:58:51 Keyboard-interactive authentication refused 19:58:59 Sent password 19:58:59 Access granted Protocol negotiation Session key exchange Host authentication Cipher negotiation Client authentication 106 SSH Secure POP3 tunnel Use SSH client to setup a tunnel from localhost:110 to mailserver:110 Setup the mail client to connect to 127.0.0.1 (localhost) instead of the mail server. Data transmitted to localhost will be delivered through the SSH tunnel to the mail server on port 110. The mail server will reply back through the SSH tunnel. Final remarks 107 18
Some observations IPSec is really transparent, SSL/TLS only conceptually, but not really in practice SSH, PGP: stand-alone applications, immediately and easy to deploy and use Network security: solved in principle Electronic commerce security: more is needed! 109 More information (1) William Stallings, Cryptography and Network Security - Principles and Practice, Second Edition, 1999 Nagand Doraswamy, Dan Harkins, IPSEC - The New Security Standard for the Internet, Intranets, and Virtual Private Networks, Prentice Hall, 1999. IETF web site: www.ietf.org e.g., IETF-TLS Working Group http://www.ietf.org/html.charters/tls-charter.html 110 More information (2) Java Security (2nd edition) http://www.securingjava.com/ W3C Security (incl WWW Security FAQ) http://www.w3.org/security/ E-Commerce Security, Weak Links, Best Defenses http://www.cigital.com/books/ecs/ Security Technologies for the World Wide Web http://www.esecurity.ch/books/wwwsec.html 111 19