From A to Z: Projective coordinates leakage in the wild
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
IACR Transactions
ISSN XXXX-XXXX, Vol. 0, No. 0, pp. 1–26. DOI:XXXXXXXX
From A to Z:
Projective coordinates leakage in the wild
Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley
Tampere University, Tampere, Finland
{alejandro.cabreraaldaya,cesar.pereidagarcia,billy.brumley}@tuni.fi
Abstract. At EUROCRYPT 2004, Naccache et al. showed that the projective coordi-
nates representation of the resulting point of an elliptic curve scalar multiplication
potentially allows to recover some bits of the scalar. However, this attack has received
little attention by the scientific community, and the status of deployed mitigations to
prevent it in widely adopted cryptography libraries is unknown. In this paper, we
aim to fill this gap, by analyzing several cryptography libraries in this context. To
demonstrate the applicability of the attack, we use a side-channel attack to exploit
this vulnerability within libgcrypt in the context of ECDSA. To the best of our
knowledge, this is the first practical attack instance. It targets the insecure binary
extended Euclidean algorithm implementation using a microarchitectural side-channel
attack that allows recovering the projective representation of the output point of
scalar multiplication during ECDSA signature generation. We captured 100k traces to
estimate the number of traces an attacker would need to compromise the libgcrypt
ECDSA implementation, resulting in less than 2k for commonly used elliptic curve
secp256r1, demonstrating the attack feasibility. During exploitation, we found two
additional vulnerabilities. However, we remark the purpose of this paper is not merely
exploiting a library but about providing an analysis on the projective coordinates
vulnerability status in widely deployed open-source libraries, filling a gap between its
original description in the academic literature and the adoption of countermeasures
to thwart it in real-world applications.
Keywords: applied cryptography · projective coordinates leak · open source libraries
· side-channel analysis · ECDSA · modular inversion · binary GCD · libgcrypt ·
CVE-2020-10932 · CVE-2020-11735
1 Introduction
Side-channel attacks (SCA) are a major concern in the context of secure cryptography
implementations. They aim at recovering secret key material using state leaks that can
be used to compromise a cryptosystem. Since the pioneering works by Kocher [Koc96,
KJJ99], every cryptographic algorithm implementation has been an attacker target.
The leakage sources available to the attackers depend on the computing platform
where the target algorithm is executed. While power consumption and electromagnetic
emanations are commonly exploited channels for embedded targets [KJJ99, Cor99, BCO04],
shared microarchitecture components play this role for software implementations running on
commodity desktop to high-end CPUs [Per05, AGS07, Ald+19b]. In the microarchitecture
domain, several components can be used as leakage sources, such as cache-timings [YF14],
cache-access patterns [OST06], branch predictors [AGS07], etc. Each microarchitecture
attack vector exploits a shared resource available in microprocessors.
The task of assessing if a given algorithm implementation is SCA vulnerable often
involves identifying which secret data the algorithm processes, usually found in the
Licensed under Creative Commons License CC-BY 4.0.
Received: 20XX-XX-XX, Accepted: 20XX-XX-XX, Published: 20XX-XX-XX2 From A to Z: Projective coordinates leakage in the wild
algorithm specification. For instance, the elliptic curve digital signature algorithm (ECDSA)
[Fip] during signature generation uses a private key and a secret nonce. Therefore, the
implementer (or adversary) knows which primitives must be protected (or targeted).
ECDSA uses the secret nonce to compute a scalar multiplication, a highly targeted
operation in the SCA realm [BH09, Fan+10, FV12, Dan+13, AVL19]. The modular
inversion of the nonce is also a target [AGS07, PGB17, Ald+19a], as well as ECDSA
private key operations [Rya19].
However, while the private key and the secret nonce are well-known values that must
be secured, other secret-related values are less obvious. In this regard, in 2004 Naccache,
Smart, and Stern [NSS04] demonstrated how the projective representation resulting from
the computation of a scalar multiplication can be related to some bits of the scalar. While
this attack does not have a direct application to ECDSA, as the projective representation
of the scalar multiplication is not made public at the protocol specification level, it could
apply if the adversary can recover this projective representation using SCA, for example.
Despite this clever projective coordinates attack being known for more than 15 years, it
has received marginal attention by the scientific community. Maimut et al. [Mai+13] is the
only related work we are aware of, where the authors proposed a set of fault attack models
that could be used to recover the projective coordinate Z, allowing them to perform the
attack. However, neither this nor the original paper targets a real implementation. This
scenario allows us to formulate the following research question: What is the status of
widely deployed open-source software libraries regarding this attack?
In this paper, we aim to answer this question by filling the gap between the academic
results in [NSS04, Mai+13] and SCA mitigations in widely-deployed cryptography libraries.
To complement this analysis, we practically demonstrate this attack feasibility by developing
an end-to-end attack against the libgcrypt cryptography library. The main contributions
in this work are: (1) Analysis of the projective coordinates attack status in open-source
libraries; (2) first SCA on projective to affine coordinates conversion; (3) first exploitation
of the projective coordinates leak in a real-world ECDSA implementation (libgcrypt); (4)
demonstration that the Montgomery ladder is not a natural protection against this attack;
(5) demonstration that randomizing the generator point sometimes does not prevent the
attack; (6) first SCA on libgcrypt modular inversion; (7) three new vulnerabilities in
libgcrypt: a projective coordinates attack, single-trace ECDSA nonce recovery, and
recovery of a countermeasure mask.
The paper is organized as follows. Section 2 presents background on elliptic curve
based cryptography and ECDSA signature generation. Section 3 describes the projective
coordinates attack as presented by Naccache, Smart, and Stern [NSS04]. Section 4 analyzes
some mitigation strategies against this attack, highlighting straightforward methods to
thwart it. Later, Section 5 analyzes several widely-deployed open-source libraries regarding
this attack, providing insight into the resistance level of these implementations to this
threat. Before concluding in Section 7, Section 6 demonstrates an end-to-end attack
against libgcrypt using microarchitectural SCA. The goal is to show the feasibility of
the projective coordinates attack by running an in-depth experiment against a real-world
application, leading to ECDSA private key recovery using fewer than 2000 traces. At the
same time, we find and discuss two other vulnerabilities in the ECDSA path.
2 Background
2.1 Elliptic Curve Cryptography
This section provides preliminary background on elliptic curve cryptography (ECC) in the
context of the projective coordinates attack [NSS04]. Following the work’s rationale, the
attack description uses a simplified Weierstrass equation for elliptic curves defined over aAlejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 3
finite prime field Fp of large characteristic. However, other elliptic curve representations
can be analyzed following the same idea with corresponding changes.
An elliptic curve E is formed by the points (x, y) ∈ F2p that satisfy the equation
E : y 2 = x3 + ax + b, in addition to the point at infinity represented by O. The set of
points of E(Fp ) and the definition of an addition operation form an additive abelian group
with O as the identity element. Group law algebraic formulae of E(Fp ) for point addition
and doubling are defined as follows:
Point addition: Let P = (x1 , y1 ) ∈ E(Fp ) and Q = (x2 , y2 ) ∈ E(Fp ) such that P 6= ±Q.
Then P + Q = (x3 , y3 ) ∈ E(Fp ), where:
2
y2 − y1 y2 − y1
x3 = − x1 − x2 y3 = (x1 − x3 ) − y1
x2 − x1 x2 − x1
Point doubling: Let P = (x1 , y1 ) ∈ E(Fp ) such that P =
6 −P . Then 2P = (x3 , y3 ) ∈ E(Fp ),
where: 2 2 2
3x1 + a 3x1 + a
x3 = − 2x1 y3 = (x1 − x3 ) − y1
2y1 2y1
The above equations involve the computation of modular inverses in Fp , often un-
desirable regarding performance due to its long computing time. To address this issue,
developers often rely on a projective coordinate system to eliminate this expensive operation
performed during addition and doubling formulae. A frequently used coordinate system is
the Jacobian projective coordinate system, confirmed by our analysis on several popular
cryptography libraries, presented in Section 5. We use this coordinate system to describe
the attack, but likewise to the elliptic curve representation, the attack is adaptable to
other coordinate systems [NSS04, Mai+13].
An affine curve point (x, y) ∈ F2p can be represented as a Jacobian point (Z 2 x, Z 3 y, Z)
for any Z ∈ F∗p . Thus, given a Jacobian projective point (X, Y, Z), the corresponding
affine point can be computed as ( ZX2 , ZY3 ). Note that this conversion from Jacobian to
affine representation involves the computation of the modular inverse of Z. Equations (1)
and (2) (resp.) show point addition (X3 , Y3 , Z3 ) = (X1 , Y1 , Z1 ) + (X2 , Y2 , Z2 ) and point
doubling (X3 , Y3 , Z3 ) = 2(X1 , Y1 , Z1 ) formulae in Jacobian coordinates [HMV04].
A = X1 Z22
B = Y1 Z23
2
C = X2 Z1 − A
JADD = D = Y2 Z13 − B (1)
X3 = −C 3 − 2AC 2 + D2
Y3 = −BC 3 + D(AC 2 − X3 )
Z3 = Z1 Z2 C
A = Y12
B = 4A · X1
D = 3X 2 + a · Z 4
1 1
JDBL = (2)
X3 = D2 − 2B
Y3 = D · (B − X3 ) − 8A2
Z3 = 2Y1 · Z1
The security of non-post-quantum ECC schemes is based on the hardness of computing
discrete logarithms on elliptic curve groups (ECDLP). Roughly speaking, the ECDLP
states that given the points P and G, recovering the integer k that satisfies P = kG is4 From A to Z: Projective coordinates leakage in the wild
an intractable problem. The operation kG is known as scalar multiplication and consists
of adding the point G with itself k times. This is the most computationally expensive
operation in ECC, a popular research topic seeking to reduce its execution time [Tav+11,
GK15].
In this regard, the scientific community has developed several proposals to implement
scalar multiplication, taking performance and SCA security as optimization metrics. The
projective coordinates attack [NSS04] adapts to different scalar multiplication algorithms
[Mai+13], but for the sake of simplicity, and following previous work approaches [NSS04,
Mai+13], we describe it using the Double-and-Add algorithm (Algorithm 1).
Algorithm 1 often uses R represented in Jacobian coordinates, implying that the
resulting point R should be converted back to affine coordinates. As mentioned before,
this conversion requires the computation of a modular inverse. Modular inversions are
commonly computed using a binary GCD based algorithm which is a well-known side-
channel target—see for example: [AGS07, ACSS17, PGB17, WSB18, Ald+19a]. Section 5
and Section 6 expand on these facts.
Note that in Algorithm 1 the execution of a point addition is only performed when
the i-th bit of k is set. This property makes implementations of this algorithm highly
vulnerable to SCA if an adversary can distinguish a double operation from an addition,
yielding the binary representation of k. In Section 6, during a real-world instance of the
projective coordinates attack, we demonstrate a SCA-hardened version of this algorithm
in the open-source library libgcrypt is vulnerable to this attack.
Algorithm 1: Double-and-Add scalar multiplication
Input: Integers k and elliptic curve point G
Output: R = kG
1 R =O
2 for i = blog2 (k)c downto 0 do
3 R = 2R
4 if ki = 1 then R = R + G
5 return R
2.2 ECDSA: The Elliptic Curve Digital Signature Algorithm
ECDSA is the elliptic curve variant of the digital signature algorithm standardized by
NIST [Fip]. Algorithm 2 shows pseudocode for the ECDSA signature generation procedure.
This algorithm generates a digital signature for a public message (m) using the secret
private key (α), where h is the output of a known hash function applied to the message m.
Algorithm 2: ECDSA signature generation
Input: Message m, private key α, domain parameters of elliptic curve E (e.g., G,
p, n)
Output: Digital signature (r, s) on m under α
1 h = HASH(m)
2 k = random s.t. 0 < k < n
3 (x, y) = kG
4 r = x mod n
−1
5 s=k (h + rα) mod n
6 return (r, s)
Each generated signature involves selecting a random secret nonce k satisfying 0 < k < n,Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 5
performing a scalar multiplication of this nonce with the elliptic curve generator point G
of prime order n, and reducing the resulting value x modulo n [Fip]. At line 5, the linear
part of the signature generation computes the modular inverse of k and uses it to calculate
the public value s.
We are interested in the scalar multiplication kG, more specifically, in the projective
coordinates resulting from the implementation of that operation. This can be achieved
by either obtaining the full Jacobian representation (X, Y, Z), or obtaining the affine
representation (x, y) and one of the coordinates in the Jacobian representation that allows
easily deriving the others.
As mentioned earlier, R in Algorithm 1 is usually represented using projective coordi-
nates to speed up computations [HMV04]. However, ECDSA requires R to be returned in
affine coordinates, therefore a conversion from projective to affine coordinates takes place
before returning R in Algorithm 1.
On the other hand, it is trivial to compute any projective representation given the
output point R in its affine representation; there are p − 1 of them [HMV04]. However,
for the projective coordinates attack described in Section 3 the attacker is interested in
a very specific representation: exactly the one stored in R before coordinate conversion
takes place.
An ECDSA signature does not explicitly contain all the information needed for the
projective coordinates attack, nevertheless it is possible to obtain part of it. In fact, it is
possible to obtain the output point in affine coordinates by using the signature verification
identity (3), where the point Q is the public key [Fip].
(x, y) = kG = hs−1 · G + rs−1 · Q (3)
Moreover, the adversary critically needs to gather some information from the Jacobian
point representation obtained during the computation of kG. This Jacobian point cannot
be obtained directly from the ECDSA output, therefore ECDSA is not vulnerable to the
projective coordinates attack at the specification level; in contrast to the division-free
Schnorr signature scheme analyzed in the original paper where the projective coordinates
of the output point are public [NSS04].
Hence, to be able to apply the projective coordinates attack to ECDSA, the adversary
must gather some information about the Jacobian projective representation of kG by using
other means such as an implementation-based attack.
2.3 Projective coordinates attack and ECDSA: previous works
Regarding implementation attacks, to the best of our knowledge, there is only one work
[Mai+13] that aims at recovering information from the Jacobian representation of kG. The
authors proposed three fault models under which it is possible to recover the coordinate
Z. Two of them require that the same scalar value is processed several times, inserting a
fault for each of them. However, in ECDSA the same scalar condition is not fulfilled as
the nonce k is generated at random for each signature.
In terms of SCA, no work in the public literature has investigated how an adversary
can recover this information, a gap that this paper starts to fill. Protecting every bit
of k in ECDSA is mandatory to hold security, because even partial leakage can lead to
the recovery of the private key using well-known lattice techniques [HS01, NS03, BT11,
Ben+14].
Scalar multiplication has received generous attention w.r.t. SCA since the attack vector’s
inception, and several good surveys exist on the topic [Fan+10, FV12, Dan+13]. But
vulnerabilities on other operations have emerged recently, such as in the nonce inversion
operation [ACSS17, PGB17], and the modular reduction after h + rα [Rya19].
The projective coordinate attack of Naccache, Smart, and Stern [NSS04] has received
very little attention by the scientific community, not only regarding ECDSA but ECC6 From A to Z: Projective coordinates leakage in the wild
in general. Therefore, the information leakage from the projective representation of the
output point during scalar multiplication is rarely perceived as a threat.
3 Projective coordinates leak
This section describes the projective coordinates attack introduced by Naccache, Smart,
and Stern [NSS04]. Assume the adversary knows the projective coordinates of a point R
resulting from R = kG, i.e., R = (X, Y, Z). For example, this is possible in cryptosystems
like ECDSA, where an attacker can obtain the affine representation (x, y) using (3), in
addition to some leak allowing Z recovery, hence obtaining X = xZ 2 and Y = yZ 3 .
The main idea is to reverse the execution of the scalar multiplication algorithm starting
from the output point R. Without loss of generality, consider Algorithm 1 describing the
Double-and-Add scalar multiplication algorithm. In this algorithm, the execution of an
addition operation is controlled by the i-th bit of the scalar k, while a point doubling
operation is always executed. Therefore, if an attacker can distinguish at which iterations
i an addition was executed, then the binary representation of k is trivially recovered.
Following Algorithm 1, let us denote Ri = (Xi , Yi , Zi ) a Jacobian representation of
point R at iteration index i, where the output point is R0 . When the adversary reverses
the computation done at the last iteration (i = 0), it aims at obtaining R1 and so on. For
reversing the scalar multiplication execution, the adversary must guess ki and attempt to
find a no-solution situation that allows to state with certainty the value of ki .
If k0 = 0, this implies that only a point doubling was executed. The adversary can
reverse it by halving the affine representation of R0 , and computing Z1 using the doubling
formula (2) that yields:
s
4 Z0
Z0 = 2Y1 Z1 = 2y1 Z14 =⇒ Z1 = (4)
2y1
According to the above equation, the recovery of Z1 requires computing a fourth root in
Fp , with solutions depending on p mod 4:
• p ≡ 3 mod 4: solutions exist with probability 12 , and when possible, obtaining two
roots.
• p ≡ 1 mod 4: solutions exist with probability 14 , and when possible, obtaining four
roots.
Therefore, each computed Z1 allows to calculate X1 and Y1 using the affine representation
of R1 = (x1 , y1 ) obtained by halving R0 .
If, on the contrary, k0 = 1, a point doubling and an addition were executed at i = 0
so the adversary must first reverse the addition operation and then the double. Let us
denote T = (XT , YT , ZT ), the Jacobian point just before an addition occurs in Algorithm 1;
while G in projective coordinates is represented as (XG , YG , ZG ) and using lower case
notation for their respective affine representations. It is worth noting that addition is
usually performed using G represented in affine coordinates—i.e. ZG = 1, to reduce the
number of modular multiplications in (1), however we are using the full formula here to
support analysis in Section 4.
Applying the Jacobian addition formula (1) yields an expression for ZT :
r
−1 3 Z0
Z0 = ZT3 ZG
3
(xG − xT ) =⇒ ZT = ZG · (5)
xG − xT
In this case ZT requires computing a third root in Fp , with solutions bound by the following
rules:Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 7
• p ≡ 2 mod 3: a unique, computable solution always exists.
• p ≡ 1 mod 3: solutions exist with probability 13 , and when possible, obtaining one of
three values.
Likewise, from each ZT the adversary can compute the corresponding XT and YT . To
recover R1 , the adversary must reverse the double operation, as explained above, that is
executed when k0 = 1, but applying T = (XT , YT , ZT ) as input point.
Note that the computation of nth roots can lead to no solutions: for example, during
guessing k0 = 0 if no fourth roots are obtained, then the attacker concludes that this path
was not executed, learning that k0 = 1. In the case that both k0 paths have solutions,
no conclusions are drawn. However, the adversary can backtrack to previous iterations
of scalar multiplication looking for a no-solution path that allows to learn more bits of
k. It is worth noting that each computed nth-root generates a candidate point for Ri or
Ti , therefore the solution tree can grow very quickly. In general terms this implies that
the number of bits of k that can be recovered is small, but sometimes sufficient to apply
lattice-based cryptanalysis to recover the ECDSA private key using several such signatures
(as we practically demonstrate later in Section 6).
Naccache, Smart, and Stern [NSS04] provide some experimental results about the
probability of recovering some bits of k for different values of p, concluding that the most
vulnerable case is when p ≡ 1 mod 12. However, it is worth noting that the probability of
recovering a number of bits depends on several factors such as:
• The characteristic of the curve’s finite field.
• The projective coordinates representation (e.g., classical projective, Jacobian, etc.).
• The scalar multiplication algorithm.
• The elliptic curve form (e.g., Weierstrass, Montgomery, twisted Edwards, etc.).
These factors define the formulae for recovering Zi and Zt , hence the nth roots that must
be computed (if any after all). It is thus difficult to give a generic approximation about
the success rate of the attack, with so many implementation details at play. Therefore,
instead of following a case-by-case approach we adopt a more general one that aims at
showing that this vulnerability represents a potential security threat. We do this by (1)
presenting an analysis of several libraries with respect to the potential impact of the attack
(Section 5); and (2) providing experimental results of an end-to-end attack against the
ECDSA implementation of libgcrypt, a widely deployed open source cryptography library
(Section 6). The rationale behind this approach is that this leakage source is relative easy
to mitigate. Therefore, the use of a simple to implement countermeasure is more important
than providing a case-by-case analysis of how vulnerable a particular implementation is.
4 Mitigations analysis
To mitigate the projective coordinates attack, the original authors proposed two counter-
measures. The first—left as a challenge to the research community—proposes to transform
the point (X, Y, Z) with (X, Y, Z), where is chosen at random in {−1, 1}. Nevertheless,
Maimut et al. [Mai+13] showed that this countermeasure only makes the attack harder
but does not prevent it, as the attacker can apply the same attack principle and treat
the unknown as another “secret bit” and execute the attack for both values of and
backtrack seeking a no-solution path, like in the original attack.
The other countermeasure proposed by both [NSS04] and [Mai+13], is to randomize the
coordinate representation of the output point. The idea is to randomize the point (X, Y, Z)8 From A to Z: Projective coordinates leakage in the wild
by (λ2 X, λ3 Y, λZ) for λ chosen at random from F∗p . Using this method, the attacker has
no information about the original Z.
Another line of defense is providing SCA resistance to the primitives that handles
the output point like the employed modular inversion algorithm. One plausible approach
is to replace the use of input-dependent execution flow binary GCD based algorithms
by a Fermat’s Little Theorem (FLT) instance. The FLT allows to compute the inverse
of Z using the modular exponentiation Z −1 = Z p−2 mod p. Using this approach, even
a modular exponentiation algorithm that leaks the exponent can be used since p − 2 is
public.
4.1 Analysis of the randomized G countermeasure
In [Sto06], the authors proposed a countermeasure based on the randomization of the
projective representation of the generator point G in Algorithm 1, following the rationale
that it would prevent an attacker from reversing the addition operation using (5). However,
it does not protect as expected.
For example, consider an attacker that first guesses k0 = 1, then it has to reverse
the addition operation using (5), but in this case the projective representation of G is
randomized, thus ZG is unknown in (5). However, note that the cubic root computation in
(5) does not involve ZG , and the affine representation of G = (xG , yG ) is public. Therefore,
if no cubic roots exist in (5), it means that k0 = 1 is a no solution path.
Continuing with the attack, now the attacker guesses k0 = 0, thus reversing a point
doubling using (4) (that does not involve G). If this path leads to solutions, the attacker
can infer that k0 = 0. Therefore, backtracking to several iterations and applying this
procedure could lead to the recovery of some zero trailing bits of k. We validated this
procedure with 1000 simulated values of k, yielding no wrong recoveries while some trailing
zeros bits of k were recovered.
This analysis is a good example about the attack adaptability and the challenges of
threat assessment for each implementation. It evidences that instead of a careful analysis
for each implementation, an easier and more secure approach is to use one or both of the
proposed countermeasures.
4.2 Why the Montgomery ladder does not offer protection
In [Mai+13] the authors marked the Montgomery ladder scalar multiplication algorithm
as not threatened by the projective coordinates attack. At first this seems like a plausible
countermeasure. However, we demonstrate that it is not, providing analytical and exper-
imental evidence that the attack could indeed by applied to Montgomery ladder-based
implementations.
Algorithm 3 shows pseudocode of the Montgomery ladder for scalar multiplication.
This algorithm updates two points R and S at every iteration. However, it only outputs
the point R and this is the one that gets converted back to affine coordinates.
Considering an attacker that targets the projective to affine coordinates conversion
(e.g., modular inversion of Z), it can only get information on the projective representation
of R but nothing about S. The lack of information on S is the reason why the projective
coordinates attack was considered not applicable to the Montgomery ladder in [Mai+13].
However, analyzing Algorithm 3 it can be observed that if ki = 0 the update of R
does not depend on S at all. Thus, if k has trailing zeros, during the processing of the
corresponding iterations R will only get updated by R = 2R (line 6).
Following the projective attack, the adversary first guesses k0 = 0 and try to reverse
the computation of R = 2R. If solutions exist the guess k0 = 0 could be right. However,
to be certain about it, the adversary needs that the guess k0 = 1 leads to a no solution
path. During this branch R is updated by R = R + S, where S is unknown to the attacker.Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 9
Algorithm 3: Montgomery ladder scalar multiplication
Input: Integers k and elliptic curve point G
Output: R = kG
1 R =G
2 S = 2R
3 for i = blog2 (k)c − 1 downto 0 do
4 if ki = 0 then
5 S =R+S
6 R = 2R
7 else
8 R=R+S
9 S = 2S
10 return R
Note that this scenario is very similar to the one analyzed in Section 4.1 that showed an
unknown addition operand does not prevent the attack.
As demonstrated in that section, for Weierstrass curves represented using Jacobian
projective coordinates, the detection of no solution paths based on an addition operation
like R = R + S does not require knowing the projective representation of S. Instead, it only
requires knowing its affine coordinates (see (5)). Unfortunately, the adversary can know
the affine representation of S by exploiting a Montgomery ladder invariant: S = R + G
[JY02]. Thus the affine coordinates of R and G are known to the adversary, and hence S.
Therefore, if during the guess of k0 = 1, no cubic root exist in (5), the adversary learns
that it is a no solution path, concluding that k0 = 0 if this path indeed gave solutions. If
the attacker recover k0 = 0, it has a number of candidates for R, thus it can repeat the
process for other iterations. This way the attacker can recover trailing zero-valued bits of
k. We have validated this variant of the projective coordinates attack with 1000 simulated
values of k allowing to recover some bits with absolute certainty and free of errors.
It is important to remark that, similar to the analysis in Section 4.1, this attack against
the Montgomery ladder applies to Weierstrass curves represented using Jacobian projective
coordinates (see Section 2). Therefore, this attack could potentially be inapplicable to
others curve forms and/or coordinates system where it could be impossible to detect no
solution paths.
Similarly to the analysis performed in Section 4.1, porting the attack to work against
the Montgomery ladder shows the difficulty of assessing if a given implementation is
indeed threatened by this attack. This motivates a secure-by-default approach, applying a
countermeasure regardless of an actual proven attack against a given implementation.
5 Threat analysis in the wild: open-source libraries
This section analyzes the susceptibility of several open source cryptography libraries to
the projective coordinates attack. The aim is to provide a perspective about how prepared
widely deployed software libraries are regarding this attack.
Table 1 summarizes this analysis. For each inspected library we used the latest
version available and performed a source code-based static analysis to determine the scalar
multiplication algorithm used in each case. We focused this study on simplified Weierstrass
elliptic curves defined over prime finite fields, however the analysis can be extended to
others as well.
The column Z −1 mod p specifies the modular inversion algorithm used during the10 From A to Z: Projective coordinates leakage in the wild
Table 1: Open-source library status regarding the projective coordinates attack.
Library Version Scalar Multiplication Z −1 mod p Countermeasures Threatened
Libgcrypt 1.8.5 Double-and-add always BEEA Nonce padding Yes
MatrixSSL 4.2.2 Sliding Window BEEA - Yes
Mozilla NSS∗∗ 3.46.1 wNAF BEEA Nonce padding Yes
Crypto++ 8.2.0 Sliding Window BEEA Nonce padding Yes
Cryptlib 3.4.5 wNAF BEEA - Yes
mbedTLS 2.16.3 SCA-Hardened Comb BEEA Starting point randomization Yes
Libtomcrypt 1.18.2 Montgomery ladder BEEA - Yes
wolfSSL 4.2.0 Montgomery ladder BEEA - Yes
OpenSSL 1.1.1d Montgomery ladder∗ FLT Starting point randomization No
LibreSSL 3.0.2 Montgomery ladder EEA Starting point randomization No
BoringSSL 5d62952 Sliding Window FLT - No
Nettle 3.4.1 Sliding Window CT-BEEA - No
∗
OpenSSL uses Montgomery ladder for all curves except secp224r1, secp256r1, and secp521r1 that use a windowed scalar multiplication.
∗∗
NSS data is for secp384r1 and secp521r1 (secp256r1 uses FLT to compute the targeted inversion).
projective to affine coordinates conversion. We used this operation as a reference to
identify where there could be leakage in the output point projective representation for the
ECDSA scalar multiplication kG result. This decision is supported by the fact, evidenced
in Table 1, that modular inversions are often computed using insecure variants of the
Binary Extended Euclidean Algorithm (BEEA).
The “Countermeasures” column refers to those protections in the ECDSA paths
that have an impact on the scalar multiplication algorithm. This means that other
countermeasures like blinding k to protect its inversion in ECDSA are not reflected in
Table 1 as they do not have any impact on the scalar multiplication kG. Also, as the
scalar multiplication algorithms have their own column in Table 1 we omit them from the
“Countermeasures” column.
We titled the last column Threatened, instead of vulnerable, because to our consideration
a vulnerability is only present when it is demonstrated for the targeted implementation.
In this regard we have made such a demonstration on the libgcrypt library, where we
developed an end-to-end attack that leads to the recovery of ECDSA private keys (see
Section 6). This last column shows those libraries whose ECDSA implementations are
threatened (i.e. potentially vulnerable) to the projective coordinates attack due to leakage
during the modular inversion of Z in F∗p , being libgcrypt one of them.
At the end of Section 3 we summarized that the projective coordinates attack depends
on several factors. Therefore, performing end-to-end attacks on every possible implemen-
tation is a time-consuming task with several degrees of freedom, especially since Table 1
combinations are not exhaustive at all!
We instead choose to analyze mitigation strategies that are independent of these factors.
In this regard, Section 4 describes generic countermeasures to thwart this attack without
a significant performance loss. This rationale follows our main objective on providing an
analysis of the projective coordinates threat in widely deployed cryptography libraries
considering the little attention that this attack has received by the academy and industry.
Analysis of scalar multiplication algorithms. In the original work by Naccache, Smart,
and Stern [NSS04], the authors describe the attack when the Double-and-Add algorithm
is in use. Additionally, they also provide simulation results for the Sliding Window
algorithm. Later, Maimut et al. [Mai+13] complemented this study by analyzing other
scalar multiplication algorithms, like variants of the first two, in addition to algorithms
based on the Montgomery ladder.
Following the analysis and [NSS04, Mai+13], in addition to our results on the Mont-
gomery ladder in Section 4.2: We conclude that the scalar multiplication algorithms
summarized in Table 1 do not offer natural protection against this attack.Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 11
Analysis of modular inversion algorithms. Table 1 shows four algorithms used to invert
Z. BEEA represents those based on a variable-time binary GCD algorithm. Library-
specific implementations vary, but after a detailed analysis, we can confirm that those
labeled as BEEA can be targeted using well-known SCA techniques [AGS07, ACSS17,
PGB17], hence potentially SCA vulnerable.
Related to the BEEA, we labeled Euclid’s classic algorithm for computing modular
inverses as EEA (Extended Euclidean Algorithm). LibreSSL uses this algorithm as a
side-channel hardened modular inversion function, even though the execution flow of
this algorithm also depends on its inputs. No evidence of a side-channel attack on this
algorithm variant has been published yet, so its resilience against SCA remains as an open
problem. Therefore, to the best of our knowledge, this algorithm is considered safe in this
context.
An interesting approach is the one used by the Nettle library. Nettle uses a constant-
time BEEA (CT-BEEA), that removes branches from the algorithm to offer SCA protection.
Therefore, it is considered safe to be used for computing the inversion of Z.
The fourth approach is orthogonal to GCD-based modular inversion algorithms and
is based on the FLT. As analyzed in Section 4, it is considered a safe way for computing
modular inverses when the modulus is public.
Analysis of countermeasures. Table 1 shows two countermeasures in place in the analyzed
libraries. Nonce padding ensures that k always has the same bit-length by adding a multiple
of n to it. Section 6 describes this countermeasure in detail in the context of projective
coordinates attack vulnerability demonstration for the libgcrypt library, showing it is
possible to bypass this countermeasure, having no effect on the attack.
On the other hand, the countermeasure labeled Starting point scalar randomization
follows the same mathematical principle of the projective randomization countermeasure
described in Section 4. However, there is an important difference that makes the way
it is used in the mbedTLS, OpenSSL, and LibreSSL libraries meaningless to thwart the
projective coordinates attack. These libraries apply projective randomization to the
starting point, whereas the countermeasure to prevent this attack requires applying this
randomization to the output point before the projective to affine conversion. This is due to
the fact that the projective coordinates attack uses the output point to reverse the scalar
multiplication algorithm, looking for paths with no solutions: paths that can exist even
when the starting point is randomized. For these reasons, the countermeasure column is
red-colored to indicate that they do not have any influence on the attack.
Conveniently, the fact that these libraries have already implemented the projective
randomization countermeasure makes it extremely straightforward to add protection against
the projective coordinates attack by using this primitive before the projective to affine
coordinates conversion. Even in safe inversion cases, we feel this low-cost countermeasure
provides future proof hardening.
6 End-to-end attack: libgcrypt ECDSA
This section demonstrates the projective coordinates attack against the widely deployed
open source library libgcrypt. We target ECDSA signature generation and perform an
extensive experiment with the NIST elliptic curve secp256r1 [Fip].
Our source code analysis for the ECDSA implementation in this library reveals that, for
Weierstrass curves, the scalar multiplication is performed using Jacobian projective coordi-
nates and employing the double-and-add always algorithm, as depicted in Algorithm 41 .
1 https://github.com/gpg/libgcrypt/blob/d9c41830/mpi/ec.c#L169112 From A to Z: Projective coordinates leakage in the wild
This is an SCA-hardened version of the double-and-add algorithm, where an addition is
executed at every iteration, and an SCA-secured conditional assignment ensures that the
point R gets updated with the correct value depending on the value of ki . This means in
an abstract point of view that Algorithm 4 is essentially a double-and-add algorithm, and
the projective coordinates attack described in Section 3 applies without further changes,
even with this SCA mitigation.
Algorithm 4: Double-and-Add always
Input: Integers k and elliptic curve point G
Output: R = kG
1 R =O
2 for i = blog2 kc downto 0 do
3 R = 2R
4 T =R+G
5 R = cond_assign(T, R, ki )
6 return R
The library performs the conversion from Jacobian to affine coordinates using the
function _gcry_mpi_ec_get_affine2 . Computing the modular inverse of Z in F∗p using
the function _gcry_mpi_invm3 , which is a variant of the well-known BEEA [Knu98].
The BEEA has input-dependent execution flow, hence a suitable SCA target [AGS07,
ACSS17, PGB17, WSB18, Ald+19a]. An attacker can recover Z using SCA techniques
during the computation of Z −1 mod p, hence obtaining the Jacobian representation of the
resulting point kG during ECDSA signature generation.
This means that from the knowledge of Z the adversary can use the projective coor-
dinates attack to recover some bits of k. Repeating the process for a set of signatures,
the attacker can build a lattice to recover the private key by solving an instance of the
well-known hidden number problem [HS01, NS03, BT11, Ben+14].
The remainder of this section evidentiates the vulnerability of the libgcrypt library
to a projective coordinates attack in the context of the ECDSA scheme. For this task we
captured 100k independent traces corresponding to the generation of ECDSA signatures.
This extensive experiment allows us to estimate the number of recovered bits probability
mass function (pmf) for the projective coordinates attack and also estimate the average
number of signatures an attacker would need to recover the private key. The attack
roadmap as covered in the following subsections is:
1. Side-channel attack during the computation of Z −1 mod p.
2. Results of applying the projective coordinates attack against libgcrypt ECDSA
implementation with curve secp256r1.
3. Lattice attack for private key recovery.
6.1 Side-channel attack on libgcrypt BEEA
We frame our experiments on a libgcrypt instance running as part of a shielded envi-
ronment provided by Intel Software Guard Extensions (Intel SGX). This technology has
received generous attention recently due to its promising approach for securing compu-
tations on Intel CPUs. This has motivated academia to investigate security features of
open source libraries like libgcrypt when secured with this technology in the face of
side-channel adversaries.
2 https://github.com/gpg/libgcrypt/blob/d9c41830/mpi/ec.c#L1051
3 https://github.com/gpg/libgcrypt/blob/d9c41830/mpi/mpi-inv.c#L160Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 13
For instance, Shinde et al. [Shi+16] provide security analysis of several symmetric and
public key algorithm implementations in libgcrypt and OpenSSL libraries. Moghimi,
Irazoqui, and Eisenbarth [MIE17] introduced the CacheZoom attack, showing how the
libgcrypt AES implementation leaks when running inside an Intel SGX enclave. On the
other hand, Van Bulck et al. [VB+17] and Wang et al. [Wan+17] tested the side-channel
resistance of the libgcrypt EdDSA implementation hardened with Intel SGX.
Intel SGX provides software implementations the possibility to isolate computations in
a secure environment called enclave [Int19b, CD16]. This technology offers authenticity
and integrity protections to processes (called enclaves) running even in the presence of a
malicious OS. On the other hand, Intel SGX does not prevent SCA leaks, and it leaves the
task to protect against this attack vector to developers. This highlights the importance of
the projective coordinates threat especially because Intel SGX considers an adversarial OS,
which means that under the Intel SGX threat model, an SCA-capable attacker controls
the OS, and can have access to reliable leakage sources.
For instance, the controlled-channels attack proposed by Xu, Cui, and Peinado [XCP15]
provides access to the sequence of memory pages executed by the victim enclave, providing
a leakage source of 4 KB granularity that can be used to track the enclave execution
[Wan+17, Shi+16, VB+17, WSB18]. This attack relies on Intel SGX which leaves control
of its memory pages to the untrusted OS. Therefore, an adversarial OS can mark a memory
page with SCA relevance as non-executable and monitor it. A triggered fault indicates the
execution of the monitored page [XCP15]. Repeating the process for a set of memory pages
allows the adversary to track the sequence of executed memory pages, thus potentially
leaking secret data processed by the enclave.
The SGX-Step framework proposed by Van Bulck, Piessens, and Strackx [VBPS17]
provides a toolbox for developing page-fault based attacks, allowing carrying out this attack
against Intel SGX enclaves. In order to test the security of the libgcrypt Jacobian to affine
conversion regarding SCA, we integrated SGX-Step into the Graphene-SGX framework
[TPV17]. Graphene-SGX allows running unmodified code inside an Intel SGX enclave,
providing a straightforward approach to execute libgcrypt code in an enclave and assess its
SCA resistance. It is worth noting that the Graphene-SGX framework is not a requirement
for the attack, since libgcrypt can be ported to Intel SGX in the same way other libraries
such as OpenSSL or mbedTLS have been [Int19a, Sil19].
Threat model and experiment setup. The experiments were performed on a desktop
workstation using an Intel i7-7700 processor with SGX support running Ubuntu 18.04
LTS with kernel 5.0.0-29. Linux SGX support is achieved using Intel SGX SDK v2.2
and Linux SGX driver v2.1. SGX-Step v1.2.0 was integrated into Graphene-SGX (commit
58e6087) as discussed before. The vulnerability is demonstrated against an SGX enclave
that generates ECDSA signatures using libgcrypt v1.8.5 as cryptography backend.
Following the Intel SGX threat model with an adversarial OS, an adversary can trace
the sequence of pages executed by the enclave [XCP15, VBPS17, CD16]. It is assumed
that the adversary knows all page address(es) of every function of interest in the compiled
enclave hence their corresponding memory pages. This can be obtained by static analysis,
or by reverse engineering, thus it is not a limiting assumption.
As mentioned in Section 6, Jacobian to affine coordinates conversion in libgcrypt
involves the computation of a modular inverse using a variant of the BEEA. Figure 1
shows a snippet of the source code, where only the execution flow control statements and
function calls are left, taking into account that a page-fault attack has a 4 KB granularity
and this code fits in one page.
Previous work analyzes the relation between classical BEEA execution flow with its
inputs [AGS07, ACSS17], concluding that the adversary needs to gather how many times
a division by two (right-shift) is executed at every iteration, in addition to the result of an14 From A to Z: Projective coordinates leakage in the wild
1 do {
2 do {
3 if( mpi_test_bit(t1, 0) )
4 mpi_add(t1, t1, v);
5 mpi_rshift(t1, t1, 1); /* Zi */
6 mpi_rshift(t3, t3, 1);
7 } while( !mpi_test_bit( t3, 0 ) );
8
9 if( !t3->sign ) {
10 mpi_set(u1, t1); /* Xi = u */
11 mpi_set(u3, t3);
12 } else {
13 mpi_sub(v1, v, t1); /* Xi = v */
14 ....
15 mpi_set(v3, t3);
16 ....
17 }
18
19 mpi_sub(t1, u1, v1);
20 mpi_sub(t3, u3, v3);
21
22 if( t1->sign )
23 mpi_add(t1, t1, v);
24
25 } while( mpi_cmp_ui( t3, 0 ) );
Figure 1: BEEA variant as implemented in libgcrypt.
integer comparison that controls the execution of two branches.
The structure of the libgcrypt variant differs slightly from the classical BEEA. The
right-shift related execution flow can be easily identified at line 6 while the integer
comparison operation is not explicit. However, it can be easily verified that the condition
instruction at line 9 in Figure 1 is equivalent to the integer comparison in the classical
BEEA. Therefore, it is possible to apply previous SCA analysis results on classical BEEA
[AGS07, ACSS17] to the libgcrypt variant.
One important difference between classical BEEA and the libgcrypt variant is that in
the latter, the conditional statement at line 9 results in unbalanced branches, regarding the
number of function calls to _gcry_mpi_set. On the other hand, in the classical version
the equivalent branches are balanced regarding function calls.
This difference has a significant impact on the security of the libgcrypt implementation
regarding SCA. In the SCA realm it is well-known that unbalanced branches facilitate the
distinction of execution flow control statement results. Applied to the libgcrypt analysis,
the result of the condition statement at line 9 can be inferred by an adversary monitoring
how many times _gcry_mpi_set is called, while in the classical version it is one of the
limitations that an attacker must face to increase the number of recovered bits [ACSS17,
PGB17].
Therefore, adapting previous SCA results of classical BEEA to libgcrypt allows
stating that the adversary needs to recover how many times t3 is divided by two at each
algorithm iteration, in addition to the result of the condition statement at line 9. Gathering
this execution flow information for all executed iterations, it is possible to recover algorithm
inputs in polynomial time as proved in [AGS07, ACSS17].
Trace capture. Employing the SGX-Step framework it is possible to track the sequence
of executed memory pages by the victim enclave [VBPS17]. This allows the adver-
sary to obtain a side-channel trace related to the execution flow during the inversion
of Z −1 mod p. For recovering the execution flow corresponding to this computation us-Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 15
Table 2: Tracked functions and their memory pages.
Function Memory page
_gcry_ecc_ecdsa_sign 0xa1000
_gcry_mpi_invm 0xcf000
_gcry_mpih_rshift 0xd8000
_gcry_mpi_set 0xd5000
_gcry_mpi_add 0xcd000
_gcry_mpih_sub_n 0xd8000
ing the _gcry_mpi_invm function, we monitored the memory pages shown in Table 2.
Tracking _gcry_ecc_ecdsa_sign allows identifying different calls to the BEEA function
_gcry_mpi_invm during this procedure and isolate the one that corresponds to Z −1 mod p.
A trace about the tracked memory pages reveals that during an ECDSA signature gen-
eration in libgcrypt the BEEA is executed four times, corresponding to the computations
of:
1. The inverse of the secret mask b related to [Rya19].
2. The inverse of 2 modulo p (used internally during the scalar multiplication).
3. Projective to affine conversion: Z −1 mod p.
4. The inversion of the secret nonce k.
Regarding the projective coordinates attack, we are interested in the third one. There-
fore, the subtrace corresponding to the sequence of executed memory pages during the
computation of Z −1 mod p should have information about its execution flow. Two of the
other three executions of the BEEA also leak secret information—we will expand on this
later.
Monitoring _gcry_mpih_rshift allows to recover the number of times t3 is divided by
two, while the number of executed _gcry_mpi_set gives information about the condition
statement result at line 9 as required. However, auxiliary memory pages should be
monitored to distinguish additional calls to these functions from other functions. For
instance, the _gcry_mpi_set is a lower-layer multiprecision integer arithmetic function
that copies integer objects. Therefore, it is expected to be called frequently by other
functions in Figure 1. Hence, the adversary must distinguish between them to reliably
identify the calls that belong to the highlighted lines in Figure 1: this is where the auxiliary
memory pages help.
For example, let us represent a sequence of executed pages by “.S.S.LSLS.” where each
character represents a memory page (arbitrary). In this sequence it is possible to distinguish
the first two S symbols from the last two by observing their preceding executed pages.
Employing this approach it is possible to reliably count the number of _gcry_mpi_set
calls and recover the condition result at line 9. It also allows a straightforward distinction
of _gcry_mpih_rshift from _gcry_mpih_sub_n executions even if they share a memory
page.
The tracked memory pages needed to succeed could vary between libgcrypt versions
and toolchains used to build it. However, without claiming a formal proof, the attacker can
search for auxiliary pages that allows identifying the execution flow as required [XCP15].
During this research, we targeted the function _gcry_mpi_invm from three libgcrypt
versions which have different memory page mappings, always being able to reliably recover
the execution flow of this function.
After processing the 100k traces obtained during the computation of ECDSA signatures,
it was possible to identify the computation of Z −1 mod p in all of them. Processing the16 From A to Z: Projective coordinates leakage in the wild
sequences of tracked pages it was possible to recover the execution flow of all BEEA
executions without any error4 leading to a reliable recovery of Z in all 100k traces.
Attack requirement and noise influence relation. The projective coordinates attack
only requires that the adversary knows the projective representation of the output point.
This point should be error free, because if it does not, the adversary would recover incorrect
bits of k. In this regard, other side-channels could be used to recover the targeted point,
but if this channel is noisy, the adversary should reduce noise influence to the minimum
by for example discarding suspicious traces or using leakage redundancy. The main idea,
is to mitigate the noise as much as possible such that trace oversampling does not make
the attack impractical.
Additional vulnerabilities. As analyzed previously in this section, an ECDSA trace reveals
four use cases of the BEEA. In addition to the projective to affine conversion (item 3),
two additional use cases of the BEEA (item 1 and item 4) also leak information during
the ECDSA signature generation path.
During our experiments, we also found two additional vulnerabilities in the ECDSA
path. These vulnerabilities rely on the same insecure libgcrypt BEEA implementation.
As a response to the attack in [Rya19], a proposed countermeasure protects the ECDSA
computation (h + rα) mod n. The countermeasure relies on multiplying h and r by a
secret mask b, before involving computations with the private key α. However, to ensure
ECDSA correctness, (h + rα) should be multiplied by b−1 mod n, where this inversion is
computed using the insecure BEEA in libgcrypt. Notice that knowing the mask b allows
launching the attack described in [Rya19].
The other vulnerability is present during the libgcrypt ECDSA inversion of k, com-
puted with the same function used to invert Z (_gcry_mpi_invm), therefore the previous
analysis described applies directly.
For the sake of completeness we also targeted the nonce inversion vulnerability, by
exploiting the same BEEA primitive and obtaining similar results, full recovery of the
k in all 100k traces. More importantly, this last vulnerability represents a bigger threat
to libgcrypt than the projective coordinates one, as it only requires a single trace to
succeed. However, the purpose of this paper is not about merely exploiting the libgcrypt
library, but about providing an analysis of the projective coordinates threat status, filling
a gap between its original description by Naccache, Smart, and Stern [NSS04] and the
adoption of countermeasures to thwart it in real-world applications. A plausible approach
for fixing both vulnerabilities is using the FLT for computing the corresponding inverses
(see Section 4).
6.2 Projective coordinates attack results
Regarding the projective coordinates attack described in Section 3, the libgcrypt ECDSA
implementation has another important difference. The libgcrypt implementation has
a countermeasure to fix the length of k as a response to [BT11], and more recently to
Minerva5 .
This countermeasure modifies the value of k by adding a multiple of n to it; the scalar
multiplication algorithm processes this padded version. However, this countermeasure has
no effect on the projective coordinates attack results, but the adversary needs to know
that it is in place to be able to revert it, as detailed later in Section 6.3.
After processing the 100k traces and extracting the correct value of Z in all of them,
we launched the projective coordinates attack in the computer algebra system sage for
4 Verified using the known private key used in the experiment.
5 https://minerva.crocs.fi.muni.cz/Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley 17
each Z. We limited the backtracking to eight iterations, implying that the best leakage we
obtained is eight bits of k (see Section 3). This decision was made considering the next
attack phase (lattice-based cryptanalysis in Section 6.3) that allows recovering the private
key even with fewer than eight bits leaked per signature.
The projective coordinates attack outputs the number of bits recovered, in addition to
the value of those bits. With the extensive set of 100k traces it was possible to estimate
the leak in terms of number of recovered bits probability mass function, allowing us to
estimate the probability to recover at least ` bits of k.
Table 3 shows these probabilities for different values of `. This table suggests that the
probability of recovering ` bits decreases very quickly as this variable increases. However,
as demonstrated in Section 6.3 these results are sufficient to compromise the security of
ECDSA using a reasonable number of traces.
Table 3: Probability of recovering at least ` bits of k.
` 1 2 3 4 5 6 7 8
Pr[leak ≥ `] (%) 66.62 13.75 4.55 1.50 0.47 0.16 0.05 0.02
6.3 Private key recovery using lattices
The previous projective coordinates attack provides us partial information of the values
of k used to generate each of the 100k ECDSA signatures. For each signature i this
attack produces a tuple (ci , `i ), where `i denotes the number of recovered LSBs of the
corresponding ki , and ci the value of those bits. Thus, we can combine and use this
information to formulate a Hidden Number Problem (HNP) [BV96] instance and solve it
using lattices, which upon success leads to the recovery of the long-term ECDSA private
key, α.
We follow the formalization of [NS02, NS03] with the construction by Benger et al.
[Ben+14, Sec. 4]. More specifically, in libgcrypt the nonce k̂ is padded to protect against
remote timing attacks [BT11], resulting in
k = k̂ + ρ · n (6)
where n is the group order, and ρ is the minimum value in {1, 2} that satisfies:
blg(k̂ + ρ · n)c = blg(n) + 1c.
NIST standardized elliptic curves define n close to a power of two, implying the value of ρ
is known in advance with overwhelming probability [Fip, Ben+14]. Regarding NIST curve
secp256r1, it can be easily verified that ρ = 1, hence we can simplify the above equation
to k = k̂ + n. Therefore, for a signature index i, the leakage about its corresponding ki
can be described as:
ci ≡ kˆi + n (mod 2`i )
kˆi ≡ ci − n (mod 2`i )
where `i and ci are the information on ki produced by the projective coordinates attack.
We set ai = ci − n ( mod 2`i ), thus resulting in equations ki = 2`i bi + ai where `i and
ai are known. Define the following values known by an attacker:
ti = bri /(2`i si )cn
ui = b(ai − hi /si )/2`i cn + n/2`i +1You can also read
