CPace Protocol—From the Perspective of Malicious Cryptography

Abstract

The CPace protocol (Internet-Draft:draft-irtf-cfrg-cpace-14) is a password-authenticated key exchange optimized for simplicity. In particular, it involves only two messages exchanged in an arbitrary order. CPace combines a simple and elegant design with privacy guarantees obtained via strict mathematical proofs. In this paper, we go further and analyze its resilience against malicious cryptography implementations. While the clever design of CPace immediately eliminates many kleptographic techniques applicable to many other protocols of this kind, we point to the remaining risks related to kleptographic setups. We show that such attacks can break the security and privacy features of CPace. Thereby, we point to the necessity of very careful certification of the devices running CPace, focusing in particular on critical threats related to random number generators.

1. Introduction

An interaction between a user and a system in cyberspace requires, in most cases, the creation of a secure communication channel between them. In this context, we usually think about a device A acting on behalf of the user and a device B serving as a gateway to the system. However, in reality, we have to deal with three participants: a user, a device A, and a device B. Moreover, the user can be passive only when there is no significant threat to allow A to act on behalf of the user without their control. In other cases, explicit consent of the user is necessary. If personal data are exchanged between A and B (as is usually the case), then the user’s consent is mandatory according to data protection regulations such as European GDPR [1]. Moreover, the communication architecture should guarantee security and privacy by design: only those parties should be able to read the data exchanged, which are indicated by the user’s consent.

1.1. PAKE—Password-Authenticated Key Exchange

The idea of PAKE (Password-Authenticated Key Exchange) is to enable users’ consent based on password presentation while binding this consent to a specific communication session in a cryptographic way. A PAKE protocol executed by devices A and B determines a session key K so that

• A and B can calculate K, but no other party with access to the interaction between A and B can derive K.
• The protocol fails unless the same password, $\mathsf{PRS}$, is used by A and B.
• A party observing the interaction cannot derive password $\mathsf{PRS}$ by an offline analysis or by an active man-in-the-middle attack, where the adversary manipulates the messages exchanged (potentially leading to protocol abortion by the legitimate participants).

• A PAKE protocol can be run independently or it can be integrated into a protocol stack where, for example, the identity of devices A and B is checked based on the possession of secret keys. There is no universal scenario indicating which party initiates the protocol, as this may depend on an application. Figure 1 shows the case where PAKE is used to authenticate a user and create a connection instead of a traditional (password, login) mechanism. The difference is that the password is already used at the stage of creating a connection and, due to the properties of the PAKE protocol, no shared key is established if different passwords are used by protocol participants. Typically, an execution of PAKE is initiated by a user who wishes to enter their account in the system. In this scenario, a phishing attack would fail: the attacker providing the phishing page would not establish a connection to the victim user, unless the attacker already knows the user’s password.

Figure 1. Example application scenarios for PAKE: A user holding a password $\mathsf{PRS}$ connects to a remote system, where a database stores a password for each user. The password is entered by the user on the local computer, while in the remote system, it is fetched from a database by the gateway unit of the system. The connection succeeds if and only if the passwords on both sides match. If the connection fails, the communicating parties learn only that the passwords used do not match.

Figure 1. Example application scenarios for PAKE: A user holding a password $\mathsf{PRS}$ connects to a remote system, where a database stores a password for each user. The password is entered by the user on the local computer, while in the remote system, it is fetched from a database by the gateway unit of the system. The connection succeeds if and only if the passwords on both sides match. If the connection fails, the communicating parties learn only that the passwords used do not match.

Another application case to mention is an e-booth for automatic passport control (see Figure 2).

Several password authentication protocols have been developed over the decades. For a general discussion on the topic, design trends, and reality issues, see [2]. Some of the protocols became widespread, such as the PACE protocol [3] adopted by the ICAO for travel documents [4], and later by the European Union as a standard for personal identity documents in the Union.

1.2. CPace Protocol

In 2020, CPace (see the Internet Draft: https://www.ietf.org/archive/id/draft-irtf-cfrg-cpace-11.html (accessed on 18 August 2025) [5]) has been selected by the IRTF Crypto Forum Research Group (CFRG) as the recommended PAKE protocol. CPace is a symmetric protocol. This means that it is not specified in advance who is the protocol initiator, and that the operations performed on either side are the same; only the parameters change. (This is not the case for the widely used PACE protocol for biometric passports, where the passport initiates the interaction and where the roles of the passport and the reader are different.) Therefore, although CPace is intended to be used for interaction between a user device $\mathsf{D}$ and a server (maybe a remote one), the description of the protocol frequently refers to party A and party B.

CPace is presented in

Table 1. CPace protocol flow.

Party A	Party B
holds:		holds:
- password $\mathsf{PRS}$		- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$		- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$		- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$		- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$		$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$		$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$Y_A:=y_A·G$		$Y_B:=y_B·G$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$K:=y_A·Y_B$		$K:=y_B·Y_A$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$		$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$		$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$		$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$		output session key $\mathsf{ISK}$

. As one can see, CPace is an extremely simple protocol with only 2 messages exchanged between the communicating parties. This is the minimal number of messages for a scenario in which each party can randomize the final key and where a low-entropy password is the only secret shared by the communicating parties.

The first important feature of CPace is that the communicating parties derive a shared group generator G using the shared password. This is a feature common with the seminal SPEKE protocol [6] and PACE in the version PACE IM (Integrated Mapping) [4]. In the case of SPEKE, the generator is a hash of the password, which leads to protocol weaknesses. PACE IM and CPace follow a different strategy: for each execution of the protocol, the generator is different. PACE IM creates the generator by hashing two random nonces, one of which was earlier transmitted by the user’s device in the form of a ciphertext obtained with an encryption key derived from the password. CPace is simpler and does not require extra messages: the generator G is derived as

$$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$$

where $\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}$ is a procedure that applies a hash function specified by the parameter $\mathsf{Hash}$ to the input obtained by concatenating the password $\mathsf{PRS}$, the channel identifier $\mathsf{CI}$, and the unique session identifier $\mathsf{sid}$. The parameters $\mathsf{CI}$ and $\mathsf{sid}$ are obtained from a higher-level protocol. As the parameters $\mathsf{CI}$ and $\mathsf{sid}$ must not repeat, each protocol execution refers to a different generator G, and due to the properties of the hash function, it is computationally infeasible to derive the discrete logarithm of G with respect to the standard generator P of the group used (that is, in the additive group notation, a scalar k such that $G=k·P$). Similarly, it is computationally infeasible to derive any relationship between the discrete logarithms of G’s from two different protocol executions.

Recall that in the widely used PACE GM (General Mapping) protocol, there is a Diffie–Hellman key exchange based on a standard generator that produces an element h. In turn, h is used to determine $\widehat{g}:=h·g^s$ (according to the original multiplicative group notation), where s is a random nonce generated by the passport and encrypted using the password-derived key. Finally, no one knows the discrete logarithm of $\widehat{g}$; element $\widehat{g}$ depends on the password, but the procedure is more complicated and less resistant to implementation attacks.

Note that an observer $\mathsf{Adv}$ cannot generate G from the CPace protocol; however, they can derive a candidate G for each possible password, provided that $\mathsf{Adv}$ has access to $\mathsf{CI}$ and $\mathsf{sid}$. Since passwords have low entropy, this is feasible. (An interested reader may notice that this is also possible for the already mentioned PACE IM but not for PACE GM.)

The next stage of the algorithm is a Diffie–Hellman key exchange and its result is a shared master key K. For Diffie–Hellman key exchange, the critical point is to choose the scalars $y_A$ and $y_B$. The function $\mathsf{sample}\_\mathsf{scalar}$ is used for this purpose. It intends to choose a scalar smaller than the group order uniformly at random. According to the specification, $\mathsf{sample}\_\mathsf{scalar}$ is a function returning a representation of an integer (referred to as a “scalar” from now on) appropriate as a private Diffie-Hellman key for the group, and some deviations from uniform distribution are allowed.

Once the master key K is created, on each side independently, the parties derive the key $\mathsf{ISK}$ by hashing K together with the parameters that may be called an interaction transcript. This should prevent relay attacks; the key $\mathsf{ISK}$ is the same for parties A and B, if they have the same view of the protocol execution. However, if the views differ, then the keys $\mathsf{ISK}$ derived on both sides should differ according to the collision resistance of the hash function.

The key $\mathsf{ISK}$ is called the “intermediate session key’ as the higher-level protocol can derive other keys based on the shared key $\mathsf{ISK}$.

Note that in the above-presented version, CPace does not contain any key confirmation mechanism. However, the authors discuss extensions of the basic scheme in this direction. Typically, key confirmation is based on a tag created by a deterministic algorithm, so that a valid tag can be created only by a party holding the right key, and where the tag does not enable to derive the key used to create the tag. Since there is not much room for attacks via key confirmation tags, we will concentrate on the main part of CPace.

In this paper, we do not need to go into detail about why the CPace construction is sound, what the backgrounds are for particular design choices, etc. The reason is that our goal is to check its resilience to implementation attacks and to find what can go wrong.

1.3. Security Analysis of CPace

Proving the security of a PAKE protocol in a real-world setting is a tricky issue. First, the number of attack scenarios is quite large. They may involve situations such as concurrent execution of the same protocol by a user with different services, exploiting false executions, small errors when inputting the passwords, etc. The adversary is not always external: for example, it may happen that a card reader B learns the password $\mathsf{PRS}$ used by card A during a legitimate interaction, and later the operator of B uses $\mathsf{PRS}$ to track A interacting with other card readers through a wireless radio channel.

Many problems may arise when a PAKE protocol is embedded in a protocol stack. A PAKE protocol that is secure in a standalone scenario can become insecure after such an embedding, or, at least, the security arguments no longer hold (this is the so-called universal composability problem).

The complexity of the security analysis of a PAKE protocol grows rapidly with the complexity of the protocol. It is a real challenge to make it complete in the real sense and not only according to a selected abstract model. Even for relatively compact protocols such as PACE, analyzing all options may become very tedious [7].

From the point of view of security analysis and immunity against attacks, the simplicity of CPace is a great advantage. Note that essentially the only messages exchanged between the parties executing CPace are two random group elements $Y_A,Y_B$. Their distribution does not depend on the password $\mathsf{PRS}$ for cyclic groups and uniformly chosen $y_A$ and $y_B$. So, intuitively, an external observer has neither any usable source of information on $\mathsf{PRS}$ nor an opportunity for a man-in-the-middle attack. The simplicity of the protocol also reduces the number of implementation errors that may occur. Such errors can be very subtle, and, in particular, they can result from efficiency optimization.

The most critical issue concerning formal security proofs for CPace is that it should be considered not as a standalone protocol but as a protocol embedded in a larger system. This issue has been reflected in the criteria in the IETF selection process. Repeating security proofs for each particular implementation case can be avoided if the protocol analyzed fulfills the properties of universal composability (UC) [8] (see also the IACR technical report [9]). UC means that, from a security point of view, a real implementation of the protocol (in our case, the execution of CPace) can be replaced by an ideal functionality that realizes the goal of the protocol when interacting with the environment. In our case, the ideal functionality assigns a shared secret session key K to the communicating parties if and only if they have the same password. Fine issues concern the abilities of the adversary and the feedback received by the adversary from the ideal functionality. There are subtle differences between the original framework from [8] and the papers that examine the universal composability of CPace.

In [10] (see also [11]), the relaxed PAKE functionality and the lazy extraction PAKE functionality are introduced. CPace falls into the category of protocols for which universal composability with regard to the lazy extraction model has been achieved. The paper [12] shows universal composability for CPace, however, in the AGM (Algebraic Group Model). The AGM imposes restrictions on the group elements returned by the adversary, requiring them to be algebraic in the base elements (that is, in additive group notation, a linear combination of the base elements). In particular, note that a solution to the DH problem for $Y_A$ and $Y_B$ cannot be expressed as an algebraic expression in $Y_A$ and $Y_B$.

An in-depth analysis of CPace in the context of algebraic implementation details versus universal composability can be found in [13] (see also the IACR report [14]). This analysis concerns, for example, issues such as collisions of the mapping deriving the elliptic curve points by the function $\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}$ and the elliptic curve groups of non-prime order.

In a more recent paper [15], the authors investigated the universal composability property of a version of the protocol in which participants do not have to agree on the shared data before entering the protocol.

1.4. Security Analysis vs. Malicious Implementations

Apart from the threats typically considered in the cryptographic literature, it is necessary to take into account subversion attacks. The goal of such attacks is to bring some advantage to the adversary (e.g., to allow tracing a user) while mimicking honest protocol execution. Thus, a user may believe that a strong cryptographic protocol with firm security and privacy guarantees is executed, while in reality, it is a different protocol with backdoors created for the adversary’s advantage.

An implementation can be subverted on purpose, as a part of a development process, or enabled by a security gap in a supply chain [16]. In the case of a software implementation, subversion is also possible during the lifetime of the product, carried out by some malware that has penetrated the operating system. Typically, attacks of this type use asymmetric cryptography: the implementation uses the adversary’s asymmetric key that functionally corresponds to the public key. Thus, extracting this key from an infected implementation is not sufficient to take advantage of the attack: for this purpose, it is necessary to use a matching key (functionally a private asymmetric key) kept by the adversary. In addition, manipulations should be designed in such a way that even knowledge of this “public key” does not allow one to determine, based on the generated output, whether another instance of the device or software is also subverted.

Initially, attacks of this type were known as kleptographic attacks (see the seminal work [17]). Typically, kleptography utilizes random values used by the attacked cryptographic scheme. Many schemes that use the discrete logarithm problem, as well as key generation in the RSA algorithm, are vulnerable to kleptographic attacks (cf. [18,19]). Post-quantum schemes are also unsafe in this regard [20,21].

In summary, a subverted implementation runs the protocol in a malicious way so that an adversary has some advantage while the attack remains undetected. In particular, black box analysis does not allow external observers to distinguish between a fair implementation and a subverted one—the outputs generated by both implementations are perceived by the observers as having the same probability distributions. Only possession of the adversary’s private key allows access to the kleptographic channel. Therefore, kleptographic attacks would be particularly difficult to detect in the case of embedded devices, such as secure elements or smart cards.

It is known that security analysis from the point of view of universal composability does not address the issues of subversion attacks. In practice, full protection against subversion attacks is hardly possible. Fortunately, in some cases, subversion resilience and universal composability can be achieved at the same time. The paper [22] (see also [23]) achieves this by sanitizing a PAKE protocol based on oblivious transfer. The paper [24] achieves the same by enhancing CPace with reverse firewalls. For each protocol participant, the authors of [24] add a reverse firewall that randomizes the elements $Y_A$ and $Y_B$. This reverse firewall chooses $\gamma$ at random and raises $Y_A$ and $Y_B$ to the power $\gamma$ before forwarding them. As a consequence, the elements $Y_A$, $Y_B$ cannot be taken for the computation of $\mathsf{ISK}$.

Although reverse firewalls address one problem, they may create another one. Namely, protocol transcripts for protocol participants become different, and it becomes impossible to detect a man-in-the-middle attack by sending a MAC code of the communication transcript via an independent channel. Moreover, if the adversary finds a way to manipulate parameters $\mathsf{sid}$ and $\mathsf{CI}$ from CPace, then context switching will be possible. Namely, suppose that two sessions are run concurrently between P and $P^{\prime }$ and between P and $P^{\prime \prime }$. In that case, the adversary can change the connections on the fly: party P from session 1 will be connected with party $P^{\prime \prime }$ from session 2, and party P from session 2 will be connected with party $P^{\prime }$ from session 1. Probably, for this reason, the specification of CPace [5] has included the communication transcript in the derivation of $\mathsf{ISK}$. Similarly, the modified CPace protocol from [24] includes identities of the communicating parties as the arguments in the computation of the element G used as the base for the Diffie–Hellman protocol (as a consequence, the session key depends also on the identities of the protocol participants). Note that reverse firewalls cannot be applied to SPAKE2 [25] and SPAKE2+ [26], as these protocols use the protocol transcript as input to the key derivation function. This, at least, shows the tendency in the design of standardized PAKE schemes.

An additional issue is that the reverse firewall increases the complexity of the protocol, while one of the design goals was to keep it as simple as possible. Last but not least, the reverse firewall can be subverted or poorly implemented. Thus, resilience against kleptographic attacks by the reverse firewall must also be shown. For example, while protecting CPace, the reverse firewall can apply rejection sampling to leak other secrets from the system. For example, a reverse firewall may facilitate user tracing.

Apart from reverse firewalls that disrupt malicious communication channels, there are two defense methods. The first method is to split the computation into two or more components so that no component can determine the random elements sent to another protocol party. In our case, this would mean creating $Y_A$ (or $Y_B$) so that no single component can enforce a particular property of $Y_A$ that enables information leakage. Thus, if at least one component is honest, it is impossible to create a hidden communication channel. Unfortunately, it might be quite complex to put together the components originating from different sources and definitely too complex in the case of simple devices.

Another strategy is to deploy a unit that monitors the component executing the protocol. Such a trusted entity is usually called a watchdog. We can assume that it can see all CPace messages; thus, according to the classification given in [27], it is an online watchdog. However, in most cases, a watchdog $\mathsf{W}$ would be physically located as an interface to a component (device) $\mathsf{D}$ that executes CPace. It is reasonable to assume that the communication between a watchdog $\mathsf{W}$ and $\mathsf{D}$ is hidden from the adversary. In fact, if $\mathsf{W}$ and $\mathsf{D}$ do not communicate over a local bus, then they can encrypt messages in such a way that kleptographic leakage on the surface of the ciphertexts (see, e.g., Section 9 in [28]) is prevented.

We assume that the watchdog $\mathsf{W}$ for $\mathsf{D}$ and the other party executing the CPace protocol, for example a reader $\mathsf{R}$, are separate entities because $\mathsf{R}$ might be run by the adversary (compare the scenarios discussed in Section 2.1). While discussing possible malicious implementations in the next session, we focus on feasibility of watchdogs that would effectively detect deviations from CPace.

1.5. Our Contribution

Due to the Spartan design of CPace, one may expect that CPace is relatively safe against implementation attacks. One may have an impression that there is no attack point for undetectable functionalities enabling covert information flow to an adversary. For more complicated PAKE protocols, one can expect that the situation could be different. In fact, broad kleptographic channels can be constructed, for example, for PACE (our work-in-progress).

The paper [24] states that CPace can be corrupted by “biasing the randomness utilized by the subverted algorithms” (randomness subversion) or by replacing the input to the algorithms (input subversion). However, the paper [24] gives no clue as to how these corruptions might be used to the advantage of the adversary. Finding an attack impact is a crucial issue, as immunizing a protocol against attacks that do not bring any advantage to the adversary is likely to be an unnecessary effort from the practical point of view.

Our goal is to verify the extent to which intuition regarding CPace’s resistance to malicious implementations is justified by reality. Our main findings are as follows:

1.

There are surprisingly many ways to corrupt an implementation of CPace and create undetectable information channels to the adversary.

2.

Fixing the problems may require substantial changes in the protocol, thereby eliminating its primary advantages: simplicity, elegance, and ease of implementation.

We maintain a certain level of generality in our considerations, avoiding focusing on specific use cases or implementations. As a result, we do not analyze how to hide or mask malicious functionality from side-channel analysis, as this is specific to the implementation. This is intentional: providing an example implementation of an attack that demonstrates even moderate resistance to side-channel analysis would not only violate our organization’s code of ethics but would also be a crime in the authors’ jurisdiction.

As it will become clear, countering malicious implementation at the protocol level may require changes in the CPace protocol (cf. e.g., Figure 3 in [24]) and increase the complexity of the system by introducing an additional component (a firewall in [24], or a watchdog). The latter brings additional dependencies related to trust management. Therefore, the adequacy of these changes depends on the use case and risk analysis—at the protocol level, we do not find a simple panacea. Consequently, we suggest that in practice, the right way to deal with the problem of subversion attacks could still be to rely on certified software and hardware. For this reason, we discuss the assets to be protected and potential threats against PAKE schemes, which are relevant for subversion attacks. This reshapes the security context of evaluation of a cryptographic product—currently, subversion attacks are not considered in such evaluations. Note that protection profiles and security targets, created according to the Common Criteria framework, contain the section “Security Objective Rationale”, which should include the risk analysis mentioned above, which in turn may indicate adequacy of introducing an additional and independent system component like a firewall or a watchdog.

2. Implementation Attacks

2.1. Establishing a Shared Key with an Adversary

This phase is a stepping stone for an attack, where the adversary is a third party $\mathsf{Adv}$. Depending on which component is involved (a malicious party A or a malicious party B), the key established during this phase is shared by $\mathsf{Adv}$ with A or B.

For the sake of simplicity, we assume that $\mathsf{Adv}$ establishes a shared key with a malicious party A; the case of a malicious party B is symmetric. To focus our attention, let us assume that party A is a device $\mathsf{D}$ owned by a user, and party B is a reader (or a system) that interacts with device $\mathsf{D}$.

There are two general scenarios for establishing a shared key:

1.

Direct interaction: at least once, a malicious device $\mathsf{D}$ interacts with a reader $\mathsf{R}$ run by the adversary $\mathsf{Adv}$ (or vice versa, a malicious reader $\mathsf{R}$ interacts with a device $\mathsf{D}$ subverted by $\mathsf{Adv}$).

2.

Passive adversary: $\mathsf{Adv}$ never interacts with $\mathsf{D}$ or $\mathsf{R}$ but may passively observe protocol executions between them.

• There are also hybrid cases, where $\mathsf{Adv}$ interacts once with a party C and later acts as a passive adversary observing interactions of C with arbitrary parties. Without loss of generality, for the remainder of this subsection, assume that the shared key $\mathsf{ssk}$ has to be established between device $\mathsf{D}$ and adversary $\mathsf{Adv}$.

2.1.1. Direct Interaction

The key K created in the session executed by $\mathsf{D}$ and $\mathsf{R}$ (recognized by $\mathsf{D}$ as a reader controlled by $\mathsf{Adv}$) can be reused to establish a shared key $\mathsf{ssk}$. Namely, it suffices to generate $\mathsf{ssk}$ in a slightly different way from $\mathsf{ISK}$, e.g., by changing the order of arguments:

$$\mathsf{ssk}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGb}\parallel \mathsf{MSGa})$$

If $\mathsf{Hash}$ is a correlated-input secure hash function [29], then, even given the keys $\mathsf{ISK}$ and $\mathsf{ssk}$, it is infeasible to determine whether they originate from the described procedure with the same master session key K, or have been determined independently at random.

2.1.2. Passive Adversary

The key-sharing mechanism is the kleptographic hidden key exchange, frequently used for this purpose (see, e.g., the seminal paper [30]). That is, the shared key $\mathsf{ssk}$ is a result of execution of the ephemeral–static Diffie–Hellman protocol, where the ephemeral key is freshly generated by $\mathsf{D}$ and the static key is provided by $\mathsf{Adv}$. Obviously, the prerequisite for the attack is that a key ${\mathsf{pk}}_{\mathsf{Adv}}$ of the adversary $\mathsf{Adv}$ is known to A. In the cryptographic sense, ${\mathsf{pk}}_{\mathsf{Adv}}$ is a public key, while, in fact, it does not need to be published. $\mathsf{Adv}$ has to hold ${\mathsf{sk}}_{\mathsf{Adv}}$, a matching secret key.

There are the following options for learning ${\mathsf{pk}}_{\mathsf{Adv}}$ by $\mathsf{D}$:

1.

${\mathsf{pk}}_{\mathsf{Adv}}$ is preinstalled in $\mathsf{D}$ by its manufacturer.

2.

${\mathsf{pk}}_{\mathsf{Adv}}$ is uploaded to $\mathsf{D}$ after subverting it.

3.

${\mathsf{pk}}_{\mathsf{Adv}}$ is hidden in $\mathsf{ADa}$ provided by the host computer environment or by the user themselves; this requires a certain degree of randomness implicitly contained in $\mathsf{ADa}$ (an implementation may imply certain limitations for $\mathsf{ADa}$).

4.

Similarly, ${\mathsf{pk}}_{\mathsf{Adv}}$ may be hidden in $\mathsf{sid}$ or $\mathsf{CI}$ generated by a higher-level protocol.

• Note that according to [5], the application layer is responsible for the creation of $\mathsf{sid}$ and $\mathsf{CI}$, so CPace must accept all the values of $\mathsf{sid}$ and $\mathsf{CI}$.

Embedding ${\mathsf{pk}}_{\mathsf{Adv}}$ into seemingly innocent data $\Delta$ requires some effort. For the adversary, the lucky case is that $\Delta$ is supposed to be a random string of length k, where k is sufficiently large. So, $\Delta$ can encode an elliptic curve point ${\mathsf{pk}}_{\mathsf{Adv}}:={\mathsf{sk}}_{\mathsf{Adv}}·G_0$ for ${\mathsf{sk}}_{\mathsf{Adv}}$ generated at random, and for $G_0$ being some fixed group element. The only issue is that the resulting representation of ${\mathsf{pk}}_{\mathsf{Adv}}$ should be uniformly distributed within bit-strings of length k. For this purpose, techniques can be used that map elliptic curve points to strings of length k. For example, one can use the twisted elliptic curves approach [31] or the elligator mapping [32].

However, in the case of a passive adversary, the problem is how to pass an ephemeral key, freshly generated by $\mathsf{D}$, to the adversary $\mathsf{Adv}$. The standard trick is to treat

$$Y_A=y_A·G,$$

as the ephemeral key and then calculate

$$\mathsf{ssk}:=y_A·{\mathsf{pk}}_{\mathsf{Adv}}$$

on the side of $\mathsf{D}$. However, it does not work. The reason is that the public key ${\mathsf{pk}}_{\mathsf{Adv}}$ has been defined with respect to the fixed base $G_0$, and not the base G, freshly generated during the execution of the CPace protocol. More specifically, on the side of $\mathsf{D}$, we would have

$${\mathsf{ssk}}_{\mathsf{D}}=y_A·{\mathsf{pk}}_{\mathsf{Adv}}=y_A·{\mathsf{sk}}_{\mathsf{Adv}}·G_0$$

while on the side of $\mathsf{Adv}$, we would have

$${\mathsf{ssk}}_{\mathsf{Adv}}={\mathsf{sk}}_{\mathsf{Adv}}·Y_A={\mathsf{sk}}_{\mathsf{Adv}}·y_A·G.$$

These values do not match. Thus, the ephemeral key must be computed by $\mathsf{D}$ with the same base $G_0$ as the public key ${\mathsf{pk}}_{\mathsf{Adv}}$ and must be passed covertly to adversary $\mathsf{Adv}$. Let the ephemeral key of $\mathsf{D}$ be denoted by

$${\mathsf{epk}}_{\mathsf{D}}={\mathsf{esk}}_{\mathsf{D}}·G_0.$$

Recall that there is no initial secret key shared with $\mathsf{Adv}$ to hide the transfer of ${\mathsf{epk}}_{\mathsf{D}}$, so the transfer must be carried out in plaintext. If it is impossible to send ${\mathsf{epk}}_{\mathsf{D}}$ in the associated data $A{D}_a$ or at a higher level as, e.g., the $\mathsf{sid}$, then rejection sampling (see [33] Section 4) could be used for this purpose: each transmission reveals a block of (few) bits from a pseudo-random position of ${\mathsf{epk}}_D$. After sufficiently many transmissions, all bits of ${\mathsf{epk}}_D$ would be collected.

Unfortunately for malicious parties, the redundancy present in techniques based on the coupon collector problem (see [33] Section 4) or rejection sampling with a limited number of trials (see [28] Section 4.2) makes the transfer vulnerable to detection. Simply, the same information on ${\mathsf{epk}}_D$ would repeat, while in honest executions, no statistical dependency should be visible.

To avoid detection, rejection sampling can be used to transfer consecutive portions (e.g., 4-bit chunks) of ${\mathsf{epk}}_{\mathsf{D}}$. That is, the ith transmission will carry the ith bit chunk of ${\mathsf{epk}}_{\mathsf{D}}$ as the least significant bits of $Y_A$. Consequently, $\mathsf{Adv}$ must be able to eavesdrop on consecutive executions.

To increase the chances of $\mathsf{Adv}$, after transferring the complete key ${\mathsf{epk}}_{\mathsf{D}}$, the implementation of the device $\mathsf{D}$ can deterministically derive the new ephemeral key from the currently established $\mathsf{ssk}$, and initiate a transfer of the new ephemeral key. As a result, consecutive ephemeral keys are transferred in cycles, and it suffices that the adversary eavesdrops on one complete cycle to be able to recalculate the current $\mathsf{ssk}$ and all subsequent pairs $({\mathsf{epk}}_{\mathsf{D}},\mathsf{ssk})$.

An alternative way to carry out a passive attack is to upload a unique seed value to device $\mathsf{D}$ (that is, the value is unique for each device). The upload is performed on the production line or, e.g., during product registration. Based on this seed, a deterministic random number generator will generate the scalars used in the protocol. Then, to reproduce the scalar value, the author of the malicious implementation uses a copy of the seed stored at their site.

2.2. Problem 1: Using Predictable Exponents

Let A be a party that shares a key $\mathsf{ssk}$ with the adversary $\mathsf{Adv}$ (it might be a device $\mathsf{D}$ or a reader $\mathsf{R}$). In this case, A can execute CPace so that the session key and the password can be reproduced by $\mathsf{Adv}$ based on the observed interactions of the communicating parties. A malicious participant, say, a device $\mathsf{D}$, works as follows:

1.

Instead of executing $y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$, $\mathsf{D}$ sets

$$y_A:={\mathsf{Hash}}_q(\mathsf{ADa},\mathsf{ssk})$$

where ${\mathsf{Hash}}_q$ is a correlated-input secure hash function that maps into ${\mathbb{Z}}_q$, where q is the order of the group used.

Note that the change is not detectable even if $y_A$ is presented to an auditor in the case of correlated-input secure hash functions.

• Attack consequences

The adversary can carry out the following:

• Calculate the session key following exactly the same steps as $\mathsf{D}$ after re-calculating $y_A:={\mathsf{Hash}}_q(\mathsf{ADa},\mathsf{ssk})$,
• Find the password used by the owner of $\mathsf{D}$, provided that $\mathsf{Adv}$ can guess $\mathsf{CI}$ and $\mathsf{sid}$ or has access to them:

  1.

  Calculate $G:=Y_A^{1/y_A}$.

  2.

  Perform brute force attack on the password by testing for each candidate password ${\mathsf{PRS}}^{\prime }$ whether

  $$G\stackrel{?}{=}\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},{\mathsf{PRS}}^{\prime },\mathsf{CI},\mathsf{sid}).$$

It follows that the scheme’s security is critically dependent on the security of the random number generator and execution of the function $\mathsf{sample}\_\mathsf{scalar}$. Breaking it on one side leads to the security collapse of CPace.

• Potential patches
• Attempt 1: In similar situations (see, e.g., [34]), one can use a static Diffie–Hellman key agreement executed in both directions. The resulting keys $K_A$ and $K_B$ are used to generate the master session key, for example, by $K:=\mathsf{Hash}(K_A,K_B)$. To break this K, the adversary $\mathsf{Adv}$ needs not only the output of a (faulty) random number generator, but also the private key of the party using this generator.

Unfortunately, this approach is incompatible with the basic design concept of CPace, which uses a new point G with an unknown discrete logarithm at each protocol execution. The static Diffie–Hellman protocol can be executed only if the challenge is computed for the same generator as the one used to create the public key of a party.

• Attempt 2: The main property required from $y_A$ and $y_B$ is their unpredictability. Another observation is that the parties executing CPace may exchange the values $y_A,y_B$ over the secure channel once it is established. So, the general framework is as follows:
  • $y_A$ and $y_B$ are created in a deterministic way, but so that they are unpredictable for an observer with access to the previous interaction transcripts and the current $Y_A,Y_B,\mathsf{ADa},\mathsf{ADb}$.
  • After successful termination of CPace and establishing a secure channel, the parties exchange the values of $y_A$ and $y_B$ together with a proof that they have been created deterministically, as described.

• (Note that this approach is related to securing SSL against kleptographic attacks from [35].) The deterministic creation of the exponent $y_A,y_B$ can be based on deterministic signature schemes:

  $$y_A:={\mathsf{Hash}}_q\left({\mathsf{Sign}}_A(\mathsf{sid},\mathsf{CI})\right),$$

  where ${\mathsf{Sign}}_A$ stands for signature creation by the party A. Analogously,

  $$y_B:={\mathsf{Hash}}_q\left({\mathsf{Sign}}_B(\mathsf{sid},\mathsf{CI},\mathsf{ADa})\right).$$

• Note that the text to be signed does not include $\mathsf{ADa}$ in the case of party A and does not include $\mathsf{ADb}$ in the case of party B. The reason is that these additional strings can be manipulated by the signer and, therefore, the signature would not be deterministic anymore.

There are many deterministic signature schemes. However, not all of them can demonstrate that they have been created according to the described procedure. For example, while EdDSA [36] is deterministic, the signature itself does not prove that the ephemeral value of the signature has been created from the signer’s secret as described in the EdDSA specification. On the other hand, signatures such as BLS [37] are verifiable in this sense. In addition, post-quantum schemes like SPHINCS [38] or HBSS [39] can be adopted for our case.

Note that the above countermeasure will not work if party B is malicious and colluding with the contaminated device A. Therefore, a trusted watchdog ${\mathsf{W}}_A$ that verifies the values produced by A (that is, $G,y_A,Y_A$) seems to be a more reliable solution. Note that such a watchdog must be trusted, because it learns the scalar $y_A$.

All in all, each method indicated above breaks the fundamental design principle of CPACE, namely its simplicity.

• Attempt 3: Following the idea from [40], the scalars $y_A$ would form a Lamport chain:

  $$y_{A,i}:={\mathsf{Hash}}_q\left(y_{A,i+1}\right)$$

  (1)

  where $y_{A,i}$ stands for $y_A$ used during the ith execution of the protocol. These scalars will be controlled by a watchdog ${\mathsf{W}}_A$ that is initialized with $y_{A,0}$. During the ith execution of the protocol, $\mathsf{W}$ obtains the following privately from A:
  • Data necessary to reconstruct the base element G.
  • The scalar $y_{A,i}$.
• Then $\mathsf{W}$ can check that $y_{A,i}$ is correct with respect to the Lamport chain (that is, ${\mathsf{Hash}}_q\left(y_{A,i}\right)=y_{A,i-1}$, or alternatively, ${\mathsf{Hash}}_q^i\left(y_{A,i}\right)=y_{A,0}$) and that $Y_A=y_{A,i}·G$ for G and $Y_A$ from the current execution.

This approach should suffice, because the only element that is freely chosen by the device A is the scalar $y_{A,n}$. However, $y_{A,n}$ must be chosen long before G used to calculate $Y_A=y_{A,n}·G$ is learned by A.

On the other hand, the procedure above can be slightly modified to make future scalars also unpredictable for device A. That is, after receiving $y_{A,0}$, the watchdog ${\mathsf{W}}_A$ picks a random key K and sends it to A. Now, it is required that the scalar $y_A$ generated in the ith session, $i=1,\dots ,n$, satisfies the formula

$$y_A={\mathsf{Hash}}_q(K,y_{A,i})$$

where $y_{A,i}$ originates from the Lamport chain (1).

Unfortunately, this approach requires some extra memory space and/or computation time (cf., e.g., [41] and references therein). It might be unacceptable from a practical point of view, as CPace is also intended for very simple devices. Moreover, as in the case of Attempt 2, the watchdog must be trusted because it learns the scalar $y_A$ used to calculate the session key.

2.3. Problem 2: Key Establishment via Static DH with Ciphertext Transmission

In this scenario, a device $\mathsf{D}$ and a reader $\mathsf{R}$ cheat the user, and secret data is transmitted from $\mathsf{R}$ to $\mathsf{D}$, or from $\mathsf{D}$ to $\mathsf{R}$ via a kleptographic channel. Both $\mathsf{D}$ and $\mathsf{R}$ cheat about the implementation of the protocol.

Table 2. A protocol pretending to be CPace, with a kleptographic channel from $\mathsf{R}$ to $\mathsf{D}$.

Malicious Device $\mathsf{D}$	Malicious Reader $\mathsf{R}$
holds:		holds:
- kleptographic public key $\mathsf{Kpk}=\mathsf{ksk}·G_0$		- kleptographic private key ksk
		- kleptographic message M
- password $\mathsf{PRS}$		- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$		- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$		- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$		- associated data $\mathsf{ADb}$
$\sout{G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})}$		$\sout{G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})}$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$		$\sout{y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)}$
$\sout{Y_A:=y_A·G}$		$\sout{Y_B:=y_B·G}$
$Y_A:=y_A·G_0$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
$K_0:=\mathsf{Hash}(y_A·\mathsf{Kpk},\mathsf{ADa},\mathsf{PRS})$		$K_0:=\mathsf{Hash}(\mathsf{ksk}·Y_A,\mathsf{ADa},\mathsf{PRS})$
$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$		$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$
		$Y_B:=\mathsf{Enc}(K_{\mathsf{Enc}};M)$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$M:=\mathsf{Dec}(K_{\mathsf{Enc}};Y_B)$
$\sout{K:=y_A·Y_B}$		$\sout{K:=y_B·Y_A}$
$K:=\mathsf{Hash}(K_0,1)$		$K:=\mathsf{Hash}(K_0,1)$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$		$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$		$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$		$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$ and message M		output session key $\mathsf{ISK}$

describes such a malicious protocol, where the kleptographic channel is from $\mathsf{R}$ to $\mathsf{D}$.

It should be noted that the reader $\mathsf{R}$ must know that $\mathsf{D}$ also implements a malicious protocol version before it decides to deviate from the original protocol. If $\mathsf{R}$ is a remote system that stores user passwords in a database (see Figure 1), then this task is easier because $\mathsf{R}$ must learn the device owner’s identity at a higher protocol layer. Alternatively, the associated data $A{D}_a$ sent by $\mathsf{D}$ could be used to inform $\mathsf{R}$ about intended malicious deviations from CPace. This message can be concealed from an observer with asymmetric cryptography.

The idea of the malicious protocol is to use the first message $Y_A$ to derive a shared key $K_0$ via the static Diffie–Hellman protocol. This releases $Y_B$ from the key agreement procedure. So, $Y_B$ can now be used exclusively to carry a hidden message M from $\mathsf{R}$ to $\mathsf{D}$ (we assume without loss of generality that M belongs to the group used by CPace, cf., e.g., [42]). $\mathsf{Enc}(K_{\mathsf{Enc}};M)$ stands for a ciphertext obtained with the key $K_{\mathsf{Enc}}$. Since the key $K_{\mathsf{Enc}}$ is session-specific (note that it depends on $\mathsf{sid}$), one can use one-time encryption. For example, $\mathsf{Enc}(K_{\mathsf{Enc}};M)={\mathsf{Hash}}_{\mathsf{curve}}\left(\mathsf{DRNG}\left(K_{\mathsf{Enc}}\right)\right)+M$, where “+’ is the group operation, $\mathsf{DRNG}\left(\right)$ is a deterministic random number generator and ${\mathsf{Hash}}_{\mathsf{curve}}$ is a hash function mapping to the curve points such that its outputs are indistinguishable from curve points received from a random source (see, e.g., the recent summary [43] of results).

Claim 1.

An external observer cannot distinguish whether $\mathsf{D}$ and $\mathsf{R}$ execute the original CPace or the scheme of Table 2.

Claim 1 will be proved using a sequence of security games according to the framework [44]. The game ${\mathcal{G}}_0$ is the malicious implementation as in Table 2.

In ${\mathcal{G}}_1$, we replace the local generation of the scalar $y_A$ (i.e., calling the procedure $\mathsf{sample}\_\mathsf{scalar}\left(\right)$) with the generation of a random but shared $y_A$ (recall that the game need not correspond to any feasible execution; here we assume that $y_A$ is shared by $\mathsf{D}$ and $\mathsf{R}$ as in the quantum entanglement), then we restore the original calculation of G and $Y_A$ and skip the decryption of $Y_B$. The result is given in

Table 3. Security game ${\mathcal{G}}_1$.

Malicious Device $\mathsf{D}$		Malicious Reader $\mathsf{R}$
holds:			holds:
- kleptographic public key $\mathsf{Kpk}=\mathsf{ksk}·G_0$			- kleptographic private key ksk
			- kleptographic message M
- password $\mathsf{PRS}$			- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$			- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$			- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$			- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$			$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$\sout{y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)}$			$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
choose random  $y_A$			choose random  $y_A$
$Y_A:=y_A·G$			$\sout{Y_B:=y_B·G}$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
$K_0:=\mathsf{Hash}(y_A·\mathsf{Kpk},\mathsf{ADa},\mathsf{PRS})$			$K_0:=\mathsf{Hash}(\mathsf{ksk}·y_A·G_0,\mathsf{ADa},\mathsf{PRS})$
$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$			$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$
			$Y_B:=\mathsf{Enc}(K_{\mathsf{Enc}};M)$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$			$\sout{K:=y_B·Y_A}$
$K:=\mathsf{Hash}(K_0,1)$			$K:=\mathsf{Hash}(K_0,1)$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$			$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$			$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$			$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$			output session key $\mathsf{ISK}$

. The observer cannot distinguish the difference between ${\mathcal{G}}_0$ and ${\mathcal{G}}_1$, as $Y_A$ has the same (uniform) distribution in the group.

In ${\mathcal{G}}_2$, we replace $y_A·\mathsf{Kpk}$ and $\mathsf{ksk}·Y_A$ with a shared random element $R_2$ (the element is shared in the same way as $y_A$ in ${\mathcal{G}}_1$). No difference can be detected between ${\mathcal{G}}_1$ and ${\mathcal{G}}_2$, as otherwise the Decisional Diffie–Hellman Problem would be solved. As $\mathsf{Kpk}$ and $\mathsf{ksk}$ are no longer used, they are removed from the specification. ${\mathcal{G}}_2$ is depicted in

Table 4. Security game ${\mathcal{G}}_2$.

Malicious Device $\mathsf{D}$		Malicious Reader $\mathsf{R}$
holds:			holds:
			- kleptographic message M
- password $\mathsf{PRS}$			- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$			- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$			- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$			- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$			$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$			$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$Y_A:=y_A·G$			$\sout{Y_B:=y_B·G}$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
choose random  $R_2$			choose random  $R_2$
$K_0:=\mathsf{Hash}(R_2,\mathsf{ADa},\mathsf{PRS})$			$K_0:=\mathsf{Hash}(R_2,\mathsf{ADa},\mathsf{PRS})$
$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$			$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$
			$Y_B:=\mathsf{Enc}(K_{\mathsf{Enc}};M)$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$			$\sout{K:=y_B·Y_A}$
$K:=\mathsf{Hash}(K_0,1)$			$K:=\mathsf{Hash}(K_0,1)$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$			$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$			$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$			$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$			output session key $\mathsf{ISK}$

.

In ${\mathcal{G}}_3$, we replace the derivation of $K_0$ by choosing a random element $R_3$ shared by $\mathsf{D}$ and $\mathsf{R}$. If $\mathsf{Hash}$ is a correlated-input secure hash function, the observer cannot distinguish between ${\mathcal{G}}_2$ and ${\mathcal{G}}_3$. As $R_2$ is no longer used, it is removed from the game. ${\mathcal{G}}_2$ is depicted in

Table 5. Security game ${\mathcal{G}}_3$.

Malicious Device $\mathsf{D}$		Malicious Reader $\mathsf{R}$
holds:			holds:
			- kleptographic message M
- password $\mathsf{PRS}$			- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$			- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$			- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$			- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$			$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$			$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$Y_A:=y_A·G$			$\sout{Y_B:=y_B·G}$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
choose random $R_3$			choose random $R_3$
$K_0:=R_3$			$K_0:=R_3$
$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$			$K_{\mathsf{Enc}}:=\mathsf{Hash}(K_0,0)$
			$Y_B:=\mathsf{Enc}(K_{\mathsf{Enc}};M)$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$			$\sout{K:=y_B·Y_A}$
$K:=\mathsf{Hash}(K_0,1)$			$K:=\mathsf{Hash}(K_0,1)$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$			$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$			$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$			$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$			output session key $\mathsf{ISK}$

.

The next game ${\mathcal{G}}_4$ replaces the generation of K and $K_{\mathsf{Enc}}$ from $K_0$ by setting two independent random values; see

Table 6. Security game ${\mathcal{G}}_4$.

Malicious Device $\mathsf{D}$		Malicious Reader $\mathsf{R}$
holds:			holds:
			- kleptographic message M
- password $\mathsf{PRS}$			- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$			- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$			- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$			- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$			$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$			$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$Y_A:=y_A·G$			$\sout{Y_B:=y_B·G}$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
choose random $K_{\mathsf{Enc}}$			choose random $K_{\mathsf{Enc}}$
			$Y_B:=\mathsf{Enc}(K_{\mathsf{Enc}};M)$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$			$\sout{K:=y_B·Y_A}$
choose random K			choose random K
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$			$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$			$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$			$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$			output session key $\mathsf{ISK}$

. If $\mathsf{Hash}$ is a correlated-input secure hash function, no difference can be observed. Since $K_0$ is no longer used, it is removed from the game.

The game ${\mathcal{G}}_5$ replaces the derivation of $Y_B$ via the encryption function with a random key, choosing $Y_B$ at random. This is achieved by first choosing $y_B$ at random and then deriving $Y_B=y_B·G$. See

Table 7. Security game ${\mathcal{G}}_5$.

Malicious Device $\mathsf{D}$		Malicious Reader $\mathsf{R}$
holds:		holds:
- password $\mathsf{PRS}$		- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$		- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$		- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$		- associated data $\mathsf{ADb}$
$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$		$G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})$
$y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$		$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$Y_A:=y_A·G$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
		$Y_B:=y_B·G$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$		$\sout{K:=y_B·Y_A}$
choose random K		choose random K
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$		$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$		$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$		$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
output session key $\mathsf{ISK}$		output session key $\mathsf{ISK}$

. If $\mathsf{Enc}$ is not distinguishable from a random permutation for a random key, the observer cannot distinguish between ${\mathcal{G}}_4$ and ${\mathcal{G}}_5$. As M is no longer used, it is removed from the game.

Now, let us compare ${\mathcal{G}}_5$ with the original CPace. The only difference is that CPace derives K according to the Diffie–Hellman key exchange protocol, while ${\mathcal{G}}_5$ takes a random K. Distinguishing between the real CPace and ${\mathcal{G}}_5$ is not easier than solving the Decisional Diffie–Hellman Problem.

Note 1.

The proposed attack can be modified so that the kleptographic data is sent from device $\mathsf{D}$ to reader $\mathsf{R}$. However, this is slightly more complicated as we assumed that $\mathsf{D}$ sends $Y_A$ before receiving $Y_B$. The attack uses two groups: the larger one, officially used for CPace, and a smaller one, which can be used to encode a Diffie–Hellman ephemeral key. The difference in sizes of these two groups will allow for encoding some m-bit message, and the adversary can benefit even from some moderate values of m, such as $m\approx 20$ (note that a 6-digit PIN can be transmitted through such a channel). Accordingly, for a 256-bit “large”, official group, even a 230-bit group can be used. Then, $Y_A$ can pretend to be an element of that large group while, in reality, it can hide a pair

$$({\mathsf{encd}}_2(k·H),{\mathsf{DRNG}}_m(k·\mathsf{Kpk})\oplus M)$$

(2)

where ${\mathsf{encd}}_2\left(\right)$ denotes invertible encoding as a bit-string, ${\mathsf{DRNG}}_m\left(\right)$ produces an m-bit output, the scalar k is random, and the base H and the asymmetric “public” key $\mathsf{Kpk}$ belong to a smaller group where the Diffie–Hellman problem is still hard and for which ${\mathsf{encd}}_2\left(\right)$ yields bit-strings uniformly distributed (see e.g., [32]). Note that the ciphertext (2) can be easily encoded on the larger group by using some injective map (cf. [42]).

Since $Y_A$ is utilized to carry the ciphertext (2), the component $Y_B$ must now be used for ephemeral–static Diffie–Hellman key exchange to derive the key K in exactly the same way as $Y_A$ was used in Table 2.

Interestingly, if the group used for CPace is larger, aiming to reach a higher security level, there is more room for the covert channel. Thus, overshooting the security requirements may lead to security problems.

• Potential patches

Once a secure channel of the session is established, the discrete logarithms of $Y_A$ and $Y_B$ could be presented to an auditor for examination. This procedure can be run on the system that runs the reader and/or on the system where the device $\mathsf{D}$ is used.

Note 2.

Let us remark that it might be a challenge to hide the described manipulations in the code of CPace against side-channel analysis (for example, by power traces). On the other hand, one of the approaches to protect implementation against side-channel analysis is reducing the signal-to-noise ratio. This can be achieved by implementing random delays or dummy operations that increase the noise. Therefore, the aim of a malicious manufacturer could be to prepare two implementations:

• The one that is going to be certified and follows the specification, but contains some “dummy” operations that officially protect the implementation against a powerful adversary, but at the same time make the implementation difficult to distinguish by side-channel analysis from the second implementation.
• The second implementation that is going to be deployed and contains a malicious functionality.

• What is more, in some attacks, most of the malicious code does not have to be executed every time the protocol is executed, but can be triggered when connecting to a specific device or service, for example, after receiving specific associated data (AD). In this case, the fact of testing the condition that triggers malicious code should be undetectable by side-channel analysis.

Furthermore, side-channel analysis requires equipment, knowledge, skills, and substantial effort. So, even if the attack implementation is not very tricky, the manipulation can be detected via side-channel analysis in a certification lab, and not by a user holding the manipulated implementation of CPace.

2.4. Problem 3: Key Establishment via Static DH with No Ciphertext

Now, we present a simplified version of the attack from Table 2. Its goal is to create a key shared by $\mathsf{D}$ and $\mathsf{Adv}$, and where malicious $\mathsf{R}$ only assists them. No direct contact between $\mathsf{D}$ and a reader controlled by $\mathsf{Adv}$ is required; $\mathsf{Adv}$ merely observes the interaction. The reader $\mathsf{R}$ does not learn the shared key and does not send any ciphertext.

$\mathsf{D}$ can execute the protocol in two ways. If it recognizes that ${\mathsf{R}}^{\prime }$ is malicious, then the protocol presented in

Table 8. A protocol pretending to be CPace, conducting a kleptographic transfer of the ephemeral key $Y_A$.

Malicious Device $\mathsf{D}$		Malicious Reader ${\mathsf{R}}^{\prime }$
holds:			holds:
- standard generator  $G_0$			- standard generator  $G_0$
- kleptographic public key $\mathsf{Kpk}=\mathsf{ksk}·G_0$
- hidden seed  $K_0$
- hidden variable counter , initially set to 0
- password $\mathsf{PRS}$			- password $\mathsf{PRS}$
- session ID $\mathsf{sid}$			- session ID $\mathsf{sid}$
- channel ID $\mathsf{CI}$			- channel ID $\mathsf{CI}$
- associated data $\mathsf{ADa}$			- associated data $\mathsf{ADb}$
$\sout{G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})}$			$\sout{G:=\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}(\mathsf{Hash},\mathsf{PRS},\mathsf{CI},\mathsf{sid})}$
$\sout{y_A:=\mathsf{sample}\_\mathsf{scalar}\left(\right)}$			$y_B:=\mathsf{sample}\_\mathsf{scalar}\left(\right)$
$y_A:=\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}(K_0,\mathsf{counter})$
$\sout{Y_A:=y_A·G}$			$\sout{Y_B:=y_B·G}$
${\mathsf{PRS}}_e:=\mathsf{Map}\mathsf{2}\mathsf{E}\left(\mathsf{PRS}\right)$			${\mathsf{PRS}}_e:=\mathsf{Map}\mathsf{2}\mathsf{E}\left(\mathsf{PRS}\right)$
$Y_A:=y_A·G_0+{\mathsf{PRS}}_e$			$Y_B:=y_B·G_0+{\mathsf{PRS}}_e$
	$\stackrel{Y_A,\mathsf{ADa}}{\to }$
	$\stackrel{Y_B,\mathsf{ADb}}{\leftarrow }$
$\sout{K:=y_A·Y_B}$			$\sout{K:=y_B·Y_A}$
$K:=y_A·(Y_B-{\mathsf{PRS}}_e)$			$K:=y_B·(Y_A-{\mathsf{PRS}}_e)$
$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$			$\mathsf{MSGa}:=\mathsf{transcript}(Y_A\parallel \mathsf{ADa})$
$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$			$\mathsf{MSGb}:=\mathsf{transcript}(Y_B\parallel \mathsf{ADb})$
$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$			$\mathsf{ISK}:=\mathsf{Hash}(par\parallel \mathsf{sid}\parallel K\parallel \mathsf{MSGa}\parallel \mathsf{MSGb})$
$K_0:=y_A·\mathsf{Kpk}$
$\mathsf{counter}:=\mathsf{counter}+1$
output session key $\mathsf{ISK}$			output session key $\mathsf{ISK}$

is executed. If $\mathsf{R}$ is honest, $\mathsf{D}$ executes the original CPace with two minor changes:

• $y_A$ is generated as in Table 8 (that is, $\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}\left(K_0\right)$ is used instead of $\mathsf{sample}\_\mathsf{scalar}\left(\right)$).
• The hidden variable $\mathsf{counter}$ is incremented.

The pseudo-random generator $\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}\left(\right)$ uses the hidden seed $K_0$ and a hidden counter, which is incremented each time the protocol is executed. The counter is used to prevent repeating the same output of $\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}\left(\right)$ for the case that the hidden seed $K_0$ is not updated. The seed $K_0$ is not shared with malicious ${\mathsf{R}}^{\prime }$, but becomes shared with $\mathsf{Adv}$ at some moment.

The modified scheme uses the password $\mathsf{PRS}$ in a different way. Instead of using it to determine a session-specific generator G, it maps the password $\mathsf{PRS}$ to a point ${\mathsf{PRS}}_e:=\mathsf{Map}\mathsf{2}\mathsf{E}\left(\mathsf{PRS}\right)$ that is used as an update during the Diffie–Hellman key exchange. The mapping $\mathsf{Map}\mathsf{2}\mathsf{E}$ can be defined analogously to $\mathsf{g}\_\mathsf{cal}\_\mathsf{gen}$. The mechanism of the update within the Diffie–Hellman protocol is borrowed from the PACE GM protocol [3]. It ensures that a party using a wrong password will learn neither the password used on the other side of the protocol execution nor the session key computed by that party. (Another option could be an empty ${\mathsf{PRS}}_e$, that is, ${\mathsf{PRS}}_e$ equal to the neutral element of $\langle G_0\rangle$—in this way, the connection can be made without any interaction of the user, for ${\mathsf{R}}^{\prime }$ in which the user has never registered.)

Near the end of the execution, device $\mathsf{D}$ re-seeds the $\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}\left(\right)$ deterministic generator with a new value $K_0$.

Now, let us look at what is going on on the side of $\mathsf{Adv}$, who privately holds $\mathsf{ksk}$ corresponding to $\mathsf{Kpk}$. Having $Y_A$ observed during an interaction, $\mathsf{Adv}$ calculates the following values for each potential password ${\mathsf{PRS}}^{\prime }$:

• $Y_{A,{\mathsf{PRS}}^{\prime }}:=Y_A-\mathsf{Map}\mathsf{2}\mathsf{E}\left({\mathsf{PRS}}^{\prime }\right)$.
• $K_{0,{\mathsf{PRS}}^{\prime }}:=\mathsf{ksk}·Y_{A,{\mathsf{PRS}}^{\prime }}$.

$\mathsf{Adv}$ utilizes the ability to calculate the above candidates $K_{0,{\mathsf{PRS}}^{\prime }}$ to reconstruct $y_A$ used by $\mathsf{D}$ when $\mathsf{D}$ connects to an honest $\mathsf{R}$. Recall that

$$y_A=\mathsf{subverted}\_\mathsf{sample}\_\mathsf{scalar}(K_0,\mathsf{counter})$$

and that for the correctly guesses ${\mathsf{PRS}}^{\prime }$ and the value of $\mathsf{counter}$, we will have

$$K=y_A·Y_B.$$

Thus, for each guess of ${\mathsf{PRS}}^{\prime }$ and the counter value, $\mathsf{Adv}$ can calculate the corresponding $\mathsf{ISK}$ and then test if the communication following execution of the PAKE protocol is meaningful. Having eliminated the wrong guesses, $\mathsf{Adv}$ can determine the internal state $K_0=K_{0,{\mathsf{PRS}}^{\prime }}$

The complexity of the above search depends on the number of $\mathsf{counter}$ values and possible passwords to consider. Although the counter has a limited entropy in regular use, the passwords chosen by some users might be hard to guess.

To ease the search, we may redefine $\mathsf{Map}\mathsf{2}\mathsf{E}\left(\right)$ so that the output entropy is small enough for the brute force search while preserving the property that an execution of modified CPace with different passwords by $\mathsf{D}$ and ${\mathsf{R}}^{\prime }$ will practically always fail. For example, one can reshape $\mathsf{Map}\mathsf{2}\mathsf{E}\left(\right)$ in the following way:

1.

$\alpha :=\mathsf{Hash}\left(\mathsf{PRS}\right)$.

2.

${\beta }_{\ell }:=$ the first ℓ bits of $\alpha$, for e.g., $\ell =24$.

3.

$\gamma :=$ encoding of ${\beta }_{\ell }$ on $\langle G_0\rangle$.

4.

Output $\gamma$.

• Then $\mathsf{Adv}$, to find $\gamma$, must just search for ℓ-bit ${\beta }_{\ell }$ and not for the original (strong) password. Note that the above procedure allows ${\mathsf{R}}^{\prime }$ to detect that the user has entered a wrong password with probability $1-{\displaystyle \frac{1}{2^{\ell }}}$. The procedure can be further extended by taking into account the parameters $\mathsf{CI}$, $\mathsf{sid}$, as in the case of calculating G in the original protocol. That is, $\alpha :=\mathsf{Hash}(\mathsf{PRS},\mathsf{CI},\mathsf{sid})$.

To further ease the brute force search, after each connection to ${\mathsf{R}}^{\prime }$ and re-initialization of the seed $K_0$, device $\mathsf{D}$ can reset $\mathsf{counter}$ to 0.

Finally, let us remark that Note 2 remains valid for malicious modifications described in this section.

2.5. Problem 4: Rejection Sampling

Rejection sampling enables one to hide secret data in elements chosen at random. Let $\mathsf{ssk}$ be a secret key shared by device $\mathsf{D}$ and an adversary $\mathsf{Adv}$. To hide a (short) string b in $Y_A$, device $\mathsf{D}$ executes the following subprocedure for generating $y_A$ and $Y_A$ with a pseudo-random function F:

1.

Choose $y_A$ at random.

2.

$Y_A:=y_A·G$.

3.

$f:=F(Y_A,\mathsf{ssk})$.

4.

If the prefix of f is not b, then

(a)

$y_A:=y_A+1modq$.

(b)

$Y_A:=Y_A+G$.

(c)

Go to 3.

5.

Output $y_A,Y_A$.

• The adversary $\mathsf{Adv}$ observing $Y_A$ and holding $\mathsf{ssk}$ can derive message b by calculating $F(Y_A,\mathsf{ssk})$ and truncating it to the length of b.

Note that the message b cannot be long, as the expected time to create $y_A$ and $Y_A$ is exponential in the length of b. In practice, only a few bits can be leaked in this way.

To leak a single bit, no backtracking is necessary [45]:

1.

Choose $y_A^{\prime }$ at random.

2.

$Y_A^{\prime }:=y_A^{\prime }·G$, $Y_A^{\prime \prime }:=-Y_A^{\prime }$.

3.

$f^{\prime }:=F(Y_A^{\prime },\mathsf{ssk})$, $f^{\prime \prime }:=F(Y_A^{\prime \prime },\mathsf{ssk})$.

4.

If $b=0$, then the following holds:

• If $f^{\prime }<f^{\prime \prime }$, then $y_A:=y_A^{\prime }$, $Y_A:=Y_A^{\prime }$.
• If $f^{\prime }>f^{\prime \prime }$, then $y_A:=-y_A^{\prime }$, $Y_A:=Y_A^{\prime \prime }$.

If $b=1$, then the following holds:

• If $f^{\prime }<f^{\prime \prime }$, then $y_A:=-y_A^{\prime }$, $Y_A:=Y_A^{\prime \prime }$.
• If $f^{\prime }>f^{\prime \prime }$, then $y_A:=y_A^{\prime }$, $Y_A:=Y_A^{\prime }$.

5.

Output $y_A,Y_A$.

• (the operation $y_A:=-y_A^{\prime }$ above is modulo the group order). To avoid the situation where $f^{\prime }=f^{\prime \prime }$, we may instantiate F as a collision-resistant hash function.

Note 3.

Other optimizations for rejection sampling from [45] do not apply, as CPace applies a different generator G for each execution of the protocol. (Note that it is no longer true if the password-dependent generator is fixed, as some authors propose.)

The same methods can be applied to leak hidden information by the reader. Unfortunately, there is no simple patch on the protocol level to repel such rejection sampling attacks. This must be performed by auditing the implemented code. In the second case (leaking a bit without backtracking), it is substantially harder to detect the problem by side-channel time analysis.

2.6. Problem 5: Faulty Executions

We must bear in mind that information can be leaked via executions that are interrupted by one party. Assume, for example, that the device aims to leak $\mathsf{PRS}$ to an adversary $\mathsf{Adv}$ with a public kleptographic key $\mathsf{Kpk}$ embedded in $\mathsf{D}$.

In that case, $Y_A$ is not created as described in the CPace specification, but as follows. In the first faulty run, the following steps are executed to create $Y_A$:

1.

Generate $y_A$ at random.

2.

Set $Y_A:=y_A·\mathsf{Kpk}+\mathsf{Mapping}\left(\mathsf{PRS}\right)$, where $\mathsf{Mapping}$ is an invertible mapping from the space of passwords to elliptic curve points.

3.

Retain $y_{\mathsf{old}}:=y_A$ for future use.

• In the first run, $\mathsf{D}$ restarts the session, for example, after receiving $Y_B$. This is not particularly suspicious, as users frequently mistype the password. In the second run, $y_A$ and $Y_A$ are generated as follows:

  1.

  $y_A:=y_{\mathsf{old}}$,

  2.

  $Y_A:=y_A·G$

Assume that the adversary $\mathsf{Adv}$ holds $Y_A=Y_{A,1}$ from the first execution and $Y_A=Y_{A,2}$ from the second execution. Then $\mathsf{Adv}$ can derive $\mathsf{PRS}$ by calculating $Y_{A,1}-\mathsf{ksk}·Y_{A,2}$.

2.7. Problem 6: Hiding in Associated Data

The specification of CPace refers to the elements $\mathsf{sid}$, $\mathsf{ADa}$, $\mathsf{ADb}$. The specification of CPace does not contain strict rules regarding these elements, allowing for freedom in how to define them in a given application. Note that $\mathsf{ADa}$ and $\mathsf{ADb}$ are transmitted in clear. If in a given application they are allowed to contain random strings (or implicit randomness that can be derived from structured data), then a malicious party can replace randomness with kleptographic messages. For example, the following attack can be run by $\mathsf{Adv}$:

1.

Choose a scalar u at random.

2.

Create $\mathsf{ADa}$ so that it encodes a point $U:=u·G_0$ (cf., e.g., [31] or [32]).

3.

Instead of generating $y_A$ at random, derive it as $y_A:={\mathsf{Hash}}_q(u·\mathsf{Kpk})$.

The adversary observing the messages exchanged can recalculate $y_A:={\mathsf{Hash}}_q(\mathsf{ksk}·U)$ and then derive the master session key K according to the CPace specification. Then, by exhaustive search in the password space, $\mathsf{Adv}$ can find a password $\mathsf{PRS}$ that yields a session key $\mathsf{ISK}$ for which the decryption of the workload messages results in meaningful data.

2.8. Problem 7: Leakage via Generation of $\mathsf{sid}$

The specification [5] says that: If the higher-level protocol that integrates CPace is able to establish a unique sid identifier for the communication session, it is RECOMMENDED that this is passed to CPace as sid parameter. One suitable option for generating sid is concatenation of ephemeral random strings contributed by both parties.

An ephemeral random string may be replaced by an encoding of the ephemeral key U depicted in Section 2.7 and/or a kleptographic ciphertext. In that way, CPace may provide space for information leakage. The leaked information could be the password $\mathsf{PRS}$ entered by the user. So, in particular, if the protocol initiator is a malicious system $\mathsf{R}$, it can fool CPace password authentication in collusion with the user’s higher-level protocol with no visible evidence.

3. Certification and Inspection Issues

Assessing the security of a protocol that uses CPace as one of its components is a complicated task, despite the simplicity and elegance of CPace. A good approach is to follow the Common Criteria methodology, due to its systematic approach and well-trained audit procedures. Among others, the Common Criteria framework helps to avoid overshooting the protection goals: If a security mechanism does not address identified assets and threats, it is unnecessary. The Common Criteria approach may be more helpful than very general and vague requirements, such as those listed in [46]. A good reference point is the protection profiles developed for eID and using the PAKE protocol PACE (see [47,48]).

3.1. Assets

The first step to formulate relevant security requirements is to identify the assets that need to be protected. In the case of PAKE, the following primary assets can be identified (we slightly adjust the list from [48]):

(A1) 

User data protection: security properties: confidentiality, integrity, and authenticity.

The data exchanged during an execution of PAKE and after establishing a channel should be secure concerning their integrity and confidentiality against third parties.

(A2) 

User tracing data: security properties: No data is produced that would enable tracing password use for non-authorized parties.

An observer who monitors the communication channel (either passively or actively, and possibly holding the user’s password) cannot derive any information about who the communicating parties are. Moreover, no party (including a legitimate protocol participant) can create a meaningful proof of having an interaction or a proof of not having an interaction with a party A.

(A3) 

Authentication: security properties: Password-based access control.

Access is granted if and only if both parties use the same password.

There are also secondary assets that serve to protect the primary assets:

(A4) 

Password accessibility: security property: The password is accessible only to authorized agents. This means, in particular, that the agents that only monitor the traffic do not gain any information about the passwords used. Similarly, active adversaries learn nothing about the password when interacting with the password holder, other than confirming the correct guess. Moreover, in the user system, PAKE passwords cannot be used without the owner’s consent.

(A5) 

No leakage of higher-level protocol data: security property: PAKE does not leak data from other protocol layers.

PAKE, as a protocol embedded in a certain data environment, does not reveal data from its environment except for data explicitly specified by the protocol. This means that data originating from the environment are not endangered by an execution of PAKE.

(A6) 

Session atomicity: security property: If a session started by parties A and B succeeds, then the created session is between A and B, and the communication transcript is the same from the point of view of A and B.

Thus, there is no redirection of communication on-the-fly, relay attacks fail, no active man-in-the-middle, etc. It is worth noting that some PAKE schemes do not protect this asset (for example, PACE), but nevertheless achieve a relevant security level.

The following asset can be regarded as a security objective. However, like the authors of [48], we believe that its role is broader and closely related to the level of trust of users:

(A7) 

Implementation genuineness: security property: The evaluation target literally follows the formal specification of PAKE and specification of the implementation (in the Common Criteria certification process, the party responsible for implementation must deliver to the evaluating body also the source codes and documentation).

It also means that the implementation does not contain undocumented additional features and optimizations. In particular, scalars $y_A$ are generated exactly as described in the documentation.

3.2. Threats Arising from Subversion Attacks

The internal design of CPace helps to protect many of the listed assets. However, the universal composability of CPace does not automatically cover all threats. In fact, we do not believe that this is possible for any protocol, and a well-balanced set of different security measures should be applied.

Note that the set of threats may depend on the type of the target of evaluation (TOE). For example, for a secure element we will rather skip “Insertion of Malware into or through the TOE”. Therefore, our aim is not to propose a complete set of threats valid for any TOE, but to indicate those that arise from subversion of the code executing CPace protocol. However, we aim to maintain a certain level of generality because we want the list of threats to be helpful for different types of TOEs.

As in the case of assets, we can, in the context of this work, distinguish between the primary threats, and the threats that are secondary in this context (we may call them associated threats)—they depend on the functionality of the malicious code. In a broader context, in the case of evaluation of a real TOE, some or all of the associated threats listed below may have a different origin than indicated in this paper.

All in all, the primary threat in the context of this work is as follows:

(T1) 

The code executed on the device differs from the specification: Depending on the TOE, different attack vectors can lead to the realization of this threat. For example, in the case of a cell phone, we may have to deal with malware that has managed to compromise the Trusted Execution Environment [49,50], or in the case of a library or a hardware device, a supply chain attack is possible [16,51,52]. Finally, it may be maliciously implemented by the manufacturer [53].

The associated threats are as follows:

(T2) 

Weakening the session key: The derivation of the session key K is weakened so that a third party can recalculate it (see, e.g., the attack from Section 2.4). Note that this situation may potentially occur without exposing the password used.

(T3) 

Breaking password indistinguishability of communication transcripts: See, e.g., side effects of the attack from Section 2.4,

(T4) 

Enabling connection without password: See the attack from Section 2.4,

(T5) 

Leaking the password: See, e.g., the attack from Section 2.2 and Section 2.6; see also Note 1.

(T6) 

Creating kleptographic channels within CPace: See the attack from Section 2.3,

(T7) 

Allowing to hijack the session: A session is started by legitimate parties using the correct password, but the final session is established between one of these parties and the adversary (see, e.g., the attack from Section 2.4).

This threat may follow the realization of the threat T2, or it may appear independently in our context as a result of a flawed design. For example, it may result from de-coupling the establishment of the session key at the higher level of the protocols’ stack, i.e., above CPace, from the key established with the CPace protocol. Then the kleptographic channel should focus on leaking data to help hijack the session at a higher level, above the execution of CPace.

We also consider an additional threat that highlights the importance of a watchdog mechanism:

(T8) 

Black box design with no inspection features: Such a feature facilitates the realization of the threat T1 and makes defense nearly impossible. All attacks presented in this paper would be undetectable, unless there were additional audit mechanisms.

A supply chain attack mentioned in T1 can be thwarted by some mechanisms that demonstrate the genuineness of the product. However, even then, users must still trust the manufacturer that the devices they acquired are consistent with the samples the manufacturer submitted for evaluation. A more open design can increase trust in the product.

3.3. Addressing the Threats

It is difficult to identify a universal method of countering the threat presented above that will be useful in every application of the CPACE protocol. Thus, defining general security objectives is difficult or impossible, as they are likely to depend heavily on the target of evaluation.

Countermeasures should depend on the risk analysis, including the expected cost of the attack for the adversary. For example, embedding malicious functionality into a dedicated hardware implementation on a VLSI chip would require a separate production line. The cost would be prohibitive as long as CPace is used for low-value transactions or low-importance connections.

On the other hand, if the protocol is software-implemented and used, for example, on a smartphone, then a reasonable way to counteract the risks described here is to require the following:

• The implementation of the protocol generates the scalars in a verifiable way.
• There is an independent watchdog application that verifies that the scalars are generated according to the specification.

4. Conclusions

Although the universal composability framework has been successfully used to prove certain security properties of CPace, the underlying models do not address all threats that can occur in practice. Particularly concerning is the possibility of subverting a user’s device or providing a user with a device that is malicious by design.

We have shown that despite the Spartan shape of CPace, numerous implementation attacks would remain undetected for an observer analyzing the data exchanged. The number of opportunities for such attacks is significantly smaller than, say, in the case of the widely used PACE protocol; nevertheless, they still exist. Some of them (leakage by rejection sampling) seem to be impossible to repel unless reverse firewalls, or a watchdog enforcing determinism, are applied. Note that most of the attacks depicted in the paper do not require sophisticated kleptographic methods like, e.g., binary twisted elliptic curves utilized in [19] or elligator [32]. Consequently, a malicious implementation can be created by people with no particular knowledge and experience.

The proposed defense methods should be carefully examined. Their application makes the protocol more complicated, whereas the extreme simplicity of CPace is one of its most appealing features. Finally, it may prove problematic to simultaneously fulfill two conditions: integrating an additional system component (a watchdog, or a firewall as proposed in [24]) with the unit executing the CPace protocol and avoiding subversion of this additional component. Hence, it might be difficult to protect the implementation solely by means available at the protocol level.

As we can see, choosing details for CPace implementation and safeguards against malicious setups is a tricky issue. In our opinion, there is no universal answer to this problem, and design decisions should heavily depend on the results of the risk analysis prepared in accordance with the Common Criteria framework. Such a risk analysis should be useful even if there is no intention to certify a concrete product using CPace according to the Common Criteria framework. Our contribution is to indicate what an auditor should look for when inspecting a product with the CPace functionality.

Finally, let us remark that the observed problems are not specific to CPace. Moreover, for other schemes, the attacks might be even easier because of a more complicated design. For example, a malicious device running OPAQUE [54] can easily leak the password and session key to the adversary. The source of the problem is an element $X_u=g^{x_u}$ (see [54], page 23) that may be used to establish a shared key $\mathsf{ssk}={\mathsf{Kpk}}^{x_u}$ with the adversary (we follow here the multiplicative notation from [54]). Then $\mathsf{D}$ can reseed its random number generator with $\mathsf{ssk}$. In the following session, the adversary that observes an interaction will be able to derive the password (by brute-forcing its hash value) and the session key. For an older protocol J-PAKE [55], exactly the same attack mechanism applies.

For SPAKE2 [25] and SPAKE2+ [26], one can slightly modify the attacks presented in this paper. However, establishing a shared secret with the adversary is easier compared to CPace. Recall that the first message sent by the device is $\mathsf{pA}$ (we follow here the notation from [25]), where

$$\mathsf{pA}=w·M+x·P$$

for the scalar x chosen at random, w is derived from the password, generator M is specifically derived for SPAKE2 with a hashing to the curve points, and P is the standard generator of the elliptic curve used. To establish a shared secret with the adversary, two consecutive executions can be used, with messages ${\mathsf{pA}}_1=w·M+x_1·P$ and ${\mathsf{pA}}_2=w·M+x_2·P$. The shared secret is calculated by the device as $\mathsf{ssk}:=(x_1-x_2)·\mathsf{Kpk}$, while the adversary calculates it as $\mathsf{ssk}:=\mathsf{ksk}·({\mathsf{pA}}_1-{\mathsf{pA}}_2)$. From the kleptographic point of view, the mistake of SPAKE2 is to use the standard generator P and enable the cancellation of the element $w·M$. So, it does not help that w is derived from the password in a sophisticated way.