Cosc 4765

1. Cryptography in action Cosc 4765

2. Building protocols • With the primitives • Symmetric Algorithms, Message Authentication Codes, One-way Hash Algorithms, Public-key Encryption, Digital Signatures, and Random Number Generators • We can build up an "security" protocol • As we saw in the last lecture, many applied applications used multiple primitives to get the job done (generally for speed).

3. File Encryption • File encryption • Person X, chooses a pass-phrase. • the cryptography software hashes the pass-phase into a secret key. • The key is used the encrypt the data. • In Theory only Person X can decrypt the file. • That assumes that only person X knows the pass-phrase, and they choose a very good pass-phrase. • Remember pass-phrases and key generation.

4. Secure E-mail • To provide a digital signature and encryption of MIME based messages • Two working groups in the IETF • S/MINE – X.509/PKIX based • PGP/MIME – Based on the PGP program • Also know as OpenPGP • We'll look at PGP and OpenPGP • And PKIX and certificates

5. About PGP • PGP stands for Pretty Good Privacy • PGP uses a public-key encryption application for exchanging files or messages with confidentiality and authentication. • Designed by Phil Zimmermann in 1980s • E-mail and file encryption software • Freeware available from MIT • http://web.mit.edu/network/pgp.html • http://www.pgp.com/ • Versions for DOS, Windows, Unix, Linux, Macintosh

6. PGP encryption • PGP combines some of the best features of both private and public key cryptography. • Like most public key cryptography, it's a hybrid • When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves modem transmission time and disk space and, more importantly, strengthens cryptographic security. • Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis.

7. PGP encryption (2) • PGP then creates a session key • This is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is cipher text. • Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the cipher text to the recipient.

8. PGP encryption Visual

9. PGP Decryption • Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted cipher text.

10. PGP Decryption Visual

11. PGP Pro's • The combination of the two encryption methods combines the convenience of public key encryption with the speed of conventional encryption. • Conventional encryption is about 1,000 times faster than public key encryption. Public key encryption in turn provides a solution to key distribution and data transmission issues. Used together, performance and key distribution are improved without any sacrifice in security.

12. PGP Con's • There has been one known successful crack of PGP. • This text was very short and the time to decrypt it was very large in comparison. • Back to Unicity Distance issues. • With compression, that unicity distance goes up, maybe 2 to 3 times • Again, the standardized beginnings can reduce it considerably.

13. OpenGPG • OpenPGP is a non-proprietary protocol for encrypting email using public key cryptography. It is based on PGP as originally developed by Phil Zimmermann. The OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys. • Beginning in 1997, the OpenPGP Working Group was formed in the Internet Engineering Task Force (IETF) to define this standard that had formerly been a proprietary product since 1991. Over the past decade, PGP, and later OpenPGP, has become the standard for nearly all of the world's encrypted email. • By becoming an IETF Proposed Standard (RFC 2440), OpenPGP may be implemented by any company without paying any licensing fees to anyone. • http://www.openpgp.org/about_openpgp/

14. Back to the key problem • Where do you get a public key from? • How do you know it's real? • How do you know the person is still using it?

15. pgp key servers • There are a number "keyservers" to hold public keys. • http://www.keyserver.net/ is a generic keyserver that passes your requests to "geography" close keyservers. • http://pgp.mit.edu for example. • The problem, there is no verification that a pgp public key actually belongs to the person.

16. A Note on posting your key • We suggest you wait until you are familiar with Public Keys and the concept of Public Key Encryption before sending a key to a key server. • This is just in case you change your mind and would like to modify the type of key or its name. • Once your key is on a public key server, it cannot be removed. • Each time you submit a key to a key server, the server will perform a merge of the new data concerning your key with the existing data of your key, if any. • You can add information to your key such as an additional identifier or certificates but you should keep in mind that the old data will not be removed. • These restrictions may change in the future as key servers evolve.

17. Verifying PGP Public Keys • There are several ways to check the authenticity of a key, that is, if the key really belongs to its purported owner. • Unless you physically received a key, for example, by means of a floppy disk, or unless you really trust the person who applied his/her Certificate on a Public Key, the best way to verify the authenticity of a key is to compare its fingerprint. • Call the purported owner of the key you want to verify. Ask them to read you the fingerprint of his Private Key: It has to match that of his Public Key.

18. Why should I use pgp? • Many people argue that their messages do not carry material that require privacy or authentication. • Zimmermann Argued • “Why, then, do people put their mail in envelopes rather than on post cards? Because it makes your message less apt to be read by someone you don't want it to be.”

19. Back to the key problem (2) • How do you know it's real? • So we have a key server, did Alice put her key there or did Eve? • Worse, what if the key server is broken into? • Do we even know if any of the keys are real? • How do you know the person is still using it? • We'll look at this questions and more with Public Key Infrastructure (PKI) and Certificates

20. Certificates • Certificates are similar in nature to an ID card, sort of. • They are an attempt to answer the question • Is this the real key for person X. • and much more. • A Certificate is a binding between your public key and a mutually trusted entity • This entity I'll refer to as god for a while.

21. Certificates (2) • The binding is generally referred to signing. • So Alice somehow gets god to take her name and public key and signs it. It creates public key certificate. • It no longer matters where Bob gets Alice's key, because the public key certificate has god's signature on it. Since Bob trusts god, then the certificate is valid. • As long as Bob knows god public key! • New problem, where is god's public key and how do we know it wasn't tampered with.

22. Real Certificates • They contain more information • The person's name • and possibly job title, e-mail address(es), more • Information about the certificate • When it was issued, when it expires • information about the issuer/signer • who they are, algorithm used to sign • public key itself • and what algorithm was used.

23. And when we loss the private key? • At some point, someone will lose their private key • which pretty much messes up the whole system. • If it was stolen, life gets even uglier. • Remember, keys can't be removed. • So we need to be able to revoke a certificate. • Alice tells god and god revokes the certificate.

24. Reality • We a key is lost or stolen, then the person tells the signer. • That signer puts the certificate on the Certificate Revocation List (CRL) • You tell your credit card company when your card has been lost or stolen. They put your card number on a similar list. • When some looks up certificates, the first thing to do is make sure it's not an CRL. Also that the certificate hasn't expired. • Which all vendors do (electronically) when you use your credit card.

25. Mutually trusted entity • Certificates are issued by a Certificate authority (CA). • The CA certificates are issued by other CA • probably VeriSign • These are signed by higher CAs until we reach "god" • The highest CAs have what knows a root certificates • They are not signed by anyone else.

26. Levels of signed certificates • These levels of signatures allows to use a hierarchies of trust. • I can trust my CA, because they are signed by a higher level CA, who is signed … • The root certificates are embedded in the software from your browser, VPN, O/S, etc. • This is what we call the Public-key Infrastructure (PKI) • Now we'll look at it more formally.

27. Overview of PKI • Establishes trust between parties across networks. • PKI used to guarantee identity and integrity. • Digital certificates used in PKI to verify identity of both parties. • Similar to an individual’s signature that is verified by a notary public. • Encryption used in PKI to prevent other parties from viewing information.

28. Components of PKI • Security Policy • Defines organization’s direction on information security. • Specifies processes and principles for use. • Certification Authorities (CA) • Issue digital certificates to valid applicants. • Schedules an expire date. • Revokes certificates when validity period expires.

29. Components of PKI (2) • Registration Authorities (RA) • Provide interface between the user and CA. • Verifies credentials of applicants and passes valid requests to CA. • Certificate Holder • Individuals or parties who receive certificates from CA.

30. Components of PKI (3) • Certificate Repository • Warehouse of all published certificates. • Stores and distributes certificate and party information. • Making data available to requests. • Validation Server • Separate server. • Provides certificate status, i.e. expired, revoked, etc.

31. PKI • Once PKI components are in place, we are ready to begin the flow of encrypted data between parties • Now we can send that encrypted e-mail between Bob and Alice • Do we still need to worry about Eve? • Business transactions • number tunneling applications, such as SSH, VPN, and SLL/STL

32. X.509 Architecture • Leading architecture for PKI. • Used for a variety of applications, including messaging, e-commerce, and web browsers. • Distinct CAs, parties, and users. • Each user trusts at least one CA. • Certificates posted to repository. • Validation checks. • Simple Distributed Security Infrastructure (SDSI) – developing architecture that simplifies X.509.

33. PKI Implementation Frameworks • X.509 clearly describes certificate format, but lacks procedures for requesting and procuring certificates. • ITU-T Recommendation X.509 is one of many implementation standards. • Governments are now realizing importance of implementation frameworks and are beginning to develop standards.

34. Disadvantages of PKI • The passing of public keys and encryption/decryption process is time consuming. • Not efficient for large amounts of data. • Costly to implement on a large scale. • Differences in implementation frameworks can create compatibility issues. • some do not allow for the CRLs.

35. Now some problems. • Back to having your private key stolen. • When you find out? • generally after it be misused. • Some laws on digital signatures, state you are responsible the "action" of your private key, even if you didn't use it. • In other words, someone else used your private key. • Using credit cards • We know when we get the bill (or that phone call) • Call all up the credit card company and state "I didn't make that purchase." • And from there you may only be liable for $50 or even less.

36. Root Certificates • Root Certificates are embedded in the software, say the browser. • If an attacker is successful in inserting their "root certificate" into the browser (An attack like this has happened), the you will accept any certificates signed by the attackers "root certificate" as valid.

37. More problems (2) • When was that certificate put on the CRLs? • If I lost my key last week and only now reported it • Can I retroactively report it "lost" • Need I mention Key length and pass-phrases.

38. More problems (3) • Certificate authority • Anyone can be CA • You don't have your public key signed into order to issue a Certificate. • Cosc is a CA at least for two certificates for department applications.

39. A possibly huge Problem • When encrypted e-mail becomes more common • There is problem that will need to be addressed. • Currently anti-virus program and anti-spam programs scan based on a hash and/or other variants (keyword searches, etc). • An encrypted e-mail will defeat the anti-virus/spam programs on gateway servers. • And even client side, until the message is decrypted. • All the work is pushed back on the client again.

40. Man In the Middle Attacks • Generally, a man in the middle attacks takes this form • Alice want to send to bob. • Instead of a direct connection eve intercepts the setup message to bob. • Alice forms a connection to eve and eve forms a connection to bob. • So data send from Alice goes to eve and then eve transmits it on to bob and vise versa.

41. Man In the Middle Attacks (2) • Most secure protocols designed to prevent this type of attack use the following method: • Client connects to the server, which sends host and server pub keys, supported encryption and possible more information • client checks to see if knows the host • If the host is not known, then may be a problem. • If the host info does not match then we stop now. • client selects and sends encryption mode and random session key encrypted with host AND server pub key • server sends confirmation encrypted with session key • server is authenticated.

42. Man In the Middle Attacks (3) • Under this method, eve won't know all the information and so won't be able to respond with all the correct info • So the attack will fail. • If this is the first time Alice attempts to talk to Bob and Eve is running an Attack • It may succeed, if Alice already has the host information from "another source"

43. Many more possible app's • E-money • Allow you sent/receive "cash". • E-voting • Allow you to vote electronically and only once • Secure phones/VOIP • Encrypted voice communication over the internet or even public phone system • Many more • But remember cryptography only transforms the security issues into another type of security problem • normally some kind of storage issue and there is almost always a "trust" issue as well.

44. For future lectures w/ Crypto • Authentication • Protecting O/S and Databases • Worms and Viruses • We'll look at these when we get to Network security • Secure Socket Layer (SSL)/ Transport Layer Security (TLS ) • VPN, ipsec, and SSH • Wireless security: WEP and WPA • Secure DNS

45. Addition information • IETF X.509 pkix, public key infrastructure (PKI) and RFC1422 • IETF Proposed Standard (RFC 2440) for OpenPGP • X509 certificates • IETF SPKI and more SPKI • S/MIME spec/RFCs and RSA's S/MIME page • NIST's PKI info • Entrust's why you need two key pairs • verisign CA and thawte and entrust • MIME RFC1521 and PKCS #7 • Establishing Identity Without Certification Authorities • McCurley's the dangers of MIME attachments • Thirteen Reasons to Say 'No' to Public Key Cryptography

46. Q A &