DOCSLIB.ORG

Cryptography and Encryption Basics

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

PRESENTED BY: • • • • • SSL1 and SSL2 SSL3 TLS 1.0 TLS 1.1 TLS 1.2 Created by Netscape Created by Netscape to Standardized SSL3 with Security fixes and TLS Added support for and contained address SSL2 flaws almost no changes extensions authenticated significant flaws RFC2246 RFC4346 encryption (AES-GCM, CCM modes) and removed hard-coded primitives RFC5246 1994 1995 1999 … 2006 2008 Things get complicated First set of public SSL exploits August 2009 RFC 5746 BEAST & CRIME Lucky 13 RC4 Attacks TIME Heartbleed Insecure renegotiation TLS extension for Client-side or MITB Another timing attack Weakness in CBC A refinement and The end of the Internet vulnerability exposes secure renegotiation attacks leveraging a cipher making plaintext variation of CRIME as we know it! all SSL stacks to DoS quickly mainstreamed chosen-plaintext flaw in guessing possible attack TLS 1.0 and TLS compression flaws August February September March March April … February 2009 2010 2011 2013 2013 2013 2014 POODLE Padding oracle attack on SSLv3 Dire POODLE Padding oracle attack on TLS FREAK Implementation attack on export ciphers OpenSSL NSS GnuTLS Apple Microsoft Secure Transport SCHANNEL CVE-2014-0160 CVE-2014-1544 CVE-2014-3566 CVE-2014-1295 CVE-2014-6332 LogJam Implementation attack on weak DH Let’s Encrypt HTTP/2 Google stops using Launched to provide HTTP released as RFC RC4 and SSLv3 free certificates with 7540. Google EOL’s Let’s Keep Encrypting TLS 1.3 Google leads the way automated issuance SPDY. HTTP/2 doesn’t Let’s Encrypt has 20 TLS 1.3 published require encryption but by deprecating obsolete MILLION active August 10, 2018 all major browsers encryption standards certificates RFC8446 implement it 2015 May 2015 2016 … 2017 2018 August 14th, 2018 You’re reading these slides Authentication & NonAvailability-Repudiation SSL – Secure Sockets Layer A suite of protocols created by Netscape in 1994 to secure data on the wire TLS – Transport Layer Security Standardized update to SSL (RFC5246) Cryptography The science and study of transforming information in order to make it secure from unintended recipients PKI (Public Key Infrastructure) An architecture that provides asymmetric cryptography and a trust model that binds certificate subjects and issuers Proxies + (Traditional) Load balancers Hubs Switches Routers Most firewalls SSL/TLS HTTP Physical Data Link Network Transport Session Presentation Application HTTP SSL TCP IP HEADERS Request Wire HTTP HTTP SSL TCP PAYLOAD HEADERS Browsers HTTP HTTP SSL PAYLOAD HEADERS HTTP HTTP PAYLOAD HEADERS HTTP PAYLOAD Transport Layer Security Modes of Certificate PRNG Operation Authorities Message Authentication Signatures Revocation Code Symmetric Asymmetric Certificates Encryption Encryption TLS 1.2 Handshake Protocol – Basic Handshake Client Server ClientHello ServerHello Specifies theContains highest the TLS chosen protocol protocol version version, supported, a random a random number, a list of suggested CipherSuites, number,Contains CipherSuite the servers, compression public key and method optionally and anythe Certificate suggested compression methods and extensions additionalcertificate supported trust chain extensions. ServerHelloDone Indicates handshake negotiation is complete Client ClientKeyExchange Server Contains a PreMasterSecret, public key or nothing ChangeCipherSpec (dependsTells the serveron cipher). that all If afollowing PreMasterSecret traffic willis be Finished Contains a hashincludedauthenticated and MACit is encrypted of and the encrypted previous with the message. servers Public Key HandshakeServer complete will attempt and todecrypted decrypt anddata verify is passed the hash to theand higher MAC. layer If decryptionon both ends or validationof the connection fails the connection is killed ChangeCipherSpec Tells the client that all the following traffic will be Contains a hash and MAC of the previous message. Finished authenticatedServer and will encrypted attempt to decrypt and verify the hash and MAC. If decryption ApplicationDataor validation fails the connection is killed Cipher Suite Key Signature Bulk Encryption Message Elliptic Exchange/ Authentication Curve Agreement Public key size is NOT part of the cipher string! Ciphers and why they matter • • • • TLS weaknesses CBC-based ciphers TLSv1.0 Diffie-Hellman • Broken by BEAST and other attacks • Key exchange broken by LogJam • BEAST (initialization vector abuse) • CRIME (compression abuse) • POODLE and DIRE POODLE (padding oracle) TLSv1.1 • Lucky 13 (timing) • Sometimes broken SSLv3 TLSv1.2 • Broken in OpenSSL by Heartbleed • Completely broken by POODLE (patched)) R.I.P 3DES C • Found to be equivalent to 112-bits BC SSL3 3DE RC4 S - RC4 • Not CBC but weak and probably broken SHA1 SHA1 • Weak – industry moving away from it TLS 1.3 Handshake Protocol – Basic Handshake Client Client Hello, Supported Cipher Suites, Guesses Key Agreement Server protocol, Key Share Similar to 1.2 handshake, however the client sends the list of supported ciphers suites and guesses which key agreement the server is likely to selectServer Hello, Key Agreement protcol, Key Share, Server finished Server replies with the key agreement protocol. Client “Server Hello” also comprises the servers key Server share, its certificate as well as the Server finished message Checks Certificate, Generates Keys, Client finished Now, the client checks the server certificate, generates keys as it hasApplication the key share Data of the server, and sends the “Client Finished” message. From here on, the encryption of the data begins. Why you want PFS, EC, and TLS 1.3 • • • • TLS best practices Only generate RSA or ECDSA keys Keep private keys private Minimum 2048–bit for RSA and 256-bit for ECDSA Choose the right type of certificate Certificate signing should use SHA256 Domain, Organization, or Extended Validation For public sites use TLS1.2, 1.3 Use a strong cipher Disable SSLv3 unless you have a good reason otherwise Something that has at least 128-bits of security Use Perfect Forward Secrecy if possible Encrypt all or nothing Avoid RSA key exchange and prefer ECDHE over DHE Use HSTS (on all subdomains) to extend this F5 Security Incident Response Team [email protected] Thank You .
Recommended publications
  • Alcatel-Lucent Security Advisory Sa0xx

    Alcatel-Lucent Security Advisory Sa0xx

    Alcatel-Lucent Security Advisory No. SA0053 Ed. 04 Information about Poodle vulnerability Summary POODLE stands for Padding Oracle On Downgraded Legacy Encryption. The POODLE has been reported in October 14th 2014 allowing a man-in-the-middle attacker to decrypt ciphertext via a padding oracle side-channel attack. The severity is not considered as the same for Heartbleed and/or bash shellshock vulnerabilities. The official risk is currently rated Medium. The classification levels are: Very High, High, Medium, and Low. The SSLv3 protocol is only impacted while TLSv1.0 and TLSv1.2 are not. This vulnerability is identified CVE- 2014-3566. Alcatel-Lucent Enterprise voice products using protocol SSLv3 are concerned by this security alert. Openssl versions concerned by the vulnerability: OpenSSL 1.0.1 through 1.0.1i (inclusive) OpenSSL 1.0.0 through 1.0.0n (inclusive) OpenSSL 0.9.8 through 0.9.8zb (inclusive) The Alcatel-Lucent Enterprise Security Team is currently investigating implications of this security flaw and working on a corrective measure, for OpenTouch 2.1.1 planned in Q4 2015, to prevent using SSLv3 that must be considered as vulnerable. This note is for informational purpose about the padding-oracle attack identified as “POODLE”. References CVE-2014-3566 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 Advisory severity CVSS Base score : 4.3 (MEDIUM) - AV:N/AC:M/Au:N/C:P/I:N/A:N https://www.openssl.org/news/secadv_20141015.txt https://www.openssl.org/~bodo/ssl-poodle.pdf Description of the vulnerabilities Information about Poodle vulnerability (CVE-2014-3566).
  • Cache-Timing Attack Against Aes Crypto System - Countermeasures Review

    Cache-Timing Attack Against Aes Crypto System - Countermeasures Review

    Edith Cowan University Research Online Australian Information Security Management Conference Conferences, Symposia and Campus Events 2014 Cache-timing attack against aes crypto system - countermeasures review Yaseen H. Taha University of Khartoum Settana M. Abdulh University of Khartoum Naila A. Sadalla University of Khartoum Huwaida Elshoush University of Khartoum Follow this and additional works at: https://ro.ecu.edu.au/ism Part of the Information Security Commons DOI: 10.4225/75/57b65fd1343d3 12th Australian Information Security Management Conference. Held on the 1-3 December, 2014 at Edith Cowan University, Joondalup Campus, Perth, Western Australia. This Conference Proceeding is posted at Research Online. https://ro.ecu.edu.au/ism/166 CACHE-TIMING ATTACK AGAINST AES CRYPTO SYSTEM - COUNTERMEASURES REVIEW Yaseen.H.Taha, Settana.M.Abdulh, Naila.A.Sadalla, Huwaida Elshoush University of Khartoum, Sudan [email protected], [email protected], [email protected], [email protected] Abstract Side channel attacks are based on side channel information, which is information that is leaked from encryption systems. Implementing side channel attacks is possible if and only if an attacker has access to a cryptosystem (victim) or can interact with cryptosystem remotely to compute time statistics of information that collected from targeted system. Cache timing attack is a special type of side channel attack. Here, timing information caused by cache effect is collected and analyzed by an attacker to guess sensitive information such as encryption key or plaintext. Cache timing attack against AES was known theoretically until Bernstein carry out a real implementation of the attack. Fortunately, this attack can be a success only by exploiting bad implementation in software or hardware, not for algorithm structure weaknesses, and that means attack could be prevented if proper implementation has been used.
  • Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities

    Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities

    Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget and Juraj Somorovsky, Ruhr University Bochum; Nimrod Aviram, Tel Aviv University; Craig Young, Tripwire VERT; Janis Fliegenschmidt and Jörg Schwenk, Ruhr University Bochum; Yuval Shavitt, Tel Aviv University https://www.usenix.org/conference/usenixsecurity19/presentation/merget This paper is included in the Proceedings of the 28th USENIX Security Symposium. August 14–16, 2019 • Santa Clara, CA, USA 978-1-939133-06-9 Open access to the Proceedings of the 28th USENIX Security Symposium is sponsored by USENIX. Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities Robert Merget1, Juraj Somorovsky1, Nimrod Aviram2, Craig Young3, Janis Fliegenschmidt1, Jörg Schwenk1, and Yuval Shavitt2 1Ruhr University Bochum 2Department of Electrical Engineering, Tel Aviv University 3Tripwire VERT Abstract the encryption key. The attack requires a server that decrypts a message and responds with 1 or 0 based on the message va- The TLS protocol provides encryption, data integrity, and lidity. This behavior essentially provides the attacker with a authentication on the modern Internet. Despite the protocol’s cryptographic oracle which can be used to mount an adaptive importance, currently-deployed TLS versions use obsolete chosen-ciphertext attack. The attacker exploits this behavior cryptographic algorithms which have been broken using var- to decrypt messages by executing adaptive queries.Vaudenay ious attacks. One prominent class of such attacks is CBC exploited a specific form of vulnerable behavior, where im- padding oracle attacks. These attacks allow an adversary to plementations validate the CBC padding structure and re- decrypt TLS traffic by observing different server behaviors spond with 1 or 0 accordingly.
  • Technical Report RHUL–ISG–2019–1 27 March 2019

    Technical Report RHUL–ISG–2019–1 27 March 2019

    20 years of Bleichenbacher attacks Gage Boyle Technical Report RHUL–ISG–2019–1 27 March 2019 Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom Student Number: 100866673 Gage, Boyle 20 Years of Bleichenbacher Attacks Supervisor: Kenny Paterson Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London. I declare that this assignment is all my own work and that I have acknowledged all quotations from published or unpublished work of other people. I also declare that I have read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences, and in accordance with these regulations I submit this project report as my own work. Signature: Date: Acknowledgements I would first like to thank my project supervisor, Kenny Paterson. This project would not have been possible without his continuous encouragement to push the boundaries of my knowledge, and I am grateful for the commitment and expertise that he has provided throughout. Secondly, I would like to thank Nimrod Aviram for his invaluable advice, particularly with respect to algorithm implementation and understanding the finer details of this project. Further thanks should go to Raja Naeem Akram, Oliver Kunz and David Morrison for taking the time to teach me Python and how to run my source code on an Ubuntu server. I am grateful for the time that David Stranack, Thomas Bingham and James Boyle have spent proof reading this project, and for the continuous support from my part- ner, Lisa Moxham.
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
  • Some Comments on the First Round AES Evaluation Of

    Some Comments on the First Round AES Evaluation Of

    Some Comments on the First Round AES Evaluation of RC6 1 2 1 Scott Contini , Ronald L. Rivest , M.J.B. Robshaw , 1 and Yiqun Lisa Yin 1 RSA Lab oratories, 2955 Campus Drive, San Mateo, CA 94403, USA fscontini,matt,yiqung@rsa. com 2 M.I.T. Lab oratory for Computer Science, 545 Technology Square, Cambridge, MA 02139, USA [email protected] 1 Intro duction The rst round of the AES pro cess is coming to an end. Since August of 1998, the cryptographic community has had the opp ortunity to consider each of the fteen prop osed AES candidates. In this note, we take the opp ortunity to answer some of the questions and to resp ond to some of the issues that have b een raised ab out the suitabilityofRC6 as an AES candidate. 2 Encryption/Decryption Performance of RC6 Since the publication of RC6 a variety of researchers and implementors have examined RC6 and considered its p erformance in a wide range of environments. 2.1 32-bit architectures RC6 is one of the fastest AES prop osals on 32-bit architectures, particularly so on the NIST reference platform of a 200 MHz Pentium Pro. It is argued by many that the most reasonable way to assess the p erformance of an algorithm is to consider its sp eed in an assembly language implementation. We agree that this is the case. However it is also interesting to consider how the p erformance of RC6 compares when using di erent compilers. It is imp ortant to note that to take advantage of compiler-sp eci c optimizations the source co de provided to the compiler might need to b e changed.
  • Yet Another Padding Oracle in Openssl CBC Ciphersuites

    Yet Another Padding Oracle in Openssl CBC Ciphersuites

    Yet Another Padding Oracle in OpenSSL CBC Ciphersuites presented by Raphael Finkel based on https://blog.cloudflare.com/ yet-another-padding-oracle-in-openssl-cbc-ciphersuites/ Keeping Current, September 5, 2018 The Cryptographic Doom Principle I reference: https://moxie.org/blog/ the-cryptographic-doom-principle/ by Moxie Marlinspike I If you have to perform any cryptographic operation before verifying the MAC (message authentication code) on a message you’ve received, it will somehow inevitably lead to doom. I MAC is a cryptographic digest based on a secret key shared by Alice and Bob. I Proper use of MAC: Encrypt Then Authenticate (Encrypt-then-MAC, EtA; used in IPsec) I Alice sends to Bob: E(P) || MAC(E(P)) I Detail: E(P) also includes such information as the initialization vector and the encryption algorithm; both are then covered by MAC(). I Bob first verifies MAC(E(P)), satisfying the principle. If that test passes, Bob decrypts P. I Good: Verifies integrity of E(P), therefore it also verifies integrity of P. I Good: MAC(E(P)) provides no information about P. Authenticate and encrypt (Encrypt-and-MAC, E&A; used in SSH) I Alice sends to Bob: E(P) || MAC(P) I Bob must first decrypt E(P) to get P, then confirm MAC(P), violating the principle. I Good: verifies integrity of P. I Not good: I May theoretically reveal information about P in MAC(P). I No integrity check on E(P). I Bad: vulnerable to chosen-ciphertext attacks on E. I Man-in-the-middle Morton can try various versions of E(P), noting whether Bob gets as far as trying to verify MAC(P).
  • An Adaptive-Ciphertext Attack Against I XOR C Block Cipher Modes With

    An Adaptive-Ciphertext Attack Against I XOR C Block Cipher Modes With

    A A-C A “I ⊕ C” B C M W O Jon Passki Tom Ritter [email protected] [email protected] May 24, 2012 Abstract Certain block cipher confidentiality modes are susceptible to an adaptive chosen-ciphertext attack against the underlying format of the plaintext. When the application decrypts altered ciphertext and attempts to process the manipulated plaintext, it may disclose information about intermediate values resulting in an oracle. In this paper we describe how to recognize and exploit such an oracle to decrypt ciphertext and control the decryption to result in arbitrary plaintext. We also discuss ways to mitigate and remedy the issue. 1 I Quoting from [1]: Adaptive chosen-ciphertext attacks on cryptographic protocols allow an attacker to decrypt a cipher- text C, getting the plaintext M, by submitting a series of chosen-ciphertexts C0= 6 C to an oracle which returns information on the decryption. The ciphertexts can be adaptively chosen so that information on previous decryptions is available before the next chosen ciphertext is submitted. Adaptive chosen-ciphertext attacks against different confidentiality modes are not novel. The CBC confidentiality mode can suffer from a side channel attack against padding verification [2], popularized by [3]. A variant of the Cipher Feedback (CFB) confidentiality mode has been attacked in different encryption mail protocols by [4, 5, 1], and the padding schemes of asymmetric ciphers are another source of such attacks [6, 7]. In some form, they rely on the use of an oracle that leaks or communicates information back to attackers. We examine four different confidentiality modes encrypting plaintext that is separated by a delimiter, and the absence or inclusion of that delimiter generates an oracle by the application.
  • Cs 255 (Introduction to Cryptography)

    Cs 255 (Introduction to Cryptography)

    CS 255 (INTRODUCTION TO CRYPTOGRAPHY) DAVID WU Abstract. Notes taken in Professor Boneh’s Introduction to Cryptography course (CS 255) in Winter, 2012. There may be errors! Be warned! Contents 1. 1/11: Introduction and Stream Ciphers 2 1.1. Introduction 2 1.2. History of Cryptography 3 1.3. Stream Ciphers 4 1.4. Pseudorandom Generators (PRGs) 5 1.5. Attacks on Stream Ciphers and OTP 6 1.6. Stream Ciphers in Practice 6 2. 1/18: PRGs and Semantic Security 7 2.1. Secure PRGs 7 2.2. Semantic Security 8 2.3. Generating Random Bits in Practice 9 2.4. Block Ciphers 9 3. 1/23: Block Ciphers 9 3.1. Pseudorandom Functions (PRF) 9 3.2. Data Encryption Standard (DES) 10 3.3. Advanced Encryption Standard (AES) 12 3.4. Exhaustive Search Attacks 12 3.5. More Attacks on Block Ciphers 13 3.6. Block Cipher Modes of Operation 13 4. 1/25: Message Integrity 15 4.1. Message Integrity 15 5. 1/27: Proofs in Cryptography 17 5.1. Time/Space Tradeoff 17 5.2. Proofs in Cryptography 17 6. 1/30: MAC Functions 18 6.1. Message Integrity 18 6.2. MAC Padding 18 6.3. Parallel MAC (PMAC) 19 6.4. One-time MAC 20 6.5. Collision Resistance 21 7. 2/1: Collision Resistance 21 7.1. Collision Resistant Hash Functions 21 7.2. Construction of Collision Resistant Hash Functions 22 7.3. Provably Secure Compression Functions 23 8. 2/6: HMAC And Timing Attacks 23 8.1. HMAC 23 8.2.
  • Side-Channel Attacks

    Side-Channel Attacks

    Side-Channel Attacks Aleksei Ivanov 26th November 2005 1 Introduction and patches the result with all 0's.This results in small, constant time when compared to complete Side-channel attacks are described in [5] as follows. multiplication. Timing side channel information Side-channel attacks are attacks that are based on can be obtained either by precisely measuring the side channel information. Side channel Information time taken by one encryption or by averaging the that can be retrieved from the encryption device time taken over several encryptions [4]. that is neither plain text to be encrypted nor the cipher text resulting from the encryption process. There are several kind of side-channel attacks, in 2.2 Power Consumption Attacks the [2] timing attack is referred to as the most Devices consume power and the power dissipated common one. Then There is one kind of informa- by a device is an other side channel. Dierential tion leakage referred to in [1] as power consumption power analysis (DPA) is a power consumption side leakage, that is a big help to the timing attacks. It channel attack that divides the encryption into a is even harder to protect a system against the power number of time slots and measures power in each consumption attacks when attacker has direct ac- slot for dierent plain text input. A small number cess to the encryption device. of the power measurements correlate with each bit The purpose of this paper is to get an overview of the interval stage during encryption [4]. of attacks on encryption systems where an attacker This attack requires little knowledge of the device is using other ways to obtain the encryption key and is dicult to hide the channel information if than breaking the mathematical algorithm.
  • Research on Microarchitectural Cache Attacks

    Research on Microarchitectural Cache Attacks

    Advances in Computer Science Research (ACSR), volume 90 3rd International Conference on Computer Engineering, Information Science & Application Technology (ICCIA 2019) Research on Microarchitectural Cache Attacks Yao Lu a, Kaiyan Chen b, Yinlong Wang c Simulation Center of Ordnance Engineering College Army Engineering University Shijiazhuang, Hebei Province, China [email protected], [email protected], [email protected] Abstract. This paper summarizes the basic concepts and development process of cache side- channel attack, analyses three basic methods (Evict and Time, Prime and Probe, Flush and Reload) from four aspects: Attack conditions, realization process, applicability, and characteristics, then I expound how to apply side-channel attack methods on CPU vulnerability. Keywords: Side-channel attacks; Cache; CPU vulnerability; Microarchitecture. 1. Background Cryptography is a technique used to confuse plaintext [1], It transforms normally identifiable information (plaintext) into unrecognizable information (ciphertext). At the same time, the encrypted ciphertext can be transferred back to the normal information through the key, the privacy information of users at this stage is mostly realized by encryption technology [28], so the security of personal information depends on the security of the encryption algorithm. 1.1 Cryptographic Algorithms Cryptographic algorithms have always been an important research object in cryptography, in recent years has also been rapid development, these algorithms are: RIJINDAEL, MARS, RC6, Twofish, Serpent, IDEA, CS-Cipher, MMB, CA-1.1, SKIPJACK Symmetric cryptographic algorithms such as Karn and backpack public key cryptography, RSA, ElGamal [29], ECC [19], NTRU and other asymmetric cryptographic algorithms [27]. in the opinion of the development trend of international mainstream cryptographic algorithms at present [25]: The symmetric cryptographic algorithm transitions from DES-3 to AES, and the password length is gradually increased: 128, 192, 256.
  • Lucky 13, BEAST, CRIME,... Is TLS Dead, Or Just Resting?

    Lucky 13, BEAST, CRIME,... Is TLS Dead, Or Just Resting?

    Lucky 13, BEAST, CRIME,... Is TLS dead, or just resting? Kenny Paterson Information Security Group Overview Introduction to TLS (and why YOU should care) BEAST and CRIME Lucky 13 and RC4 attacks Current/future developments in TLS 2 About the Speaker Academic But spent 5 years in industrial research lab Still involved in IPR, consulting, industry liaison RHUL since 2001 “You are teaching Network Security” Leading to research into how crypto is used in Network Security EPSRC Leadership Fellow, 2010-2015 “Cryptography: Bridging Theory and Practice” Support from I4, HP, BT, Mastercard, CPNI Attacks on IPsec (2006, 2007), SSH (2009) So what about TLS? 3 A Word from my Sponsors 4 TLS – And Why You Should Care SSL = Secure Sockets Layer. Developed by Netscape in mid 1990s. SSLv2 now deprecated; SSLv3 still widely supported. TLS = Transport Layer Security. IETF-standardised version of SSL. TLS 1.0 = SSLv3 with minor tweaks, RFC 2246 (1999). TLS 1.1 = TLS 1.0 + tweaks, RFC 4346 (2006). TLS 1.2 = TLS 1.1 + more tweaks, RFC 5246 (2008). TLS 1.3? 5 TLS – And Why You Should Care Originally for secure e-commerce, now used much more widely. Retail customer access to online banking facilities. User access to gmail, facebook, Yahoo. Mobile applications, including banking apps. Payment infrastructures. User-to-cloud. Post Snowden: back-end operations for google, yahoo, … Not yet Yahoo webcam traffic, sadly. TLS has become the de facto secure protocol of choice. Used by hundreds of millions of people and devices every day. A serious attack could be catastrophic, both in real terms and in terms of perception/confidence.