DOCSLIB.ORG

Practical Implementations of Quantum-Resistant Cryptography

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Practical Implementations of Quantum-Resistant Cryptography Practical Implementations of Quantum-Resistant Cryptography Jes´usAntonio Soto Vel´azquez December 18, 2017 Contents 1 Introduction 2 2 Quantum-Safe Hybrid Key Exchange for TLS version 1.3 2 2.1 Idea . .3 2.2 Modified TLS steps . .4 2.3 Recommendations on the algorithms . .5 2.4 On the security aspect . .5 3 Incorporation of Quantum-safe Algorithms into OpenSSL 5 3.1 Quantum-safe Key Exchange Mechanism . .6 3.2 Open Quantum Safe (OQS) and liboqs . .6 3.3 Quantum-Safe KEM in OpenSSL . .8 3.3.1 Stebila's OpenSSL Fork with RLWE . .8 3.3.2 Singh's OpenSSL Fork with RLWE . .9 3.3.3 Open Quantum Safe's OpenSSL Fork . .9 3.4 Quantum-safe Authentication . 11 3.5 Alternative implementations of TLS . 11 3.5.1 wolfSSL . 11 3.5.2 BoringSSL . 12 3.5.3 PolarSSL . 13 3.6 On the difficulty of extending OpenSSL . 14 4 Hybrid public keys and signatures in X.509 15 4.1 Proof of concept . 16 5 Conclusion 18 1 1 Introduction The confidentiality and authenticity of today's communication in the Internet heavily depend on the use of cryptographic primitives and protocols. These cryptographic primitives usually rely on the difficulty of solving a certain problem, e.g., prime factorization and discrete logarithm. These problems should be easy to solve for the intended participants who hold the secret pieces of information, but hard to solve for those who only hold the public pieces of information for a particular instance of these problems. Due to Shor's algorithm, which operates under a quantum computer, the discrete logarithm and prime factorization problems are solvable easily. This means that algorithms such as RSA, Diffie-Hellman Exchange (DHE), Digital Signature Algorithm (DSA), and the elliptic curve variations (ECDHE and ECDSA) can be broken by a quantum computer of enough capacity. It has been predicted that quantum computers [2] will finally be built within a decade. Thus, this calls for the need of employing a new set of algorithms that rely on hard problems that quantum computers cannot break. Such algorithms may be based on hash functions, error correcting codes, lattices (including learning with errors), multivariate equations, and supersingular elliptic curve isogenies. These algorithms already exist, and have been studied in the theoretical setting for long. As we know it is inevitable that quantum computers will eventually be built, it is relevant to consider how to move away from the vulnerable algorithms, and slowly adopt these newer, quantum-resistant1 al- gorithms. This report covers three main topics: adoption of quantum-resistant al- gorithms in the TLS 1.3 protocol, incorporation of quantum-resistant algo- rithms into the OpenSSL library, and the proposal to include multiple public keys and signatures in the X.509 certificate. 2 Quantum-Safe Hybrid Key Exchange for TLS version 1.3 The Transport Layer Security (TLS) protocol is widely used to ensure se- curity among two parties communicating over the Internet. The underlying algorithms in TLS are approved by governments [8] and organizations, e.g.: NIST SP800-131a, NSA Suite B, ISO standards, etc., and thus, are difficult 1the words quantum-resistant, quantum-safe, and post-quantum are used interchange- ably, and refer to the same security property. 2 to change. As mentioned earlier, these algorithms (ECDHE, DHE, ECDSA, RSA) are easily broken by quantum computers. Alternatives to these algo- rithms do exist, and some of them have shown similar performance results in comparison to the ones adopted in TLS. However, governments have not updated their list of approved algorithms to include these as standards. As November 2017, there is an ongoing effort organized by NIST to find a suite of post-quantum algorithms [12]. To gain some insight as how communications will be affected in the fu- ture, the idea is to incorporate these quantum-resistant algorithms into the TLS protocol. This protocol is compliant to various security requirements, and is also widely used, making it a good candidate for experimentation. Having said that, there is no guarantee that a new attack against these algo- rithms won't be discovered in the future. Therefore, even if solid alternative algorithms like NTRU and McBits could already be put into TLS, it would be desirable to keep the protocol algorithm-agnostic. In the event that one of these algorithms is broken, it would be easy to replace it with another one. Members of the IETF have proposed a mechanism [22] to incorporate quantum-safe algorithms within the protocol, while ensuring compatibility with the systems in use today. 2.1 Idea The idea behind the proposal is to encapsulate the classic key exchange that takes place in TLS, and in parallel perform another key exchange which relies on a quantum-resistant algorithm. The resulting shared key of this process will be secure in both the classical and quantum settings. This term for this mechanism is coined as Quantum-Safe Hybrid Key Exchange (QSH Key Exchange). The TLS protocol has undergone many changes between versions 1.1, 1.2, and 1.3. Particularly, in the handshake phase of TLS 1.3, Diffie-Hellman Ex- change and ECDHE groups are negotiated between the client and the server. In previous versions, a cipher suite was negotiated between peers. However, negotiating groups can also be useful for the QSH key exchange, because including quantum-safe algorithms would be very similar to having more groups for DHE and ECDHE. Thus, the overall structure of the handshake would remain unchanged, except that now it would include a description of the encoding used to hold the information regarding the new algorithms. Additionally, it is desirable to follow an hybrid approach, so that instances of a TLS protocol would use both the classical and quantum-safe algorithms to generate their respective secrets in parallel. Thus, it was proposed to include a combination of a \classical" key exchange and a \quantum-safe" 3 key exchange for the the handshake part of the protocol. This is called a hybrid key exchange, and it uses multiple key exchange methods in parallel. As an example, consider the hybrid key exchange \Curve25519+NTRU" proposed by the client to the server. The server would need to accept both key exchanges, not only one of them. It would be problematic if the client could only propose one hybrid group. Thus, the proposal allows for more than one combination, specifically up to 10, so that other ECDHE groups and other quantum-safe algorithms can be considered as alternatives. As more combinations are supported by a server, the more likely it is that a client will recognize at least one of the combinations, letting the TLS pro- tocol proceed as usual. After choosing the combinations of key-exchange mechanisms to use, their outputs can be combined through a Key Derivation Function (KDF) to obtain a secret key shared by both parties. This implies that as long as one of the negotiated key exchanges is secure, the negotiated keys will remain secure. 2.2 Modified TLS steps In very broad terms, the changes to the protocol can be observed in three steps: initial handshake, creation of pre-master secret, and derivation of secret keys. This procedure is described as follows: Initial Handshake Client initiates the protocol by sending to server a list of supported groups (for DHE and ECDHE), key shares2, other key exchanges, and hybrid groups (combination of multiple key exchanges). Server selects one of the combinations proposed by the client, and sends back the reply. Pre-master secret Client and Server proceed to generate the shared secret as it is done in TLS 1.3, except that this is done for each of the groups proposed during the handshake, in parallel. Secret keys Client and server concatenate the shared secrets obtained in the previous step, and the result is used to derivate the secret key according to TLS 1.3. There are some structural changes that should be done to the data sent during the ClientHello and ServerHello, so that it captures the possibility of having one or more hybrid key exchanges. Additionally, a hybrid extension is proposed, so that when the client lists hybrid name groups, it also includes 2share material for key derivation 4 the hybrid extension which defines which \atomic" groups form the hybrid group. Apart from this, these changes are intended to be minimal to the TLS 1.3 protocol. 2.3 Recommendations on the algorithms The proposal makes mention of an initial recommendation made in [14] re- garding which quantum-safe algorithms are deemed good enough to with- stand attacks by quantum computers. Particularly, to obtain roughly a 2128 bit post-quantum level of security, the authors recommend the following vari- ations of some of the well-known quantum-safe algorithms, and also include some parameter recommendations: McEliece with binary Goppa codes With parameters at least: length n = 6960, dimension k = 5413, and adding t = 119 errors. McEliece with Quasi-cyclic MDPC codes With parameters at least: Length n = 216 + 6, dimension k = 215 + 3, d = 274, and adding t = 264 errors. NTRU, Stehl´e-Steinfeldversion No particular parameters were recom- mended. This proposal is quite outdated, and more recommendations may be made in the future by NIST, after the process to evaluate and standarize quantum- resistant algorithms is finished. 2.4 On the security aspect In reality, the QSH Key Exchange is secure only against passive attacks. It additionally offers forward security [23], in the sense that if the communi- cation is recorded and stored, it would not be decrypted by the quantum- computers built in the future.
Load more

Recommended publications
  • Lectures on the NTRU Encryption Algorithm and Digital Signature Scheme: Grenoble, June 2002
    Lectures on the NTRU encryption algorithm and digital signature scheme: Grenoble, June 2002 J. Pipher Brown University, Providence RI 02912 1 Lecture 1 1.1 Integer lattices Lattices have been studied by cryptographers for quite some time, in both the field of cryptanalysis (see for example [16{18]) and as a source of hard problems on which to build encryption schemes (see [1, 8, 9]). In this lecture, we describe the NTRU encryption algorithm, and the lattice problems on which this is based. We begin with some definitions and a brief overview of lattices. If a ; a ; :::; a are n independent vectors in Rm, n m, then the 1 2 n ≤ integer lattice with these vectors as basis is the set = n x a : x L f 1 i i i 2 Z . A lattice is often represented as matrix A whose rows are the basis g P vectors a1; :::; an. The elements of the lattice are simply the vectors of the form vT A, which denotes the usual matrix multiplication. We will specialize for now to the situation when the rank of the lattice and the dimension are the same (n = m). The determinant of a lattice det( ) is the volume of the fundamen- L tal parallelepiped spanned by the basis vectors. By the Gram-Schmidt process, one can obtain a basis for the vector space generated by , and L the det( ) will just be the product of these orthogonal vectors. Note that L these vectors are not a basis for as a lattice, since will not usually L L possess an orthogonal basis.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • NTRU Cryptosystem: Recent Developments and Emerging Mathematical Problems in Finite Polynomial Rings
    XXXX, 1–33 © De Gruyter YYYY NTRU Cryptosystem: Recent Developments and Emerging Mathematical Problems in Finite Polynomial Rings Ron Steinfeld Abstract. The NTRU public-key cryptosystem, proposed in 1996 by Hoffstein, Pipher and Silverman, is a fast and practical alternative to classical schemes based on factorization or discrete logarithms. In contrast to the latter schemes, it offers quasi-optimal asymptotic effi- ciency and conjectured security against quantum computing attacks. The scheme is defined over finite polynomial rings, and its security analysis involves the study of natural statistical and computational problems defined over these rings. We survey several recent developments in both the security analysis and in the applica- tions of NTRU and its variants, within the broader field of lattice-based cryptography. These developments include a provable relation between the security of NTRU and the computa- tional hardness of worst-case instances of certain lattice problems, and the construction of fully homomorphic and multilinear cryptographic algorithms. In the process, we identify the underlying statistical and computational problems in finite rings. Keywords. NTRU Cryptosystem, lattice-based cryptography, fully homomorphic encryption, multilinear maps. AMS classification. 68Q17, 68Q87, 68Q12, 11T55, 11T71, 11T22. 1 Introduction The NTRU public-key cryptosystem has attracted much attention by the cryptographic community since its introduction in 1996 by Hoffstein, Pipher and Silverman [32, 33]. Unlike more classical public-key cryptosystems based on the hardness of integer factorisation or the discrete logarithm over finite fields and elliptic curves, NTRU is based on the hardness of finding ‘small’ solutions to systems of linear equations over polynomial rings, and as a consequence is closely related to geometric problems on certain classes of high-dimensional Euclidean lattices.
    [Show full text]
  • Performance Evaluation of RSA and NTRU Over GPU with Maxwell and Pascal Architecture
    Performance Evaluation of RSA and NTRU over GPU with Maxwell and Pascal Architecture Xian-Fu Wong1, Bok-Min Goi1, Wai-Kong Lee2, and Raphael C.-W. Phan3 1Lee Kong Chian Faculty of and Engineering and Science, Universiti Tunku Abdul Rahman, Sungai Long, Malaysia 2Faculty of Information and Communication Technology, Universiti Tunku Abdul Rahman, Kampar, Malaysia 3Faculty of Engineering, Multimedia University, Cyberjaya, Malaysia E-mail: [email protected]; {goibm; wklee}@utar.edu.my; [email protected] Received 2 September 2017; Accepted 22 October 2017; Publication 20 November 2017 Abstract Public key cryptography important in protecting the key exchange between two parties for secure mobile and wireless communication. RSA is one of the most widely used public key cryptographic algorithms, but the Modular exponentiation involved in RSA is very time-consuming when the bit-size is large, usually in the range of 1024-bit to 4096-bit. The speed performance of RSA comes to concerns when thousands or millions of authentication requests are needed to handle by the server at a time, through a massive number of connected mobile and wireless devices. On the other hand, NTRU is another public key cryptographic algorithm that becomes popular recently due to the ability to resist attack from quantum computer. In this paper, we exploit the massively parallel architecture in GPU to perform RSA and NTRU computations. Various optimization techniques were proposed in this paper to achieve higher throughput in RSA and NTRU computation in two GPU platforms. To allow a fair comparison with existing RSA implementation techniques, we proposed to evaluate the speed performance in the best case Journal of Software Networking, 201–220.
    [Show full text]
  • Fast Elliptic Curve Cryptography in Openssl
    Fast Elliptic Curve Cryptography in OpenSSL Emilia K¨asper1;2 1 Google 2 Katholieke Universiteit Leuven, ESAT/COSIC [email protected] Abstract. We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224. Our implementation is fully integrated into OpenSSL 1.0.1: full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key ex- change over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster. In ad- dition, our implementation is immune to timing attacks|most notably, we show how to do small table look-ups in a cache-timing resistant way, allowing us to use precomputation. To put our results in context, we also discuss the various security-performance trade-offs available to TLS applications. Keywords: elliptic curve cryptography, OpenSSL, side-channel attacks, fast implementations 1 Introduction 1.1 Introduction to TLS Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL), is a protocol for securing network communications. In its most common use, it is the \S" (standing for \Secure") in HTTPS. Two of the most popular open- source cryptographic libraries implementing SSL and TLS are OpenSSL [19] and Mozilla Network Security Services (NSS) [17]: OpenSSL is found in, e.g., the Apache-SSL secure web server, while NSS is used by Mozilla Firefox and Chrome web browsers, amongst others. TLS provides authentication between connecting parties, as well as encryp- tion of all transmitted content. Thus, before any application data is transmit- ted, peers perform authentication and key exchange in a TLS handshake.
    [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]
  • Making NTRU As Secure As Worst-Case Problems Over Ideal Lattices
    Making NTRU as Secure as Worst-Case Problems over Ideal Lattices Damien Stehlé1 and Ron Steinfeld2 1 CNRS, Laboratoire LIP (U. Lyon, CNRS, ENS Lyon, INRIA, UCBL), 46 Allée d’Italie, 69364 Lyon Cedex 07, France. [email protected] – http://perso.ens-lyon.fr/damien.stehle 2 Centre for Advanced Computing - Algorithms and Cryptography, Department of Computing, Macquarie University, NSW 2109, Australia [email protected] – http://web.science.mq.edu.au/~rons Abstract. NTRUEncrypt, proposed in 1996 by Hoffstein, Pipher and Sil- verman, is the fastest known lattice-based encryption scheme. Its mod- erate key-sizes, excellent asymptotic performance and conjectured resis- tance to quantum computers could make it a desirable alternative to fac- torisation and discrete-log based encryption schemes. However, since its introduction, doubts have regularly arisen on its security. In the present work, we show how to modify NTRUEncrypt to make it provably secure in the standard model, under the assumed quantum hardness of standard worst-case lattice problems, restricted to a family of lattices related to some cyclotomic fields. Our main contribution is to show that if the se- cret key polynomials are selected by rejection from discrete Gaussians, then the public key, which is their ratio, is statistically indistinguishable from uniform over its domain. The security then follows from the already proven hardness of the R-LWE problem. Keywords. Lattice-based cryptography, NTRU, provable security. 1 Introduction NTRUEncrypt, devised by Hoffstein, Pipher and Silverman, was first presented at the Crypto’96 rump session [14]. Although its description relies on arithmetic n over the polynomial ring Zq[x]=(x − 1) for n prime and q a small integer, it was quickly observed that breaking it could be expressed as a problem over Euclidean lattices [6].
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • No.Ntnu:Inspera:2546742.Pdf (10.61Mb)
    Krishna Shingala An alternative to the Public Key Krishna Shingala Infrastructure for the Internet of Things Master’s thesis in Communication Technology Supervisor: Danilo Gligoroski, Katina Kralevska, Torstein Heggebø Master’s thesis Master’s June 2019 An alternative to PKI for IoT PKI for to An alternative NTNU Engineering Communication Technology Communication Department of Information Security and Department of Information Faculty of Information Technology and Electrical Technology of Information Faculty Norwegian University of Science and Technology of Science University Norwegian An alternative to the Public Key Infras- tructure for the Internet of Things Krishna Shingala Submission date: June 2019 Responsible professor: Danilo Gligoroski, IIK, NTNU Supervisor: Danilo Gligoroski, IIK, NTNU Co-Supervisor: Katina Kralevska, IIK, NTNU Co-Supervisor: Torstein Heggebø, Nordic Semiconductor ASA Norwegian University of Science and Technology Department of Information Technology and Electrical Engineering Title: An alternative to the Public Key Infrastructure for the Internet of Things Student: Krishna Shingala Problem description: Internet of Things(IoT) enables participation of constrained devices on the Internet. Limited resources, bandwidth, and power on the devices have led to new protocols. Some examples of IoT driven and driving protocols are: – MQTT, CoAP that are application protocols for IoT; – 6LoWPAN enables efficient support of IPv6 on low power lossy networks; – CBOR enables concise data formatting; and – DTLS enables secure channel establishment over unreliable transport like the UDP. Security is one of the key factors for the success of IoT. TLS/DTLS secures the channel between the servers and the devices. Confidentiality is an important aspect of such a secure channel. Establishing the identity of an entity another.
    [Show full text]
  • Optimizing NTRU Using AVX2
    Master Thesis Computing Science Cyber Security Specialisation Radboud University Optimizing NTRU using AVX2 Author: First supervisor/assessor: Oussama Danba dr. Peter Schwabe Second assessor: dr. Lejla Batina July, 2019 Abstract The existence of Shor's algorithm, Grover's algorithm, and others that rely on the computational possibilities of quantum computers raise problems for some computational problems modern cryptography relies on. These algo- rithms do not yet have practical implications but it is believed that they will in the near future. In response to this, NIST is attempting to standardize post-quantum cryptography algorithms. In this thesis we will look at the NTRU submission in detail and optimize it for performance using AVX2. This implementation takes about 29 microseconds to generate a keypair, about 7.4 microseconds for key encapsulation, and about 6.8 microseconds for key decapsulation. These results are achieved on a reasonably recent notebook processor showing that NTRU is fast and feasible in practice. Contents 1 Introduction3 2 Cryptographic background and related work5 2.1 Symmetric-key cryptography..................5 2.2 Public-key cryptography.....................6 2.2.1 Digital signatures.....................7 2.2.2 Key encapsulation mechanisms.............8 2.3 One-way functions........................9 2.3.1 Cryptographic hash functions..............9 2.4 Proving security......................... 10 2.5 Post-quantum cryptography................... 12 2.6 Lattice-based cryptography................... 15 2.7 Side-channel resistance...................... 16 2.8 Related work........................... 17 3 Overview of NTRU 19 3.1 Important NTRU operations................... 20 3.1.1 Sampling......................... 20 3.1.2 Polynomial addition................... 22 3.1.3 Polynomial reduction.................. 22 3.1.4 Polynomial multiplication...............
    [Show full text]
  • Dynamic Public Key Certificates with Forward Secrecy
    electronics Article Dynamic Public Key Certificates with Forward Secrecy Hung-Yu Chien Department of Information Management, National Chi Nan University, Nantou 54561, Taiwan; [email protected] Abstract: Conventionally, public key certificates bind one subject with one static public key so that the subject can facilitate the services of the public key infrastructure (PKI). In PKI, certificates need to be renewed (or revoked) for several practical reasons, including certificate expiration, private key breaches, condition changes, and possible risk reduction. The certificate renewal process is very costly, especially for those environments where online authorities are not available or the connection is not reliable. A dynamic public key certificate (DPKC) facilitates the dynamic changeover of the current public–private key pairs without renewing the certificate authority (CA). This paper extends the previous study in several aspects: (1) we formally define the DPKC; (2) we formally define the security properties; (3) we propose another implementation of the Krawczyk–Rabin chameleon-hash- based DPKC; (4) we propose two variants of DPKC, using the Ateniese–Medeiros key-exposure-free chameleon hash; (5) we detail two application scenarios. Keywords: dynamic public key certificate; chameleon signature; certificate renewal; wireless sensor networks; perfect forward secrecy 1. Introduction Citation: Chien, H.-Y. Dynamic Certificates act as the critical tokens in conventional PKI systems. With the trust Public Key Certificates with Forward of the CA, a
    [Show full text]
  • SSL Checklist for Pentesters
    SSL Checklist for Pentesters Jerome Smith BSides MCR, 27th June 2014 # whoami whoami jerome • Pentester • Author/trainer – Hands-on technical – Web application, infrastructure, wireless security • Security projects – Log correlation – Dirty data – Incident response exercises • Sysadmin • MSc Computing Science (Dist) • www.exploresecurity.com | @exploresecurity Introduction • Broad review of SSL/TLS checks – Viewpoint of pentester – Pitfalls – Manually replicating what tools do (unless you told the client that SSL Labs would be testing them ) – Issues to consider reporting (but views are my own) • While SSL issues are generally low in priority, it’s nice to get them right! • I’m not a cryptographer: this is all best efforts SSLv2 • Flawed, e.g. no handshake protection → MITM downgrade • Modern browsers do not support SSLv2 anyway – Except for IE but it’s disabled by default from IE7 – That mitigates the risk these days – http://en.wikipedia.org/wiki/Transport_Layer_Security#W eb_browsers • OpenSSL 1.0.0+ doesn’t support it – Which means SSLscan won’t find it – General point: tools that dynamically link to an underlying SSL library in the OS can be limited by what that library supports SSLv2 • Same scan on different OpenSSL versions: SSLv2 • testssl.sh warns you – It can work with any installed OpenSSL version • OpenSSL <1.0.0 s_client -ssl2 switch – More on this later • Recompile OpenSSL – http://blog.opensecurityresearch.com/2013/05/fixing-sslv2-support- in-kali-linux.html • SSLyze 0.7+ is statically linked – Watch out for bug https://github.com/iSECPartners/sslyze/issues/73
    [Show full text]