Public Key Infrastructure (PKI)

Total Page:16

File Type:pdf, Size:1020Kb

Public Key Infrastructure (PKI) Public Key Infrastructure Public Key Infrastructure (PKI) Neil F. Johnson [email protected] http://ise.gmu.edu/~csis Assumptions • Understanding of – Fundamentals of Public Key Cryptosystems – Hash codes for message digests and integrity check – Digital Signatures Copyright 1999, Neil F. Johnson 1 Public Key Infrastructure Overview • Public Key Cryptosystems – Quick review – Cryptography – Digital Signatures – Key Management Issues • Certificates – Certificates Information – Certificate Authority – Track Issuing a Certificate • Putting it all together – PKI applications – Pretty Good Privacy (PGP) – Privacy Enhanced Mail (PEM) Public Key Cryptosystems – Quick Review • Key distribution problem of secret key systems – You must share the secret key with another party before you can initiate communication – If you want to communicate with n parties, you require n different keys • Public Key cryptosystems solve the key distribution problem in secret key systems (provided a reliable channel for communication of public keys can be implemented) • Security is based on the unfeasibility of computing B’s private key given the knowledge of – B’s public key, – chosen plaintext, and – maybe chosen ciphertext Copyright 1999, Neil F. Johnson 2 Public Key Infrastructure Key Distribution (n)(n-1) 2 Bob Bob Alice 1 Alice 2 Chris Chris 7 5 8 9 Ellie 3 Ellie 6 David 4 David Secret Key Distribution Directory of Public Keys (certificates) Public Key Cryptosystem INSECURE CHANNEL Plaintext Ciphertext Plaintext Encryption Decryption Algorithm Algorithm Bob’s PUBLIC Key Bob’s PRIVATE Key Reliable Channel Directory of Public Keys (certificates) Copyright 1999, Neil F. Johnson 3 Public Key Infrastructure Digital Signature INSECURE CHANNEL Plaintext Signed Plaintext Plaintext Sign Verify Algorithm Algorithm Alice’s PRIVATE Key Alice’s PUBLIC Key Reliable Channel Directory of Public Keys (certificate) How a Digital Signature Works SENDER RECIEVER • Calculate the hash of the message • Separate the signed hash and the • Sign the hash with Alice’s private plaintext message key • Calculate a newhash of the • Combine the plaintext message message with the signed hash • Verify the signed hash with Alice’s • Send the combined message to the public key receiver (Bob) • Compare the original hash with the new hash (they should match) Copyright 1999, Neil F. Johnson 4 Public Key Infrastructure Digital Signature and Encryption (sender) Plaintext (M) Plaintext (M) H = Hash(M) Alice’s PRIVATE S = Sign(H) Key SM = Combine S + M Reliable (Signed Plaintext) Channel Secret Key (K) C = Encrypt(SM, K) CE = C+E Public Keys Directory Encrypted Signed Plaintext Bob’s E = Encrypt K PUBLIC Key to Bob Digital Signature and Encryption (receiver) Encrypted Signed Split CE Plaintext (CE) from Alice E = Encrypted(K) C = Encrypted(SM,K) K = Decrypt(E) SM = Decrypt(C,K) Reliable Channel Bob’s PRIVATE Split SM Key S = Signed(H) M = Plaintext Public Keys Directory H = Verify Compute Signature on S H1 = Hash(M) Alice’s PUBLIC Compare H = H1 Key Copyright 1999, Neil F. Johnson 5 Public Key Infrastructure Signature and Encryption (in a nutshell) A B Encrypted Signed Signed Signed Plain- Plaintext Plaintext Plaintext Plain- text text S E D V A’s Private B’s Public B’s Private A’s Public Key Key Key Key Signature and Encryption • We could do the encryption first followed by the signature. Signature first has the advantage that the signature can be verified by parties other than B. • We could use DES, IDEA for encryption Copyright 1999, Neil F. Johnson 6 Public Key Infrastructure Non-repudiation • In general, non-repudiation requires a notarized signature, involving a third party in addition to A and B. • In large systems this can involved hierarchies of notarization (possibly certificate authority) Key Management Issues • Issues: – generating keys – keeping backup keys – dealing with compromised keys – changing keys – destroying expired keys • Problems – establishing and maintaining third-party trust – implementing consistent security policies among users – making cryptography accessible to appropriate parties Copyright 1999, Neil F. Johnson 7 Public Key Infrastructure Pretty Good Privacy (PGP) An Example of a Public Key Application Neil F. Johnson [email protected] http://isse.gmu.edu/~csis/ PGP - Pretty Good Privacy • Phil Zimmerman • Shaky start – RSA patent – US export laws • Worldwide popularity • More than just e-mail Copyright 1999, Neil F. Johnson 8 Public Key Infrastructure PGP’s Success • Freely available worldwide on a variety of platforms. • Based on algorithms that re considered secure and have been under extensive public review (RSA, IDEA, MD5). • Wide range of applications. • PGP is not controlled by any government or standards organization. PGP - What it Uses • Public/Private Key (RSA) • Secret Key (IDEA) • Message Digest/Hash (MD5) • Zip • radix 64 ASCII format Copyright 1999, Neil F. Johnson 9 Public Key Infrastructure PGP – How it Works • Confidentiality • Authentication • Compression • Compatibility measures Confidentially & Authentication • Message Encryption – IDEA - Encrypt message with one-time session key generated by sender – RSA - Session key is encrypted with receiver’s public key, and included with the message • Digital Signature – MD5 - Creates a 128-bit hash code of the message (message digest) – RSA - The message digest is encrypted with the sender’s private key, and included with the message Copyright 1999, Neil F. Johnson 10 Public Key Infrastructure Compression & Compatibility • Compression – ZIP • Messages or files may be compressed for storage or transmission • Compression occurs after signature but before encryption • E-mail Compatibility – Radix-64 • Converts binary encrypted data to ASCII through table lookup • A-Z, a-z, 0-9,+, /, = (padding) Notation Ks = Session key M = Message (plaintext) S = Sender C = Ciphertext R = Receiver Ei = Encryption with IDEA Sk = Sender’s Private Key Di = Decryption with IDEA Sp = Sender’s Public Key Er = Encryption with RSA Rk = Receiver’s Private Key Dr = Decryption with RSA Rp = Receiver’s Public Key H = Hash function (MD5) Z = ZIP compression (optional after authentication) R64 = Radix 64 conversion to ASCII Copyright 1999, Neil F. Johnson 11 Public Key Infrastructure PGP - Authentication • SM = M + Er[H{M},Sk] • Receiver: – ‘Splits’ SM • Er{Dr[H{M},Sk], Sp} = H{M} • creates a ‘new’ H{M} from M – Compares decrypted H{M} with “new” H{M} PGP - Authentication (cont) • Sender – Sender creates a message (M) – MD5 is used to creates a 128-bit message digest of the message (H{M}) – Hash code is encrypted with RSA using the sender’s private key (Dr[H{M}, Sk]) Alice’s PRIVATE Key (Sk) Plaintext (M) H = MD5(M) S = RSA(H,Sk) Combine S and M and send to Bob Copyright 1999, Neil F. Johnson 12 Public Key Infrastructure PGP - Authentication (cont) • Receiver – The receiver uses RSA with the sender’s public key to decrypt and recover the hash code (Dr{Er[H{M}, Sk], Sp} => H{M}). – Receiver generates a new hash code for the message (H{M}). – The decrypted hash code is compared with the generated hash code. SM from Alice Split SM S = RSA(H,Sk) M = Plaintext Reliable H = Verify Compute Channel Alice’s Signature RSA(S,Sp) PUBLIC H1 = MD5(M) Key (Sp) Compare H = H1 Public Keys Directory PGP - Compression • Authentication before compression – preferable to sign an uncompressed message. – Trade-off between speed and compression differs upon the message type. • Encryption after compression – Strengthens cryptographic security by reducing redundancy in the original plaintext. Sign - Compress - Encrypt Copyright 1999, Neil F. Johnson 13 Public Key Infrastructure PGP - Confidentiality • IDEA – uses 128-bit key – 64-bit cipher feedback mode with a random initialization vector (IV). Earlier version of PGP used a null (zero stream) IV. PGP - Confidentiality (cont) • Sender – Sender generates a message and a 128-bit number to be used as a session key for this message only (Ks) – Message is compressed, then encrypted using IDEA with the session key (C = Ei[Z{M}, Ks]) – Session key is encrypted with RSA using receiver’s public key (E = Er{Ks, Rp}) Plaintext (M) Z = Zip(M) Session Key (Ks) C = IDEA(Z, Ks) Bob’s PUBLIC E = RSA(Ks, Rp) Combine C and E and send to Key (Rp) Bob Public Keys Directory Copyright 1999, Neil F. Johnson 14 Public Key Infrastructure PGP - Confidentiality (cont) • Receiver – Receiver’s private key is used with RSA to decrypt and recover the session key (Ks = Dr[RpEr{Ks}, Rk]). – Session key is used to decrypt the message (Z = Di{Ei[Z{M}, Ks], Ks}). – Decompression (M = unZip{Z(M)}) Ciphertext (CE) Split CE from Alice E = RSA(K,Rp) C = IDEA(Z,K) Bob’s K = RSA(E,Rk) Z =IDEA(C,K) PRIVATE Key M = unZip(Z) PGP - Confidentiality (cont.) • May combine authentication and encryption • Multiple RSA key length options are available (from 768 to 4096). Copyright 1999, Neil F. Johnson 15 Public Key Infrastructure PGP - Putting it Together (sender) Plaintext (M) Plaintext (M) H = MD5(M) Alice’s PRIVATE S = RSA(H,Sk) Key SM = Combine S + M (Signed Plaintext) Reliable Z = Zip(SM) Channel Secret Key (K) C = IDEA(Z, K) CE = C+E Public Keys Directory Bob’s Encrypted Signed PUBLIC Key E = RSA(K,Rp) Plaintext to Bob PGP - Putting it Together (receiver) Encrypted Signed Split CE Plaintext (CE) from Alice E = RSA(K,Rp) C = IDEA(Z,K) K = RSA(E,Rk) Z =IDEA(C,K) Bob’s SM = unZip(Z) PRIVATE Key Split SM Reliable Channel S = RSA(H,Sk) M = Plaintext Public Keys Directory H = Verify Compute Signature RSA(S,Sp) H1 = MD5(M) Alice’s PUBLIC Compare H = H1 Key Copyright 1999, Neil F. Johnson 16 Public Key Infrastructure PGP - Key Distribution • Public Key • User-based certification • Key Ring • Session Key – a new, random, 128-bit secret key is generated with each message. This key is encrypted with the receiver’s public key. PGP - Key Rings • Private Key – Timestamp, KeyID, Public Key, E{Private Key}, User ID • Public Key – Timestamp, KeyID, Public Key, Trust_flag, User ID, Key Legitimacy flag, Signature(s), Signature Trust(s) Copyright 1999, Neil F.
Recommended publications
  • Authentication in Key-Exchange: Definitions, Relations and Composition
    Authentication in Key-Exchange: Definitions, Relations and Composition Cyprien Delpech de Saint Guilhem1;2, Marc Fischlin3, and Bogdan Warinschi2 1 imec-COSIC, KU Leuven, Belgium 2 Dept Computer Science, University of Bristol, United Kingdom 3 Computer Science, Technische Universit¨atDarmstadt, Germany [email protected], [email protected], [email protected] Abstract. We present a systematic approach to define and study authentication notions in authenti- cated key-exchange protocols. We propose and use a flexible and expressive predicate-based definitional framework. Our definitions capture key and entity authentication, in both implicit and explicit vari- ants, as well as key and entity confirmation, for authenticated key-exchange protocols. In particular, we capture critical notions in the authentication space such as key-compromise impersonation resis- tance and security against unknown key-share attacks. We first discuss these definitions within the Bellare{Rogaway model and then extend them to Canetti{Krawczyk-style models. We then show two useful applications of our framework. First, we look at the authentication guarantees of three representative protocols to draw several useful lessons for protocol design. The core technical contribution of this paper is then to formally establish that composition of secure implicitly authenti- cated key-exchange with subsequent confirmation protocols yields explicit authentication guarantees. Without a formal separation of implicit and explicit authentication from secrecy, a proof of this folklore result could not have been established. 1 Introduction The commonly expected level of security for authenticated key-exchange (AKE) protocols comprises two aspects. Authentication provides guarantees on the identities of the parties involved in the protocol execution.
    [Show full text]
  • 2.3 Diffie–Hellman Key Exchange
    2.3. Di±e{Hellman key exchange 65 q q q q q q 6 q qq q q q q q q 900 q q q q q q q qq q q q q q q q q q q q q q q q q 800 q q q qq q q q q q q q q q qq q q q q q q q q q q q 700 q q q q q q q q q q q q q q q q q q q q q q q q q q qq q 600 q q q q q q q q q q q q qq q q q q q q q q q q q q q q q q q qq q q q q q q q q 500 q qq q q q q q qq q q q q q qqq q q q q q q q q q q q q q qq q q q 400 q q q q q q q q q q q q q q q q q q q q q q q q q 300 q q q q q q q q q q q q q q q q q q qqqq qqq q q q q q q q q q q q 200 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q qq q q qq q q 100 q q q q q q q q q q q q q q q q q q q q q q q q q 0 q - 0 30 60 90 120 150 180 210 240 270 Figure 2.2: Powers 627i mod 941 for i = 1; 2; 3;::: any group and use the group law instead of multiplication.
    [Show full text]
  • Elliptic Curves in Public Key Cryptography: the Diffie Hellman
    Elliptic Curves in Public Key Cryptography: The Diffie Hellman Key Exchange Protocol and its relationship to the Elliptic Curve Discrete Logarithm Problem Public Key Cryptography Public key cryptography is a modern form of cryptography that allows different parties to exchange information securely over an insecure network, without having first to agree upon some secret key. The main use of public key cryptography is to provide information security in computer science, for example to transfer securely email, credit card details or other secret information between sender and recipient via the internet. There are three steps involved in transferring information securely from person A to person B over an insecure network. These are encryption of the original information, called the plaintext, transfer of the encrypted message, or ciphertext, and decryption of the ciphertext back into plaintext. Since the transfer of the ciphertext is over an insecure network, any spy has access to the ciphertext and thus potentially has access to the original information, provided he is able to decipher the message. Thus, a successful cryptosystem must be able encrypt the original message in such a way that only the intended receiver can decipher the ciphertext. The goal of public key cryptography is to make the problem of deciphering the encrypted message too difficult to do in a reasonable time (by say brute-force) unless certain key facts are known. Ideally, only the intended sender and receiver of a message should know these certain key facts. Any certain piece of information that is essential in order to decrypt a message is known as a key.
    [Show full text]
  • Topic 3: One-Time Pad and Perfect Secrecy
    Cryptography CS 555 Topic 3: One-time Pad and Perfect Secrecy CS555 Spring 2012/Topic 3 1 Outline and Readings • Outline • One-time pad • Perfect secrecy • Limitation of perfect secrecy • Usages of one-time pad • Readings: • Katz and Lindell: Chapter 2 CS555 Spring 2012/Topic 3 2 One-Time Pad • Fix the vulnerability of the Vigenere cipher by using very long keys • Key is a random string that is at least as long as the plaintext • Encryption is similar to shift cipher • Invented by Vernam in the 1920s CS555 Spring 2012/Topic 3 3 One-Time Pad Let Zm ={0,1,…,m-1} be the alphabet. Plaintext space = Ciphtertext space = Key space = n (Zm) The key is chosen uniformly randomly Plaintext X = (x1 x2 … xn) Key K = (k1 k2 … kn) Ciphertext Y = (y1 y2 … yn) ek(X) = (x1+k1 x2+k2 … xn+kn) mod m dk(Y) = (y1-k1 y2-k2 … yn-kn) mod m CS555 Spring 2012/Topic 3 4 The Binary Version of One-Time Pad Plaintext space = Ciphtertext space = Keyspace = {0,1}n Key is chosen randomly For example: • Plaintext is 11011011 • Key is 01101001 • Then ciphertext is 10110010 CS555 Spring 2012/Topic 3 5 Bit Operators • Bit AND 0 0 = 0 0 1 = 0 1 0 = 0 1 1 = 1 • Bit OR 0 0 = 0 0 1 = 1 1 0 = 1 1 1 = 1 • Addition mod 2 (also known as Bit XOR) 0 0 = 0 0 1 = 1 1 0 = 1 1 1 = 0 • Can we use operators other than Bit XOR for binary version of One-Time Pad? CS555 Spring 2012/Topic 3 6 How Good is One-Time Pad? • Intuitively, it is secure … – The key is random, so the ciphertext is completely random • How to formalize the confidentiality requirement? – Want to say “certain thing” is not learnable by the adversary (who sees the ciphertext).
    [Show full text]
  • Study on the Use of Cryptographic Techniques in Europe
    Study on the use of cryptographic techniques in Europe [Deliverable – 2011-12-19] Updated on 2012-04-20 II Study on the use of cryptographic techniques in Europe Contributors to this report Authors: Edward Hamilton and Mischa Kriens of Analysys Mason Ltd Rodica Tirtea of ENISA Supervisor of the project: Rodica Tirtea of ENISA ENISA staff involved in the project: Demosthenes Ikonomou, Stefan Schiffner Agreements or Acknowledgements ENISA would like to thank the contributors and reviewers of this study. Study on the use of cryptographic techniques in Europe III About ENISA The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU leg- islation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu. Contact details For contacting ENISA or for general enquiries on cryptography, please use the following de- tails: E-mail: [email protected] Internet: http://www.enisa.europa.eu Legal notice Notice must be taken that this publication represents the views and interpretations of the au- thors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA Regulation (EC) No 460/2004 as lastly amended by Regulation (EU) No 580/2011.
    [Show full text]
  • Applications of SKREM-Like Symmetric Key Ciphers
    Applications of SKREM-like symmetric key ciphers Mircea-Adrian Digulescu1;2 February 2021 1Individual Researcher, Worldwide 2Formerly: Department of Computer Science, Faculty of Mathematics and Computer Science, University of Bucharest, Romania [email protected], [email protected], [email protected] Abstract In a prior paper we introduced a new symmetric key encryption scheme called Short Key Random Encryption Machine (SKREM), for which we claimed excellent security guarantees. In this paper we present and briey discuss some of its applications outside conventional data encryption. These are Secure Coin Flipping, Cryptographic Hashing, Zero-Leaked-Knowledge Authentication and Autho- rization and a Digital Signature scheme which can be employed on a block-chain. We also briey recap SKREM-like ciphers and the assumptions on which their security are based. The above appli- cations are novel because they do not involve public key cryptography. Furthermore, the security of SKREM-like ciphers is not based on hardness of some algebraic operations, thus not opening them up to specic quantum computing attacks. Keywords: Symmetric Key Encryption, Provable Security, One Time Pad, Zero Knowledge, Cryptographic Commit Protocol, Secure Coin Flipping, Authentication, Authorization, Cryptographic Hash, Digital Signature, Chaos Machine 1 Introduction So far, most encryption schemes able to serve Secure Coin Flipping, Zero-Knowledge Authentication and Digital Signatures, have relied on public key cryptography, which in turn relies on the hardness of prime factorization or some algebraic operation in general. Prime Factorization, in turn, has been shown to be vulnerable to attacks by a quantum computer (see [1]). In [2] we introduced a novel symmetric key encryption scheme, which does not rely on hardness of algebraic operations for its security guarantees.
    [Show full text]
  • NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Superseded)
    ARCHIVED PUBLICATION The attached publication, NIST Special Publication 800-56 (dated July 2005), has been superseded and is provided here only for historical purposes. For the most current revision of this publication, see: http://csrc.nist.gov/publications/PubsSPs.html#800-56A. NIST Special Publication 800-56 Recommendation for Pair-Wise July 2005 Key Establishment Schemes Using Discrete Logarithm Cryptography Elaine Barker, Don Johnson, and Miles Smid C O M P U T E R S E C U R I T Y NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography DRAFT July 2005 DRAFT Abstract This Recommendation specifies key establishment schemes using discrete logarithm cryptography, based on standards developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.42 (Agreement of Symmetric Keys Using Discrete Logarithm Cryptography) and ANS X9.63 (Key Agreement and Key Transport Using Elliptic Curve Cryptography). Worked examples are provided in Appendix D. KEY WORDS: assurances; Diffie-Hellman; elliptic curve cryptography; finite field cryptography; key agreement; key confirmation; key derivation; key establishment; key management; MQV. 2 NIST SP 800-56: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography DRAFT July 2005 DRAFT Acknowledgements The National Institute of Standards and Technology (NIST) gratefully acknowledges and appreciates contributions by Rich Davis, Mike Hopper and Laurie Law from the National Security Agency concerning the many security
    [Show full text]
  • Introduction, Overview, One Time Pad
    University of Illinois, Urbana Champaign LECTURE CS 598DK Special Topics in Cryptography Instructor: Dakshita Khurana Scribe: Joshua Reynolds, Amit Agarwal Date: August 28, 2019 1 Introduction, Overview, One Time Pad 1.1 Introduction This introductory lecture introduces some fundamental goals of cryptography and defines the basic requirement for a useful private key (symmetric) encryption scheme. A basic problem in Cryptography is that of encryption. The encryption problem is that two parties wish to communicate a message without an eavesdropper being able to learn their secret, or even any information about that secret. This problem can be solved with private key (symmetric) encryption under the assumption that both parties already have a shared secret key. This problem can also be solved with public key (asymmetric) key encryption under various other assumptions. These primitives are among the building blocks of more complicated cryptography sys- tems and a useful medium to explore the assumptions made in cryptographic systems. Encryption, in particular, is important because it allows us to communicate secrets safely through an untrusted medium like the Internet. Focusing first on private key encryption, we define the property of correctness. The second necessary property of encryption is security and is covered in part 2 of these lecture notes. 1.2 Notation This set of scribe notes will use the following notation and definitions: • A set will be denoted by a capital letter { M is the set of all possible messages { K is the set of all possible keys { C is the set of all possible ciphertexts • Set subtraction will use the /operator and jSj means the cardinality of set S • An item from a set will be denoted by a lower case letter { m is a message in plaintext (not encrypted) { ct is a ciphertext (encrypted message) { sk is a secret key used as an input in symmetric encryption and decryption • A statistical method of sampling from a set will be denoted with an arrow combined with a description of how the selection is done.
    [Show full text]
  • Solutions Problem 1. the Ipsec Architecture Documents States That
    Homework 5 - Solutions Problem 1. The IPSec architecture documents states that when two transport mode SA are bundled to allow both AH and ESP protocols on the same end-to-end flow, only one ordering of security protocols seems appropriate: performing the ESP protocol before performing the AH protocol. Why is this approach recommended rather than authentication before encryption? Solution This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Problem 2. Consider the following threats to web security and describe how each is countered by a particular feature of IPSec. a. Brute force cryptoanalitic attack. An exhaustive search of the key space for a conventional encryption algorithm. b. Known plaintext dictionary. Many messages will have predictable plaintext such as HTTP DET command. An attacker can construct a dictionary containing every possible encryption of the known plaintext message. When an encrypted message is intercepted, the attacker takes the portion containing the encrypted known plaintext and looks up the ciphertext in the dictionary. The ciphertext should match against an entry that was encrypted with the same secret key. This attack is especially effective against small key sizes (e.g. 40-bit keys). c. Replay attack. Earlier SSL handshake messages are replayed. d. Man in the middle. An attacker interposes during key exchange, acting as the client to the server and a server to the client.
    [Show full text]
  • Analysing and Patching SPEKE in ISO/IEC
    1 Analysing and Patching SPEKE in ISO/IEC Feng Hao, Roberto Metere, Siamak F. Shahandashti and Changyu Dong Abstract—Simple Password Exponential Key Exchange reported. Over the years, SPEKE has been used in several (SPEKE) is a well-known Password Authenticated Key Ex- commercial applications: for example, the secure messaging change (PAKE) protocol that has been used in Blackberry on Blackberry phones [11] and Entrust’s TruePass end-to- phones for secure messaging and Entrust’s TruePass end-to- end web products. It has also been included into international end web products [16]. SPEKE has also been included into standards such as ISO/IEC 11770-4 and IEEE P1363.2. In the international standards such as IEEE P1363.2 [22] and this paper, we analyse the SPEKE protocol as specified in the ISO/IEC 11770-4 [24]. ISO/IEC and IEEE standards. We identify that the protocol is Given the wide usage of SPEKE in practical applications vulnerable to two new attacks: an impersonation attack that and its inclusion in standards, we believe a thorough allows an attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim, analysis of SPEKE is both necessary and important. In and a key-malleability attack that allows a man-in-the-middle this paper, we revisit SPEKE and its variants specified in (MITM) to manipulate the session key without being detected the original paper [25], the IEEE 1363.2 [22] and ISO/IEC by the end users. Both attacks have been acknowledged by 11770-4 [23] standards.
    [Show full text]
  • Why Passwords Stink White Paper | Why Passwords Stink
    WHITE PAPER WHY PASSWORDS STINK WHITE PAPER | WHY PASSWORDS STINK 01 INTRODUCTION 02 PASSWORDS ARE FUNDAMENTALLY INSECURE 03 THE PROBLEM WITH PASSWORDS IS THAT THEY CONTENTS ARE “SHARED SECRETS” 04 CURRENT ALTERNATIVES AREN’T THE ANSWER 05 A SOLUTION TO THE PASSWORD ISSUE 06 INTRODUCING BEYOND IDENTITY 07 CONCLUSION 02 WHITE PAPER | WHY PASSWORDS STINK There are hundreds of billions of passwords in the world today, with more being created every day. In fact, the average business user maintains an astounding average of 191 passwords.1 Unfortunately, these passwords represent a fundamentally weak link in most organizations because INTRODUCTION they will always be insecure. This white paper examines why that is, investigates some alternative solutions, and introduces a new method of authentication using asymmetric keys and certificates to eliminate passwords altogether. 01 1 https://www.securitymagazine.com/articles/88475-average-business-user-has-191-passwords 03 WHITE PAPER | WHY PASSWORDS STINK Let’s face it: Passwords stink! For employees and customers, they cause friction and frustration when logging in – Who can remember the 16-character combination of letters, symbols, and digits that are indicative of strong passwords, much less come up with them in the first place? When PASSWORDS ARE a password gets lost or stolen (and they invariably do), it places a burden on the help desk. In fact, 20-50% of help FUNDAMENTALLY desk calls are for password resets, with the average call costing the organization $70.2 INSECURE For CISOs, passwords represent corporate assets that can be targeted by bad actors. And that’s a problem because they often transit networks in the clear, are stored in databases that can be and often are hacked, are shared 02 among colleagues, and are reused across multiple apps – making them easy targets for malware, phishing attacks, and other credential-stealing schemes.
    [Show full text]
  • Lecture 19: Public-Key Cryptography (Diffie-Hellman Key Exchange & Elgamal Encryption)
    Lecture 19: Public-key Cryptography (Diffie-Hellman Key Exchange & ElGamal Encryption) Public-key Cryptography Recall In private-key cryptography the secret-key sk is always established ahead of time The secrecy of the private-key cryptography relies on the fact that the adversary does not have access to the secret key sk For example, consider a private-key encryption scheme $ 1 The Alice and Bob generate sk Gen() ahead of time 2 Later, when Alice wants to encrypt and send a message to Bob, she computes the cipher-text c = Encsk(m) 3 The eavesdropping adversary see c but gains no additional information about the message m 4 Bob can decrypt the message me = Decsk(c) 5 Note that the knowledge of sk distinguishes Bob from the eavesdropping adversary Public-key Cryptography Perspective If jskj >jmj, then we can construct private-key encryption schemes (like, one-time pad) that is secure even against adversaries with unbounded computational power If jskj = O(jmj"), where " 2 (0; 1) is a constant, then we can construction private-key encryption schemes using pseudorandom generators (PRGs) What if, jskj = 0? That is, what if Alice and Bob never met? How is “Bob” any different from an “adversary”? Public-key Cryptography In this Lecture We shall introduce the Decisional Diffie-Hellmann (DDH) Assumption and the Diffie-Hellman key-exchange protocol, We shall introduce the El Gamal (public-key) Encryption Scheme, and Finally, abstract out the principal design principles learned. Public-key Cryptography Decisional Diffie-Hellman (DDH) Computational Hardness AssumptionI Let (G; ◦) be a group of size N that is generated by g.
    [Show full text]