Networking Secure apps Aims Crypto Basics Secure Client Applications HTTPS Secure Email Networking Sirindhorn International Institute of Technology Thammasat University Prepared by Steven Gordon on 26 June 2014 Common/Reports/secure-client-apps.tex, r900 1/26
Networking Acronyms and Abbreviations Secure apps CA Certificate Authority (same as TA) Aims HTTP HyperText Transfer Protocol Crypto Basics HTTPS HTTP over SSL HTTPS PGP Pretty Good Privacy Secure Email PR Private key PU Public key SSL Secure Sockets Layer (same as TLS) TA Trusted Authority (same as CA) TCP Transmission Control Protocol TLS Transport Layer Security (same as SSL) 2/26
Networking Contents Secure apps Aims Crypto Basics Aims HTTPS Secure Email Cryptography Basics HTTPS and Digital Certificates Secure Email 3/26
Networking Workshop Aims Secure apps ◮ Understand security limitations of common Internet Aims applications Crypto Basics ◮ Increase awareness of ”extensions” of Internet HTTPS applications that increase security Secure Email ◮ Learn about techniques for enhancing your communication secrecy and privacy 4/26
Networking Applications and Extensions Secure apps Web Browsing Aims Crypto Basics ◮ Secrecy: HTTPS and certificates, HTTPS Everywhere HTTPS ◮ Privacy: AdBlock Plus, Ghostery, FoxyProxy, Hola . . . Secure Email ◮ Safety: NoScript, . . . Email ◮ Signatures and Secrecy: OpenPGP, Enigmail, Thunderbird File Encryption ◮ File: ◮ Disk: TrueCrypt, BitLocker 5/26
Networking Contents Secure apps Aims Crypto Basics Aims HTTPS Secure Email Cryptography Basics HTTPS and Digital Certificates Secure Email 6/26
Networking Cryptography Secure apps Symmetric Key Cryptography Aims Crypto Basics ◮ Source: Encrypt message with secret key K HTTPS ◮ Destination: must also know K ; decrypts data with K Secure Email ◮ Pro: Fast for large amounts of data ◮ Con: Requires K to be securely exchanged in advance Public Key Cryptography ◮ Each node has a (public, private) key pair, ( PU a , PR a ) ◮ Encrypt a message with one key in pair, can only be decrypted with other key in key pair ◮ Pro: Does not require exchange of secrets ◮ Con: Slow for large amounts of data 7/26
Networking Public Key Cryptography Secure apps Public Key Cryptography for Confidentiality Aims Crypto Basics ◮ Source: Encrypt message with public key, PU dst of HTTPS destination Secure Email ◮ Destination: decrypts data with PR dst ◮ Only destination can decrypt it Public Key Cryptography for Signatures ◮ Source: Encrypt message with own private key, PR src ◮ Destination: decrypts data with PU src ◮ Only source could have sent it 8/26
Networking Contents Secure apps Aims Crypto Basics Aims HTTPS Secure Email Cryptography Basics HTTPS and Digital Certificates Secure Email 9/26
Networking HTTP and HTTPS Secure apps HTTP Aims Crypto Basics ◮ Send request to web server; returns the web page HTTPS ◮ Malicious use can intercept/modify data Secure Email HTTPS ◮ Establish secure SSL/TLS connection between browser and server; then use HTTP ◮ Data is encrypted; interception/modification not possible ◮ But . . . 10/26
Networking HTTP: Interception is Easy Secure apps Aims Crypto Basics HTTPS Secure Email 11/26
Networking HTTPS: Data is Encrypted Secure apps Aims Crypto Basics HTTPS Secure Email ◮ Public key cryptography used to exchange a secret key ◮ Data encrypted with secret key 12/26
Networking HTTPS: Man-in-the-Middle Attack Secure apps Aims Crypto Basics HTTPS Secure Email 13/26
Networking HTTPS Encryption Secure apps ◮ To encrypt data, browser and server must exchange a Aims secret key Crypto Basics ◮ But cannot send secret key, unencrypted, across HTTPS Internet Secure Email ◮ Use public-key cryptography for secret key exchange ◮ Server has (public, private) keypair ◮ Encrypt with one, can only decrypt with the other in pair ◮ Server sends its public key to browser, then used to encrypt secret key 14/26
Networking HTTPS: Challenge is Public Key Distribution Secure apps Aims Crypto Basics HTTPS Secure Email ◮ How does browser know received public key is that of the server? 15/26
Networking HTTPS: Challenge is Public Key Distribution Secure apps Aims Crypto Basics HTTPS Secure Email ◮ How does browser know received public key is that of the server? 16/26
Networking HTTPS: Trusted Authority Signs Key Secure apps Aims Crypto Basics HTTPS Secure Email ◮ Trusted Authority: Another entity trusted by the browser and server ◮ Trusted Authority “signs” public key of server ◮ Browser “verifies” received public key using TA’s public key 17/26
Networking HTTPS: Trusted Authority Signs Key Secure apps Aims Crypto Basics HTTPS Secure Email ◮ If malicious node modifies signed public key of server, the verification at browser will detect it ◮ A public key signed by someone else is called a digital certificate 18/26
Networking Digital Certificates in Practice Secure apps How does a server obtain a certificate? Aims Crypto Basics ◮ Prove identity to CA by: HTTPS ◮ Domain validation Secure Email ◮ Extended validation ◮ Free and commercial services How does browser obtain CA certificate? ◮ Pre-loaded into browsers ◮ Hierarchy of certificates is supported What if CA certificate is not in browser? ◮ Browsers commonly present warning to user 19/26
Networking Security Issues with Digital Certificates Secure apps ◮ Identity verification of server (owners) Aims ◮ Security of CA private key Crypto Basics ◮ Pre-loaded certificates by browser publisher HTTPS Secure Email ◮ Response when invalid certificate received ◮ Algorithms used in certificates should be strong 20/26
Networking Contents Secure apps Aims Crypto Basics Aims HTTPS Secure Email Cryptography Basics HTTPS and Digital Certificates Secure Email 21/26
Networking Secure Email Secure apps ◮ Email messages originally only text with pre-defined Aims headers (To, From Subject, CC, . . . ) Crypto Basics ◮ Multipurpose Internet Mail Extensions (MIME) allows HTTPS for different message and header formats: different Secure Email character sets, attachments, new headers ◮ Secure email requirements: 1. Authentication: receiver can confirm the actual sender, and that content is not modified 2. Confidentiality: only sender/receiver can read the contents ◮ Two common ways to implement secure email: 1. S/MIME 2. OpenPGP ◮ Both use similar approach: sender signs message with private key, encrypts message with symmetric key encryption using a secret key, and encrypts the secret key using recipients public key 22/26
Networking OpenPGP Secure apps ◮ Pretty Good Privacy (PGP) developed by Phil Aims Zimmerman in 1991 Crypto Basics ◮ IETF standardised as OpenPGP HTTPS ◮ One of first and most widely used applications of Secure Email public-key cryptography ◮ Implementations: ◮ Original by Zimmerman: Symantec ◮ GNU Privacy Guard (GPG) ◮ Many email clients (either direct or through plugins, e.g. Enigmail, GPG4Win) ◮ OpenPGP vs S/MIME: ◮ OpenPGP: public keys distributed informally: phone, websites, email ◮ S/MIME: public keys distrubuted as X.509 digital certificates 23/26
Networking PGP Operation: Concept Secure apps Aims Crypto Basics HTTPS Secure Email Credit:xaedes & jfreax & Acdx, Wikimedia Commons, CC Attribution-Share Alike 3.0 24/26
Networking PGP Operation: Message Generation at A Secure apps Aims Crypto Basics HTTPS Secure Email Credit: Figure 18.5 in Stallings, Cryptography and Network Security , 5th Ed., Pearson 2011 25/26
Networking PGP Operation: Message Reception at B Secure apps Aims Crypto Basics HTTPS Secure Email Credit: Figure 18.6 in Stallings, Cryptography and Network Security , 5th Ed., Pearson 2011 26/26
Recommend
More recommend
