start	end	text
1320	5260	Hello, I'm Diego Aguirre from Aarhus University, and I'm here to present
5260	11080	LadderLeak, our latest attack against ECDSA implementations using less than one bit of
11080	17460	non-slick HPUS signature. The paper was recently accepted in CCS, but a full version is already
17460	22120	available in ePrint. This is joint work with Felipe Novaes from the University of Campinas
22120	28520	in Brazil, Akira Takahashi from Aarhus University, Mehdi Tibushi from NTTA in Japan, and Yuval
28520	34920	Yaghan from the University of Adelaide in Australia. In the talk, I will describe new
34920	41280	attacks based on randomness leakage against ECDSA Schnorr-type signature schemes. The
41280	45540	attacks are based on newly discovered vulnerabilities in ECDSA implementations
45540	51100	contained in the OpenSSL and Relic cryptographic libraries, which motivated theoretical
51100	55800	improvements to the attack framework of the hidden number problem. In the first part,
55800	61100	I will talk about how to acquire side-channel information from the vulnerable implementations.
61100	65520	In the second part, Akira will discuss how to exploit this side-channel information to
65520	71900	recover the secret key by solving the agent P. Let's start with some background material
71900	78800	on attacking ECDSA analysis. So as you know, ECDSA and Schnorr signatures are the most
78800	83940	popular schemes relying on the hardness of the discrete log problem. In modern implementations,
83940	89300	of course, we instantiate this assumption using elliptic curve proofs. The signing operation
89300	95380	involves a secret value that's sometimes called the nonce, which is actually a major
95380	100560	understatement because this value needs to remain secret for a long term. Otherwise, it
100560	106840	has an impact on the security of the signature scheme. Let's assume a scenario where Alice
106840	112900	and Bob want to exchange signatures. So Alice generates a secret key and sends the matching
112900	119680	public key to Bob. When she wants to sign a message, she samples a nonce k as an integer
119680	124240	modulo of the group order and then combines the nonce with the message and her private
124240	129980	key to obtain a valid signature that Bob can verify using her public key. What's interesting
129980	135940	here is if you look at the set of the signing equation, valid signatures look like equations
135940	141980	relating public values from the valid signature with two unknowns, the nonce and the private
141980	148140	key. This means that if the nonce is exposed somehow, this allows one to immediately compute
148140	154240	the private key. So in practice, the nonce can never be reused or exposed. Otherwise,
154240	161360	the trivial amount of computation gives the private key. But this is an extreme case.
161360	166760	What happens if the nonce is slightly biased? For example, an implementation error or randomness
166760	171740	failure fix the top bits of the nonce. Or maybe side-channel leakage in the implementation
172560	176820	reveals some of these top bits. Then the attacker can actually
179360	184580	perform a collection of signatures under the same private key and compute the private key at the end
185780	189720	by solving the hidden number problem as discussed previously.
190480	194800	This class of attacks is not just of academic interest.
194800	199620	Actually, they manifest in practice in many different ways. For example,
199620	206260	when RNGs are poorly designed or implemented, when a bad entropy source is used to initiate
206260	211620	the random number generator, or for example, when a virtual machine resets to a previous snapshot
211620	218220	repeating the internal state. In the context of this talk, side-channel leakage actually
218220	223220	reveals some bits of the nonce that, of course, this is also a danger in practice.
223220	230160	The randomness failure became famous with the PlayStation 3 case, where Sony used the same
230160	236100	nonce to sign all games, allowing the homebrew community to compute the signing key from just two
236100	243440	legitimate games, which had a major impact at the time. So our set of contributions are
244120	250820	a novel class of cache attacks against ECDSA implemented in versions 1.0.2 and 1.1.0 of OpenSSL
250820	257580	and version 0.4 of the Relic cryptographic library. In principle, the affected curves
257580	263120	include any curve in which the group order is just below a power of two among the curves
263120	268720	implemented in these libraries. And this is reflected in many of the prime curves
268720	273640	standardized by NIST, and also the binary and Koblitz curves supported in the same standard,
273640	278800	and also curves from the SECG, the older SECG standard, such as, for example, the Bitcoin
278800	286820	curve SECP256K1. In our first version of the paper, we claimed that the attack was effective
286820	294620	in OpenSSL against curve P256, but we later found out, thanks to the CCS reviewer who pointed out
294620	301120	this, that OpenSSL has custom code for this curve that's enabled by default at build time.
301120	306120	So it's not vulnerable to the same attacks we found in the rest of the code base. And there
306120	312440	are other compiler build switches that you can use to turn on custom code that's not
312440	319540	vulnerable for other curves as well, but these are not enabled by default at build time. It's hard to
319540	324540	tell exactly what products are affected by this vulnerability because the versions of OpenSSL
324540	331280	we target are already deprecated. But by searching GitHub, we actually found out that some packages
331280	339260	bumped their OpenSSL versions from 1.0.2.U to 1.0.2.V, for example, which indicates that they
339260	344380	rely on that specific version of the library. These products include the Photon lightweight
344380	351220	operating system by VMware, the Chef remote maintenance tool, and the Wikr messaging app.
351460	356920	However, it's not clear that the attack will be exploitable in these products in a realistic
356920	361500	threat model, just that the implementation is vulnerable in principle, or was vulnerable in
361500	370000	principle. So this class of new cache attacks actually motivate improvements in the Fourier
370000	375640	analysis attack on the hidden number problem, significantly reducing the number of signatures
375640	381580	required to mount the attack. And in a way that it becomes feasible even when less than one bit
381580	386340	of nonce leakage is available per signature, which means that the attacker gets one bit of the nonce
386340	392560	with less than 100% probability by exploiting, in our case, side channel leakage. By combining
392560	398380	these two, we implement a full secret key recovery attack against ECDSA implemented in OpenSSL
398380	406360	over two sets of parameters, a 163-bit binary curve standardized by Secchi and a much larger
406360	414800	prime curve over a 192-bit prime standardized by NIST. The attack was mounted in a laptop
414800	420140	with the latter, it was mounted using help of cloud computing.
421500	426320	Now let's move to some curve-based cryptography. And you all know that an elliptic curve is a set
426320	432180	of solutions, x and y, over some field that satisfy the bias-stress equation, where the
432180	437440	coefficients of the curve are also taken from the field and there are some conditions for the curve
437440	443760	to be cryptographically interesting. The point at infinity serves as the identity element for
444800	450940	group law defined over these points. When the field has a large prime characteristic,
450940	458100	the curve can actually be simplified as e1 on the left. And when the curve is defined over a
458100	465820	binary field, the equation can be simplified as e2 on the right. The set of points under the
465820	471780	coordinate tangent point addition operation forms a group of order q, where q is typically chosen as
471980	478480	a large prime or must be chosen as a large prime for security, with the point at infinity serving
478480	485160	as the identity element for the group law. For efficiency, points are represented not in
485160	489320	affine coordinates during intermediate operations, but in projective coordinates to save
489320	495840	computation of expensive field inversions. And I can give some arithmetic intuition behind that
495840	502640	by looking at the group law. So, point addition on an elliptic curve works by
502640	506680	tracing a line across the points being added and reflecting the point
507900	512300	consisting of the intersection between the line and the curve across the x-axis.
512820	518520	This line becomes a tangent when the point is being doubled. So, computing the slope of this
518520	522720	line requires a division, which of course implies the computation of a field inversion that's
522720	527940	expensive. So, projective coordinates try to delay the computation of this inversion
528460	535500	until the very end by storing the denominator of the slope on the z-coordinate of some intermediate
535500	543830	point. All elliptic curve cryptosystems rely on the scalar multiplication operation both for
543830	549130	performance and security. Scalar multiplication amounts to adding a point to itself a certain
549130	554370	number of times, typically a secret number of times, and this signature generation is not
554370	560410	different. It takes a signing key, a message, curve parameters, and a hash function as inputs,
560410	568910	and it outputs a valid signature composed of two elements. It starts by sampling the known scale,
569050	573710	a model of the group order following the uniform distribution, and then it multiplies the
573710	579650	generator by these nodes. The x-coordinate of the resulting point is used in the remaining
579650	585690	of the computation to obtain the signature over the input message. Performance reasons we want
585690	590330	this scalar multiplication operation to be as fast as possible, but security concerns
590950	595970	also determine that the operation should be implemented in a way that's protected against
595970	601810	side-channel leakage. In particular, if we worry about timing attacks, this operation must be
601810	607430	implemented in constant time. And this is extremely challenging in modern CPUs because they have
607430	612190	user-learned instructions like CFlush that can reveal secrets across different processes
612790	618150	through cache behavior. For example, when two programs share a library in memory, a flush and
618150	624350	reload attack is possible. In a flush and reload attack, an attacker process probes a set of
624350	629550	targeted addresses to find out if a different victim process is accessing them or has accessed
629550	636270	them in a certain amount of time. The flush phase of the attack is actually flushing a set of
636270	641270	addresses from the cache. The reload amounts to reloading those addresses back to the cache and
641270	645350	measuring the amount of time it takes for that operation to finish, which tells the attacker if
645350	654450	this was a cache hit or a cache miss. If a certain address was read meanwhile, this means that the
654450	661490	reload phase will be shorter and a cache hit was actually observed. The time it takes between the
661490	666610	flush and reload parts of the attack is called the slot and this will be relevant later on.
666990	670810	This is not a completely deterministic attack. There could be cases in which
670810	676690	the memory access performed by the victim's process overlaps with the reload phase and
676690	682830	creates confusion for the attacker to distinguish between if the address was read or not.
682830	689850	So that's why we don't have a 100% precision side channel attack in our work.
690630	695370	When you implement scalar multiplication in a way that's protected against these attacks, you
695370	701390	usually resort to the Montgomery ladder, here defined over the Weierstrass model of elliptic
701390	707850	curve arithmetic. This algorithm takes an input point p, typically stored in affine coordinates,
707850	713690	and the binary representation of the exponent and initializes two accumulators r0 and r1,
713690	719330	such that r1 is 2 times p. Then it scans the bits of the exponent from left to right
720990	728130	and computes the same number of group operations per iteration. What changes per iteration is the
728130	736870	inputs of the group operations and the outputs. And this depends on the key bits. If you try to
736870	741250	implement this algorithm in constant time, there are several things to be taken care of. For
741250	746850	example, the number of iterations must be fixed, otherwise the magnitude of k would be revealed.
746850	752490	The accumulators must be read and written in the same order, independently of the key bits.
752490	756030	And the group law, of course, must be implemented in constant time as well.
756250	759570	Let's see how this can be done in typical implementations.
760370	766810	To make the number of iterations constant, it's usual to add one or two multiples of the group
766810	773210	order to the scalar to obtain a related scalar k'. And it's interesting that if the group order
773210	779310	is just below a power of two, this means that k' preserves in its second most significant bit,
779310	787690	the most significant bit of the original k. This will be relevant later on. Now k' has a fixed
787690	792930	length, so the main loop runs for a fixed number of iterations. The branches in the previous slide
792930	799470	can be actually removed by performing a conditional swap between the accumulators r0 and r1 that
799470	804250	depends on the key bit, which means that the group law will always be evaluated over the same
804250	809850	accumulators in the same order. So what remains is the careful implementation of the group law such
809850	816490	that no correlation with the key bits will leak through any side channels. And this is exactly
816490	825030	the point where our attack becomes relevant. For example, if the implementation leaks the fact that
825030	830850	r1 is being stored in affine coordinates, this means that the points were actually swapped for
830850	835690	this iteration which reveals the key bit. This observation also applies to point addition.
835690	841850	If it's possible to discover if r1 here is represented in projective or affine coordinates,
841850	848190	this also tells if the points were swapped or not, which reveals the key bit. So ladder leak is an
848190	853970	attack against the first iteration of the loop when the points are still stored in different coordinate
853970	860770	systems and it exploits the tiny differences or timing differences between the two operations
860770	867010	in projective or affine coordinates. After the first iteration of the main loop, the two accumulators
867010	874030	are stored in projective coordinates, so the performance or the behavior should look
874030	882410	uniform from that point on. It's critical here that if the attacker is able to distinguish
882410	886930	between these two situations, even for the first, just the first iteration of the loop,
886930	893190	the attacker can split the set of observed signatures into two different types which are
893190	900470	biased by the most significant bit of the known scale. That's how the hidden number problem is
900470	910190	used to recover the signing key. In our attacks, we targeted browser CPUs with turbo boost disabled
910190	919450	for reducing the noise in the measurements to have a slightly more stable attack. The OpenSSL
919450	924490	library was built using the default configuration with debugging symbols turned on to make the
924490	929950	text slightly more convenient, and binaries were executed in just userland without requiring any
929950	936090	privileges. In terms of tooling, we used the frtrace binary from the Mastic Section Analysis
936090	943470	Toolkit, and we configured the program to use a slot of 5,000 cycles, which show it to be
943470	951930	easy to measure against in our target platforms. We also employed the performance degradation
951930	959550	feature of the attack tool by having the idle course evict code from the cache all the time
959550	966850	to penalize performance and make computation run slower. Now let's examine how we mounted
966850	972370	these attacks against implementations of both prime and binary curves. In the case of prime
972370	978430	curves, the attacker can detect if r1 is stored in affine coordinates inside the point doubling
978430	983130	operation. So our attack works by probing two different addresses and measuring the time it
983130	987850	takes to hit the first address and the second address, and from the timing difference between
987850	994330	these two, the attacker is able to figure out what type of computation happened in between.
994590	999710	In the implementation of point doubling, if the z-coordinate is 1, there is a branch in OpenSSL
999710	1007210	to actually copy an input to the result. It's much faster than actually performing a complete
1007210	1013730	field multiplication operation. But it's still an operation that takes just a couple of hundred
1013730	1019390	cycles, which would not be observable in the time of the full-scale multiplication. So with
1019390	1024830	performance degradation, we penalized calls to the function bnCopy here quite a lot, and we
1024830	1030390	amplified the difference to 15,000 cycles, which allows the flush and reload attack to detect if
1030390	1038030	this function is called with more than 90% precision. And we can see this behavior in the
1038030	1045810	traces. So here the y-axis has the access timing cycles for reading some addresses in the cache
1045810	1053750	memory, and the sample number is the number of that specific sample read as scale of multiplication
1053750	1063670	proceeds. Any memory access that's faster than the red line counts as a cache hit, because it's,
1063670	1070750	memory address... memory access. So in the bottom trace, we can see that there is a first
1070750	1075090	cache hit here when bnCopy is called in the first time for the first point doubling the letter
1075090	1083630	when r1 is initialized. And then we see another set of cache hits here that amount to the point
1083630	1089470	doubling the first iteration of the loop. If the bnCopy function is called, it takes a bit longer
1090190	1095910	around three slots for the operation to finish, which makes it visible here. And of course,
1095910	1100650	the same behavior is not present when the most significant bit is 1, which allows the attacker
1100650	1108190	to distinguish the two different situations by just observing what happens in the first iteration
1108190	1115750	of the loop. A similar attack was mounted against binary curve implementations. In this case,
1115750	1121330	the attacker finds out if r1 was stored in protective coordinates during point addition.
1121410	1126190	The formula for point addition, the first field multiplication multiplies the x-coordinate of
1126190	1131990	r0 by the z-coordinate of r1. So of course, if the z-coordinate of r1 is non-trivial,
1131990	1138090	this field multiplication will give a non-trivial double precision result that needs to be modular
1138090	1143990	reduced. By using performance degradation, we penalize calls to the modular reduction code
1143990	1148710	to make this field multiplication take much longer than necessary. And we managed to amplify
1148710	1154050	the difference between 200,000 cycles, which allowed us again to detect if the
1154050	1165350	z-coordinate of r1 is one with over than 99% precision. By looking at the traces, we see
1165350	1173250	similar pattern. On the bottom trace, you can see that there are two consecutive cache hits
1173250	1179090	when modular reduction is called and they are around 20 slots apart, which tells that the
1179090	1185250	difference in execution time between these two points in time was close to 100,000 cycles.
1185330	1191630	And the same pattern is not present when the most significant bit has a different value and the
1191630	1197810	modular reduction code actually finishes much faster because the result being reduced is trivial.
1200560	1206280	There are at least three possible fixes for these vulnerabilities. The first one, and perhaps most
1206280	1209920	natural, is to randomize the z-coordinates at the beginning of this scalar multiplication
1209920	1215240	for the two accumulators in a way that all points' intermediate values are stored in
1215240	1220200	projective coordinates, so no special cases arise. Another possibility is to implement the
1220200	1224560	group law in constant time using, for example, complete addition formulas without branches,
1224560	1230180	or to implement the Montgomery letter over co-z arithmetic to not handle z-coordinates directly.
1231060	1236880	We disclosed the vulnerabilities to OpenSSL in December last year when the versions we
1236880	1243580	targeted were still maintained, and the vulnerabilities were fixed in April this
1243580	1250800	year using the first countermeasure as the solution. The main takeaways of this part
1250800	1256680	of the talk is securely implementing brittle cryptographic algorithms is still very hard and
1256680	1263260	we should not underestimate timing leakage even if it looks tiny at first or not easy to exploit.
1263520	1269620	For the audience, I can recommend upgrading OpenSSL to the recent releases as soon as possible
1269620	1275900	because the development team has done a wonderful job at improving the security and quality of the
1275900	1282160	codebase across time, so we should all benefit from that. From this point on, Akira continues
1282160	1286580	with the part two of the presentation. Thanks for your attention so far.
1288460	1294520	Hello everyone, my name is Akira. I'm from OSU University in Denmark. So in this part I'm going
1294520	1300160	to explain how to exploit the randomness bias or leakage that we obtained during the
1300160	1308520	side-channel attack against ECGSA nonce. So here is the overview. So in the second part, we'd like to recover
1308520	1315280	the ECGSA secret key by solving the so-called hidden number problem, which was originally
1316020	1323260	stated by Bonnet and Ben-Carteson. And our approach follows the Fourier analysis-based attack
1323980	1331460	originally devised by Blahenbacher. And here, our main contributions can be summarized as follows.
1331740	1337400	First, we established a unified time-space data trade-off formula to solve the hidden number
1337400	1344800	problem. And then, we gave a generalized analysis that holds even in the presence of erroneous
1344800	1350000	leakage information, which is crucial when mounting the side-channel attack in practice.
1351480	1358760	Also, the techniques devised in this part, in principle, apply to other sources of
1359280	1366660	bias or leakage, independent of the ladder-leak vulnerability. And as a result, we
1367440	1373020	draw an interesting connection between the hidden number problem and the generalized
1373020	1378620	per-state problem, which often appears in the context of symmetric key cryptology.
1380660	1387900	So first, let's define the problem we tackle. So we are interested in solving the hidden number
1387900	1396180	problem with most significant bit leakage. So here, h and z are public information,
1396180	1402280	which can be computed from the ECGSA signature. And the sample h and the nonce k
1402960	1409760	follows the uniform distribution over z cube, and then satisfy this equation.
1410300	1417320	And here, the hidden number problem asks to find the secret key given the pairs h, z,
1417320	1425060	and the most significant bit information of k. However, as we observed during the side-channel
1425060	1431380	attack phase, the most significant bit information doesn't come with probability 1.
1431380	1439400	That's why we have to slightly generalize the hidden number problem by incorporating the erroneous
1439400	1446140	most significant bit leakage information. And this is exactly what we call less than
1446140	1453470	1-bit nonce leakage. So in this setting, the hidden number problem with error rate epsilon,
1453740	1460520	which is between 0 and 1.5, asks to find the secret key given h, z, and the most significant
1460520	1467620	information of k with probability 1-epsilon. And this error rate models attacker's misdetection
1467620	1474240	during the side-channel acquisition phase. If epsilon is 0, then this is same as the original
1474240	1480820	hidden number problem. If epsilon is 1.5, then essentially the attacker doesn't know anything
1480820	1487380	about the nonce bit. So this is the problem we'd like to solve.
1488220	1494120	So how do we attack the hidden number problem? There are basically two approaches.
1494120	1502120	The first one is more famous, which is called the lattice attack. So lattice attack usually works
1502120	1510920	very efficiently, even with fewer number of signatures. However, lattice attack only works
1510920	1518940	if you have a relatively large bias or leakage information about nonce. And in particular,
1519240	1525740	if you only have 1-bit information about nonce, it is known that lattice attack doesn't give you
1526220	1532040	the correct solution of the hidden number problem. So here, the Fourier analysis-based
1532040	1539180	attack comes into play. So the nice feature of the Fourier analysis-based attack is that
1539940	1548000	it can attack less bias or less leakage information. However, usually this approach
1548000	1558040	requires much more signatures as input. So in this context, we set the new attack records
1558040	1563100	for the hidden number problem. So here's the comparison with the previous attack records
1564100	1569420	of the hidden number problem. The green ones are based on Fourier analysis,
1569420	1576380	while the purple ones are based on lattices. And we basically solved these four cases.
1577080	1585960	For a 160-bit HNP with 1-bit leak, compared to prior records, we required fewer input signatures
1586700	1594160	to attack. And on the other hand, to the best of our knowledge, there has been no
1595080	1605040	attack records for the 192-bit HNP with 1-bit leakage. So we set some new attack records
1606260	1614440	in these attack parameters. Okay, so before describing our technique, let me briefly go
1614440	1620600	over the fundamentals of the Fourier analysis-based attack. So what is the Fourier analysis-based
1620600	1627540	attack? So this was originally proposed by Brian Bacher already 20 years ago. And in the last
1627540	1635340	decade, this was revisited by Demaldo et al., and also two other works, including some of us
1635340	1642360	as authors. And the great feature of the Fourier analysis-based attack is that
1642360	1648860	it can exploit arbitrary small bias or leakage of randomness to solve HNP.
1649820	1657320	And another great feature is that it can handle the erroneous input out of the box, so to speak.
1657400	1664720	However, as I mentioned, the large data complexity is the major bottleneck of this approach.
1664720	1674200	In particular, for instance, if you attack a 160-bit HNP, the prior attack required
1674200	1681140	billions of signatures to attack 1-bit leakage. So of course, the natural question is,
1681140	1687000	can we reduce the data complexity? I'm going to answer this question later.
1688220	1695680	But first, let's see how Brian Bacher's attack works. So here's a high-level overview.
1696440	1701320	So the step one is to quantify the modular bias of randomness k.
1702240	1708340	And we first define the bias function, such that it outputs something close to 0
1708820	1716160	if the noise is uniform in ZQ, while it should output something close to 1 if k is somewhat
1716160	1723840	biased in ZQ. Then, using this bias function, we'd like to find a candidate secret key,
1723840	1731960	which leads to the peak of this bias function. And then there's an important optimization step,
1731960	1737950	which is called collision search of integers h, where h is a part of the signature.
1739020	1747330	And this optimization step is very important to detect the bias peak correctly and efficiently.
1748450	1755890	Okay, so that's the overview. So first, what is the bias function? So the bias function can be
1755890	1763970	essentially defined in the form of discrete Fourier transform. So in order to interpret
1763970	1770930	this definition, it is useful to imagine the complex plane and the unit circle on it.
1771830	1780130	For instance, if the noise k is uniformly distributed in ZQ, then we can imagine that
1780770	1789730	each vector is directed to different directions. So of course, if you take the sum of those vectors
1789730	1798950	and normalize them, then we can expect that the resulting norm of the sum vector is small.
1798950	1809370	On the other hand, what if the nonce bit is biased? For instance, if the top bit of the
1809370	1819110	nonce is fixed to zero, then we can actually see that each corresponding vector is concentrated
1820070	1827750	in the upper half of the unit circle. Then in that case, if you take the sum of those vectors,
1827750	1834710	then the resulting norm is expected to be much larger than the other case.
1834750	1839470	So this is the intuitive way to interpret the bias function.
1840450	1847250	So we can actually concretely calculate the output of the bias function. So here's the
1847990	1857730	useful lemma. If the randomness k's top bits are fixed, for instance, if the nonce bits,
1857730	1866250	are fixed to zero one, like this, then its modular bias can be estimated by this form.
1867050	1873410	So using this form, we can indeed calculate the value of the bias function. And as you can see
1873410	1883670	here, if the biased bits are larger, then the resulting bias gets closer to one.
1885330	1892770	So this is the concrete behavior of the bias function. But in order to model the error-nearest
1892770	1901790	input, we have to give more analysis of the bias function. So this is what is given in the paper.
1902830	1910710	So in our case, we are particularly interested in the one-bit bias case. So here, this lemma says
1910710	1921980	that if the nonce bit, if the nonce is a one-bit bias with probability one minus epsilon,
1922290	1931510	then its bias value can be described by a bias for, sorry, the bias function
1932280	1940110	value for full one-bit bias multiplied by one minus two epsilon. So this is how
1941030	1950790	the bias value decays depending on the noise to epsilon. For instance, if the most significant
1950790	1957110	bit of the case speaks to zero, except one percent fraction, in other words, if epsilon
1957110	1967110	is equal to 0.01, then the bias function can be calculated like this. So we are going to use
1967110	1972990	this bias function under the randomness input in the complete analysis.
1974090	1980830	So now, using this bias function, we'd like to detect the bias peak. Here's a naive approach.
1980870	1986290	So first, we are given m samples of signatures satisfying this module equation.
1987050	1993830	Then, we pick a secret key candidate and compute the corresponding randomness.
1994550	2001330	Then, using the set of corresponding randomness candidates, we compute the bias function
2002150	2004350	with a suitable FFT algorithm.
2006150	2012930	And finally, if the guess is correct, we can detect a significant non-zero sample bias.
2013190	2019310	If the guess is incorrect, then actually we can show that the noise floor
2020510	2027870	of the bias function is approximately 1 over square root m, which should be small
2027870	2034530	if the m is sufficiently large. But of course, this naive approach is inefficient
2035390	2040990	because the peak only appears if you hit the exact solution.
2042010	2048090	And so this approach is of course clearly invisible if the modulus Q is large.
2048090	2054970	In the concrete case, the Q is at least 160 bit, so we cannot really compute because FFT
2055690	2062230	algorithm takes order Q space and order Q times log Q time.
2063050	2065950	So, how do we circumvent this issue?
2066550	2075830	So, Gleichenbacher gave a very clever observation to reduce the complexity of the FFT algorithm.
2076790	2083090	So, this is the most important step called collision search space.
2083750	2088450	So, this is useful to broaden the peak of the bias.
2088710	2090710	So, Gleichenbacher's observation is as follows.
2090710	2096190	By reducing the range of the input samples h to 0 and l,
2096190	2101630	where this l should be much smaller than the original modulus Q.
2101630	2106070	And by taking the linear combinations h samples,
2106070	2111230	peak width actually broadens to approximately Q over l.
2111570	2116110	However, as a negative side effect, the peak height actually decays.
2117330	2124470	But anyway, thanks to the broadened peak, it is sufficient to check only l candidates
2125050	2126410	of the secret key.
2127050	2136230	And now the complexity of FFT is much smaller if you choose the l appropriately.
2137110	2143890	And by checking the l candidates, at least you can expect that you hit somewhere in this model.
2143890	2149070	So, this is the overall idea of the collision search space.
2149470	2155650	So, more formally, collision search problem in Gleichenbacher's framework can be stated as follows.
2155650	2161620	So again, we are given m signature pairs and we set the memory budget for FFT.
2162190	2165660	Then we'd like to find sufficiently many linear combinations,
2166090	2171620	such that the resulting linear combination is smaller than the memory budget for FFT.
2172350	2180230	Also, we have to make sure that the coefficients of the linear combination is sparse.
2180230	2186470	And this is important because otherwise the bias peak decays a lot.
2186530	2194030	So, we have to make sure that the decayed bias peak is at least larger than the noise floor.
2195070	2201150	So, we have to find some good balance between the smallness of the linear combination
2201730	2204050	and the sparsity of the coefficients.
2204870	2209370	So actually, this problem looks really like a subset sum problem.
2209370	2212310	However, there's a subtle difference.
2212310	2218170	In our context, we need many linear combinations instead of a single exact solution.
2218570	2225830	So, we have to use some appropriate algorithm to solve this collision search problem.
2225830	2229270	So, in our work, we apply Cayley's sum algorithm,
2229470	2235710	which was usually applied to attack the generalized first step problem.
2236450	2242250	So, here's the very high-level overview of the Cayley's sum algorithm for generalized first step
2242250	2250710	problem. So, in Cayley's sum algorithm, you are usually given multiple lists of the samples.
2251630	2257230	And then, if the number of the list is four, for instance,
2257230	2263550	you first take the linear combinations of two between two lists.
2263550	2271480	Then, you find some linear combinations such that the top bit corresponds to a certain value.
2272210	2276950	Then, you construct the intermediate lists.
2277610	2283170	Then, by taking the difference between those two lists,
2283700	2288040	we find some small linear combinations, four.
2288310	2293230	And thanks to the intermediate collision found in the prior phase,
2293230	2299490	we can expect that the resulting difference is somewhat small.
2299490	2303100	So, that's the very high-level idea of this algorithm.
2304070	2309170	And in particular, we apply Howard Graham Joe's Cayley's sum algorithm.
2309170	2317290	There are many variants, but this version of the Cayley's sum algorithm has two great advantages.
2317290	2322480	First, it has configurable time-memory trade-offs.
2323210	2329220	Also, it is highly parallelizable, and this is important when we implement a typing practice.
2330090	2337410	So, the question we asked earlier can be elaborated as follows, because
2338110	2341930	now it is not sufficient to consider time-memory trade-offs.
2341930	2348330	We have to introduce the third parameter, that is, input data complexity.
2349190	2353590	So, our question is as follows. For a given most significant bit information
2353590	2359070	from a hidden number problem and a typical budget for computational resources,
2359070	2364750	what would be the optimal balance between the time, memory, and input data complexities?
2364750	2366530	We answer this question in the paper.
2367470	2375510	So, again, here's the high-level description of the unifying time-memory data trade-off
2375510	2383110	that we derived based on the prior work. So, I'm not going to explain how we derived this formula,
2383110	2396090	but intuitively, to interpret this formula, you can see the behavior of each variable as follows.
2396090	2405850	So, first, the goal of our program is to find many solutions, which is m i minus one,
2405850	2413130	and intuitively, if you spend more time or if you have more memory space, then we can expect that
2413990	2423250	we find many output samples. On the other hand, if you have to find many bit collisions,
2423250	2431170	then probably we get less number of samples. So, that's the intuition.
2432010	2439390	And then, together with a trade-off formula and the constraints that I showed earlier from
2439390	2445450	Blahen-Blahen, we can indeed estimate the optimal time-memory data complexity balance.
2446250	2450430	So, here's the result. So, we calculated the trade-off curves
2451330	2460690	for each HNAP instances. So, for instance, in order to attack 6163 R1 curve,
2461590	2471950	if you can spend around 2 to the 55 time, then you only need around less than a million signatures.
2472670	2479450	And if you can spend much less time, then you need more data as input. And the same analysis
2479450	2487870	applies to the other NIST curves. Also, even though I focused on a 1-bit bias case, our paper
2487870	2496090	has various trade-off graphs and improved complexity estimates for 2 or 3-bit bias.
2497730	2508710	So, to show the usefulness of our analysis, we implemented the entire attack.
2508710	2516350	Here's the experimental results on the full-key recovery for the OpenSSL.
2517250	2526510	First, when we attacked P192, our highly optimized parallel implementation helped a lot.
2526650	2535170	So, we executed our attack using AWS EC2 instances, and we used 24 instances
2535950	2543930	here. And in the end, we were able to recover the many most significant bits of the secret key.
2544470	2553070	And the attack was successful for both cases, where there was no error in the input samples,
2553070	2556010	and there was 1% error in the input samples.
2557690	2565870	And on the other hand, the attack against 163R1 was very modest in terms of computational
2566670	2573330	complexity. And we can actually infer that the attack against this case is even feasible with
2574010	2580870	an everyday laptop. And also, the input data complexity was much more modest compared to the
2580870	2590410	prior work. Actually, we improved the data complexity by a factor of 1000. And of course,
2590410	2598790	the attack works against both the samples with errors and without errors. And once you recover
2598790	2605570	the top bits of the secret key, recovering the remaining bits of the secret key is much cheaper
2605570	2613510	in Bly-Hendel's framework. And based on this empirical result, we can infer that the attacks
2613510	2625830	against P224 with 1-bit bias or P256 with 2-bit bias are also tractable. Okay, so to conclude,
2625830	2631730	in this work, we show that even less than 1-bit of nodes leakage becomes a practical concern.
2631730	2637770	And we draw the interesting connection between two different cryptographic problems,
2638470	2645490	which appear in the different contexts usually. And after the analysis, we got multiple open
2645490	2653630	questions. Of course, the first one is the least-sum algorithm. Because we only analyzed
2653630	2661490	particular instances of the k-least-sum algorithms, we are interested in exploring
2661730	2667800	more trade-offs obtained by other variants of the least-sum algorithms.
2668750	2680040	Also, in the FFT computation part, we basically used the existing library as black box.
2680630	2688520	So, of course, there's probably some room for improvement for the FFT computation phase.
2689080	2696580	And as I mentioned earlier, this analysis is not restricted to ladder-leak vulnerability.
2697320	2707720	So, in the future, if there are more sources of small leakage in the ECGSA nodes,
2707720	2715160	in particular, according to our analysis, if two or three bits of leakage of bias are available,
2715160	2723000	then the tactic attack is much more efficient, and our analysis in principle applies.
2723500	2729080	Also, we are interested in analyzing the behavior of bias function for more
2729080	2736260	general patterns of noise indication. Okay, so that's it for me. Thank you for listening.
2736620	2744020	If you have any questions, I will be happy to answer. And if you are interested in more details,
2744020	2764880	you can find our paper in this address. Welcome back, everybody. You were just listening to
2764880	2771700	ladder-leak, breaking ECGSA with less than one bit of non-sleekage. I have Diego and Akira right here
2771700	2777500	with me. Welcome back, everybody. Hello, hope you enjoyed the talk.
2778560	2783120	So, we have two questions. I'll start with the easy one first, because you answered in the
2783120	2788560	Discord chat. Again, we take questions in the Discord chat. So, would the speakers be able to
2788560	2793400	share their software on GitHub or so that we can rerun the research on the newer libraries?
2793400	2798120	Obviously, you're participating in the Discord chat. It's over there. Anything you want to add to that?
2799380	2807540	Yeah. So, yes. So, we already published a code in our repository. However, if you want to reproduce
2807540	2815300	our result, probably it's a bit difficult because we didn't document our code very well.
2815300	2824560	So, certainly, after we revise our paper, we'd like to also revise the documentation. And then,
2824560	2831600	hopefully, you can rerun the attack. And also, of course, if you have any questions about the setup
2831600	2838380	or dependencies to rerun attack, I would be happy to answer the question.
2839200	2845620	Okay. Next question. When attack is discovered in ECs, is there a way to know about which
2845620	2849140	curves will be affected by properties, or is it a guessing game?
2850380	2855360	So, I think you can classify roughly attacks against elliptic curves in two types. They could
2855360	2860540	be algebraic attacks against some specific class of curves that rely on the mathematical properties
2860540	2865080	of those curves to be effective. And usually, they destroy that class of curves from the
2865080	2869920	cryptographic perspective. So, you can think of supersingular curves as a prime example of that
2870740	2875300	by transferring the discrete log to another statement where tools are more powerful for
2875300	2880860	the attacker. This basically kills supersingular curves for ACC. In this case, we have implementation
2880860	2886760	artifacts that allow an attacker to be effective against an implementation. And then, what's
2886760	2892660	common about this is you have some creative step to think of an attack, and then you need to find
2892840	2898380	a matching scenario for it to be relevant. And then, it's about rigorously maximizing properties
2898380	2903480	of interesting curves that are standardized or maybe used in practice to see where they apply.
2903480	2909100	So, there is a creative part and just a follow-up rigorous part of maximizing
2909100	2912420	what's the real impact by looking at curves that are interesting.
2914500	2919260	Well, thank you. That was a fascinating talk. Let's just... we're going to say goodbye. So,
2919260	2925180	thanks again, Diego and Akira. Goodbye. Thank you. Enjoy the rest of the conference.