Password-Based Credentials with Security Against Server Compromise

Abstract

Password-based credentials (PBCs), introduced by Zhang et al. (NDSS’20), provide an elegant solution to secure, yet convenient user authentication. Therein the user establishes a strong cryptographic access credential with the server. To avoid the assumption of secure storage on the user side, the user does not store the credential directly, but only a password-protected version of it. The ingenuity of PBCs is that the password-based credential cannot be offline attacked, offering essentially the same strong security as standard key-based authentication. This security relies on a secret key of the server that is needed to verify whether an authentication token derived from a password-based credential and password is correct. However, the work by Zhang et al. assumes that this server key never gets compromised, and their protocol loses all security in case of a breach. As such a passive leak of the server’s stored verification data is one of the main threats in user authentication, our work aims to strengthen PBC to remain secure even when the server’s key got compromised. We first show that the desired security against server compromise is impossible to achieve in the original framework. We then introduce a modified version of PBCs that circumvents our impossibility result and formally define a set of security properties, each being optimal for the respective corruption setting. Finally, we propose a surprisingly simple construction that provably achieves our stronger security guarantees, and is generically composed from basic building blocks.

1 Introduction

Password-based authentication is still the most common form of user authentication online. Their main benefit is convenience: users can access their accounts from any device based on human-memorizable information only. On the downside, passwords provide weak security guarantees. The biggest threats are server compromise, i.e., an attacker gaining access to the password data stored on the server side, and weak passwords that can be (online) guessed.

To provide better security for users, strong authentication solutions such as FIDO [18, 23] see an increasing interest in the industry and among standardization communities. In these solutions, the user typically owns a cryptographically strong signing key, and authenticates by signing a challenge provided by the server who stores the corresponding public key. This solution eliminates both the risk of guessing attacks (the user now has a high-entropy key) and server compromise (the information on the server side is only the user’s public key, i.e., not sensitive). However, this strong security comes for the price of reduced usability, as the user must securely manage cryptographic key material. This is particularly challenging when users want to access the key from many, and possibly low-security, devices. A common approach therefore is to rely on tamper-resistant hardware tokens, e.g. Yubikey [25], which is desirable from a security perspective, but clearly not ideal in terms of usability [19].

Password-Based Credentials. To combine the best of both worlds, Zhang et al. [26] recently proposed the concept of password-based credentials (PBC) that provide similarly strong security as the key-based solution, but without having to store sensitive key material on the user side. In the PBC-system, the user establishes a cryptographically strong access credential with the server upon registration. To avoid the need of secure hardware on the user side, the user does not store the sensitive credential directly, but only a password-protected version of it. When authenticating to the server, the user needs both the credential and her password. The twist of their solution is that this password-based credential is resistant to offline brute-force attacks against the password, and thus could even be synced via (untrusted) cloud providers or simply copied on many (low-security) devices. This offline-attack resistance is achieved by relying on a high-entropy key of the server for verifying whether an authentication token derived from the credential and password is correct. Thus, verifying whether a password guess was correct requires interaction with the server, which reduces the attack surface from offline to online attacks if an attacker knows the password-based credential. If the adversary does not possess the user’s password-based credential, the security is essentially equivalent to strong authentication. Their security comes with one significant limitation though – it assumes the server never gets compromised.

Importance of Server Compromise. Server compromise is a major threat to password-based authentication, and refers to an attack where the adversary gains access to the authentication information maintained by the server, such as password hashes. The server itself is considered to be honest, but an attacker can now recover the users’ access details to either gain access to a user’s account at the compromised server or, if the same password is re-used across multiple services, even impersonate the user on different sites. Even major companies such as Yahoo [24], PayPal [10], Linkedin [1], Blizzard [20] or LastPass [22] have suffered from such attacks, resulting in millions of password hashes or password-protected files being compromised.

Thus, considering the threat of server compromise and building solutions that maintain security in such scenarios is crucial for end-user authentication. Surprisingly, despite having server compromise as a core motivation for their work, Zhang et al. [26] do not include server compromise attacks in their model. In fact, their PBC protocol loses all security if the server’s data gets compromised, as the attacker can then impersonate any user who has registered with the server. This even holds regardless of the user’s chosen password, as it does not require any additional offline attack to recover the password.

1.1 Our Contributions

We address the problem of password-based credentials that remain secure in the presence of server compromise. We show that the desired security is impossible to achieve in the framework proposed by Zhang, Wang and Yang [26] (henceforth called the ZWY framework). We adapt this framework to circumvent the impossibility result and propose a generic protocol that provably satisfies our stronger notion – and is even simpler than the one by Zhang et al.

Following the work by Zhang et al. [26], we formalize PBC as a password-based token scheme, i.e., the actual authentication protocol is abstracted away. On a high-level, the user registers with the server, obtaining a credential that is protected under her password. After registration, the user can generate a token by “signing” her username and message (which typically will be a fresh nonce in the actual authentication protocol) using the credential and password as a secret key input. The server verifies that token using it’s secret verification key.

We extend and strengthen the ZWY security framework to capture the following high-level security guarantees:

• Strong Unforgeability: An attacker without knowledge of the user’s credential should not be able to forge an authentication token – thus essentially guaranteeing the same level as classic key-based strong authentication. This property must also hold when the adversary knows the user’s password, and when the server is compromised, i.e., even if the adversary knows the server’s verification key.

• Online Unforgeability: When the adversary knows the user’s credential (but not the server’s verification key), tokens remain unforgeable as long as the adversary has not guessed the correct password. The strength of this property is that the adversary must not be able to offline attack the password but run an online attack against the honest server. Requiring participation of the server for each password guess, enables the server to notice suspicious access patterns and impose throttling on the affected account.

• Offline Unforgeability: If both the user’s credential and the server’s key are compromised, the attacker can unavoidably test passwords in an offline way. However, we require the attacker to perform such an offline attack on each password. This adds a last layer of security for users with strong passwords.

The ZWY framework captures a security definition for a combined version of online unforgeability and a weaker form of strong unforgeability where the server could not be compromised. Their work did not cover or achieve offline unforgeability.

Impossibility of Security Against Server-Compromise in Single-Key Setting. In the ZWY framework [26], the server only has a single verification key for all users. The high-level idea of their concrete construction is as follows: the server has a global MAC key, and the credential is essentially a server’s (algebraic) MAC on the username which the user encrypts under her password. The core idea of authentication is decrypting the credential with the password, recovering the MAC and sending it back to server (and bound to the message). Without knowing the server’s high-entropy key, one cannot verify if the decrypted value is indeed a correct MAC, ensuring the desired online unforgeability. It is easy to see that this construction is not secure if the server’s key got compromised, as the adversary can simply create MACs for all users he wants to impersonate.

In fact, we show that this is not merely a weakness of their scheme but inherent in the overall single-key setting. That is, we show that strong unforgeability and offline unforgeability are impossible to achieve when the server owns a single verification key for all users.

Framework for Multi-key Password-Based Credentials. As two of the three desired security properties are impossible to achieve in the single-key ZWY framework [26], we propose a new variant – Multi-key Password-based Credentials ($\textsf{mkPBC}$) – where the server maintains an individual verification key for every user. Moving to a setting where the server maintains individual verification information for each user requires an additional property also concerned with server compromise, yet not captured by any of the three properties listed above:

• Pw-Hiding: The server’s verification key for a user should not leak any information about the user’s password.

The reason this property is not covered by the unforgeability notions discussed above is that learning the password in the $\textsf{mkPBC}$ scheme does not allow the server to impersonate the user (this still requires the user credential). However, as users tend to reuse their passwords across different sites, we want the password to remain fully hidden in case the server gets compromised.

We formally define all four properties through game-based security definitions, capturing the optimal security guarantees for a $\textsf{mkPBC}$ scheme.

Simple Construction From Standard Building Blocks. Finally, we present a surprisingly simple generic $\textsf{mkPBC}$ scheme ($\textsf{PBC}_{\textsf{StE}}$) constructed from standard building blocks – a pseudorandom function, public-key encryption and signature scheme. The challenge is in formally proving that it achieves all our security notions. To do so, we require the signature scheme to satisfy two properties in addition to unforgeability – complete robustness and randomness injectivity. Both are natural properties, and we show that they are achieved by standard signature schemes, such as Schnorr and DSA.

Interestingly, our construction does not only provide stronger security than the original scheme, but is also much simpler and generic: Whereas Zhang et al. [26] gave a concrete discrete-logarithm based construction that required the q-SDH and q-DDHI assumptions, our $\textsf{PBC}_{\textsf{StE}}$ only requires basic building blocks, and thus can be easily implemented using standard cryptographic libraries. The generic approach also allows to obtain a quantum-safe variant of our scheme if the generic building blocks are instantiated with PQC-variants.

2 Single-Key Password-Based Credentials

This section presents the idea and security of the ZWY framework by Zhang et al. [26], to which we refer to as single-key password-based credentials $(\textsf{skPBC}$). We show that no $\textsf{skPBC}$ can achieve security in the presence of server compromise, which we consider a crucial goal and which motivates our switch to multi-key PBCs in the following section.

We start by presenting the definition of single-key PBCs before we present the impossibility result. We adopted the ZWY framework to our notation for consistency with our main result. For completeness, we summarize our editorial changes to the ZWY syntax and security definitions in Appendix A and explain that they do not change the technical aspects of [26].

Syntax. A (single-key) password-based credential system $\textsf{skPBC}$ consists of five algorithms $(\textsf{KGen}, \langle \textsf{RegU}, \textsf{RegS}\rangle ,\textsf{Sign},\textsf{Vf})$ used in two main phases – a registration phase and an authentication phase – and involves two parties: a server $\mathcal {S}$ and a user $\mathcal {U}$ who wishes to authenticate to the server. In the single-key setting, the server is assumed to have a single long-term key $\textsf{KGen}(1^{\lambda })\rightarrow (ssk,spk)$ that is used to register and verify all users. In the interactive registration protocol $\langle \textsf{RegU}(spk,uid,pw), \textsf{RegS}(ssk,uid)\rangle \rightarrow (ask; -)$ the user registers herself at the server with a username $uid$ and password $pw$ from password space $\mathcal {D}_{\textsf{pw}}$. The server issues her a credential $ask$ (= authenticated secret key) using a server key $ssk$ and stores her username in his database.

While the overall goal is to use PBC for user authentication, where $\mathcal {U}$ and $\mathcal {S}$ engage in a challenge-response protocol, this is abstracted away in PBCs by modelling a special type of authentication token $\tau$. This token is created through $\textsf{Sign}(uid, ask, pw,m) \rightarrow \tau$ by the user for a (challenge) message m and username $uid$, using the user’s credential $ask$ and password $pw$. Verification is a secret-key operation and allows the server with key $ssk$ to verify whether the message m was indeed signed by user $uid$. This is defined through $\textsf{Vf}(ssk,uid,m,\tau )\rightarrow 0/1$.

2.1 Security Model of ZWY [26]

Zhang et al. [26] proposed the security definition Existential Unforgeability under Chosen Message and Chosen Verification Queries Attack (EUF-CMVA). This definition comes with two independent winning conditions and guarantees, (1) classic unforgeability if the adversary only knows the user’s password but none of the keys (neither of server nor user) and (2) online unforgeability if the user’s key got compromised.

Thus, this can be seen as a combined version of the strong and online unforgeability we described in the introduction, with one significant limitation though: the ZWY model does not allow for server compromise in the strong unforgeability game, thus we refer to their version as weak unforgeability. In fact, we show that strong unforgeability is impossible in their setting.

Furthermore, their work does not capture offline unforgeability, again due to the absence of server compromise, and we show that this is also impossible in their setting. Note that the pw-hiding property is not needed in $\textsf{skPBC}$, as the server does not maintain user-specific state which could depend on the password.

For consistency and ease of presentation, we split the EUF-CMVA game along the two independent winning conditions which correspond to weak and online unforgeability. In the following we only focus on the weak unforgeability and the impossibility of strong unforgeability.

Weak Unforgeability. Weak unforgeability guarantees that the adversary cannot forge a valid authentication token for a user if he does not know the user’s credential $ask$. This provides standard security for users whose credential have not been compromised.

This property is modelled as a game played between a challenger and an adversary. The adversary chooses the usernames of all users. The challenger registers them with randomly chosen passwords with the honest server. The adversary is given the passwords of all users and can then ask arbitrary honest users to sign messages of his choice (via $\mathcal {O}_{\textsf{Sign}}$) and ask the server to verify tokens of his choice (via $\mathcal {O}_{\textsf{Vf}}$, recall that this is necessary as verify is a secret-key operation). He can also corrupt users via the $\mathcal {O}_\mathsf {{RevCred}}$ oracle, which returns the credential $ask_i$ of a user i of his choice. The adversary wins if he can forge an authentication token on a fresh message for a user whose credential he has not obtained. The security experiment $\textsf{Exp}_{\mathcal {A},\textsf{skPBC}}^{\textsf{weakUNF}}(\lambda )$ is given in Fig. 1 and the security definition is as follows:

Definition 1

($\textsf{skPBC}$ Weak/Strong Unforgeability). A $\textsf{skPBC}$ scheme is x-unforgeable, for $x\in \{ weakly, strongly \}$, if for all PPT adversaries $\mathcal {A}$, it holds that $Pr [\textsf{Exp}_{\mathcal {A},\textsf{skPBC}}^{x\textsf{UNF}}(\lambda )=1]\le \textsf{negl}(\lambda )$.

Fig. 1.

Weak and Strong ( ) Unforgeability for $\textsf{skPBC}$. The oracles use the values $(i,uid_i,ask_i,pw_i)$ established during registration.

2.2 Impossibility of Strong (and Offline) Unforgeability

Lifting the security definition from weak to strong unforgeability is straightforward: to model server compromise, we give the adversary access to the server’s secret state – here $ssk$ – after registering honest users. We require the same unforgeability for users whose individual credentials he never learned (see Fig. 1).

However, we now show that achieving this notion is impossible in the single-key setting. The idea of the attack is simple: once the adversary has learned the server’s secret key, he re-runs the registration of an arbitrary honest user with a password of his choice to obtain a valid user credential and creates tokens in her name. More precisely, the following adversary $\mathcal {A}$ wins the strong unforgeability game for $\textsf{skPBC}$ with probability 1:

$$\begin{aligned} &\underline{\mathcal {A}(spk)} \\ &\text { Pick }uid_1\xleftarrow {r}\mathcal {D}_{\textsf{uid}}\text {, send }(uid_1,st)\text { to the challenger, receive }(st,pw_1,ssk)\text {;}\\ &\text { Pick }pw'\xleftarrow {r}\mathcal {D}_{\textsf{pw}}\text { and run }(ask'; -)\leftarrow \langle \textsf{RegU}(spk,uid_1,pw'), \textsf{RegS}(ssk,uid_1)\rangle \\ &\text { Choose }m^*\xleftarrow {r}\mathcal {M}\text {; compute }\tau ^*\leftarrow \textsf{Sign}(uid_1,ask',pw',m^*)\text { and }{} {\textbf {output}} (uid_1,m^*,\tau ^*) \end{aligned}$$

Success Analysis of $\mathcal {A}$: By the correctness definition it holds that $\textsf{Vf}(ssk,uid_1,$ $m^*,\textsf{Sign}(uid_1,ask',pw',m^*))=1$ since $ask'$ is obtained by running the registration protocol with $(uid_1,pw')$ and the correct issuer secret key $ssk$. The adversary did neither query $\mathcal {O}_{\textsf{Sign}}(1,m^*)$ nor $\mathcal {O}_\mathsf {{RevCred}}(1)$, and thus wins the security experiment ${\textsf{Exp}}_{\mathcal {A},\textsf{skPBC}}^{\textsf{strongUNF}}(\lambda )$ with probability 1.

The attack exploits the fact that a single key $ssk$ is used to both register users and verify their tokens, and never gets updated when a user registers. Hence, the authentication cannot depend on any user-provided input, but solely on the server key (and the secrecy thereof). This attack also extends to the context of offline unforgeability since an adversary who knows $ssk$ can forge authentication tokens for any user without offline dictionary attacks.

3 Multi-key Password-Based Credentials

Motivated by the impossibility of strong unforgeability in the single-key setting, we now introduce our concept of multi-key password-based credentials. The crucial difference is that the server no longer has a single secret key to issue user credentials and verify their tokens. Instead, he generates a user-specific verification key for each registered user and uses that user-specific key when verifying a user’s token. We modify the original PBC syntax to the multi-key setting and then formalize the desired security properties.

Syntax. While the overall idea and concept remain the same in the multi-key setting, we change how the server stores user-specific verification information. We do not assume that the server has a single key pair $(ssk,spk)$. Instead, in the registration phase, the server will output a user-specific verification key $avk$ which allows him to verify the user’s authentication token.

Definition 2

(Multi-key Password-based Credential). A multi-key PBC scheme $\textsf{mkPBC}= (\textsf{Setup},\langle \textsf{RegU},\textsf{RegS}\rangle ,\textsf{Sign},\textsf{Vf})$ with message space $\mathcal {M}$, username space $\mathcal {D}_{\textsf{uid}}$ and password space $\mathcal {D}_{\textsf{pw}}$ is defined as follows.

• $\textsf{Setup}(1^{\lambda })\rightarrow pp$: Outputs public parameters $pp$. We assume all algorithms get the public parameters $pp$ as implicit input.

• $\langle \textsf{RegU}(uid,pw), \textsf{RegS}(uid) \rangle \rightarrow (ask;avk)$ : An interactive protocol between $\mathcal {U}$ with $(uid,pw)\in \mathcal {D}_{\textsf{uid}}\times \mathcal {D}_{\textsf{pw}}$ and $\mathcal {S}$. After successful registration, the user outputs a credential $ask$, and the server outputs a user-specific verification key $avk$.

• $\textsf{Sign}(uid, ask, pw,m) \rightarrow \tau$: Generates an authentication token $\tau$ on message $m \in \mathcal {M}$ and username $uid$, using $ask$ and $pw$.

• $\textsf{Vf}(uid,avk,m,\tau )\rightarrow 0/1$: Outputs 1 if authentication token $\tau$ is valid on $uid$ and m under $avk$ and 0 otherwise.

We require all honestly generated authentication tokens using the correct combination of $ask$ and $pw$ to pass validation under the corresponding $avk$. A formal correctness definition is given in Appendix C.

3.1 Security Model

We now provide a formal model for the following security properties motivated in Sect. 1.1 and partially inspired by the ZWY model [26].

• Strong Unforgeability: An adversary who does not know a user’s $ask$ cannot forge an authentication token for that user, even when he knows the user’s password $pw$ and the server’s verification key $avk$.

• Online Unforgeability: An adversary who knows $ask$ but not $pw$ or $avk$ cannot forge an authentication token more efficiently than through online guessing attacks, interacting with the server who has $avk$.

• Offline Unforgeability: If the adversary knows both $ask$ and $avk$ of a user, he has to conduct a brute-force offline dictionary attack on the password $pw$ in order to forge an authentication token.

• Pw-Hiding: The $avk$ does not leak any information about the underlying $pw$.

Optimal Security. We stress that all security guarantees are optimal for the respective corruption setting, i.e., achieve the strongest level of full/online/offline attack-resistance for each combination of corrupted keys and passwords. When defining these properties through formal security models, it is important to give the adversary therein as much “access” to honest parties as possible. In fact, this was not properly captured in the ZWY model: therein corrupt users where not allowed to register with an honest server, which allows entirely insecure schemes to be proven secure. See Appendix A for a discussion of that shortcoming. Interestingly, our choice of letting the server maintain independent key material for all users, simplifies the modelling significantly: since the server in $\textsf{mkPBC}$ does not have any long-term secret key used during registration or verification, the adversary can internally simulate the registration of any corrupt user (expressed through any combination of $uid$ and $pw$) that he wants. Thus, for our security model (Fig. 2), it suffices to consider only a single honest target user and let the adversary (internally) handle all other (corrupt) users in the system.

Strong Unforgeability. Without knowing the user’s credential $ask$, we want the strongest security in the sense that an adversary can forge tokens in the name of an honest user $uid$ with negligible probability only. This is modelled by letting the challenger run the registration for an honest user $uid$ with password $pw$, obtaining $ask$ and $avk$. It then hands $avk, pw$ to the adversary, and grants $\mathcal {A}$ access to a sign oracle $\mathcal {O}_{\textsf{Sign}}$, which returns tokens created with $ask$ (and $pw$) for messages $m_i$ of his choice. The adversary wins if he can produce a valid token $\tau ^*$ for a fresh message $m^*$ that verifies for the honest users $uid$ and $avk$.

Fig. 2.

Security experiments and oracles for $\textsf{mkPBC}$. The overall goal of the adversary in our three unforgeability games is the same, and is shown in the combined $\textsf{xUNF}$ experiment, where only the set of revealed keys and oracles differ depending on $\textsf{x}$.

Definition 3

(Strong Unforgeability). A $\textsf{mkPBC}$ scheme is strongly unforgeable, if for all PPT adversaries $\mathcal {A}$: $Pr [\textsf{Exp}_{\mathcal {A},\textsf{mkPBC}}^{\textsf{strongUNF}}(\lambda )=1]\le \textsf{negl}(\lambda )$.

Online Unforgeability. If the adversary knows the user’s high-entropy credential $ask$ it is impossible to achieve strong unforgeability anymore. As soon as $\mathcal {A}$ has correctly guessed the user’s password, there is no security. The best we can hope for is security against online attacks, relying on the server’s user-specific verification key $avk$ as a second defense, i.e. the honest server’s participation must be required to verify each of $\mathcal {A}$’s password guesses.

In the security game, this is modelled by giving $\mathcal {A}$ the credential $ask$ of the honestly registered user $uid$, but neither $avk$ nor $pw$. Consequently, we grant $\mathcal {A}$ access to $avk$ through a verify oracle $\mathcal {O}_{\textsf{Vf}}$ that allows the adversary to verify message-token pairs $(m_i,\sigma _i)$ of his choice under the server’s $avk$. Given that the adversary knows $ask$, he can use $\mathcal {O}_{\textsf{Vf}}$ as a password test oracle, submitting tokens generated for the correct $ask$ and different password guesses $pw'$.

It might look surprising that we grant $\mathcal {A}$ access to a sign oracle too – as he does know $ask$ here – but this oracle is necessary since he does not know the corresponding $pw$ and must be able to observe valid tokens by the honest user.

The adversary’s goal is still to forge an authentication token for the honest user. The security definition needs to be weakened to online attacks though, and states that the adversary cannot win the experiment significantly better than through testing $q_{\textsf{Vf}}+1$ of the $|\mathcal {D}_{\textsf{pw}}|$ passwords where $q_{\textsf{Vf}}$ is the number of queries made to the $\mathcal {O}_{\textsf{Vf}}$ oracle. The additional constant 1 is added because the forgery which $\mathcal {A}$ outputs in the end, can itself be seen as a password guess.

Definition 4

(Online Unforgeability). A $\textsf{mkPBC}$ scheme is online unforgeable, if for all PPT adversaries $\mathcal {A}$ it holds that $Pr [\textsf{Exp}_{\mathcal {A},\textsf{mkPBC}}^{\textsf{onlineUNF}}(\lambda )=1] \le \frac{q_{\textsf{Vf}}+1}{|\mathcal {D}_{\textsf{pw}}|}+\textsf{negl}(\lambda )$, where $q_{\textsf{Vf}}$ is the number of queries to the $\mathcal {O}_{\textsf{Vf}}$ oracle.

Offline Unforgeability. If both keys, $ask$ and $avk$, related to an honest user are compromised, the unforgeability solely relies on the strength of the user password $pw$. The best we can hope for in this setting are offline attacks: the adversary can test passwords by signing a message using the corrupted $ask$ and password guess $pw'$ and verify the resulting token using the key $avk$. As soon as the adversary has correctly guessed $pw$, there is no secret left, and he can create tokens for arbitrary messages. Offline attacks are unavoidable in this case, but we also want them to be the best possible attack. This means that choosing a strong password adds an additional (albeit weak) layer of security for the user.

To quantify the offline amount of work the adversary has to perform, we took inspiration from security models of other password-based protocols [6,7,8] and introduce an oracle $\mathcal {O}_{\textsf{TestPW}}$ which takes the adversaries password guess $pw'$ and returns 1 if $pw=pw'$ and 0 else. The adversary’s goal stays the same – forging an authentication token for the honest user – which he must not be able to do significantly better than through testing $q_f$ of the $|\mathcal {D}_{\textsf{pw}}|$ passwords where $q_f$ is the number of queries made to the $\mathcal {O}_{\textsf{TestPW}}$ oracle.

Note that proving a concrete scheme to satisfy this property inherently requires some idealized assumption such as the random oracle, which needs to get invoked on the user’s password – otherwise we could simply not count the offline password guesses.

Definition 5

(Offline Unforgeability). A $\textsf{mkPBC}$ scheme is offline unforgeable, if for all PPT adversaries $\mathcal {A}$ it holds that $Pr [\textsf{Exp}_{\mathcal {A},\textsf{mkPBC}}^{\textsf{offlineUNF}}(\lambda )=1]\le \frac{q_{f}}{|\mathcal {D}_{\textsf{pw}}|} + \textsf{negl}(\lambda )$, where $q_{f}$ is the number of queries to the oracle $\mathcal {O}_{\textsf{TestPW}}$.

PW-Hiding. This property guarantees that a malicious server learns nothing about the user’s password, or rather that a user-specific key $avk$ – despite being derived from a user password $pw$ – does not leak any information about $pw$.

To model this property, we follow the classic indistinguishability approach. The adversary chooses two passwords $pw_0$ and $pw_1$ for a user uid. The challenger randomly chooses a bit b and runs the registration protocol for user $uid$ and $pw_b$, yielding $ask$ and $avk$. It hands $avk$ to the adversary, whose goal is to output the correct bit b better than through guessing. To model any possible leakage through other parts of the PBC system, we also grant the adversary access to an $\mathcal {O}_{\textsf{Sign}}$ oracle which is keyed with $ask$ and $pw_b$.

Definition 6

(Pw-Hiding). A $\textsf{mkPBC}$ scheme is pw-hiding, if for all PPT adversaries $\mathcal {A}$ it holds that $Pr [\textsf{Exp}_{\mathcal {A},\textsf{mkPBC}}^{\mathsf {PW-Hiding}}(\lambda )=1]\le 1/2 + \textsf{negl}(\lambda )$.

4 Our Instantiation: Sign-Then-Encrypt Based Scheme

In this section, we describe $\textsf{PBC}_{\textsf{StE}}$ which securely realizes all security guarantees described in Sect. 3. Our scheme is conceptually entirely different from the one proposed by Zhang et al. [26], which essentially relied on a DL-based algebraic MAC. Our scheme is generic and soley relies on basic building blocks: a signature scheme, encryption scheme and a pseudorandom function. In order to prove security, we need two less common properties from the signature scheme in addition to unforgeability: complete robustness and randomness injectivity. We stress that both are natural assumptions and argue that they are satisfied by standard signatures schemes such as Schnorr, DSA and BLS. We start by defining the main building blocks and their required security properties before describing our provably secure construction.

4.1 Building Blocks

We now introduce the building blocks needed for our construction, focusing on the lesser known properties that we will require from the signature scheme.

Notation. Since our construction depends on a signature scheme with deterministic key generation algorithm using explicit randomness, we write “$y:=A(x;r)$” to highlight that the output y is derived deterministically by algorithm A on input x with randomness r. Conversely, when we write “$y\leftarrow A(x)$”, the output y may be derived either deterministically or probabilistically by algorithm A from input x. We utilize “$s\xleftarrow {r}S$” to denote the uniformly random sampling of a value s from the set S.

Pseudorandom Function. We require a secure PRF $F:\{0,1\}^{\lambda }\times \mathcal {X} \rightarrow \mathcal {Y}$. In some of our security experiments, the adversary will be in possession of the PRF key, and we still want unpredictability of outputs – we then resort to assuming F to be a random oracle for the combined input domain of $\{0,1\}^{\lambda }\times \mathcal {X}$.

Public-Key Encryption. A public-key encryption (PKE) scheme $\varPi _{Enc}:=(\textsf{KGen}_E,$ $\textsf{Enc},\textsf{Dec})$ consisting of key generation $(pk_{\textsf{Enc}},sk_{\textsf{Enc}})\leftarrow \textsf{KGen}_E(1^{\lambda })$, an encryption $c \leftarrow \textsf{Enc}(pk_{\textsf{Enc}},m)$ and decryption algorithm $m \leftarrow \textsf{Dec}(sk_{\textsf{Enc}},c)$. We require $\varPi _{Enc}$ to be indistinguishable against chosen-ciphertext attacks (IND-CCA).

Signature Scheme. A signature scheme $\varPi _{Sign}:=(\textsf{Setup}_S,\textsf{KGen}_S,\textsf{Sign}_S,\textsf{Vf}_S)$ with setup $pp \leftarrow \textsf{Setup}(1^{\lambda })$, key generation $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}) := \textsf{KGen}( pp ;r)$ for randomness r, sign algorithm $\sigma \leftarrow \textsf{Sign}_S(sk_{\textsf{Sig}},m)$, and verify algorithm $b \leftarrow \textsf{Vf}_S(pk_{\textsf{Sig}}, m, \sigma )$. Note that we make the randomness used in key generation explicit and assume $\textsf{KGen}$ to be a deterministic function when given randomness $r \in \mathcal {R}_\lambda$ as input. $\mathcal {R}_\lambda$ is part of the public parameters $pp$ and denotes the randomness space. We require the scheme to be existentially unforgeable under chosen-message attacks (EUF-CMA): It must be infeasible for an adversary given $pk_{\textsf{Sig}}$ from $(sk_{\textsf{Sig}},pk_{\textsf{Sig}}) := \textsf{KGen}( pp ;r)$ for random $r \xleftarrow {r}\mathcal {R}_\lambda$ and access to a sign oracle to produce a valid signature on a fresh message. Our construction requires two additional properties: complete robustness and randomness injectivity.

Complete Robustness. Géraud and Naccache [12] formalized the notion of complete robustness which requires that it should be hard for an adversary to find a message-signature-pair which verifies under two different public keys.

Definition 7

(Complete Robustness). A signature scheme $\varPi _{Sign}:=(\textsf{Setup},$ $\textsf{KGen},\textsf{Sign},\textsf{Vf})$ achieves complete robustness (CROB) or is CROB-secure if for $pp \leftarrow \textsf{Setup}(1^{\lambda })$ it holds that for every PPT $\mathcal {A}$, the probability $Pr [(pk,pk',m,\sigma )\leftarrow \mathcal {A}( pp ): pk\ne pk' \wedge \textsf{Vf}(pk,m,\sigma )=\textsf{Vf}(pk',m,\sigma )=1]$ is negligible in $\lambda$.

Randomness Injectivity. The second property we need is randomness injectivity which requires that the $\textsf{KGen}$ algorithm is injective on the randomness space. We call a signature scheme randomness injective if it is hard for an adversary to find two distinct values $r,r'\in \mathcal {R}$, which, when given to $\textsf{KGen}$, map to the same sk or pk. This also implies that for every public key there exists only one secret key. In Appendix C, we give a formal definition of randomness injectivity.

4.2 Our $\textsf{PBC}_{\textsf{StE}}$ Protocol

The idea of our protocol – referred to as $\textsf{PBC}_{\textsf{StE}}$ – is surprisingly simple and turns classic signature-based authentication into a secure $\textsf{mkPBC}$. In the following, we describe the intuition and give the full description in Fig. 3.

Upon registration, the user generates a signature key pair $(pk_{\textsf{Sig}},sk_{\textsf{Sig}})$ and sends the public key $pk_{\textsf{Sig}}$ to the server. Such a key pair enables strong authentication through signing $(uid,m)$, but all security will be lost when an attacker gets access to the user’s signing key. We therefore do not store (or even generate) the key normally, but derive it deterministically as $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}) := \textsf{KGen}_S( pp ;F(k,pw))$ from a PRF key k and the user’s password $pw$. The user now only stores the PRF key k and re-derives the signature key pair when she wants to generate an authentication token.

This solution already satisfies strong and offline unforgeability as well as password hiding. The challenge is to also guarantee online unforgeability, i.e., ensuring that the knowledge of the user’s key and an authentication token does not allow to brute-force the password. So far, this isn’t achieved as an attacker who knows k and a valid signature $\sigma$ can mount an offline password test by computing possible key-pairs $(pk_{\textsf{Sig}}',sk_{\textsf{Sig}}')$ from password guesses $pw'$ until he has found the correct $pw'$ under which $\sigma$ verifies.

Preventing Offline Attacks. We prevent this offline attack by hiding the actual signature $\sigma$ in the token. Therefore, we let the user encrypt $\sigma$ under an encryption public-key $pk_{\textsf{Enc}}$ to which the server knows the corresponding secret key $sk_{\textsf{Enc}}$. More precisely, $(pk_{\textsf{Enc}}, sk_{\textsf{Enc}})$ is a key pair that the user normally generated upon registration, where she keeps $pk_{\textsf{Enc}}$ as part of her credential, i.e., $ask=(k,pk_{\textsf{Enc}})$ and sends the secret decryption key to the server, i.e., $avk=(sk_{\textsf{Enc}},pk_{\textsf{Sig}})$. Now, only the server knowing $sk_{\textsf{Enc}}$ can recover the signature from the authentication token and verify its validity. Thus, this encryption finally turns the verification into a secret-key operation, which is essential for the desired online unforgeability. We stress that this additional and explicit encryption layer is essential for our security and cannot be achieved from assuming secure channels between the user and server: honest user’s can be subject to phishing attacks, and accidentally send authentication tokens to a malicious server.

The Challenge of Proving Online Unforgeability. While the additional encryption immediately removes the obvious offline attack, proving that this is sufficient to achieve online unforgeability is not straightforward.

The challenge is that the adversary knows the PRF key k and can offline attack the password and thereby recover the secret signing key $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}) := \textsf{KGen}_S( pp ;F(k,pw))$. Once he knows the correct secret key there is no security left. And indeed, we cannot rely on any unforgeability guarantees of the signature for this proof. The reason why our scheme is still secure stems from the fact that the adversary does not know which key is the correct one: he does not know $pk_{\textsf{Sig}}$ (this is part of the server’s secret key) nor any signature value (they are encrypted under the server’s key). The only way for $\mathcal {A}$ to learn whether a recovered key is correct, is to compute a signature and send it for validation to the server. The crucial part in our proof is to show that every interaction with the honest server for such a verification is bound to a single password guess only, ensuring the desired online unforgeability.

To illustrate how the signature scheme could allow multiple password tests in one interaction, consider a signature $\sigma$ on m which verifies under two different public keys $pk_1$ and $pk_2$ constructed from passwords $pw_1$ and $pw_2$. If the adversary sends $(m,\sigma )$ to the server and learns that the signature is not valid, he concludes that the server’s public key is neither $pk_1$ nor $pk_2$ and has ruled out the two passwords $pw_1$ and $pw_2$ with one interaction. Hence, we require that every signature verifies under at most one public key which is achieved through complete robustness. Another way how the signature scheme could allow multiple password tests is if the public key $pk_1$ can be constructed from multiple passwords $pw_1$ and $pw_2$. Therefore, we require that every password maps to a unique secret key and unique public key. This is achieved if F is injective, and if the signature scheme has randomness injectivity.

4.3 Security Analysis

In this section, we provide the main security theorems for our $\textsf{PBC}_{\textsf{StE}}$ scheme and sketch their proofs. The detailed proofs are given in the full version of the paper [9]. Table 1 provides an overview of the different security properties and the necessary assumptions on the building blocks of $\textsf{PBC}_{\textsf{StE}}$.

Fig. 3.

Our $\textsf{PBC}_{\textsf{StE}}$ scheme.

Theorem 1

If F is a secure PRF and $\varPi _{Sign}$ is an EUF-CMA secure signature scheme, then $\textsf{PBC}_{\textsf{StE}}$ is strongly unforgeable.

Proof

(Sketch). In the strong unforgeability game, the adversary knows the verification key $avk=(pk_{\textsf{Sig}},sk_{\textsf{Enc}})$ and password $pw$ of a user $uid$, but not the user credential $ask=(k, pk_{\textsf{Enc}})$. He does have access to a sign oracle $\mathcal {O}_{\textsf{Sign}}$ that creates tokens for $ask$, and $\mathcal {A}$ wins if he can create an authentication token $\tau ^*$ which verifies under $avk$ on a fresh message $m^*$. In this proof, we can ignore the encryption, as the adversary knows $sk_{\textsf{Enc}}$, i.e., for all tokens returned by $\mathcal {O}_{\textsf{Sign}}$, he can recover the contained signature derived from $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}) := \textsf{KGen}_S( pp ;F(k,pw))$. Thus, the task of the adversary boils down to forging a standard signature under the unknown $sk_{\textsf{Sig}}$. This is infeasible if the signature scheme is unforgeable (EUF-CMA) under the assumption that the PRF-derived secret key is indistinguishable from a randomly chosen one. The latter follows from the pseudorandomness of F which concludes our proof.

Theorem 2

If F is a random oracle, $\varPi _{Sign}$ is completely robust and randomness injective, and $\varPi _{Enc}$ is CCA-secure, then $\textsf{PBC}_{\textsf{StE}}$ is online unforgeable.

Proof

(Sketch). Here, the adversary knows the high-entropy credential $ask=(k, pk_{\textsf{Enc}})$ of a user $uid$, but neither her password $pw$ nor the corresponding verification key $avk=(pk_{\textsf{Sig}},sk_{\textsf{Enc}})$. Both are accessible through the $\mathcal {O}_{\textsf{Sign}}$ and $\mathcal {O}_{\textsf{Vf}}$ oracle though. We must show that if $\mathcal {A}$ outputs a valid token $\tau ^*$ for a fresh message $m^*$ for $uid$, he must have conducted a successful online-attack on the password. In this proof, we first show that, due to the CCA-security of encryption, the $\mathcal {O}_{\textsf{Sign}}$ oracle does not give the adversary any information about the underlying signature. Then, we argue that the adversary knows the PRF key k and may offline guess passwords to create possible key pairs $(pk_{\textsf{Sig}}',sk_{\textsf{Sig}}'):=\textsf{KGen}_S( pp ;F(k,pw'))$ and forge signatures under $sk_{\textsf{Sig}}'$. However, in order to create a valid authentication token, he needs to use the correct secret key $sk_{\textsf{Sig}}$. As the correct $pk_{\textsf{Sig}}$ is part of the secret $avk$ and $\mathcal {A}$ never sees any signature $\sigma _i$, his only chance of learning which key is correct, is by using the verify oracle $\mathcal {O}_{\textsf{Vf}}$. Complete robustness of the signature ensures that every interaction with $\mathcal {O}_{\textsf{Vf}}$ only leaks whether $pk_{\textsf{Sig}}=pk_{\textsf{Sig}}'$, allowing a single public-key guess per query. The injectivity of F and the randomness injectivity of $\varPi _{Sign}$ ensure that this $pk_{\textsf{Sig}}'$ maps to a single password guess, thus the adversary can only guess one password per interaction with $\mathcal {O}_{\textsf{Vf}}$. This concludes our proof.

Theorem 3

If F is a random oracle and if $\varPi _{Sign}$ is EUF-CMA secure and randomness injective, then $\textsf{PBC}_{\textsf{StE}}$ is offline unforgeable.

Proof

(Sketch). In the offline unforgeability game, the adversary now knows all keys, i.e.,. $ask=(k,pk_{\textsf{Enc}})$ and $avk=(pk_{\textsf{Sig}},sk_{\textsf{Enc}})$ of a user $uid$. The only secret left is her password $pw$, and we must show that forging a fresh token $m^*, \tau ^*$ for $uid$ requires to (at least) offline-attack the password. Note that the adversary is given k here, but not the actual signature key $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}):= \textsf{KGen}_S( pp ;F(k,pw))$, which still depends on the password. Thus the task of $\mathcal {A}$ again boils down to forging a valid signature under $pk_{\textsf{Sig}}$. He could either aim at forging the signature directly, i.e., without trying to recover the secret key, or brute-force the password to compute $sk_{\textsf{Sig}}$, as then creating a signature is trivial. The former is infeasible if the signature is unforgeable, and the latter is bounded by the number of password guesses if the signature is randomness injective (RI) and F a random oracle. RI guarantees that there is only one value $r=F(k,pw)$ such that $(pk_{\textsf{Sig}},sk_{\textsf{Sig}})=\textsf{KGen}_S( pp ;r)$, i.e., there is only a single password that leads to the correct key. Since the password $pw$ was chosen uniformly at random from $\mathcal {D}_{\textsf{pw}}$, the adversary needs to query the random oracle F for each password guess, and after $q_F$ queries his success probability is bounded by $q_F/|\mathcal {D}_{\textsf{pw}}|$.

Theorem 4

If F is a secure PRF, then $\textsf{PBC}_{\textsf{StE}}$ is pw-hiding.

Proof

(Sketch). Recall that in the pw-hiding game the adversary receives a verification key $avk=(pk_{\textsf{Sig}},sk_{\textsf{Enc}})$ that is either derived for $pw_0$ or $pw_1$, and his task is to determine the underlying password. In our scheme, the only password-dependent information is $(pk_{\textsf{Sig}},sk_{\textsf{Sig}}) := \textsf{KGen}_S( pp ;F(k,pw_b))$. The adversary knows $pk_{\textsf{Sig}}$, but not the PRF key k, and has access to the key through the sign oracle for $ask=(k,pk_{\textsf{Enc}})$. As k is chosen at random from $\{0,1\}^{\lambda }$, it immediately follows from the PRF property that the adversary cannot distinguish whether $pk_{\textsf{Sig}}$ was created from $r=F(k,pw_b)$ or r chosen at random from $\mathcal {R}_\lambda$. Since in the latter case, the $avk$ is independent of the password, the pw-hiding property follows. Note that we do not require any property from the signature scheme here, as the pw-hiding concerns confidentiality of the password instead of unforgeability as the other three properties.

Concrete Instantiation of Building Blocks. The requirements for both the PRF and PKE are standard, so we only focus on how randomness injectivity and complete robustness can be achieved by a signature scheme. In Appendix D, we show that the DL-based standard signature schemes DSA [16], Schnorr [21] and BLS [5] all achieve both properties (apart from being (EUF-CMA) unforgeable).

Notable signature schemes which are not completely robust include RSA, GHR and Rabin signatures (see [17]). Nevertheless, Géraud and Naccache [12] show a generic method to transform any signature scheme into a completely robust scheme by appending a hash of the public key to the signature. This transformation also preserves the unforgeability property of the scheme.

5 Related Work

While our work builds upon the novel PBC work by Zhang et al. [26], we also put it in a bigger context of password-based authentication schemes.

Works Without Online Unforgeability. Isler and Küpcü [14] give an overview of existing schemes where a user authenticates with the combination of a password and a password-based credential. As in PBCs, the password-based credential is not directly the user’s secret key but only a password-protected version of it. They analyzed several existing works [2,3,4, 13, 15] and argued that most are not resistant against server-compromise and proposed a new scheme. The main drawback of all schemes (except DE-PAKE [15], discussed below) is that they do not achieve the same strong online unforgeability as [26] and our work. Roughly, when the password-based credential got compromised, their model only guarantees security when the adversary never sees any authentication token from the honest user, thus excluding phishing attacks from their model. Our work provides online unforgeability without assuming full secrecy of tokens.

DE-PAKE. Device Enhanced PAKE by Jarecki et al. [15] is a variant of password-authenticated key exchange where a user and a server derive a shared key based on the user’s knowledge of a strong key (stored on an auxiliary device) and a password. Jarecki et al. show a generic solution which uses the Ford-Kaliski method [11] to strengthen her password into a strong key using a PRF and uses this strong key in an asymmetric PAKE protocol to derive a shared key with the server. Our work uses the same PRF-based method to strengthen a password into a key. Similarly to the work of Jarecki et al., we aim to achieve optimal protection against online and offline attacks, albeit in the context of pure user authentication instead of key exchange. Our $\textsf{PBC}_{\textsf{StE}}$ scheme uses simpler building blocks than the solution presented in [15]. As our scheme allows for non-interactive generation of challenge messages (e.g., by hashing the user id with a current timestamp), we can even achieve the optimal solution of user authentication with one message.

6 Conclusion

We revisited the existing framework of password-based credentials from Zhang et al. [26] and found that an important security property was missing – the resistance to server compromise. We showed that achieving this level of security is impossible in their single-key framework. While the attack is simple, it is of practical relevance considering that data breaches happen frequently. This motivated us to propose a new framework called multi-key password-based credentials which remain secure in the presence of server compromise. We established formal definitions for the optimal security levels and proposed a solution that utilizes generic building blocks and satisfies all desirable security properties.

Given the simplicity of our construction, an immediate question is whether our multi-key setting is somehow weakening the overall security guarantees, when compared with the single-key ZWV version. We argue in Appendix B that the opposite is true by showing how a secure $\textsf{mkPBC}$ can be transformed into a secure $\textsf{skPBC}$ scheme.

Appendices

A The ZWY Framework

In order to improve the clarity and the consistency with our framework of $\textsf{mkPBC}$ we made some minor changes to the syntax and security definitions of Zhang et al. [26]. We explain the changes and why this does not affect the technical result. Further, we highlight one of the shortcomings of the ZWY framework: It does not consider the registration of corrupt users.

Changes to the Syntax. We made the following minor changes to the syntax of ZWY [26]: (1) We do not explicitly describe the behaviour of the registration protocol if a party aborts. (2) We do not enforce the registration protocol to keep a registry Reg with $uid$’s but assume this happens on the application level.

Changes to the Security Experiments. The ZWY framework models password compromise through an oracle which reveals honest users’ passwords. Since in the weak and strong unforgeability definition, the win condition of the adversary is independent of his knowledge of $pw$, we did not model this oracle but instead hand the adversary all user passwords directly.

Furthermore, the ZWY framework considers the forgery of a user who has not registered with the server a valid attack, while we removed this condition from the security experiment. We argue that this type of forgery is not a concern as it will be caught on the application level. This change was made to focus on attacks that are relevant to the security of the system.

No Registration Oracle. We note that the ZWY security model [26] has another weakness: it does not allow corrupt users to register, which allows to prove entirely insecure schemes secure (e.g. the server sends his secret key $ssk$ to the user during registration). We stress that this is primarily an oversight in the security model, and can be easily fixed by granting the adversary such registration access. We do not see any issue in the concrete $\textsf{skPBC}$ scheme proposed in [26] and conjecture that it can be proven secure in this adjusted security model.

B Comparison of $\textsf{mkPBC}$ and $\textsf{skPBC}$

Given the simplicity of our construction, an immediate question is whether our multi-key setting is somehow weakening the overall security guarantees, when compared with the single-key ZWV version. We show that the opposite is true by showing how a secure $\textsf{mkPBC}$ can be transformed into a secure $\textsf{skPBC}$ scheme. Our transformation additionally requires symmetric authenticated encryption (AE) scheme, thus can only be seen as a relativized comparison.

Table 1. Overview of the different security properties and the security assumptions needed for the building blocks of our $\textsf{PBC}_{\textsf{StE}}$ scheme. CROB stands for complete robustness and RI is randomness injectivity.

The high-level idea of the transformation is as follows: In order to transform the $\textsf{mkPBC}$ to have only one key, the server outsources storage of the user-specific verification keys $avk$ to the users. In the tranformation, the server in the $\textsf{skPBC}$ scheme has a single long-term key $ssk$ which is the secret key $k_{\textsf{AE}}$ of an AE scheme. In the registration phase, the server and user run the $\textsf{mkPBC}$ registration, but instead of letting the server store the obtained $avk$ it returns its encryption $c\leftarrow \mathsf {AE.Enc}(k_{\textsf{AE}}, (uid,avk))$ to the user. During authentication, the user passes c back to the server by appending it to the authentication token $\tau$ which is computed via the $\textsf{mkPBC}$ process. The server can decrypt c to obtain the verification key $avk$ and verify the user’s token. For the security of the scheme, it is crucial that the user does not learn $avk$ from c otherwise she could run offline attacks. Furthermore, it is important that users cannot pass the valid ciphertext of a different verification key $avk'$ to the server as this would allow forgeries. Both, confidentiality and integrity, is achieved by using a secure authenticated encryption scheme.

In the full version, we prove that his transforms yields an online and weakly unforgeable $\textsf{skPBC}$, if $\textsf{mkPBC}$ is online and strongly unforgeable and AE is a secure authenticated encryption scheme.

C Formal Definitions

In this section, we give formal definitions for the correctness of a $\textsf{mkPBC}$ scheme, and for the randomness injectivity of a signature scheme.

Definition 8

(Correctness of $\textsf{mkPBC}$). A $\textsf{mkPBC}$ scheme is correct, if for all $pp \leftarrow \textsf{Setup}(1^{\lambda })$, $(uid,pw)\in \mathcal {D}_{\textsf{uid}}\times \mathcal {D}_{\textsf{pw}}$, $m\in \mathcal {M}$ it holds that: $\textsf{Vf}(uid,avk,m,$ $\textsf{Sign}(uid,ask,pw,m))=1$ where $(ask; avk)\leftarrow \langle \textsf{RegU}(uid,pw), \textsf{RegS}(uid)\rangle$.

Definition 9

(Randomness Injectivity). A signature scheme $\varPi :=(\textsf{Setup},$ $\textsf{KGen},\textsf{Sign},\textsf{Vf})$ is called randomness injective if for $pp \leftarrow \textsf{Setup}(1^{\lambda })$ with $\mathcal {R}_\lambda \in pp$, it holds that for every PPT $\mathcal {A}$, the following probability is negligible in $\lambda$:

$$\begin{aligned} Pr [&(r,r')\leftarrow \mathcal {A}( pp ): r,r'\in \mathcal {R}_\lambda \wedge r\ne r' \wedge (sk= sk' \vee pk= pk') \\ {} &\text {for } (pk,sk)\leftarrow \textsf{KGen}( pp ;r), (pk',sk')\leftarrow \textsf{KGen}( pp ;r') ] \end{aligned}$$

D Signatures with Complete Robustness

In this section, we show that DSA [16], Schnorr [21] and BLS [5] signatures achieve complete robustness and randomness injectivity.

Theorem 5

The DSA, Schnorr and BLS signature scheme all achieve randomness injectivity information-theoretically. DSA and Schnorr are CROB-secure assuming a collision-resistant hash function, and BLS is information-theoretically CROB-secure.

Proof

For the randomness injectivity, observe that DL-based signature schemes where it holds that $pk=g^{sk}$ for $sk\xleftarrow {r}\mathbb {Z}_q$ achieve randomness injectivity by setting $\mathcal {R}_\lambda =\mathbb {Z}_q$ and $(g^r,r):=\textsf{KGen}( pp ;r)$.

Since the complete robustness only considers the verification algorithm we can ignore the key generation and signing algorithms. We argue about complete robustness for each of the signatures individually:

• DSA: In DSA, a signature $\sigma :=(r,s)$ verifies for m under pk if $F(g^{H(m)\cdot s^{-1}}\cdot pk^{r\cdot s^{-1}})=r$ for two hash functions F and H. Thus, $\sigma$ verifies under a second public key $pk'$ only if $F(g^{H(m)\cdot s^{-1}}\cdot pk^{r\cdot s^{-1}})=F(g^{H(m)\cdot s^{-1}}\cdot (pk')^{r\cdot s^{-1}})$ which happens only with negligible probability if F is collision resistant.

• Schnorr: In Schnorr signatures, a signature $\sigma =(r,s)$ verifies under pk for message m if $H(g^s\cdot pk^{-r},m)=r$ for a hash function H. Thus, $\sigma$ verifies under a second public key $pk'$ only if $H(g^s\cdot pk^{-r},m)=H(g^s\cdot (pk')^{-r},m)$ which happens only with negligible probability if the hash function H is collision resistant.

• BLS: In BLS signatures, a signature $\sigma$ verifies under pk for message m if $e(\sigma ,g)=e(H(m),pk)$. Thus, it verifies under a second public key $pk'$ only if $e(H(m),pk)=e(H(m),pk')$. But this means that $pk=pk'$ and the signature only verifies under a single public key $pk=pk'$.