The use of email and instant messaging (IM) has become pervasive and entrenched in the fabric of modern communication. Thanks to cryptography, modern messaging tools have reached a considerable degree of sophistication (e.g., Signal) and offer advanced security features ranging from end-to-end encryption to forward secrecy and deniability. For these reasons, coupled with better usability, although email has a long history and remains undeniably popular with hundreds of billions of emails exchanged on a daily basis [clark2018securing], secure messaging has often been recommended by security experts as the go-to tool for secure communication. Yet, secure messaging and email share two long-standing challenges, namely entity authentication and key management.
The primary concern is entity authentication, which invariably involves a mechanism that associates some cryptographic material with an identity, e.g., public key authentication. Key management, affecting email more acutely, is intertwined with authentication and the need for automating it has been known for a long time, e.g., see [ruoti2018comparative].
Over the years, several methods have been established to tackle authentication, and indirectly key management: manual validation, web of trust, public key infrastructure (PKI) and hierarchical validation, public key directories as well as server-derived public keys such as identity-based encryption (IBE). The set of viable candidates becomes much smaller once we consider a decentralized setting, i.e., without a PKI or a trusted third party (TTP). For this scenario, the body of work on key authentication contains hundreds of works focusing on methods based on the use of out-of-band (OOB) channels and short authentication string (SAS) comparisons, see Section I-C. However, when it comes to schemes that rely on low-entropy shared secrets, which is what we address here, the only work that to the best of our knowledge proposes a solution is by [alexander2007improved]. They use a modified solution to the socialist millionaires’ problem (SMP) by [boudot2001fair], also known as secure equality test, for authentication in the off-the-record messaging (OTR) protocol.
Due to the required user interaction in most of these approaches, e.g., for verifying the authenticity of an interlocutor’s public key, usability plays a key role in achieving authentication. Reducing the gap between security and usability, by finding optimal trade-offs, has been a central theme for decades with a plethora of long-standing open problems, e.g., see [unger2015sokMessaging, clark2018securing].
Here we revisit the problem of authenticating public keys in a decentralized setting and propose a user-friendly and robust approach based on password-authenticated key exchange (PAKE) to solve SMP
via low-entropy secrets. These secrets are not expected to be sampled from a large, uniformly distributed space, but rather from a small set of values, e.g., typical human-memorable passwords or pin numbers. The task ofSMP boils down to two parties verifying equality of their inputs and in a zero-knowledge manner such that by the end they learn nothing but the boolean result of the test. By solving SMP via PAKE, we also establish a shared cryptographically strong secret key, making further cryptographic enhancements possible. Furthermore, this approach would not require any understanding of cryptographic concepts from the user, e.g., knowing about public-keys and fingerprints.
We also show how the suggested approach would not only work naturally in the context of secure messaging, but also in the inherently asynchronous setting of email. Apart from offering improved usability properties and eliminating a host of vulnerabilities present in OOB-based protocols, as discussed in Section III, we show how the PAKE-generated secret key can be used to pave the path towards providing a series of enhancements in secure email and messaging. These include inattentive user resistance, automated key renewal, automated future key pair authentication and multi-device synchronization, along with security properties such as deniability, forward secrecy, post-quantum security, auditability for detecting guess and abort attacks, secure secret storage and retrieval with applications in email and secure messaging.
By applying PAKE to this problem, we advance the state-of-the-art in the use of shared low-entropy secrets for entity authentication, an idea considered only in [alexander2007improved]. Also note that while SMP is a subproblem solved naturally by PAKE, the latter has not been applied to the problem of authenticating public keys in decentralized settings.
Entity authentication in decentralized, non-PKI environments is generally brushed aside. Solutions that do consider this problem typically rely on users correctly executing a manual comparison and even tend to keep this feature rather hidden, e.g., Signal. Our incentive for replacing OOB authentication with a cryptographic protocol is the impact of failures occurring in methods highly-dependent on user behavior, which could completely jeopardize security.
Our motivation for using PAKE—a method that does not seem to have enjoyed enough recognition due to a lack of mature implementations, reluctance towards client side crypto, patent-encumbered designs and perhaps even unawareness of its usefulness—is grounded not only in its independence from a PKI or a TTP, but also in its provision of a zero-knowledge (ZK) solution for the secure equality test problem using a low number of rounds, compatible with asynchronous settings, and in the fact that it enables additional cryptographic enhancements.
We were also motivated by two open problems stressed by [unger2015sokMessaging, clark2018securing]: bridging the gap between known theoretical results and real-world solutions, and the need for more robust authentication methods that also improve the trade-off between security and usability in secure solutions. Finally, the need for addressing common challenges such as key management automation and device synchronization also spurred us on.
I-B Contributions and structure
After a brief review of the state-of-the-art in Section I-C, we cover background concepts in Section II. In Section III, we focus on a few vulnerabilities in the use of OOB channels for authentication, including a partial preimage attack aimed at lazy users, which we analyze in the context of the pp secure email solution. In Section IV, we present an efficient PAKE-based solution for authentication in secure messaging and email via low-entropy secrets, which enables further cryptographic enhancements. We provide a concrete illustrative scheme along with an analysis of various PAKE constructions and properties relevant for our work. We show how our proposal can be used to achieve additional cryptographic tasks and properties such as automation in key management and key renewal, forward secrecy in a symmetric-key setting, deniability, post-quantum security, secure secret retrieval, and auditability for mitigating a certain class of online guess and abort attacks. We briefly analyze network transport mechanisms and security. Section V concludes with remarks on future work.
I-C Related Work
The works of [unger2015sokMessaging] and [clark2018securing] provide extensive systematic surveys on secure messaging and email covering numerous aspects. We limit ourselves to the decentralized setting without elaborating on the drawbacks of web of trust approaches covered in the above mentioned works.
The literature contains a sizeable body of work on OOB-based approaches, considered first by [rivest1984expose], many of which are inspired by the original work of [vaudenay2005secure] based on SAS comparisons, e.g., [nguyen2011authentication, kainda2009usability, kainda2010secureMobile, tan2017can], to name a few. This area has also been investigated by the formal methods community, see e.g. [delaune2017formal] for a recent formal analysis of SAS-based schemes in the symbolic model.
As for low-entropy secret-based authentication, to the best of our knowledge, in the only work in the literature, [alexander2007improved] use a modified version of a solution to SMP [boudot2001fair], which is mainly suitable for synchronous settings, to improve authentication in OTR [borisov2004off].
Ii Framework and Preliminaries
We use and to refer to honest parties Alice and Bob, and for the adversary, Mallory. We use to denote an element sampled uniformly at random, and to denote concatenation. We denote low-entropy secrets provided by users with .
Security model. We consider the standard Dolev-Yao model [DolevYao]. We do not assume any trusted infrastructure. In one of our proposed methods for transport protocol, we assume the existence of untrusted buffer/relay servers, somewhat akin to the ones used in the design of Signal or OTR4 (see Section IV-C). Regarding PAKEs, we will consider various constructions in Section IV, largely proven secure in the so-called BPR model [bellare2000authenticated] under various hardness assumptions.
Cryptographic notions. For space reasons, we assume familiarity with common cryptographic concepts, in particular with Diffie-Hellman (DH)-based computational hardness assumptions.
We discuss schemes based on the Ring Learning With Errors (RLWE) problem, a special case of the Learning With Errors (LWE) problem whose security may be reducible to the hardness of solving the Shortest Vector Problem
Shortest Vector Problem(SVP) in lattices, for which no efficient quantum algorithms are known, thus conjectured to be quantum-secure. Post-quantum (PQ) cryptography encompasses schemes that are considered to be safe against adversaries equipped with scalable, cryptographically relevant quantum computers.
We use to denote a key derivation function that takes a source of keying material, typically with a fair amount of entropy but not uniformly distributed, and produces one or more cryptographically strong secret keys, see [krawczyk2010cryptographic] for details. We denote with a keyed message authentication code scheme that computes a tag on under key .
System requirements. We assume standard requirements for email transfer as our proposal does not require any format modifications and preserves compatibility between existing systems. As for secure messaging, we do not introduce any extra trust assumptions and no additional infrastructure would be required. Any exchanges relayed or buffered by intermediate servers can be done by untrusted ones.
Socialist Millionaires’ Problem. In the realm of secure multi-party computation (MPC), Yao’s millionaires’ problem [yao1982protocols] is a famous example in which two parties want to find out whose input is greater without revealing any more information on the actual value. SMP is a variant of this and a ZK proof of knowledge protocol, with the difference that the parties only wish to know if their inputs are equal.
A series of works have been dedicated to solving SMP, including a well-known solution by [boudot2001fair] that provides a fair and efficient protocol, where fairness roughly means that no party can evaluate the function and walk away with the result without the other party learning the output.
[garay2004efficient] showed that the fairness and the security definition of [boudot2001fair] are not compatible with the simulation paradigm and that their solution would not be secure when composed concurrently; they present a construction that can be composed arbitrarily, with similar complexity results.
PAKE. Password-authenticated key exchange (PAKE) protocols enable the establishment of secure channels without the need for a PKI, TTPs or empirical OOB channels. They allow two parties who share only a low-entropy secret, hereafter password, to agree on a cryptographically strong shared secret key, using the password for authentication.
Since the seminal work of [DBLP:conf/sp/BellovinM92], numerous PAKE protocols have been proposed, which largely fall into the two categories of balanced (symmetric) and augmented (or asymmetric), referred to as aPAKE. The latter stores one-way mappings of passwords on the server side in client-server settings.
Intuitively, a core property of PAKE is that a run of the protocol should not leak any information about the password. Moreover, they should be resistant to offline dictionary attacks; an online guessing attack with at most one test per run should be the optimal attack strategy for an active interacting with a party. Similar to SMP, can mask failed guessing attempts as network failures, thus allowing numerous attempts without raising suspicion. This is in general unavoidable, however, we will see in Section IV how a recent work by [roscoe2017auditable] can mitigate this.
Iii Pitfalls in Out-of-Band Authentication
In OOB authentication, users compare some representation of a cryptographic hash (fingerprint) of their partners’ public keys via a separate authenticated channel. This representation is usually in the form of a list of words, numbers or images.
Strong security and usability properties can be achieved if users execute the manual verification correctly. Yet, the difficulty of having users do the assigned tasks correctly while finding the right balance between usability and security is the root cause of security pitfalls, which have been amply discussed by research on fingerprint and SAS comparison via OOB channels (see Section I-C). Usability studies encourage the replacement of manual comparisons by automated software whenever possible [tan2017can].
Selection of an adequate OOB channel. In practice, the theoretical and strong authentication requirements of OOB methods are not easy to satisfy. While face-to-face conversations provide a strong authenticated channel [nguyen2011authentication], they are often not viable. It is usually assumed that an OOB channel cannot be forged, but it can be blocked, overheard, delayed or replayed. Typical instantiations are done via voice-based channels, e.g. a phone call. However, some already consider voice-based SAS comparison to be obsolete from a security perspective [unger2015sokMessaging] as nowadays messages can be forged by voice synthesizers with a small sample of the victim’s voice. Indeed, a voice impersonation attack on users comparing PGP words [wiretapping2014] reported the fake voice to be indistinguishable in about 50% of the cases.
Social engineering attacks. There are multiple ways for humans to interact via OOB, but with few indications about secure, privacy-preserving, or fair ways to do it, e.g., without knowing the authentication value, can fool by pretending to be , asking her to read the words first, and confirming a full match.
Inattentive and lazy users. Users misreading words (inattentive) or comparing only subsets of them (lazy). A recent paper by [naor2018security] analyzes approaches based on SAS authentication that are vulnerable to MITM attacks w.r.t. lazy users. For instance, the approach in WhatsApp and Signal would be flawed if users compared only either the first or the second half of the value, since it would amount to verifying only one peer’s fingerprint. To fix this, the authors propose an influence spreading technique in which every bit of the value to be authenticated influences the generation of each element of the OOB representation.
Partial preimage attack. [dechand2016empirical] study an attack aimed at finding a partial preimage for a fingerprint verified by lazy users; specifically, they assume that subsets of bits at the boundaries and in the middle are checked. Let
denote the probability of finding a partial preimage for a given fingerprintand its complementary event. To calculate , we work out (i.e., the absence of partial preimages for a specific bit permutation). Let be the length of the fingerprint and assuming that consecutive boundary bits are fixed (checked by the user), in this case, the leftmost and rightmost bits of , we let denote the number of remaining bits in the middle from which a possible variation of bits could be fixed, i.e., checked by the user. Thus, we have fixed bits that the adversary cannot invert without the user noticing. Valid preimages can thus be obtained by flipping up to bits within the middle bits; by removing these from the total space of size , we obtain the number of invalid ones. With denoting a given number of positions to modify, the valid strings are then given by choices of positions to flip. Thus, is given by
Expressing as a function of the computational effort in terms of brute-force attempts, we have
. To estimate the number of steps needed for finding partial preimages with a success probability, we simply compute . Expressing in base 2 gives results comparable to [dechand2016empirical].
Iii-a Case Study
Pretty Easy Privacy (pp) is a software aimed at providing usable privacy-by-default in email via end-to-end opportunistic encryption. The tool largely automates initial key generation and storage. The public key of a user is attached to outgoing emails when a key of the recipient has not been stored. Received keys are automatically stored for future use (trust-on-first-use) and outgoing emails are automatically encrypted when a public key of the intended receiver is available. This approach requires neither a PKI nor a TTP.
Similar to the PGP word list, pp trustwords [pepTwds] are natural language words that two users compare via a low-bandwidth OOB authenticated channel to prevent man-in-the-middle (MITM) attacks. The trustwords generation algorithm is a deterministic algorithm that runs locally taking as input the public key of the peer obtained by email and the user’s own public key. Informally, performs an XOR over the fingerprints of each of the input arguments, and then maps each block of 16 bits from the resulting 160-bit long string to a word in a predefined dictionary of size , thus yielding a list of ten words.
To encourage users to perform the OOB authentication, by default pp shows only five words; this means that the peers compare the first 80 out of the 160 bits of a PGP fingerprint, assuming that they check all the words. Since an “influence spreading” property, similar to Naor et al.’s, is already present, the best adversarial strategy is a brute-force attack over the public key space requiring steps to find a key such that the first 80 bits of are equal to those of , with being the public key of .
We consider lazy users and compute estimates for partial preimage attacks similar to the one presented above. We consider the two cases where, out of five words, the user verifies the first and last words as well as two from the middle the first and last words, along with one of the three in the middle. Let , and for we have and we get ; for , with , we get . These results show that would succeed with costs equal to and lower than the computational power estimated for an average adversary [dechand2016empirical].
Clearly the decision to show five words instead of ten by default needs to be reconsidered. Users might feel less annoyed by having to compare fewer words, however, its adverse effect on security is considerable as it practically renders brute-force attacks viable.
Iv Authentication in Email and Messaging via Pake
We now show how PAKE can be used to perform a secure equality test and thereby authentication. Compared to OTR that uses a modified solution to the SMP protocol, we show that our PAKE-based approach yields a more efficient solution with better security guarantees and enables further cryptographic features.
Trust establishment using low-entropy secrets. For and to mutually authenticate, for now we assume that they share a low-entropy secret—e.g., a short password—either agreed upon beforehand or decided by posing and answering a question. Intuitively, the goal is to perform a secure equality test such that upon termination of the protocol, and would only learn whether or not their respective secrets and were the same, thus authenticating each other on the basis of knowing the same secret.
In other words, and wish to authenticate their public keys via a secure equality test of their secrets without revealing any information about the latter, hence the need for a zero-knowledge protocol. This means that the resulting transcript of their exchanges should not leak any information on and to . Also, it should not be possible for to brute-force the password via offline dictionary attacks. Thus, ’s only strategy would amount to making online attempts.
Iv-a Public Key Authentication via PAKE
To determine at the end of a PAKE run whether the user secrets and are equal, without revealing anything else, we suggest the enforcement of explicit authentication using key confirmation (KC) after the key establishment phase. While this step may be optional in the general case for PAKE protocols, here it would be necessary in order to bind the cryptographic material with an identity. The information that and wish to authenticate—e.g., public keys for email addresses in pp or key fingerprints for phone numbers in Signal—can be incorporated either into the KC phase or into the initial user secrets.
Next we show using a concrete example how this can be constructed. For the moment, we do not focus on engineering aspects related to (a)synchronicity and message transport mechanisms, but we will come back to these inSection IV-C. The literature contains several well-studied instances of PAKE and for this reason, we first pick a candidate to demonstrate how it can be used for public key authentication, and then compare a few prominent schemes according to specific properties of interest, as shown in Table I.
Iv-A1 An Instantiation based on SPAKE2
For illustration, in Figure 1 we propose an extension of SPAKE2, a one-round protocol, with a KC step to achieve explicit authentication, thus binding a public key to an entity. This yields a 2-round scheme, the minimum when KC is enforced; see [katz2011round] for optimal-round PAKEs. For KC we can use the generic refresh-then-MAC transformation. Despite its long history and popularity, this transform was only recently proved secure [fischlin2016key].
With being a finite cyclic group of prime order , generated by an element , let and hash function denote public parameters and the private low-entropy secret, with the user password assumed to be appropriately mapped to an element in . The parties perform the key exchange phase, as shown in Figure 1, which concludes with the generation of a symmetric key. Upon termination of the key establishment, and each use the symmetric key to carry out a key-refreshing step via a key derivation function in order to generate fresh MAC keys (for both parties), along with a new session key, , which will be the secret shared key. Next, under the freshly generated keys, they each compute a MAC on the fingerprints of both parties’ public keys. The authentication now amounts to exchanging and verifying the obtained tags and .
The addition of the KC step increases the number of rounds and flows to 2 and 4, respectively. Note that this is merely an illustrative example and as already mentioned, other possibilities for KC do exist, some of which offer additional properties. For instance, [becerra2018forward] showed that a modified version of SPAKE2, called PFS-SPAKE2, coupled with a KC step can achieve perfect forward secrecy (PFS) at the cost of increasing the number of rounds from 1 to 3. More recently, [cryptoeprint:2019:1194abdalla] showed that SPAKE2 does indeed satisfy PFS even without KC under a different hardness assumption. They also prove a version with a KC step (yielding a better bound) almost identical to the one given in Figure 1, except that the protocol has one less flow.
Alternatively, the public key fingerprints can be embedded in the secret , but note that even in that case, the KC step cannot be skipped as an explicit authentication of the public keys would still be needed. More precisely, we would let , where denotes the original user provided secrets, and we would compute the tags as , where the identifier is computed over the transcript, with computed similarly. Similar one round KC methods for explicit authentication can be found in IETF internet-drafts for SPAKE2111https://tools.ietf.org/id/draft-irtf-cfrg-spake2-08.html and J-PAKE222https://tools.ietf.org/html/rfc8236.
Iv-A2 Choice of PAKE
We consider a number of representative PAKE protocols and analyze their properties w.r.t. our use case: SPAKE2 [abdalla2005simple], OPAQUE [jarecki2018opaque], PFS-SPAKE2 [becerra2018forward], J-PAKE [hao2010j], KV-SPOKE [katz2011round], RLWE-PAK and PPK [ding2017provably]. PAKEs are typically evaluated according to the security model in which they are proven secure, support for forward secrecy, the number of rounds, along with their communication and computational complexity. The complexity related aspects become more relevant in a client-server setting wherein a server has to process a high number of requests and sessions. In a decentralized peer-to-peer setting, such properties no longer play a major role.
In Table I, we present some of the relevant properties of the said constructions. Note that except for RLWE-PAK and RLWE-PPK that make use of lattice-based cryptography, all other schemes are Diffie-Hellman-based. In terms of PQ security, an immediate implication of this is that the latter cases would not be safe against quantum adversaries, whereas the first two would provide conjectured quantum-security due to the underlying RLWE problem.
ROM: Random Oracle Model; AAM: Algebraic Adversary Model; CRS: Common Reference String
DH: Diffie-Hellman; CDH: Computational DH; DDH: Decisional DH; DSDH: Decision Square DH; OMDH: One-More DH; RLWE: Ring Learning With Errors
Minimizing the number of rounds becomes more important for secure email than for messaging, especially if the transport mechanism is based on attachments or hidden emails (see Section IV-C). As for secure messaging, this may be equally relevant for solutions that do not operate in a purely decentralized and peer-to-peer setting in which one may wish to reduce the load on relay or buffer servers, e.g., Signal or OTR4, but the number of rounds would in general be arguably less of a concern. Note that KC can be added to schemes that do not have it by default at the cost of an extra round.
Intuitively, the notion of forward secrecy (FS) captures the requirement that a long-term secret compromise should not result in prior session keys getting compromised and consequently the corresponding exchanges. Weak FS (wFS) refers to those schemes satisfying FS against passive adversaries who did not interfere in the previous sessions and perfect FS to those achieving the same against active adversaries. We will come back to this in Section IV-B2.
We limit the discussion on security models to practical considerations. In the random oracle model (ROM), an ideal truly random function being accessible to the parties through oracle calls is typically instantiated using cryptographic hash functions, and the common reference string (CRS) model implies the accessibility of a random string to all parties, generated in a trusted way. The latter may be less obvious to implement in the case of email due to the constraints of decentralization given that the generation of the CRS would be typically done by a trusted party or via a secure MPC protocol, see e.g., [sasson2014zerocash] for an example of CRS generation in a decentralized setting. Finally, regarding the RLWE-based schemes, their proofs are unfortunately in the ROM, as opposed to the quantum ROM (QROM), which would allow adversaries to query the random oracle in superposition.
Iv-B Cryptographic Enhancements
We first show how a number of key properties related to key management automation and error resilience that have been identified in the literature [unger2015sokMessaging] are satisfied and improved upon by our approach. We then present novel uses of PAKEs in secure email and messaging. Note that once a PAKE-generated key is established, subsequent PAKE instances can be run automatically via a chaining self-sustaining mechanism. While we mainly focus on enhancements for existing paradigms that depend on public-keys, we also consider possibilities for shifting to entirely symmetric-key solutions. Indeed, once a PAKE-generated shared symmetric key has been established, not only a wide range of well-understood techniques become possible, but one could also consider the benefits of transitioning to symmetric-key constructions, e.g., MAC-based authentication and symmetric-key encryption schemes.
In Table II, we compare our proposal with a select set of approaches extracted from [unger2015sokMessaging]. Due to space reasons, we refer the reader to the cited source for details on the properties therein.
Iv-B1 Key Management Automation
Automation of future key pair authentications. This is the underlying feature facilitating the achievement of some of the subsequent properties. Once authentication between and is bootstrapped from an initial PAKE, the authentication of new key pairs from either or can be automated using the PAKE-generated shared keys without prompting the users to yet again enter new secrets. For instance, in the case of email (e.g., pp), authentication due to key pair generations can be triggered whenever a new key pair needs to be associated with an existing identity, or for binding a new email of or to a new key pair or when keys expire. Note that upon each future authentication, the PAKE-generated symmetric keys can be refreshed by automatically carrying out a new PAKE.
Immediate enrolment. This property refers to a user’s keys being reinitialized in such a way that other parties can verify and use them immediately. The PAKE-generated key allows to automate the new key exchange and the corresponding authentication.
Alert-less key renewal. Complementing the previous property, this one refers to users not receiving alerts or warnings prompting them to take action when other parties renew their public keys. This would be automated similarly to immediate enrolment.
Low key maintenance. This property pertains to the amount of user effort required for maintaining keys, e.g., tasks such as signing keys, renewing expired keys. For instance, while the pp client does automate key generation and renewal, the established trust level disappears with every key refreshment; key maintenance can be improved with PAKEs as explained above.
Multi-device syncing. Another quite natural application of PAKE is in the realm of device pairing and multi-device synchronization. These typically rely on a human interactive security protocol (HISP) and OOB techniques requiring manual intervention, which can give rise to new and subtle attacks. The application of PAKEs in other contexts for device pairing has been considered before; it is thus natural to consider incorporating them in multi-device syncing of email agents and secure messaging systems.
can enter a password in both devices to be paired, and , triggering a PAKE protocol that establishes a secure channel between them for synchronization; alternatively, this can even be done asynchronously without the two devices being online: pushes its state (e.g., key store, chat or email archive) to a server in encrypted form and later retrieves the secrets stored on the server in an oblivious manner w.r.t. the server, see Section IV-B3 for more details. For example, the current implementation of pp resorts to an ad-hoc pairing technique for key synchronization that could benefit from such a PAKE-based solution.
Inattentive user resistance. As discussed earlier, manual OOB key/fingerprint verification methods are susceptible to human error and inattentiveness. In the PAKE-based approach, even if the users enter the wrong value, the result would not be as catastrophic as trusting a key prepared by the adversary. At worst, it would be inconvenient as the authentication would fail prompting the user to eventually repeat the process.
Iv-B2 Cryptographic Properties
Perfect forward secrecy (PFS). Once, more popular in the context of secure messaging (e.g., Signal and OTR), PFS is now a requirement for cipher suites supported in TLS 1.3. PFS means that in the event of a password disclosure, prior derived session keys remain secure. Clearly, a compromised PAKE-generated key would have to be discarded and refreshed via a new PAKE instance. A PAKE-chaining mechanism that automatically performs key rotations and periodically refreshes the long-term key would provide limited windows of opportunity for , after which the resulting key would be secure again.
Several PAKE constructions provide PFS by default, some of which are listed in Table I; it is known that PFS can be obtained by adding explicit authentication via a KC step [bellare2000authenticated]. This paradigm would be more relevant when such PAKE-based approaches are used for synchronization purposes, be it device-to-device or device-to-server where PAKE can be used to both authenticate and establish a secure channel, thus providing PFS for the session keys used for syncing. For more efficiency, a symmetric-key scheme with PFS such as SAKE [avoine2020symmetric] can be bootstrapped using PAKE.
Finally, the approach adopted by the Sequoia-PGP project for adding FS to OpenPGP-based solutions using regular sub-key rotations would also benefit from automated authentication in case the master key, certifying the short-term sub-keys, needs to be refreshed and authenticated. For additional security, with slightly hampered usability, a separation of storage can be enforced by for example storing such PAKE long-term keys in dedicated hardware, e.g., hardware security modules or smart key storage devices such as YubiKey or Nitrokey, to protect against a device compromise; see Section IV-B3 for more details on this.
Deniability. This is another subtle and fundamental property that has been of particular interest in recent secure messaging systems such as Signal and OTR. Deniable exchange, applied to tasks ranging from authentication to encryption, has a long and somewhat controversial history due to the subtleties in various existing security definitions. We limit ourselves to the case of key exchange and the seminal framework of [di2006deniable] providing security definitions in the simulation paradigm for deniable key exchange and authentication in which message and participation repudiation are considered as requirements.
Since limited space does not allow us to elaborate, we consider only sender/receiver deniability for non-augmented PAKE, i.e., symmetric. We conjecture that such a construction would satisfy the said definition of deniability in the symmetric-key setting: in a two-party setup, a malicious party would not be able to produce binding cryptographic proofs from communication transcripts, associating a party with a particular exchange, as all exchanges could have been simulated by the accusing party . We now observe that a simulator can be constructed as is the only private input shared by both parties and all other parameters are public and drawn at random. Finally, assuming composability, using the PAKE-generated key with symmetric ciphers and MAC-based authentication would preserve deniability. Clearly, this and other forms of deniability for PAKE need to be studied rigorously in future work.
Post-quantum security. As pointed out in Section IV-A2, in the event that secure messaging and email tools transition to PQ cryptography, there are candidate PAKE constructions that provide conjectured PQ security; see Table I. Moreover, a PQ-secure PAKE can be combined with the recent symmetric-key authenticated key exchange (SAKE) by [avoine2020symmetric] that provides PFS to obtain an efficient, PQ-secure and primarily symmetric key scheme with PFS. A quantum-resistant PAKE can be used once to bootstrap authentication via low-entropy secrets and to provide the initial master key needed by SAKE, which is conjectured to be PQ-secure due to its use of symmetric-key primitives, thus offering a low cost and efficient PQ-AKE suitable for settings with limited computational power.
|Network MitM Prevented||Operator MitM Prevented||Operator MitM Detected||Operator Accountability||Key Revocation Possible||Privacy Preserving||Deniability Facilitated||Forward Secrecy Facilitated||Post-quantum Security||Automatic Key Initialization||Low Key Maintenance||Easy Key Discovery||Easy Key Recovery||In-Band||No Shared Secrets||Alert-less Key Renewal||Immediate Enrollment||Inattentive User Resistant||No Service Provider||Asynchronous||Multiple Key Support|
|Web of Trust||PGP||●||●||●||◐||◐||✗||✗||-||✗||✗||✗||◐||◐||✗||✗||✗||✗||✗||●||●||●|
|KD + SaL||CONIKS||●||✗||◐||●||●||●||✗||-||✗||●||●||●||●||●||●||●||●||●||●||●||●|
|OE + SMP||OTR||◐||◐||◐||◐||●||●||-||-||✗||✗||●||✗||✗||◐||◐||✗||●||✗||●||✗||●|
|OE + TOFU||TextSecure||◐||◐||◐||◐||✗||●||-||-||-||●||●||●||●||●||●||✗||●||✗||●||●||✗|
|OE + TOFU + OOB||pp||◐||◐||◐||●||◐||●||-||-||-||●||◐||●||◐||✗||●||✗||✗||✗||●||✗||✗|
|OE + TOFU + PAKE||-||◐||◐||◐||●||◐||●||⍟||⍟||⍟||●||●||●||●||●||✗||●||●||●||●||●||●|
|KFV + OOB||SilentText||●||●||●||●||◐||●||-||-||-||✗||✗||✗||✗||✗||●||✗||✗||✗||✗||✗||✗|
|KFV + PAKE||-||●||●||●||●||◐||●||●||●||⍟||●||●||●||●||●||✗||●||●||●||●||●||●|
Paradigm property is: ; ; ; ;
KD = Key directory; KFV = Key fingerprint verification; OE = Opportunistic encryption; SaL = Self-auditable logs; TOFU = Trust-on-first-use
Iv-B3 Secure Secret Retrieval and Storage
OPAQUE is a recent construction that can, among other things, serve as an aPAKE to offer protection against breaches and server password file compromises. It also offers a secret retrieval mechanism, based on oblivious pseudo-random functions, to retrieve a secret from a server, stored in encrypted form, using only a low-entropy password.
This feature is inspired by the notion of password-protected secret sharing (PPSS) schemes formalized by [bagherzandi2011password], which are -threshold constructions wherein security is preserved against an adversary controlling up to servers out of . A problem that PPSS addresses is protecting ’s secret data (e.g., cryptographic secret key used for decryption, authentication credentials, etc) in the event of a device compromise.
Such a scheme would secret-share among a set of agents so that only a collusion of more than corrupt ones would compromise the data. Secret-sharing is combined with a password-based mechanism that allows the authentication of the owner of to the secret-share holders in order to trigger a reconstruction protocol and retrieve the secret. The private storage of can be shared among external network entities to protect against user device compromise. Alternatively, if does not trust external entities, her device can partake in the secret-sharing by storing multiple shares instead of any other external entity, thus preventing online dictionary attacks by a network attacker and not allowing to learn anything about the secret without corrupting ’s device.
Secret retrieval would have several use cases in secure messaging. For instance, instead of retrieving contacts from the user’s phone, servers could store lists of contacts in encrypted form; this would enable asynchronous syncing of contacts across multiple devices without the service provider learning the content333It is worth noting that the developers of the Signal secure messaging protocol seem to have recently developed a similar functionality for the Signal application, which they refer to as “Secure Value Recovery” [signalSVR2020]. Among other things, they describe a design involving a key stretching of a user’s PIN and a master key derivation using the stretched key and a piece of server-side stored randomness. The same core functionality can be achieved using well-known solutions discussed in our work, i.e., the use of either PPSS or PAKE constructions such as OPAQUE for secure secret storage and retrieval. Signal’s developers also mention secret sharing and oblivious pseudo-random functions as future possibilities [signalSVRtech2020], both of which can be achieved using existing cryptographic primitives, as explained in this section.. A general anonymity/privacy related criticism directed at messaging services has to do with the identification of users via their phone numbers. This can be dealt with by securely storing long-term identities in encrypted form on the server, accessible only to the users.
Another use case would be to secret-share user data among several of their own devices, e.g., smartphone, laptop and tablet, so that a device compromise would not provide any useful information to an attacker; this can also be used for performing key synchronization among multiple devices. All these mechanisms would work in a similar manner from the user’s point of view, i.e., simply by providing a password.
Iv-B4 Auditable Pakes for Thwarting Online Guessing Attacks
As is the case for SMP in OTR, online guessing attacks are unavoidable in PAKEs. This is usually dealt with by fixing a limit on the number of failed attempts that can be tolerated before invalidating a password.
However, in certain cases, another subtle adversarial strategy aimed at sidestepping the (at most) one online test per run would be to resort to a class of guess and abort attacks in which intercepts a message in a given session (or initiates a session of her own) at a crucial step of a protocol run, verifies her guess at the password and in case of an incorrect guess, drops the said message to disguise her attempt as a network communication failure.
This can be done in both directions to double the chance of discovering the password, or in parallel against many network nodes depending on the setting. Such an attack can be carried out repeatedly without raising an alarm as the honest parties may simply view this as a network failure.
We identify a similar vulnerability in the use of a modified version of SMP in OTR: just before the last phase where the parties perform their secure equality test, when and exchange their blinded DH terms incorporating the low-entropy password in the exponent, i.e., , could make a guessing attempt at and in case of obtaining 0 (not equal), drop the message and force an abort, see sections 4.2 and 4.3 in [alexander2007improved]. Note that the non-interactive zero-knowledge (NIZK) proofs that are attached to the messages at every exchange are not meant to protect against this type of attack.
In a relatively recent work, [roscoe2017auditable] apply a mechanism based on commitment schemes and delay functions (e.g., timed-release encryption), originally developed by [roscoe2016detecting] for protecting against online attacks in HISPs that use SAS, to the setting of PAKEs in order to make them auditable by achieving stochastic fair exchange.
Roughly speaking, this is achieved by a transformation for PAKEs at the level of KC using a combination of blinding, randomization, commitments and delay functions such that a series of messages consisting of fake ones and the real intended message are exchanged and the parties will only get to know which is the right one until their exchange is complete. In a follow-up work, [cryptoeprint:2019:1281] generalize this result to achieve -fair exchange using oblivious transfer and timed-release encryption.
This transformation can be used to enhance any PAKE with auditability, thus lending itself quite naturally to the authentication method suggested in this work. An important limitation here is that, due to the highly interactive design of the solution, it would be more suitable to the setting of secure messaging than email, unless a given email solution were to opt for untrusted buffer servers for transport, see Section IV-C.
Finally, note that some of the ideas in this transformation, specifically those related to enforcing fairness, have common elements with the original SMP [boudot2001fair] solution aimed at providing fairness, a property that was removed from the modified version of SMP used in OTR [alexander2007improved] on account of achieving efficiency.
Iv-C Transport Mechanism
Email-based approach. Given the small number of rounds required by PAKE protocols, in the case of email we can afford to use standard email attachments or specially formatted hidden emails as messages’ carriers, processed by the email client in the background.
can choose (via an interface option) to enter her secret upon sending her first email, allowing the first flow of the protocol to occur via an attachment; similarly, when replies, if he opts for entering his secret , the initial PAKE round would be done; the subsequent KC can be done automatically by the dedicated software.
Alternatively, one can resort to a hidden email transport model such as the one used by pp for multi-device key synchronization. Here, the implementations would encapsulate crypto messages in specially crafted email attachments, kept hidden from the user (e.g., archived separately) and processed automatically. Since we primarily deal with authentication, our proposal would have minimal impact in terms of communication and computational complexity as it would have to take place only once.
Untrusted server approach. Although early IM tools were entirely online services that maintained an active session for each conversation, modern IM tools are in fact quite similar to email in that the underlying system follows an asynchronous model. Both Signal and the latest version of OTR [otrv4Spec] achieve offline messaging by using “buffer servers” for hosting pre-key bundles that can be fetched without the other party being online.
We can use a similar mechanism to overcome transport engineering obstacles in email more elegantly, since all aspects related to the exchange of emails remain unchanged and thus interoperable. In fact, the use of an intermediate server would not introduce additional trust assumptions as the transcript of a PAKE protocol does not leak useful information to the adversary; such a server would be untrusted and any entity would be able to set up their own instance.
Iv-D Security and Low-Entropy Secrets
The schemes considered thus far come with proofs of security, see Table I for the corresponding models and assumptions. The security guarantees can be traced back to the core properties of PAKEs: they can in effect fulfill the role of ZK proof of knowledge schemes such that a run of the protocol does not leak any information on the password and upon termination only reveals whether the secrets were equal; they resist offline dictionary attacks and online ones by limiting active adversarial tests to one password per run; compromised session keys will not compromise the security of other session keys; depending on the choice of PAKE; FS would ensure that past session keys remain secure if the password is leaked.
The only way for to gain knowledge about the secret would be via active online guessing attempts, typically dealt with by fixing a limit on the number of failed attempts, e.g., SMP in OTR. We discussed how the possibility of making PAKEs auditable can be used to mitigate this class of attacks by distinguishing between failed adversarial attempts and network failures to minimize the adversary’s tries to one, under the assumption of correct input entry by honest users.
Low-entropy secret agreement. Our proposal does come with its own caveat, namely the need for either presharing or agreeing on a low-entropy secret in-band. As already discussed in [alexander2007improved], the users can either share a secret over a secure channel, e.g. OOB, or agree on one via an in-band solution without revealing sensitive information about the secret itself, for instance, asking to use the name of their favorite restaurant. The user interface of a tool implementing this could warn users not to include the secret itself, similar to standard email warnings reminding users to attach documents in case they have mentioned it in the body of the message.
Another possibility would be to use another already authenticated and secure channel to agree on a secret. For instance, given the widespread use of tools such as Signal, the parties could simply use it to agree on a secret for a one-time entity authentication of their secure email solution. While it may not be appealing from a theoretical point of view, due to the assumption of there being an already authenticated and secure channel, practically speaking, this approach would in fact provide a realistic and usable solution.
Usability aspects. Implementations of the approach must pay proper attention in providing an adequate interface for entering the low-entropy secret, in addition to the usual considerations for providing easy explanations and documentation for users. A lesson learned from a usability study on the OTR/SMP tool [usabilityOTR] stresses the need for further research on how to guide users towards establishing a secure shared human-memorable secret.
For instance, adding a list pre-populated with questions might serve as a guide to generate similar ones or reduce user effort by allowing them to choose one from the list; the questions should not lead to evident answers or to answers belonging to very small known sets, such as “yes/no” or colors, as such cases increase the successful guessing probability of the adversary. Another measure for dealing with disparities due to letter cases would be to just convert the secret to upper-case, at the cost of reducing entropy.
V Future Work
We foresee as a next step an implementation of our proposal, along with research on usability dedicated to assisting users with deriving low-entropy secrets, reducing mental effort and the likelihood of mistakes. We also consider an analysis of our approach applied to encrypted mailing lists. Furthermore, we expect follow-up theoretical work on all the suggested cryptographic enhancements and implementations thereof.
We thank Peter Y.A. Ryan for his valuable feedback and pEp Security S.A./SnT for funding the project “Security Protocols for Private Communications”.