DOCSLIB.ORG

Hands-On Workshop

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hands-On Workshop Session ID: FTF-INS-F1145 June, 2015 HANDS-ON WORKSHOP Create Secure Network-Connected Embedded Systems with CyaSSL and Kinetis SDK 1 Copyright 2015 wolfSSL Inc. SESSION INTRODUCTION • Abstract • Secure your data communications with TLS/SSL for embedded systems, now available in an easy-to-use package for Kinetis SDK and MQX™ RTOS. Learn how to enable secure web server connections to browsers and mobile devices as well as web client connections to the cloud. • Presenters • Chris Conlon | wolfSSL Inc. | Software Engineer • Timing • 1 Hour : Presentation (Protocol, technology overview) • 1 Hour : Hands-on Lab with FRDM-K64F 2 #FTF2015 Copyright 2015 wolfSSL Inc. SESSION OBJECTIVES • Gain overview knowledge of SSL / TLS protocols • Learn about TLS and cryptography performance • Gain insight into best practices for using TLS on devices • Learn how to enable secure web server communication, using demos included in the CyaSSL patch for the Kinetis SDK • Learn the advantages to using wolfSSL and CyaSSL on Freescale platforms • Get hands on experience, directly from experts at wolfSSL 3 #FTF2015 Copyright 2015 wolfSSL Inc. AGENDA 1. Introduction and History of wolfSSL 2. Overview of SSL / TLS, and Cryptography 3. X.509 and Certificates 4. Overview of wolfSSL Embedded SSL / TLS 5. Using CyaSSL with Freescale KDS IDE and Kinetis MCUs 6. Using Wireshark to Inspect a TLS Connection 7. Hands On Lab: HTTPS Server Example with CyaSSL, KDS, and FRDM-K64F 8. Additional Tips and Tricks about CyaSSL (Time Permitting) 4 #FTF2015 Copyright 2015 wolfSSL Inc. ABOUT WOLFSSL Founded: 2004 Products: - wolfSSL - wolfSSL FIPS Location: Bozeman, MT - wolfCrypt Seattle, WA - wolfSSH - wolfSCEP Portland, OR - wolfSSL Inspection - yaSSL Our Focus: Open Source Embedded Security (for Applications, Devices, IoT, and the Cloud) 200 OEM Customers 2011 3 employees 2012 9 employees 10 Resale Partners 2013 11 employees 2014 15 employees Currently Securing 2015 17 employees 1 Billion Connections! 5 #FTF2015 Copyright 2015 wolfSSL Inc. WOLFSSL LIGHTWEIGHT SSL/TLS • Advantages to wolfSSL: • Written from the Ground Up. wolfSSL owns the Copyright • Built for Portability, Modularity, and Performance • Strong, collaborative partnership with Freescale • Commitment to new ciphers, features, and addressing ongoing security threats • Current SSL/TLS/DTLS protocol support up to TLS 1.2 and DTLS 1.2 • Community, User, and Professional vetted since 2006 6 #FTF2015 Copyright 2015 wolfSSL Inc. WOLFSSL LIGHTWEIGHT SSL/TLS • Advantages to wolfSSL: • Dedicated support via [email protected] and direct phone support • Free Presales Support! 7 #FTF2015 Copyright 2015 wolfSSL Inc. OVERVIEW OF SSL / TLS GOALS, HISTORY 16 #FTF2015 Copyright 2015 wolfSSL Inc. SSL / TLS : HISTORY AND PROTOCOLS • SSL / TLS / DTLS versions 1995 SSL 2.0 1996 SSL 3.0 Notes: • SSL 2.0 is insecure 1999 TLS 1.0 • SSL = “Secure Sockets Layer” 2006 TLS 1.1 DTLS 1.0 • TLS = “Transport Layer Security” 2008 TLS 1.2 • DTLS = “Datagram TLS” 2012 DTLS 1.2 17 #FTF2015 Copyright 2015 wolfSSL Inc. SSL / TLS : GOALS • Enables secure client/server communication Privacy + Prevent eavesdropping Authentication + Prevent impersonation Integrity + Prevent modification 18 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SIMPLIFIED ANALOGY Goals: A. Talk to the desired person B. Talk privately (securely) ? ? Alice Bob 19 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SIMPLIFIED ANALOGY Goals: A. Talk to the desired person B. Talk privately (securely) Drivers Drivers License License Alice Bob 20 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SIMPLIFIED ANALOGY Goals: A. Talk to the desired person B. Talk privately (securely) Drivers Drivers License License Alice Bob 21 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SIMPLIFIED ANALOGY Goals: A. Talk to the desired person B. Talk privately (securely) Drivers Drivers License License Alice Bob 22 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SIMPLIFIED ANALOGY Goals: • Talk to the desired peer • X.509 Certificates (RSA, ECC) • Talk privately (securely) • Encryption, Integrity checks 23 #FTF2015 Copyright 2015 wolfSSL Inc. MITM ATTACKS • Man in the Middle Attacks • One of the most prominent attacks TLS tries to prevent Device Server Attacker 24 #FTF2015 Copyright 2015 wolfSSL Inc. SSL / TLS TECHNICAL OVERVIEW, RFC’S, HANDSHAKE 25 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : PROTOCOL SPECS Protocol Specifications • RFC 6101: SSL 3.0 • RFC 2246: TLS 1.0 • RFC 4346: TLS 1.1 • RFC 5246: TLS 1.2 • “Draft”: TLS 1.3 26 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : PROTOCOLS AND LOCATION Protocols Secured by SSL/TLS SSL SSL Change SSL Alert LDAP, Handshake Cipher Spec HTTP Protocol etc. SMTP, Protocol Protocol HTTP etc. SSL Record Layer Application Layer TCP Transport Layer IP Internet Layer Network Access Network Layer 27 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Responsible for negotiating a session, includes: 2 • Session identifier • Peer certificate • Compression method 3 • Cipher spec (A) • Master secret 4 (B) • “is resumable” 28 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS Client Server 1 1 Client Hello Cryptographic Info (SSL version, supported ciphers, etc.) 2 3 Server Hello 2 Cipher Suite Verify server cert, Server Certificate check crypto Server Key Exchange (public key) parameters ( Client Certificate Request ) Server Hello Done 4 3 Client Key Exchange 5 ( Certificate Verify ) Verify client cert ( Client Certificate ) (if required) 6 (A) Change Cipher Spec 4 (B) Client Finished 7 Change Cipher Spec Server Finished 8 Exchange Messages (Encrypted) 29 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Client Hello ! 2 • Sent when client first connects to server • Includes • Protocol version 3 • Random structure • Session ID (A) • Cipher suites (B) 4 • Compression methods • Extensions 30 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Server Hello 2 • Sent in response to Client Hello • Only when it can find acceptable set of algorithms • Includes 3 • Protocol version • Random (A) (B) • Session ID 4 • Cipher suite • Compression method • Extensions 31 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Hello Extensions 2 • Signature Algorithms • Which signature / hash pairs may be used 3 • Maximum Fragment Length • Set maximum SSL record fragment size (A) (B) 4 • Several more… 32 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Server Certificate 2 • Server’s certificate chain sent to client • X.509v3 certificates • Must be compatible with selected key exchange 3 method (A) 4 (B) 33 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Server Key Exchange 2 • Sent when cert message doesn’t contain enough data for client to exchange premaster secret: • DHE_DSS 3 • DHE_RSA • DHE_ANON (A) (B) 4 *Or rather, when “ephemeral” suites are used. 34 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " (Certificate Request) 2 • Server request for client certificate 3 • Used when “mutual authentication” is done (A) 4 (B) 35 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Server Hello Done 2 • Indicates end of Server Hello 3 • After sending, server waits for client response (A) 4 (B) 36 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Client Authenticates Server 2 • Using cert sent previously and loaded CA certs 3 (A) 4 (B) 37 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • (Client Certificate) ! 2 • Only sent if server requests it 3 • If no cert available, must send empty one (A) 4 (B) 38 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Client Key Exchange ! 2 • Sets the premaster secret: • RSA-encrypted premaster secret message 3 • Client DH public value (A) 4 (B) 39 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Certificate Verify ! 2 • Used to provide explicit verification of the client certificate • Client signs some data* with private key 3 • Server tries to decrypt with public key (A) 4 (B) *concatenation of all handshake messages thus far 40 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Change Cipher Spec ! 2 • Switches to agreed upon cipher suite, compression, etc. 3 (A) 4 (B) 41 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • Finished ! 2 • Verifies that key exchange and authentication process was successful. • First message sent under negotiated algorithms, 3 keys, and secrets. (A) 4 (B) 42 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Change Cipher Spec 2 • Same purpose as client’s 3 (A) 4 (B) 43 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Handshake Protocol • " Finished 2 • Same purpose as client’s 3 (A) 4 (B) 44 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Change Cipher Spec Protocol • Signals transitions in ciphering strategies 2 • Sent by both client and server 3 • Notifies receiving party that subsequent records will be protected under newly negotiated CipherSpec (A) and keys 4 (B) 45 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS 1 Alert Protocol • Convey severity and description of alert 2 • Either “warning” or “fatal” • Fatal results in immediate termination of connection 3 • Encrypted and compressed as per CipherSpec (A) 4 (B) 46 #FTF2015 Copyright 2015 wolfSSL Inc. TLS : SUB PROTOCOLS
Load more

Recommended publications
  • 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]
  • Secure Industrial Device Connectivity with Low-Overhead TLS
    Secure Industrial Device Connectivity with Low-Overhead TLS Tuesday, October 3, 2017 1:10PM-2:10PM Chris Conlon - Engineering Manager, wolfSSL - B.S. from Montana State University (Bozeman, MT) - Software engineer at wolfSSL (7 years) Contact Info: - Email: [email protected] - Twitter: @c_conlon A. – B. – C. – D. – E. F. ● ● ● ○ ● ○ ● ○ ● Original Image Encrypted using ECB mode Modes other than ECB ● ○ ● ○ ● ● ● ● ○ ● ● ● ● ○ ● ○ ○ ○ ○ ● ○ ● ● ● ● ○ ● ● ○ By Original schema: A.J. Han Vinck, University of Duisburg-EssenSVG version: Flugaal - A.J. Han Vinck, Introduction to public key cryptography, p. 16, Public Domain, https://commons.wikimedia.org/w/index.php?curid=17063048 ● ○ ● ○ ■ ■ ■ ● ○ ■ ● ● ● ● ● ○ ● ● ● ● ● ● ● ○ ○ ○ ○ ● “Progressive” is a subjective term ● These slides talk about crypto algorithms that are: ○ New, modern ○ Becoming widely accepted ○ Have been integrated into SSL/TLS with cipher suites ● ChaCha20 ● Poly1305 ● Curve25519 ● Ed25519 Created by Daniel Bernstein a research professor at the University of Illinois, Chicago Chacha20-Poly1305 AEAD used in Google over HTTPS Ed25519 and ChaCha20-Poly1305 AEAD used in Apple’s HomeKit (iOS Security) ● Fast stream cipher ● Based from Salsa20 stream cipher using a different quarter-round process giving it more diffusion ● Can be used for AEAD encryption with Poly1305 ● Was published by Bernstein in 2008 Used by ● Google Chrome ● TinySSH ● Apple HomeKit ● wolfSSL ● To provide authenticity of messages (MAC) ● Extremely fast in comparison to others ● Introduced by a presentation given from Bernstein in 2002 ● Naming scheme from using polynomial-evaluation MAC (Message Authentication Code) over a prime field Z/(2^130 - 5) Used by ● Tor ● Google Chrome ● Apple iOS ● wolfSSL Generic Montgomery curve. Reference 5 Used by ● Tera Term ● GnuPG ● wolfSSL Generic Twisted Edwards Curve.
    [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]
  • Analysis of DTLS Implementations Using Protocol State Fuzzing
    Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Brostean and Bengt Jonsson, Uppsala University; Robert Merget, Ruhr-University Bochum; Joeri de Ruiter, SIDN Labs; Konstantinos Sagonas, Uppsala University; Juraj Somorovsky, Paderborn University https://www.usenix.org/conference/usenixsecurity20/presentation/fiterau-brostean This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Bro¸stean˘ Bengt Jonsson Robert Merget Joeri de Ruiter Uppsala University Uppsala University Ruhr University Bochum SIDN Labs Konstantinos Sagonas Juraj Somorovsky Uppsala University Paderborn University Abstract reach 11.6 billion by 2021 [26]. This will constitute half of all devices connected to the Internet, with the percentage set to Recent years have witnessed an increasing number of proto- grow in subsequent years. Such trends also increase the need cols relying on UDP. Compared to TCP, UDP offers perfor- to ensure that software designed for these devices is properly mance advantages such as simplicity and lower latency. This scrutinized, particularly with regards to its security. has motivated its adoption in Voice over IP, tunneling techno- DTLS is also used as one of the two security protocols in logies, IoT, and novel Web protocols. To protect sensitive data WebRTC, a framework enabling real-time communication. exchange in these scenarios, the DTLS protocol has been de- WebRTC can be used, for example, to implement video con- veloped as a cryptographic variation of TLS.
    [Show full text]
  • Breaking Ed25519 in Wolfssl
    Breaking Ed25519 in WolfSSL Niels Samwel1, Lejla Batina1, Guido Bertoni, Joan Daemen1;2, and Ruggero Susella2 1 Digital Security Group, Radboud University, The Netherlands fn.samwel,lejla,[email protected] 2 STMicroelectronics [email protected] [email protected] Abstract. Ed25519 is an instance of the Elliptic Curve based signature scheme EdDSA that was recently introduced to solve an inconvenience of the more established ECDSA. Namely, both schemes require the gen- eration of a random value (scalar of the ephemeral key pair) during the signature generation process and the secrecy of this random value is critical for security: knowledge of one such a random value, or partial knowledge of a series of them, allows reconstructing the signer's private key. In ECDSA it is not specified how to generate this random value and hence implementations critically rely on the quality of random number generators and are challenging to implement securely. EdDSA removes this dependence by deriving the secret deterministically from the mes- sage and a long-term auxiliary key using a cryptographic hash function. The feature of determinism has received wide support as enabling secure implementations and in particular deployment of Ed25519 is spectac- ular. Today Ed25519 is used in numerous security protocols, networks and both software and hardware security products e.g. OpenSSH, Tor, GnuPG etc. In this paper we show that in use cases where power or electromagnetic leakage can be exploited, exactly the mechanism that makes EdDSA deterministic complicates its secure implementation. In particular, we break an Ed25519 implementation in WolfSSL, which is a suitable use case for IoT applications.
    [Show full text]
  • Analysis of Software Vulnerabilities Through Historical Data
    Analysis of software vulnerabilities through historical data Magnus Törnquist [email protected] Department of Electrical and Information Technology Lund University Supervisor: Martin Hell Assistant Supervisor: Jonathan Sönnerup Examiner: Thomas Johansson June 29, 2017 c 2017 Printed in Sweden Tryckeriet i E-huset, Lund Popular science summary Lately there has been increasing media coverage of cyber crime, especially in re- lation to the elections in France and the United States. Every day information is being stolen from governments, businesses and private citizens. Information that can be sold, used for blackmail or for other nefarious purposes. Commonly this information is obtained through exploiting vulnerabilities in software. A vulnera- bility is essentially a bug in the code and they are very hard to avoid, especially in large complex programs. Having vulnerabilities in software is inevitable and software is everywhere: in every computer, router, webcam, mobile device and even in some coffeemakers. As long as these devices are connected an intruder has a wide variety of options on how to attack a network and the fast growth of Internet of Things (IoT) has lead to a huge amount of new devices on networks all over the world. This reality means that larger organizations have to spend a lot of time making sure all their software is updated and keeping track of potential breaches. This also means that it is very important for the software developer to maintain their code and patch any discovered vulnerabilities quickly. So how does an organization, the developer of an IoT product or a regular user choose which software to use if they are concerned about software security and is there a way to help them do it? That is what this thesis explores.
    [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]
  • Practical Invalid Curve Attacks on TLS-ECDH
    Practical Invalid Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky Horst Görtz Institute for IT Security Ruhr University Bochum @jurajsomorovsky 1 Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 1 Recent years revealed many attacks on TLS… • ESORICS 2004, Bard: The Vulnerability of SSL to Chosen Plaintext Attack • Eurocrypt 2002, Vaudenay: Security Flaws Induced by CBC Padding—Applications to SSL, IPSEC, WTLS • Crypto 1998, Bleichenbacher: Chosen Ciphertext Attacks Against Protocols based on the RSA Encryption Standard PKCS #1 Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 2 2 Another “forgotten” attack • Invalid curve attack • Crypto 2000, Biehl et al.: Differential fault attacks on elliptic curve cryptosystems • Targets elliptic curves – Allows one to extract private keys • Are current libraries vulnerable? Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 3 3 Overview 1. Elliptic Curves 2. Invalid Curve Attacks 3. Application to TLS ECDH 4. Evaluation 5. Bonus Content Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 4 4 Elliptic Curve (EC) Crypto • Key exchange, signatures, PRNGs • Many sites switching to EC • Fast, secure – openssl speed rsa2048 ecdhp256 – ECDH about 10 times faster Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 5 5 Elliptic Curve • Set of points over a
    [Show full text]
  • Quantum Safe Cryptography; Case Studies and Deployment Scenarios
    ETSI GR QSC 003 V1.1.1 (2017-02) GROUP REPORT Quantum Safe Cryptography; Case Studies and Deployment Scenarios Disclaimer The present document has been produced and approved by the Quantum-Safe Cryptography (QSC) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. 2 ETSI GR QSC 003 V1.1.1 (2017-02) Reference DGR/QSC-003 Keywords algorithm, authentication, confidentiality, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Analyzing Semantic Correctness of Security-Critical Algorithm Implementations with Symbolic Execution
    Poster: Analyzing Semantic Correctness of Security-critical Algorithm Implementations with Symbolic Execution Author: Sze Yiu Chau ([email protected]) Affiliation: Purdue University Poster Abstract: In order to achieve security, protocol implementations not only need to avoid low-level memory access errors, but also faithfully follow and fulfill the requirements prescribed by the protocol specifications at the semantic level. Failure to do so could lead to compatibility issues and damage the security guarantees intended by the original design. In this poster, I will discuss how to use symbolic execution to analyze semantic correctness of implementations of security-critical algorithms. The main intuition is that, while symbolic execution faces scalability challenges, it provides a systematic means of exploring possible execution paths and a formula-based abstraction, both of which are useful in finding semantic level implementation flaws. In many cases, scalability challenges can be avoided with concolic inputs carefully crafted by exploiting features of the input formats used by target protocols, along with optimizations based on domain knowledge that can help prune the search space. As examples, the poster will first present our previous work on analyzing implementations of X.509 certificate validation. Our analysis of 9 small footprint TLS libraries has uncovered 48 instances of noncompliance, as well as some inaccurate claims in a previous work based on blackbox fuzzing. It will then discuss our most recent work on analyzing implementations of PKCS#1 v1.5 RSA signature verification, and explain how some of the implementation flaws we found in crypto libraries and IPSec software suites can lead to authentication bypass and denial-of-service attacks due to new variants of the Bleichenbacher-style low-exponent RSA signature forgery.
    [Show full text]
  • Practical Invalid Curve Attacks on TLS-ECDH
    Practical Invalid Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky Horst Görtz Institute for IT Security Ruhr University Bochum @jurajsomorovsky 1 Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 1 About Me and Our Institute • Security Researcher at: – Chair for Network and Data Security • Prof. Dr. Jörg Schwenk • Web Services, Single Sign-On, (Applied) Crypto, SSL, crypto currencies • Provable security, attacks and defenses – Horst Görtz Institute for IT-Security • Further topics: embedded security, malware, crypto… – Ruhr University Bochum • Penetration tests, security analyses, workshops… Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 2 2 Recent years revealed many attacks on TLS… • ESORICS 2004, Bard: The Vulnerability of SSL to Chosen Plaintext Attack • Eurocrypt 2002, Vaudenay: Security Flaws Induced by CBC Padding—Applications to SSL, IPSEC, WTLS • Crypto 1998, Bleichenbacher: Chosen Ciphertext Attacks Against Protocols based on the RSA Encryption Standard PKCS #1 Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 3 3 Another “forgotten” attack • Invalid curve attack • Crypto 2000, Biehl et al.: Differential fault attacks on elliptic curve cryptosystems • Targets elliptic curves – Allows one to extract private keys • Are current libraries vulnerable? Practical Invalid Elliptic Curve Attacks on TLS-ECDH Tibor Jager, Jörg Schwenk, Juraj Somorovsky 4 4 Overview 1. Elliptic
    [Show full text]
  • Algebraic Eraser™ and Lightweight Cryptography
    Walnut Digital Signature AlgorithmTM: A lightweight, quantum-resistant signature scheme for use in passive, low-power, and IoT devices Derek Atkins, SecureRF Corporation Historically “Lightweight Cryptography” has focused on symmetric schemes, yet asymmetric methods can also work effectively in these environments. Specifically, the Walnut Digital Signature AlgorithmTM (WalnutDSATM) provides a public-key signature scheme that verifies signatures significantly faster than ECC in both software and hardware, even in small, constrained environments and is resistant to all known attacks, both conventional and quantum. Specifically, WalnutDSA can validate a signature anywhere from 32 to 178 times faster than ECC using less ROM/RAM or fewer gates. This presentation previews the Walnut Digital Signature Algorithm, performance results, and shows how it can be applied to real-world uses. SecureRF Corporation 100 Beard Sawmill Road Suite 350 Shelton, CT 06484 203-227-3151 [email protected] www.SecureRF.com Walnut Digital Signature AlgorithmTM: A lightweight, quantum-resistant signature scheme for use in passive, low-power, and IoT devices 1. Introduction As Moore's Law continues, smaller and smaller devices are gaining more and more computational power. Where in the previous decades end systems were home personal computers, laptops, and even cloud servers, these days systems are getting smaller and more constrained. Growing into the Internet of Things, no longer are systems as powerful as before, as companies spend pennies to add computational resources to devices as small as light bulbs. However as these devices get smaller, the need to secure them grows exponentially. As more devices get connected the need to identify, authenticate, and protect those devices grows.
    [Show full text]