DOCSLIB.ORG

Vorbemerkung Zu Projekt 197 „Sichere Implementierung Einer Allgemeinen Kryptobibliothek – Arbeitspaket 1: Sichtung Und Analyse Bestehender Kryptobibliotheken“

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Vorbemerkung Zu Projekt 197 „Sichere Implementierung Einer Allgemeinen Kryptobibliothek – Arbeitspaket 1: Sichtung Und Analyse Bestehender Kryptobibliotheken“ Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63, 53133 Bonn Vorbemerkung zu Projekt 197 „Sichere Implementierung einer allgemeinen Kryptobibliothek – Arbeitspaket 1: Sichtung und Analyse bestehender Kryptobibliotheken“ Zielsetzung bei der Untersuchung der Kryptobibliotheken Ziel des Projektes „Sichere Implementierung einer allgemeinen Kryptobibliothek“ ist die Bereitstellung einer quelloffenen, sicheren, übersichtlichen, kontrollierbaren und gut dokumentierten Kryptobibliothek, die für möglichst viele Einsatzszenarien des BSI geeignet ist und auch in Anwendungen mit erhöhtem Sicherheitsbedarf eingesetzt werden kann. In der (hier im Ergebnis vorliegenden) ersten Projektphase wurden bestehende Open Source Kryptobibliotheken gesichtet und analysiert, um einen für das BSI geeigneten Kandidaten für eine Weiterentwicklung zu identifizieren. Dazu wurde eine Liste von Kriterien mit Gewichtungen zusammengestellt, die spezifisch im Hinblick auf das Gesamtprojekt ausgewählt wurden. Der Fokus des Projekts war dabei klar auf eine Vorarbeit für die folgende Entwicklung einer sicheren Kryptobibliothek beschränkt. So stellt die folgende Sichtung der Bibliotheken keine eigenständige Studie zu Sicherheitseigenschaften von Kryptobibliotheken dar, da sowohl die Vorauswahl der Bibliotheken als auch die Methodik und die Aufbereitung der Analyse sowie die Ermittlung und Untersuchung der Kandidaten für die Weiterentwicklung nur auf den internen Gebrauch im Rahmen der Durchführung des Gesamtprojekts ausgerichtet war. Die vorliegenden Projektergebnisse beruhen somit nicht auf einer allgemeingültigen oder vollumfänglichen Untersuchung und sind insbesondere keine offizielle Bewertung von Open Source Kryptobibliotheken durch das BSI. Mit der im Projektverlauf weiterentwickelten Bibliothek Botan (siehe https://github.com/Rohde- Schwarz-Cybersecurity/botan) steht jetzt eine Kryptobibliothek zur Verfügung, die den grundsätzlichen Vorstellungen des BSI entspricht und die zum Einsatz in Sicherheitsprodukten empfohlen wird. Botan steht unter der Simplified BSD Lizenz und kann freizügig sowohl für offene als auch für kommerzielle Anwendungen verwendet werden. Insbesondere sind auf GitHub alle Dokumente zu finden, die im Rahmen der Weiterentwicklung im Projekt entstanden sind und die Sicherheitseigenschaften von Botan ausführlich dokumentieren. ZUSTELL- UND LIEFERANSCHRIFT: Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee 185-189, 53175 Bonn Eine Studie im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik Projekt 197 Sichere Implementierung einer allgemeinen Kryptobibliothek Arbeitspaket 1: Sichtung und Analyse bestehender Kryptobibliotheken Version 1.0.0 / 2017-02-15 2 Zusammenfassung In diesem Projekt wird die sichere Implementierung einer allgemeinen Kryptobibliothek realisiert, die alle gängigen und für den breiten kryptographischen Einsatz notwendigen kryptographischen Primitive beinhaltet. Dazu zählen unter anderem symmetrische und asymmetrische Verschlüsselungs- und Signaturverfahren, PRFs, Hashfunktionen und RNGs. Zusätzlich müssen verbreitete Sicherheitsstandards wie X.509-Zertifikate oder SSL/TLS unterstützt werden. Diese Bibliothek soll dann auch Herstellern von VS-Produkten zur Verfügung stehen, womit der Evaluierungsaufwand des BSI für solche Produkte erheblich reduziert wird. Dieser Bericht ist das Ergebnis der Sichtung und Analyse bestehender Kryptobibliotheken. Es wird zunächst die Untersuchungsmethodik erläutert. Anschließend werden die Analyseergebnisse vorgestellt und es wird ein geeigneter Kandidat für eine Weiterentwicklung präsentiert. Die Analyse wurde im Zeitraum August 2015 bis November 2015 durchgeführt. Autoren Copyright Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urhebergesetzes ist ohne Zustimmung des BSI unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigung, Übersetzung, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 3 4 Sichere Implementierung einer allgemeinen Kryptobibliothek Sichtung und Analyse bestehender Kryptobibliotheken 5 6 Änderungshistorie Version Autor Kommentar Datum 1.0 Initiale Dokumentenversion erstellt 2017-02-15 7 8 Inhaltsverzeichnis 1 Vorauswahl der Kryptobibliotheken..............................................................................................13 1.1 Methodik.................................................................................................................................14 1.2 Analyse....................................................................................................................................18 1.2.1 Beecrypt..........................................................................................................................18 1.2.2 Botan...............................................................................................................................21 1.2.3 Cryptlib...........................................................................................................................24 1.2.4 Crypto++.........................................................................................................................27 1.2.5 GnuTLS...........................................................................................................................30 1.2.6 Libgcrypt.........................................................................................................................33 1.2.7 LibreSSL.........................................................................................................................36 1.2.8 Libsodium.......................................................................................................................39 1.2.9 Libtomcrypt.....................................................................................................................42 1.2.10 MatrixSSL.....................................................................................................................45 1.2.11 mbed TLS......................................................................................................................48 1.2.12 NaCl..............................................................................................................................51 1.2.13 Nettle.............................................................................................................................54 1.2.14 NSS...............................................................................................................................57 1.2.15 OpenSSL.......................................................................................................................60 1.2.16 Poco...............................................................................................................................63 1.2.17 s2n.................................................................................................................................66 1.2.18 WolfSSL........................................................................................................................69 1.3 Ergebnis..................................................................................................................................73 2 Detaillierte Analyse der vorausgewählten Bibliotheken...............................................................75 2.1 Methodik.................................................................................................................................75 2.2 Analyse....................................................................................................................................75 2.2.1 Implementierung von SCA-Gegenmaßnahmen..............................................................75 2.2.1.1 RSA-Blinding..........................................................................................................75 Botan..........................................................................................................................75 LibreSSL....................................................................................................................76 NSS............................................................................................................................77 2.2.1.2 Bleichenbacher-Angriff..........................................................................................77 Botan..........................................................................................................................78 LibreSSL....................................................................................................................79 NSS............................................................................................................................80 2.2.1.3 Invalid Curve Angriffe...........................................................................................81 Botan..........................................................................................................................81 LibreSSL....................................................................................................................81 NSS............................................................................................................................82 2.2.1.4 Small Subgroup Angriffe........................................................................................82 Botan..........................................................................................................................82
Load more

Recommended publications
  • 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.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [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]
  • A Security Analysis of the WPA-TKIP and TLS Security Protocols
    ARENBERG DOCTORAL SCHOOL Faculty of Engineering Science A Security Analysis of the WPA-TKIP and TLS Security Protocols Mathy Vanhoef Supervisor: Dissertation presented in partial Prof. dr. ir. F. Piessens fulfillment of the requirements for the degree of Doctor in Engineering Science: Computer Science July 2016 A Security Analysis of the WPA-TKIP and TLS Security Protocols Mathy VANHOEF Examination committee: Dissertation presented in partial Prof. dr. ir. P. Van Houtte, chair fulfillment of the requirements for Prof. dr. ir. F. Piessens, supervisor the degree of Doctor in Engineering Prof. dr. ir. C. Huygens Science: Computer Science Prof. dr. D. Hughes Prof. dr. ir. B. Preneel Prof. dr. K. Paterson (Royal Holloway, University of London) July 2016 © 2016 KU Leuven – Faculty of Engineering Science Uitgegeven in eigen beheer, Mathy Vanhoef, Celestijnenlaan 200A box 2402, B-3001 Leuven (Belgium) Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt worden door middel van druk, fotokopie, microfilm, elektronisch of op welke andere wijze ook zonder voorafgaande schriftelijke toestemming van de uitgever. All rights reserved. No part of the publication may be reproduced in any form by print, photoprint, microfilm, electronic or any other means without written permission from the publisher. Preface When I started my PhD four years ago, I thought people were exaggerating when they said that doing a PhD was a unique and special experience. Turns out I was wrong: it is indeed quite the journey! It was a roller coaster of exciting and sometimes no so exciting research results, late-night deadline races, moments of doubt, enriching and rewarding travels, grueling dilemmas, facing your own limitations,.
    [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]
  • No.Ntnu:Inspera:2546742.Pdf (10.61Mb)
    Krishna Shingala An alternative to the Public Key Krishna Shingala Infrastructure for the Internet of Things Master’s thesis in Communication Technology Supervisor: Danilo Gligoroski, Katina Kralevska, Torstein Heggebø Master’s thesis Master’s June 2019 An alternative to PKI for IoT PKI for to An alternative NTNU Engineering Communication Technology Communication Department of Information Security and Department of Information Faculty of Information Technology and Electrical Technology of Information Faculty Norwegian University of Science and Technology of Science University Norwegian An alternative to the Public Key Infras- tructure for the Internet of Things Krishna Shingala Submission date: June 2019 Responsible professor: Danilo Gligoroski, IIK, NTNU Supervisor: Danilo Gligoroski, IIK, NTNU Co-Supervisor: Katina Kralevska, IIK, NTNU Co-Supervisor: Torstein Heggebø, Nordic Semiconductor ASA Norwegian University of Science and Technology Department of Information Technology and Electrical Engineering Title: An alternative to the Public Key Infrastructure for the Internet of Things Student: Krishna Shingala Problem description: Internet of Things(IoT) enables participation of constrained devices on the Internet. Limited resources, bandwidth, and power on the devices have led to new protocols. Some examples of IoT driven and driving protocols are: – MQTT, CoAP that are application protocols for IoT; – 6LoWPAN enables efficient support of IPv6 on low power lossy networks; – CBOR enables concise data formatting; and – DTLS enables secure channel establishment over unreliable transport like the UDP. Security is one of the key factors for the success of IoT. TLS/DTLS secures the channel between the servers and the devices. Confidentiality is an important aspect of such a secure channel. Establishing the identity of an entity another.
    [Show full text]
  • 7) Internet of Things a Survey on the Security of Iot Frameworks
    Journal of Information Security and Applications 38 (2018) 8–27 Contents lists available at ScienceDirect Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa Internet of Things: A survey on the security of IoT frameworks ∗ Mahmoud Ammar a, , Giovanni Russello b, Bruno Crispo a a Department of Computer Science, KU Leuven University, Heverlee, 3001, Belgium b Department of Computer Science, University of Auckland, Private Bag 92019, Auckland 1142, New Zealand a r t i c l e i n f o a b s t r a c t Article history: The Internet of Things (IoT) is heavily affecting our daily lives in many domains, ranging from tiny wear- able devices to large industrial systems. Consequently, a wide variety of IoT applications have been devel- Keywords: oped and deployed using different IoT frameworks. An IoT framework is a set of guiding rules, protocols, Internet of Things and standards which simplify the implementation of IoT applications. The success of these applications IoT mainly depends on the ecosystem characteristics of the IoT framework, with the emphasis on the security Framework mechanisms employed in it, where issues related to security and privacy are pivotal. In this paper, we sur- Platform vey the security of the main IoT frameworks, a total of 8 frameworks are considered. For each framework, Security we clarify the proposed architecture, the essentials of developing third-party smart apps, the compati- ble hardware, and the security features. Comparing security architectures shows that the same standards used for securing communications, whereas different methodologies followed for providing other security properties.
    [Show full text]
  • Performance of State-Of-The-Art Cryptography on ARM-Based Microprocessors
    NIST Lightweight Cryptography Workshop 2015 Session VII: Implementations & Performance Performance of State-of-the-Art Cryptography on ARM-based Microprocessors Hannes Tschofenig & Manuel Pegourie-Gonnard ([email protected], [email protected] ) Presented by Hugo Vincent ([email protected] ) IoT Business Unit Tuesday, July 21, 2015 1 Outline § Why does ARM care about crypto performance? § ARM Cortex-M vs. Cortex-A Class processors. § Short overview of the Cortex-M processor family. § Internet of Things – a world full of constraints. § Performance of crypto on Cortex-M class processors § Assumptions § Hardware used for measurement § Symmetric Key Cryptography § Public Key Crypto (with different curves) § Cortex-M3/M4 Performance § Cortex-M0/M0+ Performance § Curve25519 § RAM Usage § Applying Results to TLS/DTLS § Conclusion & Next Steps 2 Why does ARM care about Crypto Performance? 3 ARM Processors in Smartphones § ARM Cortex-A family: § Applications processors for feature-rich OS and 3rd party applications § ARM Cortex-R family: § Embedded processors for real-time signal processing, control applications § ARM Cortex-M family: § Microcontroller- oriented processors for MCU, ASSP, and SoC applications 4 Cortex-M Processors Maximum Performance Flexible Memory Cache Single & Double Precision FP Digital Signal Control (DSC)/ Examples: Automotive, Processor with DSP High-end audio set Accelerated SIMD Performance & efficiency Floating point (FP) Example: Sensor fusion, Feature rich connectivity motor control Example:
    [Show full text]
  • Performance Investigations
    Performance Investigations Hannes Tschofenig, Manuel Pégourié-Gonnard 25th March 2015 1 Motivation § In <draft-ietf-lwig-tls-minimal> we tried to provide guidance for the use of DTLS (TLS) when used in IoT deployments and included performance data to help understand the design tradeoffs. § Later, work in the IETF DICE was started with the profile draft, which offers detailed guidance concerning credential types, communication patterns. It also indicates which extensions to use or not to use. § Goal of <draft-ietf-lwig-tls-minimal> is to offer performance data based on the recommendations in the profile draft. § This presentation is about the current status of gathering performance data for later inclusion into the <draft-ietf-lwig-tls-minimal> document. 2 Performance Data § This is the data we want: § Flash code size § Message size / Communication Overhead § CPU performance § Energy consumption § RAM usage § Also allows us to judge the improvements of various extensions and gives engineers a rough idea what to expect when planning to use DTLS/TLS in an IoT product. § <draft-ietf-lwig-tls-minimal-01> offers preliminary data about § Code size of various basic building blocks (data from one stack only) § Memory (RAM/flash) (pre-shared secret credential only) § Communication overhead (high level only) 3 Overview § Goal of the authors: Determine performance of asymmetric cryptography on ARM-based processors. § Next slides explains § Assumptions for the measurements, § ARM processors used for the measurements, § Development boards used, § Actual performance data, and § Comparison with other algorithms. 4 Assumptions § Main focus of the measurements so far was on § raw crypto (and not on protocol exchanges) § ECC rather than RSA § Different ECC curves § Run-time performance (not energy consumption, RAM usage, code size) § No hardware acceleration was used.
    [Show full text]
  • Prying Open Pandora's Box: KCI Attacks Against
    Prying open Pandora’s box: KCI attacks against TLS Clemens Hlauschek, Markus Gruber, Florian Fankhauser, Christian Schanes RISE – Research Industrial Systems Engineering GmbH {clemens.hlauschek, markus.gruber, florian.fankhauser, christian.schanes}@rise-world.com Abstract and implementations of the protocol: their utility is ex- tremely limited, their raison d’ˆetre is practically nil, and Protection of Internet communication is becoming more the existence of these insecure key agreement options common in many products, as the demand for privacy only adds to the arsenal of attack vectors against cryp- in an age of state-level adversaries and crime syndi- tographically secured communication on the Internet. cates is steadily increasing. The industry standard for doing this is TLS. The TLS protocol supports a multi- 1 Introduction tude of key agreement and authentication options which provide various different security guarantees. Recent at- The TLS protocol [1, 2, 3] is probably the most tacks showed that this plethora of cryptographic options widely used cryptographic protocol on the Internet. in TLS (including long forgotten government backdoors, It is designed to secure the communication between which have been cunningly inserted via export restric- client/server applications against eavesdropping, tamper- tion laws) is a Pandora’s box, waiting to be pried open by ing, and message forgery, and it also provides additional, heinous computer whizzes. Novel attacks lay hidden in optional security properties such as client authentica- plainsight. Parts of TLS areso oldthat theirfoul smell of tion. TLS is an historically grown giant: its predecessor, rot cannot be easily distinguished from the flowery smell SSL [4,5], was developed more than 20 years ago.
    [Show full text]
  • Directed Greybox Fuzzing
    Directed Greybox Fuzzing Marcel Böhme Van-Thuan Pham∗ National University of Singapore, Singapore National University of Singapore, Singapore [email protected] [email protected] Manh-Dung Nguyen Abhik Roychoudhury National University of Singapore, Singapore National University of Singapore, Singapore [email protected] [email protected] ABSTRACT However, existing greybox fuzzers cannot be effectively directed.1 Existing Greybox Fuzzers (GF) cannot be effectively directed, for Directed fuzzers are important tools in the portfolio of a security instance, towards problematic changes or patches, towards critical reseacher. Unlike undirected fuzzers, a directed fuzzer spends most system calls or dangerous locations, or towards functions in the of its time budget on reaching specific target locations without stacktrace of a reported vulnerability that we wish to reproduce. wasting resources stressing unrelated program components. Typical In this paper, we introduce Directed Greybox Fuzzing (DGF) applications of directed fuzzers may include which generates inputs with the objective of reaching a given set • patch testing [4, 21] by setting changed statements as targets. of target program locations efficiently. We develop and evaluate When a critical component is changed, we would like to check a simulated annealing-based power schedule that gradually as- whether this introduced any vulnerabilities. Figure 1 shows the signs more energy to seeds that are closer to the target locations commit introducing Heartbleed [49]. A fuzzer that focusses on while reducing energy for seeds that are further away. Experiments those changes has a higher chance of exposing the regression. with our implementation AFLGo demonstrate that DGF outper- • crash reproduction [18, 29] by setting method calls in the forms both directed symbolic-execution-based whitebox fuzzing stack-trace as targets.
    [Show full text]
  • The Rocky Road To
    The Rocky Road to Hanno Böck https://hboeck.de @hanno 1 Transport Layer Security A protocol to create an encrypted and authenticated layer around other protocols 2 TLS 1.3 was published in August 2018 3 How did we get there? 4 In 1995 Netscape introduced Secure Socket Layer or SSL version 2 5 In 1996 it was followed up with SSL version 3 6 In 1999 the IETF took over and renamed it to TLS 7 SSL/TLS History 1995: SSL 2 1996: SSL 3 1999: TLS 1.0 2006: TLS 1.1 2008: TLS 1.2 2018: TLS 1.3 8 Vulnerabilities C C S 9 Padding Oracles in CBC mode 10 Plaintext Plaintext Plaintext Initialization Vector (IV) block cipher block cipher block cipher Key Key Key encryption encryption encryption Ciphertext Ciphertext Ciphertext WhiteTimberwolf, Wikimedia Commons, Public Domain 11 CBC Padding for Block Ciphers (AES) Encryption of data blocks means we have to fill up space 12 CBC in TLS MAC-then-Pad-then-Encrypt 13 Valid Padding 00 01 01 02 02 02 03 03 03 03 ... 14 We assume a situation where the attacker can see whether the padding is valid 15 Ciphertext Ciphertext block cipher block cipher Key Key decryption decryption Initialization Vector (IV) ?== 00 -> padding valid Plaintext Plaintext Attacker wants to decrypt Attacker manipulates / XOR with guess 16 Ciphertext Ciphertext block cipher block cipher Key Key decryption decryption Initialization Vector (IV) ?== 01 01 -> padding valid Plaintext Plaintext Attacker knows Attacker manipulates to 01 Attacker wants to know Attacker manipulates to guess 01 17 2002: Serge Vaudenay discovers Padding Oracle Vaudenay,
    [Show full text]