Authenticated Key Exchange Protocols, SRP-6A and PAKE2+

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 password authentication on the web. This report looks at both the theoretical and practical aspects of the PAKE protocols, SRP-6a and PAKE2+, from a business 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 protocol 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 signiﬁcantly faster than PAKE2+, but it has greater market 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 Diﬃe–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 conﬁrmation ...... 21 4.4 Salt ...... 22 4.5 Server security ...... 22

i ii CONTENTS

5 Discussion 23 5.1 "The ﬁrst 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 ﬁxed 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 protocols 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 making 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 human privacy, by keeping confidential and sensitive information safe and secure on the internet [2]. Passwords are currently the go-to approach for handling authentication 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 companies face the risk of a data breach exposing stored personal information of customers and employees. The frequency of such incidents has been increasing 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 password) 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 passwords in clear-text [5]. The European union article 8 states, "Everyone has the right to the protection 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 suﬃcient for some applications, it is unclear why PAKE is not used more in practice considering its theoretical beneﬁts 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. Some of which not included in this research are:

• OPAQUE (brieﬂy mentioned in the introduction)

• EKE

• AMP

• J-PAKE

• Dragonﬂy

• SPEKE

Only SRP-6a and PAKE2+ are closely investigated in the research. The programming language, JavaScript, is the only programming language ex- plored. The reasoning for these limitations and choices are discussed in the method chapter. Chapter 2

Background

2.1 Transport security layer (TLS)

TLS 1.0 was created in 1999 by Internet Engineering Task Force (IETF) as an successor of SSL created by Netscape in 1994 [15]. The purpose of TLS is to ensure information that goes from your device to any other device web- site is encrypted and secure [15]. However, encryption is not of much use if you aren’t communicating with the correct party (device, host, server etc) Therefore, TLS also manages the verification of identities and the prevention of man-in-the-middle (MITM) attacks, eavesdropping, tampering, and message forgery [15]. This is full-filled by ensuring integrity between both parties, and the data being transferred. The lastest standard of TLS 1.3 was defined in August of 2018 [16]. TLS is very widely adopted through HTTPS with 95% of popular websites supporting at least TLS 1.2 [17]. Having a particular PAKE implementation integrated into TLS is a large step towards a more widen adoption. Further- more, it drastically reduces and simplifies the implementation complications of having individual businesses create an own implementation.

2.1.1 Password over TLS Today, it is standard practice to send passwords in plain-text to a server. How- ever, this statement by itself is somewhat deceptive. Most communication between two parties is transferred through an encrypted channel via TLS. Even though TLS greatly complicates attacks from dishonest parties, it is not per- fect by any means. In 2015 the IETF released a report, "Summarizing Known Attacks on Transport Layer Security", which listed over 13 known vulnerabil-

6 CHAPTER 2. BACKGROUND 7

ities:

• Theft of RSA Private Keys: When TLS is used with most non-Diﬃe- Hellman cipher suites, it is suﬃcient to obtain the server’s private key in order to decrypt any sessions [18]

• Renegotiation: A major attack on the TLS renegotiation mechanism ap- plies to all current versions of the protocol [18].

• ...

Passwords are a convenient way of handling authentication on the internet. However, they are frequently re-used, meaning a single successful attack by a dishonest party leads to a user having to change their password everywhere. Therefore, avoiding sending the password as much as possible is an eﬀective approach of protecting users’ passwords from reaching adversaries. This is exactly what password-authenticated key exchange aims to do.

2.2 Zero Knowledge Proofs

The discovery of Zero Knowledge Proofs in 1989 by Shaﬁ Goldwasser, Silvio Micali, and Charles Rackoﬀ gave the rise to a new type of encryption, PAKE [19]. Zero Knowledge proof is a mathematical system in which one party can prove to another party that the given statement is valid or true, without con- veying any information except that the given statement is indeed true [19]. Essentially, Zero knowledge proof allows for a shared agreement between two parities without giving up the secret they share. Zero Knowledge proof provides the following properties:

• Completeness: if the provided statement is true, an honest veriﬁer will be convinced.

• Soundness: if the provided statement is false, cheating cannot convince a honest provider. (except to some small probability).

• Zero-knowledge: if the statement is true, nothing else is conveyed except between the two parties.

[19] These properties in theory hold for PAKE. 8 CHAPTER 2. BACKGROUND

2.3 Password-authenticated key exchange

The ﬁrst type of Password-authenticated key exchange (PAKE) protocol encrypted key exchange (EKE) was initially described by Bellovin and Merritt in 1992 [6]. PAKE protocols allows for two or more entities to authenticate each other and create an encrypted channel for further communication using a shared password. This is accomplished by creating a shared cryptographic key derived from a pre-shared human-memorable password. The password or key is never sent, but parties in the exchange can prove possession of the shared password and thus authenticate [20]. When both parties have computed the same session key, it is used to sym- metrically encrypt all data sent in the session. This encryption is strong as the generated key is high entropy, i.e seemingly random, long and hard to guess. No party has to remember or store the session key in between sessions as a new key can and should be generated for every successful authentication (login).

Figure 2.1: Flow diagram of a generalized augmented PAKE implementation

PAKE protocols generally have two components, session key exchange and key confirmation. An explicit key confirmation step is not necessary for setting up an encrypted channel but adds stronger authentication guarantees. If it is not explicitly confirmed that both parties calculated the same session key, a server will not immediately know that a bad password guess was made, making it harder to detect an adversary online guessing attack.

2.3.1 Diffie–Hellman key exchange The Diffie-Hellman (DH) key exchange is a method of establishing a shared secret between to parties without sending the secret. Both parties derive the same secret from random asymmetric keys sent over an insecure link [21]. Diffie-Hellman key exchange on its own is vulnerable to man-in-the-middle CHAPTER 2. BACKGROUND 9

attacks because the messages sent using the established shared key is not cryptographically signed, i.e it is unauthenticated. PAKE protocols are typically extensions or variants of a Diﬃe-Hellman exchange, using the shared password as part of the input for generating the shared secret (session key). This makes the key exchange authenticated and prevents against man-in-the-middle attacks, as the key depends on a password which is not sent.

2.3.2 Types of PAKE PAKE is not a complete protocol for communication over networks. It is in most cases a part in a complete protocol like TLS. Depending on the setting in which PAKE is to be implemented, diﬀerent types of PAKE may be used. An augmented PAKE may be the more secure option in a strict client-server setting but impractical in a multi-party setting such as distributed systems. [7] Balanced PAKE protocols rely on all parties knowing the password. The security of such protocol then depends on the security of password storage [22]. If a party is compromised the stored raw password may be leaked if they are stored in plain-text. Any party can initiate the protocol in a balanced PAKE scheme. This may be a necessary property when client relationships are not known. Augmented PAKE assumes a two-party setting where one party may not know the password, but only stores a derivative of the password [22]. This is typically a client-server relationship, where the server stores a hashed derivative of the password [7]. For augmented PAKE, or aPAKE, a password veriﬁer (a secret derived from the password) is stored instead of a raw password. This is can be a hash of the password using a one way function. An attacker who knows the hash function can in this case pre-compute password hashes using a dictionary, and decipher the passwords if the server is compromised. Some protocols use a unique salt for every client to protect against pre-computation attacks, but may send that salt in plain-text if an attacker asks for it [23].

2.3.3 Security Ideally only an inevitable online guessing attack should be possible for an adversary. PAKE protocols are immune to oﬄine dictionary attacks [4]. An eavesdropper in a PAKE setting does not learn anything about the password by listening in on the communication between the two parties. The only 10 CHAPTER 2. BACKGROUND

way for the adversary to gain knowledge about the password is to guess and receive a yes or no from interacting with the server. For example, sending network requests. Therefore, it is not possible to verify a guess without interacting with the server. This makes it impossible to run an offline dictionary attack. An online guessing attack can be made, but that is detectable and hard to complete successfully [24]. While the communication channel may be secure, as discussed previously a compromised server may leak passwords stored on file. Augmented PAKE protocols address this issue with various degrees of security by using different methods of computing the password verifiers [4].

2.3.4 PAKE in practice Today, as previously mentioned, the standard method for handling authentication online is through a username (e-mail or free-text), and a password [2]. Therefore, it would seem reasonable that PAKE based protocols were used ex- tensively to ensure safe password handling. "Given that many protocols are designed to use the user name and password method of authentication, being able to safely use user names and passwords provides an easier route to additional security." [25]. Even though there exist some usage of PAKE protocols among large companies such as Apple Inc. and 1Password, wide adoption is far from reality. Apple Inc. and 1Password use variants of Secure Remote Password Protocol (SRP) only in few selected services, where secure authentication is imperative [26]. With the current frequency of data breaches and the increasing storage of personal information online, it is reasonable for more businesses to con- sider using PAKE. The financial cost of data breaches and its toll on a companies reputation, is certainly becoming more costly. "The overall effect of a data breach on shareholder wealth is negative and statistically significant. The negative effect of a data breach on the firm’s stock price and that the negative market reaction to a data breach is more significant in the most recent time periods of the sample." [11]. Humans are increasingly valuing their right to privacy. As a result companies are starting to take their security model into greater consideration. Considerations such as using PAKE based protocol may lead to one of the PAKE implementations to become a standard in the future. CHAPTER 2. BACKGROUND 11

2.3.5 Implementations There exists many different implementations of PAKE protocols. Most implementation also have different versions, which have been refined over time. Based on availability and implementation consistency we limited the scope of comparison to SRP-6a and PAKE2+. Both of these implementations are mature and have concrete mathematical proofs supporting their implementations. Furthermore, Stanford University has readily available implementations of both SRP-6a and PAKE2+ in JavaScript within SJCL. Furthermore, only a few augmented PAKE protocols satisfies the security requirements of TLS 1.3. SRP and PAKE2+ are two of those. While the tests used for this report are not implemented in TLS, it is of great importance to achieve wide spread adoption [27].

SRP SRP was created by Thomas J. Wu at Stanford University in 1997 [28]. Secure Remote Password (SRP) protocol is an augmented Password-based Authenti- cated Key Exchange (PAKE) protocol based on discrete logarithm problem (DLP) [28]. SRP was designed to work around existing patents, and be open source. In an interview with Thomas J. Wu regarding SRP he stated, "Open Source software has a big advantage, because it can move quickly on an idea and not be burdened by bureaucracy or politics, but instead can focus on deliv- ering security to the end user using the best technical solution." [29]. Patents and closed licences is a deterrent towards wider market adoption. The ﬂow diagram 2.2 details how a client and server reaches mutual agreement by deriving the same session key in SRP-6a. The diagram shows the veriﬁcation and authentication steps, but ignores initial registration. 12 CHAPTER 2. BACKGROUND

Figure 2.2: Flow diagram of SRP-6a [30] CHAPTER 2. BACKGROUND 13

In the original research paper, Thomas J. Wu states the following security guarantees. This list excludes the standard beneﬁts of a PAKE protocol.

• If the host’s password ﬁle is captured and the intruder learns the value of v (shown in ﬁgure 2.2),it should still not allow the intruder to imper- sonate the user without an expensive dictionary search [28].

• If the session key of any past session is compromised, it should not help the intruder guess at or otherwise deduce the user’s password [28].

• If the user’s password itself is compromised, it should not allow the intruder to determine the session key K for past sessions and decrypt them. Even present sessions should at least be protected from passive eavesdropping [28].

Like many protocols, SRP has had many iterations over its initial release in 1997. Below you can find a summary of various changes that have been made in different versions. The purpose is to indicate that refinement takes time. Therefore protocol maturity is always a strength, as it is indicative that refinements have been made over time.

• SRP-1 was the original implementation of SRP. SRP-1 contained a vul- nerability that allowed an intruder to verify themselves as a particular user given that the password database was compromised. This was re- solved in SRP-2 [31].

• SRP-2 does not contain any known security weaknesses. However, its usage of composite modulus with unknown factorization makes param- eter certiﬁcation an issue [32].

• ...

• SRP-6 is the newest version of SRP. It is resistant to all the well-known passive and active attacks over the network [33].

• SRP-6a is augmented based ﬂavor of SRP-6.

Even the lastest verion of SRP, SRP6-a, has quite a wide range of available libraries in diﬀerent languages.

• Nimbus SRP Implementation in Java

• csrp Implementation in C 14 CHAPTER 2. BACKGROUND

• Botan Implementation in C++

• pysrp Implementation in Python

• srp-rb Implementation in Ruby

• thinbus-srp-js Implementation in Javascript

• Crypt-SRP Implementation in Perl

This list is not exhaustive. It only serves to highlight the overall availability to developers, which is a great step towards adoption. Furthermore it is indicative of interest from the developer community. A large consideration why 1Password chose SRP was, "We didn’t want to roll our own solution" [34]. Developing your own implementation is not only time consuming, but requires high expertise. Having a large selection of libraries in different languages makes implementation more cost efficient and flexible for companies. Not only does SRP-6a have a large range of available libraries, SRP-6a is also readily interchangeable with TLS. TLS-SRP is a set of ciphersuites for transport layer security, which is implemented in GnuTLS [25].

PAKE2+ PAKE2+ is an augmented variant of SPAKE2, a protocol proposed by Abdalla in 2005. SPAKE2 is based on the first PAKE protocol, EKE, by Bellovin and Merritt [24]. The security of SPAKE2 relies on the hardness of the computa- tional Diffie-Hellman problem. The goal of SPAKE2 was to achieve simplicity and strong security properties while minimizing the use of random oracles for efficiency. At the time of its proposal, Abdalla claims that SPAKE2 is as efficient, if not more efficient, than any other PAKE protocol [24]. This protocol doesn’t include a key authentication step, thus the SPAKE2 protocol is secure under a threat of distinguishing a generated session key from a random string only. There are two editions of implementation for the PAKE2+ protocol in JavaScript. PAKE2+EE is an alternative implementation of PAKE2+ which uses Elligator for some operations. This may affect performance and security. According to Hamburg, the author of PAKE2+, the differences of PAKE2+ and PAKE2+EE are as following:

"SPAKE2-EE is probably slightly better overall than SPAKE2. It is slightly faster, has better security assumptions, and makes one or two cases that can arise in SPAKE2 slightly easier. It is also CHAPTER 2. BACKGROUND 15

more complicated to spec and implement, since you need Elli- gator. SPAKE2-vanilla needs more complicated optimizations to achieve its top speed, but at least you don’t have to spec them."

[35] Unlike SRP-6a, PAKE2+ has few revisions. There exists some libraries for PAKE2+. Overall, the availability in quite limited. Especially with respect to SRP-6a. PAKE2+ is not available in TLS. However it is in theory compatible with a general PAKE extension as speciﬁed in a recent draft [27]. Chapter 3

Method

The implementations of PAKE2+, PAKE2+EE and SRP-6a compared were written in JavaScript using Standford JavaScript Crypto Library. Both PAKE2+/PAKE2+EE and SRP-6a are augmented PAKE protocols. They are the augmented variants of SPAKE2 and SRP-6 respectively. Aug- mented protocols were chosen deliberately as they provide additional security in the scenario of interest where a client gets the password from user input and a server stores a derivative of the password. If the server is compromised, the password derivatives can be exposed but not the plain passwords directly. An important aspect when it comes to the practicality of an encryption protocol is performance. Therefore latency and memory usage of SRP-6a and PAKE2+/PAKE2+EE implementations were compared using tests. The tests are small programs intended to mimic a real world scenario. PAKE2+EE or PAKE2+ Elligation Edition is conceptually the same as PAKE2+ but uses diﬀerent calculation at some points in the implementation, which may aﬀect performance. It is of interest to benchmark JavaScript implementations that can run in the browser since the that would allow for adoption of a protocol in internet applications without the need for built-in browser support. It opens up for cus- tom implementations and support on systems where a native implementation can’t be installed. It is also, like in the case with SJCL, possible to run the code in a server environment such as NodeJS. This allows both the client and server to have the same implementation making adoption easier. The following metrics were used for benchmarking:

• Latency

• Memory

16 CHAPTER 3. METHOD 17

3.1 Creating benchmarks

To create a fair benchmark the SRP-6a and PAKE2+/PAKE2+EE implementations were merged into a single project. The library was then recompiled. The SJCL library has a built in test runner for testing in the browser. The next step consist of writing comparable tests for both SRP-6a and SPAKE2+. The code with benchmarks respective benchmarks can be found on Github (https:// gits-15.sys.kth.se/fsebek/kexjobbet-benchmarks) and in the appendix.

3.2 Benchmarking

The test case used is a full key exchange performed between a client and server assuming both parties have knowledge of a shared password before the exchange is initiated. It is also known beforehand which party is the client and which is the server since augmented PAKE protocols are designed with this assumption in mind. Note that the client and server are not separate programs or even separate machines when testing. Client and server in the context of a test are data structures in the test program holding the necessary data for the key exchange. This approach avoids external factors such as network latency and concurrency. All tests are run on a MacBook Pro 2017, 2.3 GHz Intel Core i5 machine. The built-in browser proﬁlers were used for measuring latency of the diﬀerent parts of the tests. This allows for more detailed analysis of latency throughout the protocol execution. Since the benchmark system itself takes time and uses memory to initialize, the system was run without actually performing any of our own written tests. This was to done to ensure there was a basis to subtract our result from. Some variation due to the operating system and hardware is unavoidable. To minimize this variance, the tests for latency and memory usage were run 10 times for each respective implementations, resulting in a total of 40 trial runs. Chapter 4

Results

Figure 4.1 below shows the average latency in Chrome for the 10 trial runs. SRP-6a was the fastest with an average speed of 114.5 ms, while PAKE2+ was the slowest with an average speed of 439 ms.

Figure 4.1: Latency - Chrome

Figure 4.2 below shows the average latency in Safari for the 10 trial runs. SRP-6a was the fastest with an average speed of 230.8 ms, while PAKE2+ was the slowest with an average speed of 521.3 ms.

18 CHAPTER 4. RESULTS 19

Figure 4.2: Latency - Safari

Table 4.1 summarizes all the trial runs, displaying the average and standard deviation for each respective protocol and browser.

Chrome Safari Protocol µ (ms) σ (ms) µ (ms) σ (ms) PAKE2+ 439 8.8 521 9.0 PAKE2+EE 368 7.6 418 6.9 SRP-6a 114 1.3 231 1.8

Table 4.1: Average latency and standard deviation of trials by protocol and browser 20 CHAPTER 4. RESULTS

Besides password stretching, almost all compute time was spent multiply- ing points on curves, i.e doing the math necessary for generating the keys and key material. Performance is thus closely tied to the protocol design. It is clear from table 4.1 that performing the key exchange with SRP-6a was at least twice as fast as PAKE2+/PAKE2+EE. The standard deviation σ for each set of 10 runs show that the variance in latency is largely negligible. SRP- 6a is about twice as fast in Chrome as in Safari. The large difference between browsers may be due to differences in how Chrome’s V8 engine and Safari’s JavaScriptCore runs and potentially compiles the computation intensive parts of the code. PAKE2+EE is slightly faster than standard PAKE2+ while still having at least twice the latency of SRP-6a. The latencies are generally large enough to be perceivable for a human user. The average memory usage of the ten trials was 3353 Kb for PAKE2+ and 3267 Kb for SRP-6a. The memory difference between the two implementations are negligible. This outcome, in afterhand, is rather reasonable given that the calculated key and intermediate key material are the only values that needs to be stored in memory in the exchange. Saving values in memory may actually pose a security risk. Therefore, memory usage between the two implementation will not be taken into strong consideration.

4.1 Security analysis

In order to evaluate the diﬀerence between the protocols with respect to latency, it was important for us to understand the security guarantees between them. Slower performance may be justiﬁable in the case of guaranteeing stronger security. Therefore the following sections outlines the crypto primitives of each protocol.

4.1.1 Attributes The protocols and their implementations share some structure, as they are both augmented PAKE protocols, but vary in implementation details which aﬀect performance and security. The cryptographically signiﬁcant aspects of the benchmarked implementations are compared in table 4.2: CHAPTER 4. RESULTS 21

Property PAKE2+ SRP-6a Encryption support elliptic curve finite field hash function SHA-256 (256 bit) SHA-1 (160 bit) password stretching PBKDF2 20000 iterations optional Key confirmation implicit, optionally explicit explicit Group 256 bit elliptic curve 1024 bit finite field salt 128 bit 64 bit Key size 256 bit 160 bit Message count 3 + 2 for added explicit key conf 4

Table 4.2: Protocol implementation details

As shown in table 4.2, the bit lengths are generally larger for PAKE2+ indicating stronger crypto primitives. Other diﬀerences in security properties are further analyzed below.

4.2 Elliptic Curve

A major diﬀerence between the two protocols is that PAKE2+ uses elliptic curve cryptography where as SRP-6a does not support it due to its mathematical nature. Elliptic Curve Cryptography (ECC) uses smaller keys compared to non-EC cryptography for equivalent security, which makes the use of ECC interesting for PAKE implementations [7]. A 256-bit elliptic curve, which PAKE2+ uses, is comparable to a 3072-bit group. The benchmarked implementation of SRP-6a uses a 1024 bit group, providing weaker security than the elliptic curve. While it is possible to use larger groups with SRP, it would require more computations and negatively impact latency.

4.3 Key conﬁrmation

In the original paper for SPAKE2 [24] explicit key confirmation is not included in the protocol execution. However it can be added as an additional step in practice. If an adversary guesses a wrong password and computes an invalid session, the honest user does not know that a bad guess has been made unless an explicit key confirmation is required by the user. If the adversary’s session key is invalid, no communication can be decrypted and while this might be possible to detect it can be more practical to have the PAKE protocol know directly when this is the case. Enforcing explicit key confirmation thus makes 22 CHAPTER 4. RESULTS

detecting online dictionary attacks practical to implement while requiring two more messages and computations, sacrificing performance and latency. For PAKE2 and PAKE2+ explicit key confirmation is highly recommended [36]. In SRP-6a a variant of explicit key confirmation is performed during the key exchange. The client sends an authentication messages created using its session key along with other data. The server generates its own authentication message using its session key and the clients authentication message. This is sent back to the client so the client can check authentication of the server and vice versa, effectively confirming the session key.

4.4 Salt

Both PAKE2+ and SRP-6a assume that the server stores the salt and sends the salt in the clear to the client when requested before the session key is ex- changed. This allows an adversary to get the salt for a particular user and pre-compute a dictionary attack, which can be launched if the server is compromised. Thus, eﬀectively making the salt inadequate as a security feature on a user basis [4]. Since it is required to know the identity (username) of a user to retrieve the salt, it is non-trivial for an adversary to pre-compute passwords of an entire user database if salts are used. The use of salts in the protocols therefor signiﬁcantly enhance security in common applications such as websites storing many user accounts.

4.5 Server security

Both protocols use salts to force an adversary to compute guesses after the server is compromised thus making it time consuming to guess. However, as previously described, the salt can in both cases easily be retrieved by the adversary before a server compromise. PAKE2+ uses PKDF2 for password stretching which would make it more computationally intensive to launch a dictionary attack on the veriﬁer database, making it less feasible to restore passwords in a given amount of time. If, however, the salt is retrieved before compromise, guesses could be pre-computed. Password stretching would in this case only make the pre-computation more time consuming, but passwords could be restored almost instantly on compromise using the pre-computed guesses. Chapter 5

Discussion

5.1 "The ﬁrst contact problem"

A large security issue with PAKE, which is rarely mentioned in research pa- pers, is the "the first contact problem". This is especially significant with augmented protocols of PAKE. Where the initial registration, will occur through the internet. A plain-text password derivative is sent through, for example TLS, during registration. A dishonest party could eavesdrop the honest parties password derivative. Even though registration is only done once. A successful, but highly unlikely attack, would allow a dishonest party to deceive the server into granting authentication until, the password is either changed by the honest or dishonest party. The honest and the dishonest party become essential indistinguishable to the server. In these situations a password reset email would work, thus allowing the honest party to regain access to their account. However, this assumes an account registration was done using email. Furthermore it would require a new registration over TLS. The "First contact problem" is not something PAKE can solve by itself, since it relies on both parties having shared derivatives to form a common secret. One approach that can be taken to make registration more secure is to first send a random temporary password derivative, generate a shared session key, and then finalize the registration using the encrypted channel from the shared session key. The honest party can now more safely send their actual password. This works by assuming that eavesdroppers are always behind in the information flow. Therefore, even if the eavesdropper would have access to the temporary password derivative, by the time the dishonest party were to use it against the server, the honesty party would have already set their actual password. Thus rendering the shared session key from derived from temporary

23 24 CHAPTER 5. DISCUSSION

password useless to the dishonest party.

5.2 Implementation details

From a theoretical perspective, PAKE oﬀers great amount security beneﬁts, which by now the reader should already be fully aware of. However, the shared PAKE security guarantees will only hold, if what it is implemented by is secure as well. Therefore, if PAKE were to be integrated browser side the imple- menter must carefully design an UI where the user enters their passwords. Oth- erwise, an attack may use to exploit weaknesses in the UI to confuse the user to input their password incorrectly [37]. Furthermore, handling authentication in a browser’s JavaScript environment may pose additional security risks such as code injection, malicious servers and side-channel attacks which can be avoided using a built in browser implementation or separate client. Since PAKE may be used by several applications, it would be desirable from a security perspective to implement a PAKE manager it into the browser application (Chrome, Firefox, Safari...) [37]. Such implementation would drastically improve the performance and avoid common vulnerabilities faced by HTML and JavaScript. However, a user may use more than one browser. Therefore, having a independent software client running on the operating system, fully man- aging the inter-layer communication mechanism between various application requesting authentication would be most secure and convenient approach for the user [37].

5.3 Performance

It is surprising that the PAKE2+ implementation was considering how eﬃ- cient and simple it is in theory. An implementation of SRP-6a with stronger hash functions, salt, group etc can be tested to match the security properties of PAKE2+ as closely as possible to better understand how performance and security relate and whether the choices of such implementation details are the main cause for the diﬀerence in performance. The performance of particular parts of SCJL such as SHA-256 or exponen- tiation with big numbers could be a source of great variance in performance compared to machine code. These details would have to be tested individually for a more granular performance analysis. The low level operations common in cryptographic computation can have some hardware support on common CHAPTER 5. DISCUSSION 25

systems, which may greatly aﬀect performance if the instructions are accessi- ble to the implementation.

5.4 Adoption

Native implementations, built in browsers support, and TLS 1.3 integration are not necessary for PAKE protocols. However, it is important step to ensure other vulnerabilities doesn’t impact its security benefits. Furthermore, PAKE protocols will presumably not achieve significant adoption unless the practical complexities of using it is abstracted away from users and developers alike by native integration. Adoption of HTTPS for example has taken a long time despite being more secure and having significant browser/OS support. As long as standard TLS works well for most use cases, the lack of urgency can prevent adoption of PAKE. Some other possible reasons for the lack of wide adoption may include:

• Patents - Several PAKE protocols have been patented preventing use

• Two-Factor Authentication - easier to implement and does not require a protocol change

• Financial risks - Cost of implementation, and user migration to a new protocol

• Lack of incentive - Why invest money into increasing users security if it does not provide any direct monetary gains?

• Standards inertia - technical standards takes time to change, especially if the current solution “works”.

While we have seen interest for PAKE from the IETF though multiple RFCs proposing and deﬁning their use, none of them seem to be near comple- tion for use as a standard. PAKE2+ and SRP-6a can, despite its lacking support in implementation, be used through SJCL or other implementations to provide strong security for certain applications where the additional security is worth the complexities of good implementation. A typical example of such application is a password manager. 1Password and Apple’s iCloud keychain are examples of password managers already using PAKE. These implementations are however not standard out-of-box. Chapter 6

Conclusion

The PAKE protocols compared can provide additional security over standard password over TLS as the protocols never send the password, use strong cry- pographic primitives and store verifiers server side. Both PAKE2+ and SRP-6a are useful implementations in practice. SRP- 6a is, in the case of JavaScript implementation, significantly faster. It also has TLS integration. Having stronger crypto primitives and supporting ECC, PAKE2+ is a good candidate for practical use, although the particular implementation used is lacking in performance compared to SRP-6a. Performance is in some cases slow enough, about 0.5 seconds, to be noticeable to a user and varies greatly between browsers, making it unsuitable in applications where very low latency is important. In applications where security is of great concern and some noticeable latency is tolerated, these implementations can be used to improve security. Integrating any of the protocols into browsers would allow for better security and likely better performance. When choosing between using SRP-6a or PAKE2+ in an application today, SRP-6a is likely the more practical choice as it has more available implementations, built in integration with TLS, is faster and secure enough for common use. As PAKE2+ reaches more maturity in implementation, its security benefits such as supporting elliptic curve cryptography and having stronger crypto primitives might make it a competitive option. SRP-6a and PAKE2+ aside, there is a larger concern. There is not much talk about PAKE at all from businesses. In the words of Rick Fillion from 1Password, "the marketing department of augmented password-authenticated key agreement protocols is underfunded" [34].

26 Bibliography

[1] E. Stark, M. Hamburg, and D. Boneh. “Symmetric Cryptography in Javascript”. In: 2009 Annual Computer Security Applications Confer- ence. Dec. 2009, pp. 373–381. doi: 10.1109/ACSAC.2009.42. [2] Nicholas J. Hopper and Manuel Blum. “Secure Human Identiﬁcation Protocols”. In: Advances in Cryptology — ASIACRYPT 2001. Ed. by Colin Boyd. Berlin, Heidelberg: Springer Berlin Heidelberg, 2001, pp. 52– 66. isbn: 978-3-540-45682-7. [3] Richard Shay et al. “Encountering Stronger Password Requirements: User Attitudes and Behaviors”. In: Proceedings of the Sixth Sympo- sium on Usable Privacy and Security. SOUPS ’10. Redmond, Wash- ington, USA: ACM, 2010, 2:1–2:20. isbn: 978-1-4503-0264-7. doi: 10.1145/1837110.1837113. url: http://doi.acm.org/ 10.1145/1837110.1837113. [4] Stanislaw Jarecki, Hugo Krawczyk, and Jiayu Xu. “OPAQUE: An Asym- metric PAKE Protocol Secure Against Pre-computation Attacks”. In: Jan. 2018, pp. 456–486. isbn: 978-3-319-78371-0. doi: 10.1007/ 978-3-319-78372-7_15. [5] Twitter Support. We recently found a bug that stored passwords un- masked in an internal log. 2018. url: https://twitter.com/ TwitterSupport/status/992132808192634881. [6] S. M. Bellovin and M. Merritt. “Encrypted key exchange: password- based protocols secure against dictionary attacks”. In: Proceedings 1992 IEEE Computer Society Symposium on Research in Security and Pri- vacy. May 1992, pp. 72–84. doi: 10.1109/RISP.1992.213269. [7] Joern-Marc Schmidt. Requirements for Password-Authenticated Key Agree- ment (PAKE) Schemes. RFC 8125. Apr. 2017. doi: 10.17487/RFC8125. url: https://rfc-editor.org/rfc/rfc8125.txt.

27 28 BIBLIOGRAPHY

[8] Bill Buchanan. Why Do We Still Pass Passwords Over a Network — Meet PAKE? 2018. url: https://medium.com/asecuritysite- when-bob-met-alice/why-do-we-still-pass-passwords- over-a-network-meet-pake-f51b197e835f. [9] Matthew Green. Let’s talk about PAKE. 2018. url: https://blog. cryptographyengineering . com / 2018 / 10 / 19 / lets - talk-about-pake/. [10] Ulrike Hugl. “Reviewing person’s value of privacy of online social net- working”. In: Internet Research 21.4 (2011), pp. 384–407. doi: 10. 1108/10662241111158290. eprint: https://doi.org/10. 1108/10662241111158290. url: https://doi.org/10. 1108/10662241111158290. [11] Kevin M. Gatzlaff and Kathleen Mccullough. “The Effect of Data Breaches on Shareholder Wealth”. In: Risk Management and Insurance Review 13 (Mar. 2010). doi: 10.1111/j.1540-6296.2010.01178.x. [12] Jiexin Zang. “Information Privacy, Data Surveillance and Security–How Aus-tralian Privacy Law Fully Plays Its Role in the Age of Big Data”. In: Journal of Educational Theory and Management 3 (Apr. 2019), p. 22. doi: 10.26549/jetm.v3i1.1168. [13] Manoj Jayabalan and Thomas O’Daniel. “A Study on Authentication Factors in Electronic Health Records”. In: (Mar. 2019). [14] European Union. Charter of Fundamental Rights of the European Union. Vol. 53. Brussels: European Union, 2010, p. 380. [15] Eric Rescorla and Tim Dierks. The Transport Layer Security (TLS) Pro- tocol Version 1.2. RFC 5246. Aug. 2008. doi: 10.17487/RFC5246. url: https://rfc-editor.org/rfc/rfc5246.txt. [16] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446. Aug. 2018. doi: 10.17487/RFC8446. url: https: //rfc-editor.org/rfc/rfc8446.txt. [17] Qualys SSL Labs. SSL Pulse. Accessed: 2019-05-18. url: https : //www.ssllabs.com/ssl-pulse/. [18] Yaron Sheffer, Ralph Holz, and Peter Saint-Andre. Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). RFC 7457. Feb. 2015. doi: 10 . 17487 / RFC7457. url: https : //rfc-editor.org/rfc/rfc7457.txt. BIBLIOGRAPHY 29

[19] S Goldwasser, S Micali, and C Rackoff. “The Knowledge Complexity of Interactive Proof-systems”. In: Proceedings of the Seventeenth An- nual ACM Symposium on Theory of Computing. STOC ’85. Providence, Rhode Island, USA: ACM, 1985, pp. 291–304. isbn: 0-89791-151-2. doi: 10.1145/22145.22178. url: http://doi.acm.org/ 10.1145/22145.22178. [20] Kazuki Yoneyama. “Cross-Realm Password-Based Server Aided Key Exchange”. In: Information Security Applications. Ed. by YongwhaChung and Moti Yung. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 322–336. isbn: 978-3-642-17955-6. [21] W. Diffie and M. Hellman. “New Directions in Cryptography”. In: IEEE Trans. Inf. Theor. 22.6 (Sept. 2006), pp. 644–654. issn: 0018-9448. doi: 10.1109/TIT.1976.1055638. url: http://dx.doi.org/ 10.1109/TIT.1976.1055638. [22] X. Liu, F. Zhou, and G. Chang. “Verifier-based password-authenticated key exchange protocol in cross-realm setting”. In: 2009 Chinese Control and Decision Conference. June 2009, pp. 5560–5563. doi: 10.1109/ CCDC.2009.5195187. [23] Dr. Hugo Krawczyk. The OPAQUE Asymmetric PAKE Protocol. Internet- Draft draft-krawczyk-cfrg-opaque-01. Work in Progress. Internet Engi- neering Task Force, Dec. 2018. 20 pp. url: https://datatracker. ietf.org/doc/html/draft-krawczyk-cfrg-opaque- 01. [24] Michel Abdalla and David Pointcheval. “Simple Password-based En- crypted Key Exchange Protocols”. In: Proceedings of the 2005 Interna- tional Conference on Topics in Cryptology. CT-RSA’05. San Francisco, CA: Springer-Verlag, 2005, pp. 191–208. isbn: 3-540-24399-2, 978-3- 540-24399-1. doi: 10.1007/978-3-540-30574-3_14. url: http://dx.doi.org/10.1007/978-3-540-30574-3_14. [25] David Taylor et al. Using the Secure Remote Password (SRP) Proto- col for TLS Authentication. RFC 5054. Nov. 2007. doi: 10.17487/ RFC5054. url: https://rfc-editor.org/rfc/rfc5054. txt. [26] Xinwei Gao et al. “Post-Quantum Secure Remote Password Protocol from RLWE Problem”. In: Jan. 2018, pp. 99–116. isbn: 978-3-319- 75159-7. doi: 10.1007/978-3-319-75160-3_8. 30 BIBLIOGRAPHY

[27] Richard Barnes. Usage of PAKE with TLS 1.3. Internet-Draft draft- barnes-tls-pake-04. Work in Progress. Internet Engineering Task Force, July 2018. 20 pp. url: https://tools.ietf.org/id/draft- barnes-tls-pake-04.html. [28] Thomas D Wu et al. “The Secure Remote Password Protocol.” In: NDSS. Vol. 98. Citeseer. 1998, pp. 97–111. [29] Clipperz. Interview with Tom Wu, inventor of the SRP protocol. 2007. url: https://clipperz.is/blog/2007/01/04/interview_ tom_wu_inventor_srp_protocol/. [30] Ondrej Uzovic. Communication using Secure Remote Password protocol. 2016. url: https : / / www . codeproject . com / KB / security/1082676/SrpAuthenticationSequence.png. [31] Thomas Wu. url: http://srp.stanford.edu/design1. html. [32] Thomas Wu. url: http://srp.stanford.edu/design2. html. [33] Thomas Wu. url: http : / / srp . stanford . edu / design . html. [34] Rick Fillion. Developers: How we use SRP, and you can too. 2018. url: https://blog.1password.com/developers-how-we- use-srp-and-you-can-too/. [35] Mike Hamburg. [curves] SPAKE2 and SPAKE2 Elligator Edition. 2015. url: https://moderncrypto.org/mail-archive/curves/ 2015/000424.html. [36] Dan Boneh and Victor Shoup. “A Graduate Course in Applied Cryp- tography”. In: 0.4. Sept. 2017. [37] John Engler et al. “Is it too late for PAKE?” In: indicators 5.9 (2009), p. 17. Appendix A

Code

PAKE2+ test code new sjcl.test.TestCase("SPAKE2/PAKE2+ test", function (cb) { if (!sjcl.pake || !sjcl.misc || !sjcl.misc.hkdf || !sjcl.hash.sha256 || !sjcl.ecc || !sjcl.random) { this .unimplemented (); cb && cb ( ) ; r e t u r n ; }

var stretch = false; var useEE = true; let sharedKey1 = "password1"; if (stretch) { v a r s a l t = sjcl . codec . hex . toBits ( ’BEB25379D1A8581EB5A727673A2441EE ’); sharedKey1 = sjcl .misc.pbkdf2(sharedKey1 , salt , 20000); } aPake = sjcl .pake.createPake2Plus("Alice", "example.com", useEE ) ; bPake = sjcl .pake.createPake2Plus("Alice", "example.com", useEE ) ; // send aData to server aData = aPake. startClient(sharedKey1); // read from DB dbData = bPake.generateServerData(sharedKey1); // send bData to client

31 32 APPENDIX A. CODE

bData = bPake. startServer(dbData.pw_M, dbData.pw_N, dbData.pw, dbData.pw2_G); aKey = aPake.finish(bData); bKey = bPake.finish(aData); this.require(sjcl .bitArray.equal(aKey, bKey), ’Key not match’);

cb && cb ( ) ; }); SRP test code new sjcl . test .TestCase("SRP known−answer tests", function (cb) { if (!sjcl.keyex.srp) { this .unimplemented (); cb && cb ( ) ; r e t u r n ; }

var i, kat = sjcl.test.vector.srp, tv, hash, group, verifier , client , server;

for(var j=0; j<1; j++) { t v = k a t [ 0 ] ; hash = sjcl.hash[tv.hash]; group = sjcl .keyex.srp.getGroup(tv.group);

salt = sjcl.codec.hex.toBits(tv.s);

/ ∗ check calculateVerifier ∗ / client = new sjcl.keyex.srp.client(tv.I, tv.P, hash, group); var res = client.calculateVerifier(salt); verifier = sjcl.codec.hex.toBits(tv.v);

/ ∗ check _calculateX ∗ / client = new sjcl.keyex.srp.client(tv.I, tv.P, hash, group); var srpX = client.calculateX(salt).toBits(); APPENDIX A. CODE 33

/ ∗ check group.calculateK ∗ / var k = group.calculateK(hash);

/ ∗ check success ∗ / client = new sjcl.keyex.srp.client(tv.I, tv.P, hash, group); var clientA = client.getClientChallenge( sjcl .codec.hex.toBits(tv.a));

server = new sjcl.keyex.srp.server(tv.I, salt , verifier , hash, group); var serverB = server.getServerChallenge( sjcl .codec.hex.toBits(tv.b));

var clientK = client.setServerResponse(salt , s e r v e r B ) ;

var serverK = server.setClientResponse(clientA);

this.require(sjcl.bitArray.equal(clientK , serverK), "srp K #" + i);

} cb && cb ( ) ; });

TRITA-EECS-EX-2019:363