4dade2d669283ba231391cd696e9e4f2.ppt
- Количество слайдов: 55
Protocols PK Encr. /Auth. PK Key Establishment Secure Comm. in Open Networks SSL/TLS Nicolas T. Courtois - University College London
Security Notions 3 Stages 2 Nicolas T. Courtois, 2006 -2010
Comp. Sec COMPGA 01 Three Stages in Information Security [Courtois] 3 degrees of evolution: 1. Protections that are secret. 2. Based on a secret key. 3. Private-public key solutions. 3 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 PK Crypto Public-Key Cryptography == Asymmetric Cryptography 4 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 3 d Stage – Public Key Cryptography No shared key, One private and one public key. Private key: generated and stored securely… 5 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Third Stage – Public Key Cryptography Public key: can be distributed to many parties. Does not have to be public (but the system remains secure when it is). 6 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Public Key Schemes Symmetric == Conventional Schemes = 1 algorithm. Asymmetric == Public-Key Cryptography = 3 algorithms: • • • 7 Key Generation Algorithm Encryption / Signature Verification Algorithm. Decryption / Signature Algorithm. Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 *Traditional Secret-Key Encryption Bob Alice 8 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Public Key Encryption r m m or invalid Eve encryption algorithm c c decryption algorithm past: setup phase pk key generation algorithm (public key) 9 Nicolas T. Courtois, January 2009 sk (private key)
Comp. Sec COMPGA 01 MACs = “Secret-Key Signatures” m MAC algorithm yes/no (m, ) MAC algorithm forgery sk (secret key) 10 sk (secret key) Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Digital Signatures m signing algorithm yes/no (m, ) verification algorithm forgery sk (private key) 11 pk (public key) Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Signatures - Requirements 1. Authenticity – 2. Non-repudiation – 3. Public verify-ability - 12 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Protocols: Security of Email 13 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 SMTP Protocol THE original email protocol. Plaintext commands in a telnet session. Access: No authentication or basic password-based authentication, Emails: no encryption (in cleartext) no authentication. In addition everybody can send email => epidemics of spam!!!! 14 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Standards for Secure Email Two main open standards: • PGP – – – • [Phil Zimmerman, US activist, 1991], much later became open standard Gnu. PG [RFC 2440] some PGP products are certified by US gov NIST S/MIME [RSA Labs] – free implementation in Open SSL same general method called hybrid encryption: 15 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Hybrid Encryption random key K IV mi mi Data Encapsulation Module K block cipher + mode Eve ci ci K Key Encapsulation Module r PK encryption algorithm + K “good” padding encapsulated key PK decryption algorithm + verif. K padding past: setup phase pk 16 key generation algorithm (public key) Nicolas T. Courtois, January 2009 sk (private key)
Comp. Sec COMPGA 01 PKI Comparison • PGP – web of trust, totally decentralized system • • users can chose how much they trust each key is trust transitive? not really in particular, can also implement normal hierarchical PKI. S/MIME [RSA Labs] – uses the same standard PKI as SSL: X. 509 certificates. In both cases organisations can implement their own closed PKI. 17 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Problems with PK crypto and email encryption 18 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 • • * Problems with the PKI Systems Cf. Ellison and Schneier: “Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure” http: //www. schneier. com/paper-pki. pdf Ben Laurie: Seven and a Half Non-risks of PKI. http: //www. apache-ssl. org/7. 5 things. txt Problem 373: Þ once done it can hardly be undone… 19 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Main Risks / Pitfalls 1. 2. 3. 4. 5. 6. 7. 20 • • • Bugs? Backdoors? Source code? People/country trusted? Is it really the key of Bob? Certificates: trusting third parties in foreign countries Was his real key lost or stolen (e. g. virus)? Revocation Lists: lists of blacklisted keys stored on an Internet server Was my key of good quality? size (1024 bit: expired 2010) strength (RSA-PSS 2048 bits) randomness (mouse keyboard…) Was the message changed at signing time? Real-time substitution Did parties perform all the checks? Shall I save the message? Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 21 Nicolas T. Courtois, January 2009 **Attack Tree for PGP © Bruce Schneier
Comp. Sec COMPGA 01 Email Storage Questions: • should received and decrypted email be stored encrypted? • why when sending a message we sometimes need to add ourselves to the recipient list? 22 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Happy with Secure Email? Problems kind of solved: • confidentiality • authenticity Unsolved problems: • privacy of the recipient • privacy of the sender • hiding the existence of the message (=> Steganography). 23 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Key Establishment 24 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 The Need for a session key (a short term key): 25 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 What PK Encryption Can/Cannot Achieve and What Kind of Setup is Needed (PKI=Public Key Infrastructure) 26 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 What Is Achieved by PK Crypto ? Fact: There is no security possible to two parties that do not know each other and communicate via a public channel. [Man in the Middle] Bob Alice 27 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 But… Security is however possible if there is “some authenticity” available. 28 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Authentic Channel PK Crypto For example, if the channel is authentic: passive eavesdropping Bob Alice 29 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Can be done With Even Less (!) Security is however possible • [stronger] when the channel is authentic / authenticated (!!!). • [weaker] when a public key of Alice is securely hold by Bob. • [even weaker] when at least one authentic public key is hold by all parties. Can be used to certify other keys with digital signatures. ROOT OF TRUST Bob 30 Alice Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 ROOT of TRUST PK Crypto is ALL ABOUT trading security for authenticity. (and there is no security without an authentic public key. ) => Example: If Windows is hacked and there is no TPM/smart card, there is no security for e-Commerce or e-Banking. 31 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Asymmetric Techniques for Key Establishment 32 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Key Exchange by Public Discussion 33 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Diffie-Hellman Setup Diffie-Hellman Exponential Key Exchange. (brilliant idea unique in its kind…) Setup: (done once, can be the same for all users). g, a generator of Zp*. (DH works also in many other groups). also works mod n, composite n. 34 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Diffie-Hellman Exponential Key Exchange Alice a Bob b ga mod p gb mod p shared key: gab mod p 35 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Diffie-Hellman Exponential Key Exchange Alice a Bob b ga mod p gb mod p shared key: gab mod p Alice computation: (gb)a=gab mod p. Bob’s computation: (ga)b mod p. 36 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 MIM Attack Man In the Middle ga mod p gc mod p Alice computes gac mod p PKCert gb mod p Bob computes gbc mod p Fix: Authenticated Diffie-Hellman PKCert CAlice, ga mod p, Sign. Alice(ga mod p) CBob, gb mod p, Sign. Bob(gb mod p) 37 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Protocols: Electronic Commerce: SET vs. SSL or let the worse candidate win… 38 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 History See Ross Anderson, chapter 10. Secure Electronic Transaction (SET) protocol was designed by VISA and Master. Card [1996]. • Required installation of a software on each computer. • Very nice system – – • Failed to become widely adopted, – – 39 credit card numbers would never be known to merchants. the bank doesn’t need to know what people buy higher cost burden on merchants also because of much simpler SSL alternative available. Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 TLS = Transport Layer Security Goals: • two parties not knowing each other want to communicate • more, they want to involve in business/commerce – – • • • confidentiality: protect your credit card number also protect your privacy (what I’m buying) integrity => authenticity Am I really talking to Amazon. com? Key problem: MIM Attacks. What is TLS? In a nutshell it is a standard and practical way of doing authenticated Diffie-Hellman + extra bits and pieces that were required to make it work in the real life… Originally developed by Netscape as SSL=Secure Socket Layer and patented(!) – 1994. Now open standard renamed TLS = Transport Layer Security. 40 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 MIM Attack Man In the Middle ga mod p gc mod p Alice computes gac mod p PKCert gb mod p Bob computes gbc mod p Fix: Authenticated Diffie-Hellman PKCert CAlice, ga mod p, Sign. Alice(ga mod p) CBob, gb mod p, Sign. Bob(gb mod p) 41 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Revision: How Kerberos solved the n 2 problem… 42 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 TTP vs. CA, Kerberos vs. TLS As in Kerberos we need trusted parties (unless we adopt web of trust model, PGP, very hard to imagine in e-commerce). Differences: Kerberos is a symmetric system. • TTP must be online. • The TTP has all keys and must be trusted to keep them secret. • Future compromise of TTP can compromise all past sessions. TLS uses asymmetric cryptography. Much more powerful: less “exposure”. • CA is offline. Most of the time not needed at all. – • • 43 Even CRLs can be distributed in asynchronous offline way (e. g. . updates). We only need CA to be trusted for authenticity and only in the past. No compromise of past sessions. Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 TLS = Transport Layer Security Two Stages: 1. TLS Handshake: – Establish a shared key using PK crypto. • e. g. Authenticated DH • PKs are authenticated with certificates. 2. Encrypted and Authenticated Communication E+A 44 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 TLS = Transport Layer Security Contains lots of options for cryptographic implementation of these: negotiated crypto suite, compatibility and exportability. Example: 1. Establish shared key with authenticated D-H. 2. Encrypt + Authenticate with AES 128 + SHA_1 -based MAC. E+A 45 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Trouble: SSL Certificates 1) technical side 46 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Is TLS Secure? Should be… Oops, most current implementations are insecure, as it seems, due to issues with X 509 certificates, as shown at Black Hat 2009 (July 2009). 47 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Trouble: SSL Certificates 2) human and practical side 48 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Main Certificate Errors • Expired certificate: – • OK if the key sizes are OK and the key was not revoked or compromised. Self-signed certificate: – The certificate's issuer is itself. • • • Incomplete certificate chain: – • can be OK, information missing to connect. Domain mismatch: – can be OK after inspection, example: • 49 common in test servers, and on intranets. Banks and online businesses should never use it. gmail. com redirected to mail. google. com Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Main Weakness of SSL People ignore warnings, say YES. A study by Carnegie Mellon university, 409 participants, The researchers found that the majority of respondents would ignore warnings about an expired SSL certificate. – – MOREVOER: The more tech-savvy the user, the more likely they would be to ignore it, the study found. Respondents were able to identify other risks indicated by browser certificate notifications. • 50 Of the 59 percent of Firefox 2 users who understood the significance of a "domain mismatch" warning, 19 percent said they would ignore the hazard (!!!!). Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Solutions? Block completely all invalid certificates! Yes, but not so easy: People will • switch to a different browser, • or hack the browser, • or downgrade it • etc… 51 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Server Side: Not a joke: frequent question on Internet forums. Q: Does anyone know where I can get a free legitimate SSL certificate for my website? Otherwise, rather than having a SSL certificate on the site, is there some sort of JAVA code which makes the site look secure? Any comments? 52 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Has Been Done Cut-&-paste attacks with JAVA, Serge LEFRANC and David NACCACHE in ICISC 2002 http: //citeseer. ist. psu. edu/old/737003. html This paper describes malicious applets that use Java's sophisticated graphic features to rectify the browser's padlock area and cover the address bar with a false https domain name. The attack was successfully tested on Netscape's Navigator and Microsoft's Internet Explorer; we consequently recommend to neutralize Java whenever funds or private data transit via these browsers and patch the flaw in the coming releases. 53 Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Corrupting the CA Emerged around 2010. REAL certificates issued to… • maybe the government spooks (can implement man-in-the middle, can forge the web site, can eavesdrop? , etc… – • • 54 a bank can buy equipment to intercept the SSL traffic of employees… maybe criminals (not caught yet, no evidence yet) ‘somebody’ in Iran for sure… Nicolas T. Courtois, January 2009
Comp. Sec COMPGA 01 Quiz • What is a session key? • What is the minimum integrity/authenticity requirement so that two computers can securely establish a private channel, by using standard public key cryptography (e. g. SSL). • Why do we need an authenticated Diffie-Hellman? 55 Nicolas T. Courtois, January 2009
4dade2d669283ba231391cd696e9e4f2.ppt