Authenticated Key Exchange Protocols, SRP-6A and PAKE2+
Total Page:16
File Type:pdf, Size:1020Kb
DEGREE PROJECT IN TECHNOLOGY, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2019 A Comparison of the Password- Authenticated Key Exchange Protocols, SRP-6a and PAKE2+ FREDIK SEBEK OLIVER PETRI KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE A Comparison of the Password-Authenticated Key Exchange Protocols, SRP-6a and PAKE2+ FREDRIK SEBEK OLIVER PETRI Bachelor in Computer Science Date: June 20, 2019 Supervisor: Arvind Kumar Examiner: Örjan Ekeberg School of Electrical Engineering and Computer Science Swedish title: En komparativ studie av lösenordsbaserad autentisering för nyckeldelning, SRP-6a och PAKE2+ iii Abstract Privacy is a rising concern globally, and more of our personal information is stored online. It is therefore, important to securely authenticate and encrypt all communication between the client and the server. Password authenticated key-exchange (PAKE) protocols are promising schemes for more secure pass- word authentication on the web. This report looks at both the theoretical and practical aspects of the PAKE protocols, SRP-6a and PAKE2+, from a busi- ness perspective. Benchmarks were used to determine the overall performance of both the protocols using latency and memory as metrics. The benchmarked implementations are written in JavaScript. Furthermore, availability of proto- col implementations and theoretical security aspects such as crypto primitives were also analyzed. Our results indicate that SRP6-a is likely the more viable alternative for businesses today. Measured latencies ranged from 368 to 521 ms for PAKE2+ and 114 to 230 ms for SRP-6a, depending on the browser. SRP-6a is not only significantly faster than PAKE2+, but it has greater mar- ket adoption and maturity, which PAKE2+ lacks in comparison. However, PAKE2+ has a stronger theoretical security footprint, which may make it a strong contender in the future. iv Sammanfattning Integritet på internet är en stigande oro och mer av vår personliga information lagras på servrar online. Det är därför viktigt att säkert autentiera och kryptera all kommunikation mellan klienterna och servern. Protokoll för Lösenordsau- tentiserat Nyckelutbyte (PAKE) är lovande för säkrare lösenordsautentisering på webben. Denna rapport tittar på både de teoretiska och praktiska aspek- terna av PAKE-protokollen, SRP-6a och PAKE2+, ur ett företagsperspektiv. Benchmarks användes för att bestämma den övergripande prestandan för båda protokollen med avseende på hasighet och minne. De benchmarkerade imple- mentationerna är skrivna i JavaScript. Dessutom analyserades tillgängligheten av protokollimplementeringarna och deras teoretiska säkerhetsaspekter. Våra resultat tyder på att SRP6-a sannolikt är det mer användbara alternativet för företag idag. Mätvärdena varierade mellan 368 och 521 ms för PAKE2+ och mellan 114 och 230 ms för SRP-6a, beroende på webbläsare. SRP6-a är inte bara betydligt snabbare än PAKE2+ men har också större marknadsupptag- ning och mognad, vilket PAKE2+ saknar i jämförelse. PAKE2+ har dock ett starkare teoretiskt säkerhetsfotavtryck, vilket kan göra det till en stark konkur- rent i framtiden. Contents 1 Introduction 3 1.1 Privacy and Digitalization . .4 1.2 Problem Statement . .5 1.3 Limitations and scope . .5 2 Background 6 2.1 Transport security layer (TLS) . .6 2.1.1 Password over TLS . .6 2.2 Zero Knowledge Proofs . .7 2.3 Password-authenticated key exchange . .8 2.3.1 Diffie–Hellman key exchange . .8 2.3.2 Types of PAKE . .9 2.3.3 Security . .9 2.3.4 PAKE in practice . 10 2.3.5 Implementations . 11 3 Method 16 3.1 Creating benchmarks . 17 3.2 Benchmarking . 17 4 Results 18 4.1 Security analysis . 20 4.1.1 Attributes . 20 4.2 Elliptic Curve . 21 4.3 Key confirmation . 21 4.4 Salt . 22 4.5 Server security . 22 i ii CONTENTS 5 Discussion 23 5.1 "The first contact problem" . 23 5.2 Implementation details . 24 5.3 Performance . 24 5.4 Adoption . 25 6 Conclusion 26 Bibliography 27 A Code 31 Glossary adversaries Plural form of adversary. 4, 7 adversary A malicious entity within in a cryptographic system. 1, 3, 9, 10, 21, 22 brute force attack An attack to gain authentication to a system by consciously trying various combinations of passwords until it succeeds. 4 dictionary attack An attack to gain authentication to a system by generating potential passwords from a large subset of commonly used words. 4, 9, 22 eavesdropper A third party listening in on other parties communication. 9 ECC Elliptic Curve Cryptography. 21 hash function A one way function, which takes a string as input and produces a fixed size string output, which seems random in relation to the original input. 9, 21 IETF Internet Engineering Task Force. 6, 25 JavaScript JavaScript is a programming language, which is widely used by websites and runs primarily in browsers. 5, 11, 14 man-in-the-middle (MITM) An attack where an adversary intercepts, re- lays, or alters the communication between the victim and the victim’s intended host. 6 PAKE Password-authenticated key exchange. A family of cryptographic pro- tocols that allows two parties to exchange a high entropy key using a weaker shared password. 3, 4, 13, 24 1 2 Glossary PAKE2+ A more modern PAKE implementation of the type augmented. 20, 22 password stretching The process of hashing a password recursively, thus mak- ing it more computationally demanding to guess. 21, 22 salt Random n-bit number to be concatenated with a password before hashing. 9, 21, 22 SJCL Stanford JavaScript Crypto Library. "A secure, powerful, fast, small, easy-to-use, cross-browser library for cryptography in Javascript"[1]. 11 SRP Secure Remote Password Protocol. 10, 11 SRP-6a The latest augmented SRP protocol. 11, 20, 22 TLS Transport Layer Security. 4, 9, 11 Chapter 1 Introduction Encryption is the process of encoding information in a way only authorized parties can consume it. Encryption has been in the forefront of protecting hu- man privacy, by keeping confidential and sensitive information safe and secure on the internet [2]. Passwords are currently the go-to approach for handling au- thentication on the internet [2]. However, human chosen passwords are usually weak, frequently re-used, and even sent in clear-text [3]. That being through an encrypted channel or not. Today, websites use encrypted traffic over TLS (HTTPS) for security, but even TLS has its problems. An encrypted channel may be established with an adversary server, allowing the adversary to decrypt the password sent [4]. Even when the password is sent to an honest server, it is decrypted at the server, which allows for password leaks or implementation bugs, such as logging or storing plain text passwords. In 2016, Twitter urged all their users, 330 million, to change their passwords, after logging them in plain text [5]. Using a password-authenticated key exchange (PAKE) protocol on top of a TLS channel can provide a safer way for users to authenticate themselves online. A PAKE protocol allows two parties to establish an encrypted channel without the user having to send their actual password. PAKE protocols date back as far as 1992 [6]. However, due to various reasons such as patents and privacy concerns, growing interest in PAKE can be seen. The latest PAKE protocol is OPAQUE, which was defined in 2018 [4], the Internet Research Task Force published a requirements document for PAKE in 2017 [7] and multiple cryptography professors have recent (2018) blog posts advocating for PAKE [8][9]. 3 4 CHAPTER 1. INTRODUCTION 1.1 Privacy and Digitalization With the increase in the amount of personal data we put online, especially that case of sensitive information, privacy has become a growing worry [10]. Personal information is distributed and disseminated all over the world. This personal data is collected by adversaries through data breaches. "Many com- panies face the risk of a data breach exposing stored personal information of customers and employees. The frequency of such incidents has been increas- ing over time" [11] The internet has not just created the age of information, but also the age of information collection, "the big data age" [12]. Naturally, the strongest protection for privacy is strong encryption from the client to the server. Today, single factor authentication (username and pass- word) are prone to vulnerabilities [2]. Users often chose weak passwords [2], which adversaries are able to steal using sophisticated techniques such as brute force attack and dictionary attacks [13]. Furthermore companies cannot and be trusted to safely manage passwords. Even large companies such as Twitter, Facebook, and Amazon, face data breaches with twitter even logging pass- words in clear-text [5]. The European union article 8 states, "Everyone has the right to the protec- tion of personal data concerning him or her." [14]. With our current system, we do not have control over what happens to our passwords and information at the other end (the server). PAKE protocols can serve as an alternative to the common method of au- thenticating a client and server using passwords. Sending passwords over TLS in plain-text pose some security risks that PAKE protocols can elimi- nate. While password over TLS may be sufficient for some applications, it is unclear why PAKE is not used more in practice considering its theoretical benefits such as not sending passwords and being more resistant to adversaries. Practical implementation details of the protocol have to be considered along- side theoretical proofs. A protocol proven secure mathematically can still break and leak information if it is not implemented well [7]. To ensure a future where humans can share data with each other securely and maintain their right to privacy, we explore the practicality and security of two PAKE protocols from a business perspective. CHAPTER 1. INTRODUCTION 5 1.2 Problem Statement Which of the two PAKE protocols, SRP-6a and PAKE2+ is the most suitable for business applications with respect to latency, memory, and security? 1.3 Limitations and scope There are 12 well-documented PAKE protocols proposed and implemented in various languages.