DOCSLIB.ORG

Quantum Safe Cryptography; Case Studies and Deployment Scenarios

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI 3 ETSI GR QSC 003 V1.1.1 (2017-02) Contents Intellectual Property Rights ................................................................................................................................ 5 Foreword ............................................................................................................................................................. 5 Modal verbs terminology .................................................................................................................................... 5 1 Scope ........................................................................................................................................................ 6 2 References ................................................................................................................................................ 6 2.1 Normative references ......................................................................................................................................... 6 2.2 Informative references ........................................................................................................................................ 6 3 Abbreviations ........................................................................................................................................... 8 4 QSC deployment scenarios ...................................................................................................................... 9 5 Network security protocols .................................................................................................................... 10 5.1 Introduction ...................................................................................................................................................... 10 5.2 TLS ................................................................................................................................................................... 10 5.2.1 TLS cryptography ....................................................................................................................................... 10 5.2.2 Drop-in replacement ................................................................................................................................... 11 5.2.3 Hybrid scheme ............................................................................................................................................ 11 5.2.4 Re-engineering ............................................................................................................................................ 11 5.3 Discussion ........................................................................................................................................................ 11 5.3.1 Integration into the protocol stack .............................................................................................................. 11 5.3.2 Handling large key sizes ............................................................................................................................. 12 5.3.3 Is quantum-safe authentication required today? ......................................................................................... 13 6 Offline services ...................................................................................................................................... 13 6.1 Secure e-mail .................................................................................................................................................... 13 6.2 Credentials for offline services ......................................................................................................................... 14 6.3 Discussion ........................................................................................................................................................ 14 7 Internet of Things ................................................................................................................................... 14 7.1 Introduction ...................................................................................................................................................... 14 7.2 IoT cryptography .............................................................................................................................................. 15 7.3 Discussion ........................................................................................................................................................ 15 8 Satellite communications ....................................................................................................................... 16 8.1 Requirements .................................................................................................................................................... 16 8.2 Constraints ........................................................................................................................................................ 16 8.3 Discussion ........................................................................................................................................................ 17 9 Key Distribution Centres ........................................................................................................................ 17 9.1 Introduction ...................................................................................................................................................... 17 9.2 Examples .......................................................................................................................................................... 18 9.2.1 Kerberos® .................................................................................................................................................... 18 9.2.2 ZigBee® Trust Centre .................................................................................................................................. 18 9.2.3 Datagram Transport Layer Security (DTLS) .............................................................................................. 18 9.3 Discussion ........................................................................................................................................................ 18 10 Authentication ........................................................................................................................................ 19 10.1 Introduction ...................................................................................................................................................... 19 10.2 Requirements and use cases ............................................................................................................................. 19 10.2.1 Authenticating Internet-based applications ................................................................................................. 19 10.2.2 Offline file Authentication
Load more

Recommended publications
  • Cryptography
    Pattern Recognition and Applications Lab CRYPTOGRAPHY Giorgio Giacinto [email protected] University of Cagliari, Italy Spring Semester 2019-2020 Department of Electrical and Electronic Engineering Cryptography and Security • Used to hide the content of a message • Goals – Confidentiality – Authenticity – Integrity • The text is modified by an encryption function – An interceptor should not be able to understand all or part of the message content http://pralab.diee.unica.it 2 Encryption/Decryption Process Key Key (Optional) (Optional) Original Plaintext Encryption Ciphertext Decryption Plaintext http://pralab.diee.unica.it 3 Keys and Locks http://pralab.diee.unica.it 4 Keys L F A Y B D E T C A R C S E E T Y H G S O U S U D H R D F C E I D B T E M E P Q X N R C I D S F T U A E T C A U R M F N P E C J N A C R D B E M K C I O P F B E W U X I Y M C R E P F N O G I D C N T M http://pralab.diee.unica.it 5 Keys L F A Y B D E T C A R C S E E T Y H G S O U S U D H R D F C E I D B T E M E P Q X N R C I D S F T U A E T C A U R M F N P E C J N A C R D B E M K C I O P F B E W U X I Y M C R E P F N O G I D C N T M http://pralab.diee.unica.it 6 Steganography - = http://pralab.diee.unica.it https://towardsdatascience.com/steganography-hiding-an-image-inside-another-77ca66b2acb1 7 Definitions • Cryptography algorithm C = E(K,M) A function E with two inputs – a message M – a key K that outputs – the encrypted message C The algorithm is based on a shared secret between the sender and the receiver K The Encryption Key http://pralab.diee.unica.it 8 Symmetric
    [Show full text]
  • N2N: a Layer Two Peer-To-Peer VPN
    N2N: A Layer Two Peer-to-Peer VPN Luca Deri1, Richard Andrews2 ntop.org, Pisa, Italy1 Symstream Technologies, Melbourne, Australia2 {deri, andrews}@ntop.org Abstract. The Internet was originally designed as a flat data network delivering a multitude of protocols and services between equal peers. Currently, after an explosive growth fostered by enormous and heterogeneous economic interests, it has become a constrained network severely enforcing client-server communication where addressing plans, packet routing, security policies and users’ reachability are almost entirely managed and limited by access providers. From the user’s perspective, the Internet is not an open transport system, but rather a telephony-like communication medium for content consumption. This paper describes the design and implementation of a new type of peer-to- peer virtual private network that can allow users to overcome some of these limitations. N2N users can create and manage their own secure and geographically distributed overlay network without the need for central administration, typical of most virtual private network systems. Keywords: Virtual private network, peer-to-peer, network overlay. 1. Motivation and Scope of Work Irony pervades many pages of history, and computing history is no exception. Once personal computing had won the market battle against mainframe-based computing, the commercial evolution of the Internet in the nineties stepped the computing world back to a substantially rigid client-server scheme. While it is true that the today’s Internet serves as a good transport system for supplying a plethora of data interchange services, virtually all of them are delivered by a client-server model, whether they are centralised or distributed, pay-per-use or virtually free [1].
    [Show full text]
  • Security & Savings with Virtual Private Networks
    Everybody’s connecting. Security & Savings with Virtual Private Networks In today’s New Economy, small businesses that might have dealt with just local or regional concerns now have to consider global markets and logistics. Many companies even have facilities spread across the country or throughout the world. At the same time security concerns of their network from hackers, Denial-of-Service (DoS) attacks and sending data over the Internet have become more widespread. Whether companies have a local, national, or global presence, they all need one thing: a way to maintain fast, secure, and reliable communications wherever their offices and workers are located. Until recently, such communications were only available by using leased telephone lines to maintain a Wide Area Network (WAN). Leased lines enabled companies to expand their private network beyond their immediate geographic area. Moreover, a WAN provided advantages over a public network like the Internet when it came to reliability, performance, and security. Unfortunately, leased lines are expensive to maintain, with costs rising as the distance between the offices increases. As the popularity of the Internet grew, businesses turned to it as a cost-effective way to extend their networks. The continuing popularity with the Internet has led to the evolution of Virtual Private Networks (VPNs). A VPN is a connection that allows private data to be sent securely over a shared or public network, such as the Internet. In fact, one of the driving forces behind VPNs is the Internet and its global presence. With VPNs, communication links between users and sites can be achieved quickly, inexpensively, and safely across the world.
    [Show full text]
  • Analysis of Recent Attacks on Ssl/Tls Protocols A
    ANALYSIS OF RECENT ATTACKS ON SSL/TLS PROTOCOLS A THESIS SUBMITTED TO THE GRADUATE SCHOOL OF APPLIED MATHEMATICS OF MIDDLE EAST TECHNICAL UNIVERSITY BY DUYGU OZDEN¨ IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN CRYPTOGRAPHY SEPTEMBER 2016 Approval of the thesis: ANALYSIS OF RECENT ATTACKS ON SSL/TLS PROTOCOLS submitted by DUYGU OZDEN¨ in partial fulfillment of the requirements for the de- gree of Master of Science in Department of Cryptography, Middle East Technical University by, Prof. Dr. Bulent¨ Karasozen¨ Director, Graduate School of Applied Mathematics Prof. Dr. Ferruh Ozbudak¨ Head of Department, Cryptography Assoc. Prof. Dr. Murat Cenk Supervisor, Cryptography, METU Examining Committee Members: Assoc. Prof. Dr. Murat Cenk Cryptography, METU Assoc. Prof. Dr. Ali Doganaksoy˘ Mathematics, METU Asst. Prof. Dr. Fatih Sulak Mathematics, ATILIM UNIVERSITY Date: I hereby declare that all information in this document has been obtained and presented in accordance with academic rules and ethical conduct. I also declare that, as required by these rules and conduct, I have fully cited and referenced all material and results that are not original to this work. Name, Last Name: DUYGU OZDEN¨ Signature : v vi ABSTRACT ANALYSIS OF RECENT ATTACKS ON SSL/TLS PROTOCOLS Ozden,¨ Duygu M.S., Department of Cryptography Supervisor : Assoc. Prof. Dr. Murat Cenk September 2016, 46 pages Transport Layer Security(TLS) and its predecessor Secure Socket Layer(SSL) are two important cryptographic, certificate based protocols that satisfy secure communication in a network channel. They are widely used in many areas such as online banking systems, online shopping, e-mailing, military systems or governmental systems.
    [Show full text]
  • Cryptographic Control Standard, Version
    Nuclear Regulatory Commission Office of the Chief Information Officer Computer Security Standard Office Instruction: OCIO-CS-STD-2009 Office Instruction Title: Cryptographic Control Standard Revision Number: 2.0 Issuance: Date of last signature below Effective Date: October 1, 2017 Primary Contacts: Kathy Lyons-Burke, Senior Level Advisor for Information Security Responsible Organization: OCIO Summary of Changes: OCIO-CS-STD-2009, “Cryptographic Control Standard,” provides the minimum security requirements that must be applied to the Nuclear Regulatory Commission (NRC) systems which utilize cryptographic algorithms, protocols, and cryptographic modules to provide secure communication services. This update is based on the latest versions of the National Institute of Standards and Technology (NIST) Guidance and Federal Information Processing Standards (FIPS) publications, Committee on National Security System (CNSS) issuances, and National Security Agency (NSA) requirements. Training: Upon request ADAMS Accession No.: ML17024A095 Approvals Primary Office Owner Office of the Chief Information Officer Signature Date Enterprise Security Kathy Lyons-Burke 09/26/17 Architecture Working Group Chair CIO David Nelson /RA/ 09/26/17 CISO Jonathan Feibus 09/26/17 OCIO-CS-STD-2009 Page i TABLE OF CONTENTS 1 PURPOSE ............................................................................................................................. 1 2 INTRODUCTION ..................................................................................................................
    [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]
  • 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]
  • What Is a Virtual Private Network?
    C H A P T E R 1 What Is a Virtual Private Network? A virtual private network (VPN) allows the provisioning of private network services for an organization or organizations over a public or shared infrastructure such as the Internet or service provider backbone network. The shared service provider backbone network is known as the VPN backbone and is used to transport traffic for multiple VPNs, as well as possibly non-VPN traffic. VPNs provisioned using technologies such as Frame Relay and Asynchronous Transfer Mode (ATM) virtual circuits (VC) have been available for a long time, but over the past few years IP and IP/Multiprotocol Label Switching (MPLS)-based VPNs have become more and more popular. This book focuses on describing the deployment of IP- and IP/MPLS-based VPNs. The large number of terms used to categorize and describe the functionality of VPNs has led to a great deal of confusion about what exactly VPNs are and what they can do. The sections that follow cover VPN devices, protocols, technologies, as well as VPN categories and models. VPN Devices Before describing the various VPN technologies and models, it is useful to first describe the various customer and provider network devices that are relevant to the discussion. Devices in the customer network fall into one of two categories: • Customer (C) devices—C devices are simply devices such as routers and switches located within the customer network. These devices do not have direct connectivity to the service provider network. C devices are not aware of the VPN. • Customer Edge (CE) devices—CE devices, as the name suggests, are located at the edge of the customer network and connect to the provider network (via Provider Edge [PE] devices).
    [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]
  • Final Resourcediscoverysecuritydistrsystems Thesis Linelarsen
    Resource discovery and Security in Distributed systems Resource discovery and Security in Distributed systems by Line Larsen Thesis is partial fulfilment of the degree of Master in Technology in Information and Communication Technology Agder University College Faculty of Engineering and Science Grimstad Norway May 2007 May 2007 – Line Larsen 1 Resource discovery and Security in Distributed systems Abstract To be able to access our files at any time and any where, we need a system or service which is free, has enough storage space and is secure. A centralized system can handle these challenges today, but does not have transparency, openness and scalability like a peer to peer network has. A hybrid system with characteristics from both distributed and centralized topologies is the ideal choice. In this paper I have gone through the basic theory of network topology, protocols and security and explained “search engine”, “Middleware”, “Distributed Hash Table” and the JXTA protocol. I then have briefly examined three existing peer to peer architectures which are “Efficient and Secure Information Sharing in Distributed, collaborative Environments” based on Sandbox and transitive delegation from 1999, pStore: A Secure Peer–to-Peer backup System” based on versioning and file blocks from 2001 and iDIBS from 2006, which is an improved versions of the SourceForge project Distributed Internet Backup System (DIBS) using Luby Transform codes instead of Reed-Solomon codes for error correction when reconstructing data. I have also looked into the security aspects related to using distributed systems for resource discovery and I have suggested a design of a resource discovery architecture which will use JXTA for backup of personal data using Super-peer nodes in a peer to peer architecture.
    [Show full text]