DOCSLIB.ORG

Das SSL-Dilemma

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Das SSL-Dilemma Das SSL-Dilemma Security Forum 2015 – April 2015 Christopher Dreher cirosec GmbH 2 Agenda . Verschlüsselung im WWW . SSL/TLS, was läuft falsch? – Designschwächen – Implementierungsfehler . Vertrauen in Zertifikatsstellen . Das Revocation-Problem . Fehlkonfigurationen erkennen und fixen . Ausblick 3 Verschlüsselung im WWW Von damals bis heute . HTTPS wurde von Netscape entwickelt und zusammen mit SSLv1 erstmals 1994 erwähnt . Kipp Hickman von Netscape veröffentlichte SSLv2 als IETF Draft in 1995 The SSL Protocol is designed to provide privacy between two communicating applications (a client and a server). Second, the protocol is designed to authenticate the server, and optionally the client. [...] Quelle: Wikipedia 5 Von damals bis heute . SSLv2 gilt seit Ende 1996 als gebrochen – Aktiver Man-in-the-Middle-Angriff erlaubt die komplette Kompromittierung der Vertraulichkeit und Integrität der gesicherten Übertragen (http://osvdb.org/56387) . SSLv3 wird wiederum von drei Wissenschaftlern bei Netscape erarbeitet und 1996 veröffentlicht . 1999 wird SSL zu TLS umbenannt, jedoch minimale Änderung der Spezifikation zu SSLv3 (SSLv3.1->TLS 1.0) 6 SSL und/oder TLS . 2000 – 2006 erfolgt eine Vielzahl wissenschaftlicher Angriffe gegen SSLv3 und TLS 1.0 – Padding-Oracle-Angriff gegen Padding der Block Cipher (2002 Vaudenay „Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS...“) – Timing-Attacke (2003 Brumley u. Boneh „Remote timing attacks are practical“) – Chosen-Plaintext-Attacke: IV ist vorhersagbar (2006 Bard) . TLS 1.1 wird 2006 als Standard veröffentlicht (RFC4346) – Entfernung der Export Ciphers (40 Bit) . Bereits 2008 wird die finale Version von TLS 1.2 als Ablösung von TLS 1.1 veröffentlicht (RFC5246) 7 SSL und TLS im Web 2015 Quelle: Universal-Pictures 8 SSL und TLS im Web 2015 9 Quelle: https://www.trustworthyinternet.org/ssl-pulse/ SSL und/oder TLS Server beweist seine Identität durch Zertifikat Browser Webserver #*+x!3@f_ TLS TLS Daten werden verschlüsselt übertragen 10 Verbindungsaufbau bei TLS Client-Hello Server-Hello Client-Zufallszahl Server-Zufallszahl Protokollversion TLS 1.1 Protokollversion TLS 1.1 Liste von Algorithmen Algorithmus AES 11 Verbindungsaufbau bei TLS TLS 1.1 TLS 1.1 AES privat öffentlich Client Key Exchange Pre-Master-Secret 12 Verbindungsaufbau bei TLS TLS 1.1 TLS 1.1 AES Pre-Master-Secret Client-Zufallszahl + Server-Zufallszahl privat öffentlich Fixer Startwert Master-Secret Symmetrischer Sitzungsschlüssel 13 Designschwächen in SSL / TLS Designschwächen in SSL / TLS . Probleme basieren nicht auf den einzelnen Implementierungen von SSL (OpenSSL, LibreSSL, MatrixSSL, PolarSSL, GnuTLS usw.) . Lässt sich in der Regel nicht durch die Entwickler beheben, sondern bedarf – Anpassung und Änderung des Protokolls (Versionsupdate) – Workaround durch Deaktivierung betroffener Cipher Suites 15 BEAST (CVE-2011-3389) . Browser Exploit Against SSL/TLS . Ausnutzung der Chosen-Plaintext-Attacke gegen den IV von Bard (2006) . Angreifer muss einen passiven Man-in-the-Middle-Angriff durchführen (Sniffing) und innerhalb des Opfer-Browsers eine Vielzahl von Anfragen abschicken können . PoC-Exploit basierte auf einem Java-Applet, das vom Opfer aufgerufen wurde – Java-Applet kam von einer Domain des Angreifers, deswegen zusätzliche Schwachstelle in JVM nötig zur Überwindung der SOP . http://vnhacker.blogspot.de/2011/09/beast.html (Juliano Rizzo und Thai Duong) 16 BEAST (CVE-2011-3389) . Keine bekannte Ausnutzung in the wild . Empfehlung: Update auf TLS 1.1 oder Nutzung von RC4 anstelle von AES Verwundbare SSL/TLS-Versionen TLS 1.2 - TLS 1.1 - TLS 1.0 JA SSL 3.0 JA 17 SSL 2.0 JA CRIME (CVE-2012-4929) . Compression Ratio Info-leak Made Easy . Ausnutzung der Informationspreisgabe durch den Einsatz der SSL-Kompression . Angreifer muss einen passiven Man-in-the-Middle-Angriff durchführen (Sniffing) und innerhalb des Opfer-Browsers eine Vielzahl von Anfragen abschicken können . Angreifer kann Klartextdaten erraten durch Abgleich der Länge der komprimierten Daten (z.B. Cookie-Wert) . https://isecpartners.com/blog/2012/september/details- on-the-crime-attack.aspx (Juliano Rizzo und Thai Duong) 18 CRIME (CVE-2012-4929) . Keine bekannte Ausnutzung in the wild . Empfehlung: Deaktivierung der SSL-Kompression auf Client- und Serverseite Verwundbare SSL/TLS-Versionen TLS 1.2 JA TLS 1.1 JA TLS 1.0 JA SSL 3.0 JA 19 SSL 2.0 JA BREACH (CVE-2013-3587) . Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext . Ausnutzung der Informationspreisgabe durch den Einsatz der HTTP-Kompression . Angreifer muss einen passiven Man-in-the-Middle-Angriff durchführen (Sniffing) und innerhalb des Opfer-Browsers eine Vielzahl von Anfragen abschicken können . http://breachattack.com/ 20 BREACH (CVE-2013-3587) . Keine bekannte Ausnutzung in the wild . Empfehlung: – Deaktivierung der HTTP-Kompression (theoretisch) – Schutz gegen automatisierte Anfragen Verwundbare SSL/TLS-Versionen TLS 1.2 JA TLS 1.1 JA TLS 1.0 JA SSL 3.0 JA 21 SSL 2.0 JA RC4-Schwäche . RC4 ist ein Stream Cipher . Algorithmus generiert eine Sequenz von Schlüsseln, die mit den Daten „ge-XOR-ed“ werden . Schlüsselwerte sind nicht ausreichend zufällig verteilt . Praktischer Angriff erfordert sehr hohe Anzahl an Verbindungen . Entdeckt: – 2013 (http://www.isg.rhul.ac.uk/tls/RC4biases.pdf) . Betroffen: – RC4 Ciphers . Gegenmaßnahme: – Verzicht auf RC4 – Schutz gegen automatisierte Anfragen 22 POODLE: SSLv3 vulnerability (CVE-2014-3566) . Padding Oracle On Downgraded Legacy Encryption . Angreifer muss einen passiven Man-in-the-Middle-Angriff durchführen (Sniffing) und innerhalb des Opfer-Browsers 256 x n (n-Byte langes Cookie) Anfragen abschicken können . https://www.openssl.org/~bodo/ssl-poodle.pdf 23 POODLE: SSLv3 vulnerability (CVE-2014-3566) . Keine bekannte Ausnutzung in the wild – Wahrscheinlicher im Gegensatz zu BEAST, BREACH oder CRIME . Empfehlung: Deaktivierung von SSLv3 Verwundbare SSL/TLS-Versionen TLS 1.2 - TLS 1.1 - TLS 1.0 - SSL 3.0 JA 24 SSL 2.0 JA POODLE: SSLv3 vulnerability (CVE-2014-3566) 25 Quelle: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html SSLv3 Downgrade 26 Quelle: http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html FREAK: < TLS 1.1 vulnerability . Factoring RSA Export Keys . Angreifer muss einen aktiven Man-in-the-Middle-Angriff durchführen und verlangt vom Server die Verwendung von EXPORT Cipher Suites . Faktorisierung von 512bit RSA-Schlüsseln kostet ca. 100$ Amazon EC2-Rechenzeit und dauert weniger als 8 Stunden . https://www.smacktls.com/ 27 FREAK: < TLS 1.1 vulnerability HTTPS serves of Alexa‘s Top 1 Million Domains Quelle: https://freakattack.com/ . Empfehlung: Deaktivierung von TLS 1.0 und kleiner Verwundbare SSL/TLS-Versionen TLS 1.2 - TLS 1.1 - TLS 1.0 JA SSL 3.0 JA 28 SSL 2.0 JA Implementierungsfehler in SSL / TLS Implementierungsfehler in SSL / TLS . Fehler erzeugt durch einzelne Entwickler / Teams innerhalb einer Bibliothek . Fehlerhafte Qualitätssicherung des Codes . Typische Softwareschwachstellen – Buffer Overflows – Control Flow Manipulation 30 Heartbleed (CVE-2014-0160) . Heartbeat-Nachrichten dienen der Sicherstellung einer intakten Kommunikationsverbindung über UDP . Fehlerhafte Überprüfung der Längenangabe der Heartbeat-Anfrage . Heartbeat-Antwort liefert die empfangene Nachricht zurück und mehr (max. 64 kB) – Auslesen zufälliger Werte, die zum aktuellen Zeitpunkt in dem dynamischen Prozessspeichers des Webserver-Prozesses liegen . http://heartbleed.com/ Verwundbare OpenSSL-Versionen OpenSSL 1.0.1 bis 1.0.1f OpenSSL 1.0.2-beta bis 1.0.2-beta1 31 Heartbleed (CVE-2014-0160) 32 Quelle: http://xkcd.com/1354/ Heartbleed (CVE-2014-0160) 33 Quelle: http://xkcd.com/1354/ Heartbleed (CVE-2014-0160) „A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is received, it SHOULD be answered with a corresponding HeartbeatResponse message.“ https://tools.ietf.org/html/rfc6520 34 OpenSSL CCS Injection Vulnerability (CVE-2014-0224) . Begünstigte die Erzwingung zur Verwendung von schwachem Schlüsselmaterial durch externe Angreifer auf der Leitung . ChangeCipherSpec-Instruktion konnte zu beliebigen Zeiten injected werden . http://ccsinjection.lepidum.co.jp/ Verwundbare OpenSSL-Versionen OpenSSL 1.0.1 bis 1.0.1g OpenSSL 1.0.0 bis 1.0.0l Alle Versionen vor OpenSSL 0.9.8y 35 Vertrauen in Zertifikatsstellen Authentisierung / Identifizierung bei TLS . Woher weiß der Browser, dass der angefragte Server legitim ist? . Server-Zertifikate sind wie Ausweisdokumente – Der Aussteller der Zertifikate ist vergleichbar mit einer nationalen Passbehörde 37 Vertrauenswürdige CAs in Browsern . Keine zentrale Datenbank . Internet Explorer / M$ CTL . Mozilla Firefox . iOS / Android . Insgesamt über 650 CAs inklusive Sub-CAs Quelle: https://www.eff.org/observatory 38 Beispiel: Aufbrechen der Verschlüsselung Browser Angreifer Webserver TLS-Verbindung 1 TLS-Verbindung 2 Gefälschtes Zertifikat Echtes Zertifikat 39 Beispiel: Aufbrechen der Verschlüsselung . Gefälschtes Zertifikat ist nicht gültig . Ist das ein Problem? 40 You Won’t Be Needing These Any More . Untersuchung von ca. 48 Mio. HTTPS-Seiten ergab: – Über 140 CA-Zertifikate in den unterschiedlichen Truststores werden nicht verwendet (Geheimdienste lassen grüßen) – Von insgesamt 426 CA-Zertifikaten werden nur 2/3 benutzt . Welche CAs werden für .de-Domains gebraucht? . http://fc14.ifca.ai/papers/fc14_submission_100.pdf 41 DigiNotar Hack Quelle: Heise . Analyse-Bericht
Load more

Recommended publications
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Sizzle: a Standards-Based End-To-End Security Architecture for the Embedded Internet
    Sizzle: A Standards-based end-to-end Security Architecture for the Embedded Internet Vipul Gupta, Matthew Millard,∗ Stephen Fung*, Yu Zhu*, Nils Gura, Hans Eberle, Sheueling Chang Shantz Sun Microsystems Laboratories 16 Network Circle, UMPK16 160 Menlo Park, CA 94025 [email protected], [email protected], [email protected] [email protected], {nils.gura, hans.eberle, sheueling.chang}@sun.com Abstract numbers of even simpler, more constrained devices (sen- sors, home appliances, personal medical devices) get con- This paper introduces Sizzle, the first fully-implemented nected to the Internet. The term “embedded Internet” is end-to-end security architecture for highly constrained em- often used to refer to the phase in the Internet’s evolution bedded devices. According to popular perception, public- when it is invisibly and tightly woven into our daily lives. key cryptography is beyond the capabilities of such devices. Embedded devices with sensing and communication capa- We show that elliptic curve cryptography (ECC) not only bilities will enable the application of computing technolo- makes public-key cryptography feasible on these devices, it gies in settings where they are unusual today: habitat mon- allows one to create a complete secure web server stack itoring [26], medical emergency response [31], battlefield including SSL, HTTP and user application that runs effi- management and home automation. ciently within very tight resource constraints. Our small Many of these applications have security requirements. footprint HTTPS stack needs less than 4KB of RAM and For example, health information must only be made avail- interoperates with an ECC-enabled version of the Mozilla able to authorized personnel (authentication) and be pro- web browser.
    [Show full text]
  • Configuring SSL for Services and Servers
    Barracuda Web Application Firewall Configuring SSL for Services and Servers https://campus.barracuda.com/doc/4259877/ Configuring SSL for SSL Enabled Services You can configure SSL encryption for data transmitted between the client and the service. In the BASIC > Services page, click Edit next to a listed service and configure the following fields: Status – Set to On to enable SSL on your service. Status defaults to On for a newly created SSL enabled service. Certificate – Select a certificate presented to the browser when accessing the service. Note that only RSA certificates are listed here. If you have not created the certificate, select Generate Certificate from the drop-down list to generate a self-signed certificate. For more information on how to create self- signed certificates, see Creating a Client Certificate. If you want to upload a self-signed certificate, select Upload Certificate from the drop- down list. Provide the details about the certificate in the Upload Certificate dialog box. For information on how to upload a certificate, see Adding an SSL Certificate. Select ECDSA Certificate – Select an ECDSA certificate presented to the browser when accessing the service. SSL/TLS Quick Settings - Select an option to automatically configure the SSL/TLS protocols and ciphers. Use Configured Values - This option allows you to use the previously saved values. If the values are not saved, the Factory Preset option can be used. Factory Preset - This option allows you to enable TLS 1.1, TLS 1.2 and TLS 1.3 protocols without configuring override ciphers. Mozilla Intermediate Compatibility (Default, Recommended) - This configuration is a recommended configuration when you want to enable TLS 1.2 and TLS 1.3 and configure override ciphers for the same.
    [Show full text]
  • 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.
    [Show full text]
  • Crypto Projects That Might Not Suck
    Crypto Projects that Might not Suck Steve Weis PrivateCore ! http://bit.ly/CryptoMightNotSuck #CryptoMightNotSuck Today’s Talk ! • Goal was to learn about new projects and who is working on them. ! • Projects marked with ☢ are experimental or are relatively new. ! • Tried to cite project owners or main contributors; sorry for omissions. ! Methodology • Unscientific survey of projects from Twitter and mailing lists ! • Excluded closed source projects & crypto currencies ! • Stats: • 1300 pageviews on submission form • 110 total nominations • 89 unique nominations • 32 mentioned today The People’s Choice • Open Whisper Systems: https://whispersystems.org/ • Moxie Marlinspike (@moxie) & open source community • Acquired by Twitter 2011 ! • TextSecure: Encrypt your texts and chat messages for Android • OTP-like forward security & Axolotl key racheting by @trevp__ • https://github.com/whispersystems/textsecure/ • RedPhone: Secure calling app for Android • ZRTP for key agreement, SRTP for call encryption • https://github.com/whispersystems/redphone/ Honorable Mention • ☢ Networking and Crypto Library (NaCl): http://nacl.cr.yp.to/ • Easy to use, high speed XSalsa20, Poly1305, Curve25519, etc • No dynamic memory allocation or data-dependent branches • DJ Bernstein (@hashbreaker), Tanja Lange (@hyperelliptic), Peter Schwabe (@cryptojedi) ! • ☢ libsodium: https://github.com/jedisct1/libsodium • Portable, cross-compatible NaCL • OpenDNS & Frank Denis (@jedisct1) The Old Standbys • Gnu Privacy Guard (GPG): https://www.gnupg.org/ • OpenSSH: http://www.openssh.com/
    [Show full text]
  • 26. Java 8 and 8 Security Controls 2-28-2017
    New Security Control Enhancements Java 8 and 9 JIM MANICO Secure Coding Instructor www.manicode.com A little background dirt… [email protected] @manicode § Author of "Iron-Clad Java, Building Secure Web APPlications” from McGraw-Hill/Oracle-Press § 20+ years of software develoPment experience § OWASP Volunteer and Former OWASP Global Board Member § Kauai, Hawaii Resident Creative Commons MANICODE SECURITY 2 Java Enhancement ProPosals Creative Commons MANICODE SECURITY 3 'ohana (oh-ha-na) MEANING: Family. MOST COMMON USE: In referring to the WHOLE family. Creative Commons MANICODE SECURITY JEP IT UP § JEP stands for a JDK Enhancement Proposal § JEP's are how you drive change in the Java ecosystem. § Involvement is actually a lot of work. § Attention is given to PeoPle that put in the work. § The way to make imProvements or get ideas seriously considered is to do them via the JEP ProPosal Process. § Mike Ernst and Werner Dietl are good examPles. They are the duo that built type annotations which we we will talk about soon. Creative Commons MANICODE SECURITY 5 Java 9 Security JEP's Creative Commons MANICODE SECURITY 6 Java 9 Security Enhancements § There are 8 main security related JEPs for JDK 9: 219: Datagram Transport Layer Security (DTLS) 229: Create PKCS12 Keystores by Default 232: ImProve Secure APPlication Performance 244: TLS Application-Layer Protocol Negotiation Extension 246: Leverage CPU Instructions for GHASH and RSA 249: OCSP Stapling for TLS 287: Support SHA-3 Hash Algorithms 288: DisaBle SHA-1 Certificates Creative Commons MANICODE SECURITY 7 akamai (ah-ka-my) MEANING: Smart or Clever. MOST COMMON USE: Smart.
    [Show full text]
  • Post-Quantum Authentication in Openssl with Hash-Based Signatures
    Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Post-Quantum Authentication in OpenSSL with Hash-Based Signatures Denis Butin, Julian Wälde, and Johannes Buchmann TU Darmstadt, Germany 1 / 26 I Quantum computers are not available yet, but deployment of new crypto takes time, so transition must start now I Well established post-quantum signature schemes: hash-based cryptography (XMSS and variants) I Our goal: make post-quantum signatures available in a popular security software library: OpenSSL Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key cryptography (RSA, DSA, ECDSA) breaks once large quantum computers exist I Post-quantum cryptography: public-key algorithms thought to be secure against quantum computer attacks 2 / 26 Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • X.509V3 Certificates for SSH Authentication
    X.509v3 Certificates for SSH Authentication The X.509v3 Certificates for SSH Authentication feature uses public key algorithm (PKI) for server and user authentication, and allows the Secure Shell (SSH) protocol to verify the identity of the owner of a key pair via digital certificates, signed and issued by a Certificate Authority (CA). This module describes how to configure server and user certificate profiles for a digital certificate. • Prerequisites for X.509v3 Certificates for SSH Authentication, on page 1 • Restrictions for X.509v3 Certificates for SSH Authentication, on page 1 • Information About X.509v3 Certificates for SSH Authentication, on page 2 • How to Configure X.509v3 Certificates for SSH Authentication, on page 3 • Verifying the Server and User Authentication Using Digital Certificates , on page 6 • Configuration Examples for X.509v3 Certificates for SSH Authentication, on page 6 • Additional References for X.509v3 Certificates for SSH Authentication, on page 7 • Feature Information for X.509v3 Certificates for SSH Authentication, on page 8 Prerequisites for X.509v3 Certificates for SSH Authentication The X.509v3 Certificates for SSH Authentication feature replaces the ip ssh server authenticate user command with the ip ssh server algorithm authentication command. Configure the default ip ssh server authenticate user command to remove the ip ssh server authenticate user command from the configuration. The IOS secure shell (SSH) server will start using the ip ssh server algorithm authentication command. When you configure the ip ssh server authenticate user command, the following message is displayed: Warning SSH command accepted; but this CLI will be deprecated soon. Please move to new CLI ip ssh server algorithm authentication.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • 12 Certificates-In-The-Wild Slides
    Certificates in the wild Slides from • Dave Levin 414-spring2016 • Michelle Mazurek 414-fall2016 Certificates in the wild The lock icon indicates that the browser was able to authenticate the other end, i.e., validate its certificate Certificate chain Subject (who owns the public key) Common name: the URL of the subject Issuer (who verified the identity and signed this certificate) Serial number: Uniquely identifies this cert with respect to the issuer (look for this in CRLs) Signature algorithm: How the issuer will sign parts of the cert Not valid before/after: When to start and stop believing this cert (start & expiration dates) The public key: And the issuer’s signature of the public key Subject Alternate Names: Other URLs for which this cert should be considered valid. (wellsfargo.com is not the same as www.wellsfargo.com) Can include wildcards, e.g., *.google.com CRL & OCSP: Where to go to check if this certificate has been revoked Non-cryptographic checksums Certificate types Why are these different? This is an EV (extended validation) certificate; browsers show the full name for these kinds of certs Root CAs Root CAs in iOS9 • iOS9 ships with >50 that start with A-C • Full list at: https://support.apple.com/en-us/HT205205 Verifying certificates Browser Certificate “I’m because I say so!” Certificate “I’m because says so” Certificate “I’m because says so” Verifying certificates Browser Certificate “I’m because I say so!” Root key store Every device has one Certificate “I’m because says so” Must not contain malicious certificates Certificate
    [Show full text]