1 / 39

Cryptography

Cryptography. Module III. Security Services. Confidentiality/Privacy Has to do with hiding information. Only the intended receiver can make sense out of the message. Message Authentication Data Origin Can it be achieved by symmetric cipher? Yes

williamwalsh
Download Presentation

Cryptography

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. Cryptography Module III

  2. Security Services • Confidentiality/Privacy • Has to do with hiding information. Only the intended receiver can make sense out of the message. • Message Authentication • Data Origin • Can it be achieved by symmetric cipher? Yes • Can it be achieved by asymmetric cipher? No • Data Integrity • Can it be achieved by symmetric cipher? (not really) • Can it be achieved by asymmetric cipher? (not really) • There is that possibility that bits (cipher bit-block) can be re-ordered in transit • Non-Repudiation • The receiver must proof that the message came from a specific sender. • The sender can not repudiate/deny sending the message K. Salah

  3. Digital Signature – signing whole document K. Salah

  4. Digital Signature – signing the digest K. Salah

  5. Digital Signature • Provides • Authentication • Data Origin • Data Integrity (with free-collision hashing) • Nonrepudiation • Does not provide confidentiality/privacy • Need to encrypt the message K. Salah

  6. What is the difference (in terms of non-repudiation, data origin, data integrity, confidentiality) when: • Sign then Encrypt • Encrypt then Sign • Sign and encrypt only PT message K. Salah

  7. MIM Attack and ARP Poisoning with a demo

  8. User Authentication • User Authentication = Verification of identity • Secret key approach • Using Symmetric-Key only • MIM attack where data is intercepted, tampered with, or replayed again to receiver • Using a nonce/challenge • A random number • Replay is resolved • Bidirectional • Must have a unique challenge per sessions • Public key approach • Subject to MIM attack K. Salah

  9. Key Management • Symmetric Key Distribution • Problems with distributing symmetric key • Diffe-Hellman Method • Subject to MIM attack • KDC Method • Public-Key Certification • Certificate-based K. Salah

  10. Diffe-Hellman Method K. Salah

  11. MIM Attack K. Salah

  12. KDC (Key Distribution Center) • Problem with Diffe-Hellman approach is that information is sent in plaintext • R1 and R2 needs to encrypted • A secret key is needed • So we have a vicious circuit • Three solutions • Using KDC • Needham-Schroeder Protocol • Otway-Rees Protocol K. Salah

  13. Using KDC • Sender and receiver registers with KDC and each given a private key • KDC sends a ticket back to sender • Vulnerable to replay attacks at step 3 and beyond K. Salah

  14. Needham-Schroeder Protocol • Solve replay attack • Uses 4 nonces • (R1-1) and (R2-1) are used to ensure that ticket was received correctly (decrypted and processed properly) K. Salah

  15. Otway-Rees Protocol • Solve replay attack with fewer steps • R is a common nonce. R is different for each session. Used to make sure encryption and decryption got processed properly K. Salah

  16. Public Key Certification • MIM attack. Intruder can intercept the public key in transit and send his own. • A need for a trusted entity, a certificate authority (CA) to solve public key fraud • CA can be public. • Their public key is trusted and embedded with the OS and Applications. Also it can be added manually. • Examples • Thawte • veriSign • Entrust • CA can be private • Owned by an organization K. Salah

  17. X.509 K. Salah

  18. PKI (Public Key Infrastructure) • Like DNS, there is a need for hierarchical structure of CAs that are public and private • The principle of cross certification • The CA does not to be on-line • CA certificate is typically issued by upper level certificate. • Root CA issues its own certificate • Local CA can issue its own certificate K. Salah

  19. Use of Certificates • Email • PGP-based: • Faster than S/MIME • PGP, OpenPGP, GnuPG (Gnu Privacy Guard) • Email clients: • Enigmail • PGP Mail • Hushmail (web based) • S/MIME or Certificate based (Digitally signed and then encrypted) • Email Clients: • Outlook • Mozilla Thunderbird • https and SSL • SSH • Software protection and signing • User authentication through certificate-based • FTP • Dialup • Directory • .Net K. Salah

  20. PGP • Invented by Phil Zimmermann to provide privacy, integrity, authentication, and nonrepudiation • Uses digital signature to provide integrity, authentication, and nonrepudiation • Uses one-time secret-key and public-key encryption to provide privacy • Message only makes sense at the receiver • What is the job of one-time secret key? What if it gets removed? • Encryption is faster with one-time secret key, especially when email is long. • One-time key is very short K. Salah

  21. S/MIME • Secure / Multipurpose Internet Mail Extension • provides similar services to PGP • based on technology from RSA Security • Can use symmetric or asymmetric key encryption • As specified in the MIME headers • S/MIME certificates are X.509 conformant • Contained in email clients • MS outlook • Netscape communicator • Eudora • Mozilla Thunderbird • etc K. Salah

  22. OpenSSL vs. PGP • http://www.openssl.org • OpenSSL is a cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related cryptography standards required by them. • The openssl program is a command line tool for using the various cryptography functions of OpenSSL's crypto library from the shell. It can be used for • Creation of RSA, DH and DSA key parameters • Creation of X.509 certificates, CSRs and CRLs • CSR (Certificate Signing Request) containing public key to submit to CA • CRL (Certificate Revocation List) to submit to CA to revoke certificates • Calculation of Message Digests • Encryption and Decryption with Ciphers • SSL/TLS Client and Server Tests • Handling of S/MIME signed or encrypted mail K. Salah

  23. Security facilities in the TCP/IP protocol stack K. Salah

  24. SSL and TLS • SSL – Secure Socket Layer • TLS – Transport Layer Security • Both provide a secure transport connection between applications (e.g., a web server and a browser) • SSL was originated by Netscape • SSLv1 and SSLv2 • SSL version 3.0 has been implemented in many web browsers (e.g., Netscape Navigator and MS Internet Explorer) and web servers and widely used on the Internet • SSL v3.0 was specified in an Internet Draft (1996) • It evolved into TLS specified in RFC 2246 • TLS can be viewed as SSL v3.1 K. Salah

  25. Transport Layer Security • For any TCP protocol: HTTP (https:// port 443), NNTP, telnet, POP, SFTP, etc. • For transactions on Internet, a browser needs: • Make sure that server belongs to the actual vendor • Contents of message are not modified during transition • Make sure that the impostor does not interpret sensitive information. • TLS has two protocols: Handshake and data exchange protocol. • Handshake: Responsible for negotiating security parameters (encryption method, etc), authenticating the server to the browser, and (optionally) defining other communication parameters. • Data exchange (record) protocol uses the secret key to encrypt the data for secrecy and to encrypt the message digest for integrity. K. Salah

  26. SSL Record Protocol Services • Confidentiality – the handshake protocol defines a shared key for encryptions of SSL payloads • Message Integrity – the handshake protocol defines a shared key used to form message authentication code (MAC) K. Salah

  27. SSL Record Protocol Operation K. Salah

  28. SSL Architecture K. Salah

  29. Handshake Protocol • Browser sends a hello message that includes TLS version and some preferences • Server sends a certificate message that includes the public key of the server. The public key is certified by some certification authority, which means that the public key is encrypted by a CA private key. Browser has a list of CAs and their public keys. It uses the corresponding key to decrypt the certification and finds the server public key. This also authenticates the server because the public key is certified by the CA. • Browser sends a secret key, encrypts it with the server public key, and sends it to the server. • Browser sends a message, encrypted by the secret key, to inform the server that handshaking is terminating from the browser key. • Server decrypts the secret key using its private key and decrypts the message using the secret key. It then sends a message, encrypted by the secret key, to inform the browser that handshaking is terminating from the server side. K. Salah

  30. SSL Hashing and Encryption • supported hash functions: • MD5 • SHA-1 • supported encryption algorithms • block ciphers (in CBC mode) • RC2_40 • DES_40 • DES_56 • 3DES_168 • IDEA_128 • Fortezza_80 • stream ciphers • RC4_40 • RC4_128 K. Salah

  31. client_hello Phase 1: Negotiation of the session ID, key exchange algorithm, MAC algorithm, encryption algorithm, Compression, and exchange of initial random numbers or nonces to prevent replay attacks of key exchange. server_hello certificate Phase 2: Server may send its certificate and key exchange message, and it may request the client to send a certificate. Server signals end of hello phase. server_key_exchange certificate_request server_hello_done certificate Phase 3: Client sends certificate if requested and may send an explicit certificate verification message. Client always sends its key exchange message. client_key_exchange certificate_verify change_cipher_spec finished Phase 4: Change cipher spec (to change the operating state to finished) and finish handshake change_cipher_spec finished K. Salah

  32. the sending part of the pending state is copied into the sending part of the operating state the receiving part of the pending state is copied into the receiving part of the operating state State changes • State • Handshake • Alert • Data Exchange • operating state • currently used state • pending state • state to be used • built using the current state • operating state  pending state • at the transmission and reception of a Change Cipher Spec message party A (client or server) party B (server or client) Change Cipher Spec K. Salah

  33. Server certificate and key exchange messages • certificate • required for every key exchange method except for anonymous DH (Diffe-Hellman) • contains one or a chain of X.509 certificates (up to a known root CA) • may contain • public RSA key suitable for encryption, or • public RSA or DSS key suitable for signing only, or • fix DH parameters • server_key_exchange • sent only if the certificate does not contain enough information to complete the key exchange (e.g., the certificate contains an RSA signing key only) • may contain • public RSA key (exponent and modulus), or • DH parameters (p, g, public DH value), or • Fortezza parameters • digitally signed • if DSS (Digital Signature Standard by NIST): SHA-1 hash of (client_random | server_random | server_params) is signed • if RSA: MD5 hash and SHA-1 hash of (client_random | server_random | server_params) are concatenated and encrypted with the private RSA key • certificate_request • sent if the client needs to authenticate itself • specifies which type of certificate is requested (rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, …) • server_hello_done • sent to indicate that the server is finished its part of the key exchange • after sending this message the server waits for client response • the client should verify that the server provided a valid certificate and the server parameters are acceptable K. Salah

  34. Client authentication and key exchange • certificate • sent only if requested by the server • may contain • public RSA or DSS key suitable for signing only, or • fix DH parameters • client_key_exchange • always sent (but it is empty if the key exchange method is fix DH) • may contain • RSA encrypted pre-master secret, or • client one-time public DH value, or • Fortezza key exchange parameters • certificate_verify • sent only if the client sent a certificate • provides client authentication • contains signed hash of all the previous handshake messages • if DSS: SHA-1 hash is signed • if RSA: MD5 and SHA-1 hash is concatenated and encrypted with the private key • MD5( master_secret | pad_2 | MD5( handshake_messages | master_secret | pad_1 ) ) • SHA( master_secret | pad_2 | SHA( handshake_messages | master_secret | pad_1 ) ) • finished • sent immediately after the change_cipher_spec message • first message that uses the newly negotiated algorithms, keys, IVs, etc. • used to verify that the key exchange and authentication was successful • contains the MD5 and SHA-1 hash of all the previous handshake messages: MD5( master_secret | pad_2 | MD5( handshake_messages | sender | master_secret | pad_1 ) ) | SHA( master_secret | pad_2 | SHA( handshake_messages | sender | master_secret | pad_1 ) ) where “sender” is a code that identifies that the sender is the client or the server (client: 0x434C4E54; server: 0x53525652) K. Salah

  35. Countermeasures to hijacking SSL sessions using MIM attack • Education • Sysadmins • Register with CA • Users • Beware of alerts • Use L3 Switches • Track and maintain IP/MAC pairs • S-ARP protocol • Certificate-based • Modify kernel to not honor unsolicited ARP replies • Sun Solaris • Linux 2.4 and 2.6 • Use IDS • Track and maintain IP/MAC pairs K. Salah

  36. Kerberos V5– not a certificate based authentication • A network authentication protocol of users developed by MIT • Name after Greek Mythology – a dog with 3 heads that guards the gates • Used in Windows to overcome shortcomings of NTLM • NTLM is less secure. Latest version uses a challenge/response authentication • Client id itself to the Server • Server sends the Client a challenge, R • Client responds in one message with NT response and LM response • NT response is based on LM Hash (of user password) and R • LM response is based on NT Hash (of user password) and R • Therefore, one can crack LM Hash or NT Hash separately! • This info is based on reverse engineering • In Windows XP, either Kerberos or NTLM can be selected for user authentication • Kerberos claims of more scalability and is more backward compatible. • Has three servers • Authentication Server (AS) • Ticket-Granting Server (TGS) • Real Server • FTP server • Dial up server • Directory server K. Salah

  37. Kerberos Servers K. Salah

  38. Kerberos Example • KA is generated locally when AS replies the first time. Alice has to enter a password. The password is then destroyed. • T is a challenge or a Timestamp to prevent replay attack • KS is the session key • If Alice wants to communicate to anther server, she does not to do the first two steps again K. Salah

  39. Kerberos on youtube • http://www.youtube.com/watch?v=7-LjpO2nTJo K. Salah

More Related