 Hello, my name is Vladimir Sidlacek and I welcome you to this talk called Formula for Disaster. First, let us recall that elliptic curve cryptography is based on the infeasibility of the discrete logarithm problem. That is, if we are given a point P and it's multiple K times P, recovering the private key K must be hard. But how do we compute K times P? There are different scalar multiplication algorithms, but they always internally used point addition. Here you can see a textbook formula for adding two affine points. But it has many caveats. You need to distinguish several cases. The point representation is not really efficient and so on. There are many other addition formulas which try to optimize the operation count, but there is no single best solution for each context. This creates a lot of complexity. Let us imagine that you are a developer who wants to implement ECC. You have many choices to make. Depending on your curve, you might need to pick a curve model, short wire strass, Montgomery, Edwards or Twisted Edwards. Then you need to decide which point representation to use. Projective coordinates, Jacobian coordinates, extended Jacobian coordinates or any of the others. Based on these choices, you now need to select an addition formula. And finally, you have to choose a scalar multiplication algorithm, such as a variant of the blend add, ladder one or window one. Not all of these choices are compatible, but still there are lots of them. In this talk, we will focus on the formula part. So how does an addition formula look like? Well, it takes two points in the chosen coordinates as inputs and outputs their sum in the same form. There are many intermediate computational steps, and on this slide you can see an example. Starting at the left column, each of the computed expressions depends only on the previous ones until we obtain the output from the right column. Note that the addition formula is this whole thing while we refer to the individual lines as intermediate expressions. Alright, but why does the formula matter? The problem is that many formulas have exceptional cases, meaning there exist points for which the formula doesn't compute their sum correctly. Often there are hidden assumptions for the formula to function properly, which can lead to behavior that the developer doesn't expect. And indeed, in the past, we have seen several examples of this phenomenon in popular cryptographic libraries. Mozilla has issued two CVEs in its NSS, and there were also problems with the exceptional cases in OpenSSL and Google's BoringSSL. These led to incorrect computations, and in some cases also internal state leakage. The good news is that there is the explicit formula database, which catalogs a large number of formulas and tries to verify their correctness. Unfortunately, it takes some shortcuts and might miss some scenarios. Therefore, we decided to classify all exceptional cases in the EFD formulas to finally settle this. More concretely, here you can see all the addition and differential addition formulas in the EFD, divided by model and coordinates. So the short virus trust addition formula that we saw a moment ago was just one of 21 possibilities for that case. That's really quite a high number. To classify the exceptions, we took two different approaches. Posing allowed us to automatically go through all pairs of points on small curves so that we could try to extrapolate the results. Unfortunately, it had a lot of false positives, so we had to resort to manually going through all the formulas. In this way, we managed to completely classify all the non-reveal exceptional points. In most cases, there wasn't anything surprising, but for the formula I showed you before, we actually discovered a whole family of exceptional points. You can see its description here, but let me explain a bit more. To find all exceptional points, it is enough to analyze when you could possibly divide by zero, which in this scenario means investigating when the Z-free coordinate becomes zero. To make this easier, we developed a tool that allows you to unroll the formula using back substitution. So in this case, you can expand the Z-free coordinate like this, and you can further simplify it by letting Z1 and Z2 equal zero, meaning both P and Q are fine points. And now you can see that when Y2 equals minus Y1, you really get a zero for Z3. In fact, you also need the X coordinates of the inputs to be different to really get an exceptional case. Okay, so we found an exception. So what? Well, there's this exceptional procedure attack, or EPA for short, that can apply. But before I tell you more about it, let me mention two other attacks, the refined power analysis, RPA, and zero-value point attack, ZVP. We noticed that these attacks are quite similar in some sense, so we decided to describe a formal framework that unifies them and allows for generalizations. So what do these attacks have in common? Well, they all make use of a scalar multiplication side-channel oracle, which is constructed from the implementation. The idea here is that you are free to input any point you want to the implementation, and while it is multiplied by the secret key, you observe a side-channel of some type. Assuming these oracles was probably the most challenging aspect of our unification. We also need to assume that the private key is static, which can be the case, for example, for key exchange protocols. And finally, the scalar multiplication algorithm must have the property that if K' is a prefix of the secret key K, then K' times P is computed in the course of computing K' times P. With all these assumptions in place, how do we recover the private key K from the implementation? Well, the implementation computes a sequence of adds and doubles depending on K, and with a good side-channel, we can learn some information along the way. So at a very high level, the attack starts by guessing a prefix K' of K. Based on this guess and the given formula, we construct a special point and give it to the implementation. The side-channel then tells us if our guess was correct or not. So in this way, we learn a prefix of K, and we can repeat the whole process bit by bit until we learn the whole private key. The specific attacks differ only in steps 2 and 4, while the rest stays the same. So for EPA, in the second step, we construct P in a way to hit the exceptional case of the formula. The side-channel here is given by our ability to detect that the result was not computed correctly. We can see this either from software or physically. Even if there are no exceptional points and EPA does not apply, we can perform a slight variation to obtain ZVP, which can actually also be seen as a generalization of RPA. Here in the second step, we are choosing a point which zeroes out an intermediate expression, and the side-channel is based on our ability to notice computations with zero values. For example, by a shorter execution time, let's see an example. We can choose any of the intermediate expressions in the formula, so let's pick T4 here. By unrolling the formula, just like before, we obtain an expression that we need to zero out, but in this case it's not so clear how to do that. So let us try to formalize what's going on. We are given a scalar K' an elliptic curve and a multivariate polynomial F. The number of variables might depend on actual point representation. The goal is to find two curve points P and Q, whose coordinates are roots of F such that U is K' times P. We call this the dependent coordinates problem, or just DCP for short. And solving the DCP allows us to construct our oracles and recover the private key. Let's summarize the two cases we have already seen. For EPA, we can take F to be the expression for ZVP. For ZVP, we have more freedom, we can take F to be any intermediate expression. In the last example we took P4. And also for RPA, we can pick either the expression for X3 or Y3. So you can see that from this viewpoint, the attacks really look quite similar. But the problem is that the DCP seems to be hard in general. It is not clear how to capture the relationship between P and Q, because the strategy of using division polynomials does not really scale. It allows you to recover maybe 20 bits, which is not negligible, but perform enough. We managed to solve some new cases, for example, when K' can be represented as a ratio of two small numbers modulo the curve order. Unfortunately such numbers are rare enough it does not really help the attacks. But on the bright side, we also noticed that when F does not depend on one of the points, then the DCP becomes easy. For RPA, this is nothing surprising really, but RPA is not that powerful because it requires a curve with at least one point with zero X or Y coordinate, and it's quite easy to classify these and prevent the attack. More interestingly, we noticed this easy scenario can also occur for ZVP with some formulas. Moreover, we managed to use this to adapt ZVP to a new attack on window methods. We simulated such an attack on an implementation using the RCB addition formula, which is actually the only complete formula for prime-older short-virus stress curves. So you can see that even with a complete formula, you cannot prevent all possible attacks. To wrap it up, what are our contributions? We released the tool for formula unrolling as an extension of PSK, which is an open-source toolkit for reversing ECC implementations by one of our co-authors. We completed the classification of EFD addition formulas and found a new family of exceptions. We unified three known attacks in a formal framework that allowed us to come up with a new attack on window methods. We unfortunately did not manage to find a vulnerable implementation in the wild, but maybe that's a good thing, and it's not an unrealistic scenario as history shows. And finally, we solved new cases of a hard underlying math problem, which we call the deep TCP, but it still remains open in general, and it would be great if more people looked into it. So what are the lessons to be learned here? We should study widely deployed systems in advance and not wait for the actual attacks to happen. It's also useful to come up with simpler and conceptual viewpoints as they can push cryptonalysis further. We saw that the choice of the addition formula really matters, and that we should be more conservative with our claims. The best way to do that is to be very explicit about all assumptions, and ideally document them to help create a complete understanding. That's all from my side. If you enjoyed this talk, check out our webpage with all supplementary materials and software. Thanks and enjoy the rest of the conference.