“Make Sure DSA Signing Exponentiations Really Are Constant-Time”

Total Page:16

File Type:pdf, Size:1020Kb

Load more

“Make Sure DSA Signing Exponentiations Really are Constant-Time” Cesar Pereida García Billy Bob Brumley Yuval Yarom Department of Computer Department of Pervasive The University of Adelaide and Science Computing Data61, CSIRO, Australia Aalto University, Finland Tampere University of [email protected] cesar.pereida@aalto.fi Technology, Finland billy.brumley@tut.fi ABSTRACT Our attack builds upon several techniques to profile the TLS and SSH are two of the most commonly used proto- cache memory and capture timing signals. The signals are cols for securing Internet traffic. Many of the implemen- processed and converted into a sequence of square and mul- tations of these protocols rely on the cryptographic primi- tiplication (SM) operations from which we extract informa- tives provided in the OpenSSL library. In this work we dis- tion to create a lattice problem. The solution to the lattice close a vulnerability in OpenSSL, affecting all versions and problem yields the secret key of digital signatures. forks (e.g. LibreSSL and BoringSSL) since roughly October Flush+Reload [40] is a powerful technique to perform 2005, which renders the implementation of the DSA signa- cache-timing attacks. We adapt the Flush+Reload tech- ture scheme vulnerable to cache-based side-channel attacks. nique to OpenSSL's implementation of DSA and, exploit- Exploiting the software defect, we demonstrate the first pub- ing properties of the Intel implementation of the x86 and lished cache-based key-recovery attack on these protocols: x64 processor architectures, our spy program probes rele- 260 SSH-2 handshakes to extract a 1024/160-bit DSA host vant memory addresses to create a signal trace. key from an OpenSSH server, and 580 TLS 1.2 handshakes We process the captured signal to get the SM sequence to extract a 2048/256-bit DSA key from an stunnel server. performed by the sliding window exponentiation (SWE) al- gorithm. Then we observe and analyze the number of bits that can be extracted and used from each of those sequences. Keywords Later, the variable amount of bits extracted from each trace applied cryptography; digital signatures; side-channel anal- is used as input to a lattice attack that recovers the private ysis; timing attacks; cache-timing attacks; DSA; OpenSSL; key. CVE-2016-2178 To bridge the gap between the limited resolution of the Flush+Reload technique [4] and the high-performance of 1. INTRODUCTION the OpenSSL code we apply the performance-degradation One of the contributing factors to the explosion of the technique of Allan et al. [4]. This technique slows the expo- Internet in the last decade is the security provided by the nentiation by an average factor of 20, giving a high resolution underlying cryptographic protocols. Two of those protocols trace and allowing us to extract up to 8 bits of information are the Transport Layer Security (TLS) protocol, which pro- from some of the traces. vides security to network communication and the more spe- Similar to previous works [9, 14, 21, 32], we perform a cialized Secure Shell (SSH), which provides secure login to lattice attack to recover the secret key. We use the lattice remote hosts. construction of Benger et al. [9] and solve the resulting lat- Software implementations of these protocols often use the tice problem using the lattice reduction technique of Nguyen cryptographic primitives' implementations of the OpenSSL and Shparlinski [28]. cryptographic library. Consequently, the security of these A unique feature of our work is that we target common implementations depends on the security of OpenSSL. cryptographic protocols. Previous works that demonstrate In this paper we present a novel side-channel cache-timing cache-timing key-recovery attacks only target the crypto- attack against OpenSSL's DSA implementation. The attack graphic primitives, ignoring potential cache noise from the exploits a vulnerability in OpenSSL, which fails to use a side- protocol implementation. In contrast, we present end-to- channel-secure implementation of modular exponentiation end attacks on two common cryptographic protocols: SSH | the core mathematical operation used in DSA signatures. and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the Permission to make digital or hard copies of part or all of this work for personal or cache activity of the whole protocol suite. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation Our contributions in this work are the following: on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). • We identify a security weakness in OpenSSL which CCS’16 October 24-28, 2016, Vienna, Austria fails to use a side-channel safe implementation when c 2016 Copyright held by the owner/author(s). performing DSA signatures. (Section 3) ACM ISBN 978-1-4503-4139-4/16/10. DOI: http://dx.doi.org/10.1145/2976749.2978420 • We describe how to use a combination of the Flush+ Reload technique with a performance-degradation at- cache levels above them. In the case of Intel processors, tack to leak information from the unsafe SWE algo- the contents of the L1 and L2 caches is also stored in the rithm. (Section 4) last-level cache. A consequence of the inclusion property is that when data is evicted from the last-level cache it is also • We present the first key-recovery cache-timing attack evicted from all of the other levels of cache in the processor. on the TLS and SSH cryptographic protocols. (Sec- Intel architecture implements several cache optimizations. tion 5) The spatial pre-fetcher pairs cache lines and attempt to fetch the pair of a missed line [17]. Consecutive accesses to mem- • We construct and solve a lattice problem with the side- ory addresses are detected and pre-fetched when the pro- channel information and the digital signatures in order cessor anticipates they may be required [17]. Additionally, to recover the secret key. (Section 6) when the processor is presented with a conditional branch, speculative execution brings the data of both branches into 2. BACKGROUND the cache before the branch condition is evaluated [35]. Page [30] noted that tracing the sequence of cache hits 2.1 Memory Hierarchy and misses of software may leak information on the internal working of the software, including information that may lead Accessing data and instructions from main memory is a to recovering cryptographic keys. time consuming operation which delays the work of the fast This idea was later extended and used for mounting sev- processors, for that reason the memory hierarchy includes eral cache-based side-channel attacks [10, 29, 31]. Other smaller and faster memories called caches. Caches improve attacks were shown against the L1-instruction cache [3], the the performance by exploiting the spatial and temporal lo- branch prediction buffer [1,2] and the last-level cache [20, cality of the memory access. 22, 25, 40]. In modern processors the hierarchy of caches is structured as follows, higher-level caches, located closer to the processor 2.2 The Flush+Reload Attack core, are smaller and faster than low-level caches, which are Our LLC-based attack is based on the [20, located closer to main memory. Recent Intel architecture Flush+Reload 40] attack, which is a cache-based side-channel attack tech- typically has three levels of cache: L1, L2 and Last-Level nique. Cache (LLC). Unlike the earlier technique [29, 31] that Each core has two L1 caches, a data cache and an instruc- Prime+Probe detects activity in cache sets, the technique tion cache, each 32 KiB in size with an access time of 4 Flush+Reload identifies access to memory lines, giving it a higher resolu- cycles. L2 caches are also core-private and have an inter- tion, a high accuracy and high signal-to-noise ratio. mediate size (256 KiB) and latency (7 cycles). The LLC is Like , relies on cache shar- shared among all of the cores and is a unified cache, con- Prime+Probe Flush+Reload ing between processes. Additionally, it requires data shar- taining both data and instructions. Typical LLC sizes are ing, which is typically achieved through the use of shared in megabytes and access time is in the order of 40 cycles. libraries or using page de-duplication [6, 36]. The unit of memory and allocation in a cache is called A round of the attack, which identifies victim access to cache line. Cache lines are of a fixed size B, which is typ- a shared memory line, consists of three phases. (See Algo- ically 64 bytes. The lg(B) low-order bits of the address, rithm 1.) In the first phase the adversary evicts the mon- called line offset, are used to locate the datum in the cache itored memory line from the cache. In the second phase, line. the adversary waits a period of time so the victim has an When a memory address is accessed, the processor checks opportunity to access the memory line. In the third phase, the availability of the address line in the top-level L1 cache. the adversary measures the time it takes to reload the mem- If the data is there then it is served to the processor, a ory line. If during the second phase the victim accesses the situation referred to as a cache hit. In a cache miss, when memory line, the line will be available in the cache and the the data is not found in the L1 cache, the processor repeats reload operation in the third phase will take a short time.
Recommended publications
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

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

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

    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
  • A Technical Comparison of Ipsec and SSL

    A Technical Comparison of Ipsec and SSL

    A Technical Comparison of IPSec and SSL y Ab delNasir Alshamsi Takamichi Saito Tokyo University of Technology Abstract p osed but the most famous secure and widely de ployed are IPSec IP Security and SSL Secure So cket Layer IPSec IP Security and SSL SecureSocket Layer In this pap er we will provide a technical comparison have been the most robust and most potential tools of IPSec and SSL the similarities and the dierences available for securing communications over the Inter of the cryptographic prop erties The results of per net Both IPSec and SSL have advantages and short formance are based on comparing FreeSWAN as comings Yet no paper has been found comparing the IPSec and Stunnel as SSL two protocols in terms of characteristic and functional ity Our objective is to present an analysis of security and performancepr operties for IPSec and SSL IPSec IPSec is an IP layer proto col that enables the Intro duction sending and receiving of cryptographically protected packets of any kind TCPUDPICMPetc without any provides two kinds of crypto mo dication IPSec Securing data over the network is hard and compli graphic services Based on necessity IPSec can provide cated issue while the threat of data mo dication and condentiality and authenticity or it can provide data interruption is rising The goal of network security authenticity only is to provide condentiality integrity and authenticity Condentiality is keeping the data secret from the ESP Encapsulated SecurityPayload unintended listeners on the network Integrity is en suring
  • Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D

    Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D

    Main Points • Applying last week’s lectures in practice • Creating Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D. Joseph – VPN: Virtual Private Network September 26, 2005 September 26, 2005 CS161 Fall 2005 2 Joseph/Tygar/Vazirani/Wagner What is a Secure Channel? Plaintext Plaintext Creating Secure Channels Encryption / Internet Encryption / • Authentication and Data Integrity Decryption Decryption Ciphertext and MAC – Use Public Key Infrastructure or third-party server to authenticate each end to the other • A stream with these security requirements: – Add Message Authentication Code for – Authentication integrity • Ensures sender and receiver are who they claim to be – Confidentiality • Confidentiality • Ensures that data is read only by authorized users – Data integrity – Exchange session key for encrypt/decrypt ops • Ensures that data is not changed from source to destination • Bulk data transfer – Non-repudiation (not discussed today) • Ensures that sender can’t deny message and rcvr can’t deny msg • Key Distribution and Segmentation September 26, 2005 CS161 Fall 2005 3 September 26, 2005 CS161 Fall 2005 4 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Symmetric Key-based Symmetric Key-based Secure Channel Secure Channel Alice Bob • Sender (A) and receiver (B) share secret keys KABencrypt KABencrypt – One key for A è B confidentiality KABauth KABauth – One for A è B authentication/integrity Message MAC Compare? Message – Each message
  • Plaintext-Recovery Attacks Against Datagram TLS

    Plaintext-Recovery Attacks Against Datagram TLS

    Plaintext-Recovery Attacks Against Datagram TLS Nadhem J. AlFardan and Kenneth G. Paterson∗ Information Security Group Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK fNadhem.Alfardan.2009, [email protected] Abstract GnuTLS2. Both of these provide source toolkits that imple- ment TLS and DTLS as well as being general purpose cryp- The Datagram Transport Layer Security (DTLS) proto- tographic libraries that software developers can use. The col provides confidentiality and integrity of data exchanged first release of OpenSSL to implement DTLS was 0.9.8. between a client and a server. We describe an efficient and Since its release, DTLS has become a mainstream proto- full plaintext recovery attack against the OpenSSL imple- col in OpenSSL. There are also a number of commercial mentation of DTLS, and a partial plaintext recovery attack products that have taken advantage of DTLS. For example, against the GnuTLS implementation of DTLS. The attack DTLS is used to secure Virtual Private Networks (VPNs)3;4 against the OpenSSL implementation is a variant of Vaude- and wireless traffic5. Platforms such as Microsoft Windows, nay’s padding oracle attack and exploits small timing differ- Microsoft .NET and Linux can also make use of DTLS6. ences arising during the cryptographic processing of DTLS In addition, the number of RFC documents that are be- packets. It would have been prevented if the OpenSSL im- ing published on DTLS is increasing. Recent examples in- plementation had been in accordance with the DTLS RFC. clude RFC 5415 [1], RFC 5953 [8] and RFC 6012 [13]. A In contrast, the GnuTLS implementation does follow the new version of DTLS is currently under development in the DTLS RFC closely, but is still vulnerable to attack.
  • Prying Open Pandora's Box: KCI Attacks Against

    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.
  • Plaintext-Recovery Attacks Against Datagram TLS

    Plaintext-Recovery Attacks Against Datagram TLS

    Plaintext-Recovery Attacks Against Datagram TLS Nadhem J. AlFardan and Kenneth G. Paterson∗ Information Security Group Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK nadhem.alfardan.2009, kenny.paterson @rhul.ac.uk { } Abstract GnuTLS2. Both of these provide source toolkits that imple- ment TLS and DTLS as well as being general purpose cryp- The Datagram Transport Layer Security (DTLS) proto- tographic libraries that software developers can use. The col provides confidentiality and integrity of data exchanged first release of OpenSSL to implement DTLS was 0.9.8. between a client and a server. We describe an efficient and Since its release, DTLS has become a mainstream proto- full plaintext recovery attack against the OpenSSL imple- col in OpenSSL. There are also a number of commercial mentation of DTLS, and a partial plaintext recovery attack products that have taken advantage of DTLS. For example, against the GnuTLS implementation of DTLS. The attack DTLS is used to secure Virtual Private Networks (VPNs)3,4 against the OpenSSL implementation is a variant of Vaude- and wireless traffic5. Platforms such as Microsoft Windows, nay’s padding oracle attack and exploits small timing differ- Microsoft .NET and Linux can also make use of DTLS6. ences arising during the cryptographic processing of DTLS In addition, the number of RFC documents that are be- packets. It would have been prevented if the OpenSSL im- ing published on DTLS is increasing. Recent examples in- plementation had been in accordance with the DTLS RFC. clude RFC 5415 [1], RFC 5953 [8] and RFC 6012 [13]. A In contrast, the GnuTLS implementation does follow the new version of DTLS is currently under development in the DTLS RFC closely, but is still vulnerable to attack.
  • Download CVS 1.11.1P1-3 From: Ftp://Ftp.Software.Ibm.Com/Aix/Freesoftware/Aixtoolbox/RPMS/Ppc/Cvs/ Cvs-1.11.1P1-3.Aix4.3.Ppc.Rpm

    Download CVS 1.11.1P1-3 From: Ftp://Ftp.Software.Ibm.Com/Aix/Freesoftware/Aixtoolbox/RPMS/Ppc/Cvs/ Cvs-1.11.1P1-3.Aix4.3.Ppc.Rpm

    2003 CERT Advisories CERT Division [DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution. http://www.sei.cmu.edu REV-03.18.2016.0 Copyright 2017 Carnegie Mellon University. All Rights Reserved. This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The view, opinions, and/or findings contained in this material are those of the author(s) and should not be con- strued as an official Government position, policy, or decision, unless designated by other documentation. References herein to any specific commercial product, process, or service by trade name, trade mark, manu- facturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Carnegie Mellon University or its Software Engineering Institute. This report was prepared for the SEI Administrative Agent AFLCMC/AZS 5 Eglin Street Hanscom AFB, MA 01731-2100 NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [DISTRIBUTION STATEMENT A] This material has been approved for public release and unlimited distribu- tion. Please see Copyright notice for non-US Government use and distribution.
  • Applications of Quantum Key Distribution to Security Protocols

    Applications of Quantum Key Distribution to Security Protocols

    POLITECNICO DI TORINO Master degree course in Computer Engineering Master degree thesis Applications of Quantum Key Distribution to security protocols Supervisors prof. Antonio Lioy dott. Ignazio Pedone Candidate Orazio Lucio Terranova July 2021 A Martina Alla mia famiglia Agli amici vicini e lontani Contents 1 Introduction 7 2 Quantum computing and QKD 9 2.1 Quantum computing threat...............................9 2.2 Quantum information..................................9 2.3 Quantum computing use cases............................. 10 2.4 Quantum and post-quantum cryptography....................... 11 2.4.1 Post-quantum cryptography........................... 11 2.4.2 Quantum cryptography............................. 12 2.5 QKD theoretical and implementation security..................... 13 2.5.1 Attacks exploiting QKD implementation vulnerabilities........... 14 2.6 QKD use cases...................................... 15 3 IKE Protocol 17 3.1 Introduction........................................ 17 3.2 Protocol overview..................................... 17 3.2.1 IKE SA INIT................................... 18 3.2.2 IKE AUTH.................................... 22 3.2.3 CREATE CHILD SA.............................. 25 3.2.4 INFORMATIONAL............................... 25 3.3 Protocol variations.................................... 28 3.3.1 EAP within IKE................................. 28 3.3.2 NAT Traversal.................................. 28 3.3.3 Error handling.................................. 28 3.4 Usage scenarios.....................................
  • How to Get SSL Into Apache?

    How to Get SSL Into Apache?

    How to get SSL into Apache? Tutorial at Open Source Convent 99/08/22 Holger Reif What is SSL? • SSL = Secure Socket Layer • Socket == concept of Unix network API • Means for securing The Web? • Means for securing _any_ connection oriented communication • Most often used to secure HTTP (transport protocol for the web) • Other Protocols use SSL as well (NNTP, POP3, IMAP, ...) Open Source Software Convention Tutorial How to get SSL into Apache? Holger Reif <[email protected]> 2/80 Properties • authenticates server • optionally authenticate client • protect confidentiality (privacy) • protect integrity (reliability) • end-2-end security for communication Open Source Software Convention Tutorial How to get SSL into Apache? Holger Reif <[email protected]> 3/80 Typical Applications that use SSL • e-commerce - ordering ⇒ protect form input sent to server ⇒ sensitive personal data? • payment ⇒ protect credit card information ⇒ SET is different • secure web-based intranet access ⇒ secure transmission of confidential content Open Source Software Convention Tutorial How to get SSL into Apache? Holger Reif <[email protected]> 4/80 What can SSL do for you? • protect data transmitted to and from your server • reduce some spoofing attacks • provide reliable authentication • show your security and privacy awareness Open Source Software Convention Tutorial How to get SSL into Apache? Holger Reif <[email protected]> 5/80 What can SSL not do for you? • protect your server from being hacked • protect data on your server from being stolen • provide non-repudiation
  • Administrator Guide

    Administrator Guide

    PRODUCT DOCUMENTATION Pivotal™ Greenplum Database® Version 4.3 Administrator Guide Rev: A31 © 2017 Pivotal Software, Inc. Copyright Administrator Guide Notice Copyright Privacy Policy | Terms of Use Copyright © 2017 Pivotal Software, Inc. All rights reserved. Pivotal Software, Inc. believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." PIVOTAL SOFTWARE, INC. ("Pivotal") MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any Pivotal software described in this publication requires an applicable software license. All trademarks used herein are the property of Pivotal or their respective owners. Revised August 2017 (4.3.16.1) 2 Contents Administrator Guide Contents Preface: About This Guide......................................................................... x About the Greenplum Database Documentation Set......................................................................... xi Document Conventions......................................................................................................................xii Text Conventions.................................................................................................................... xii Command Syntax Conventions..............................................................................................xiii