 Okay, so hello everyone. My name is Akira Takahashi. I'm from Office University in Denmark. So today I'm going to talk about our recent paper, Security of Hedged Fiat Shamiya Signatures under Phototax. This is a joint work with Diego Aranya and Claudio Orandi from Office University and Greg Zabrucha from Microsoft Research. So, as the title suggests, this work is basically about the photo attacks against the Fiat Shamiya type signatures. Especially, our goal in this work is to formally analyze the photo resilience of the existing Fiat Shamiya signature schemes using the provable security methodology. So this work is actually motivated by the existing concrete photo attacks against such signature schemes. So in this talk, first I'm going to briefly talk about the history of the photo attacks against the Fiat Shamiya type signatures. Also, I'm going to explain what the randomness hedging counter measure is. And then I'm going to present our formal photo attack model, which we use in the paper. And then, finally, I'm going to give you a brief overview of our provable security analysis. So what are the Fiat Shamiya type signatures? So Fiat Shamiya type signatures are usually derived from this kind of three-round canonical identification protocol. So here, the provable holds a secret key SK together with randomness, and the verifier has some public key. And then provable commits to SK and R, outputs the commitment and some state, and sends the first message to the verifier. And then verifier sends back some challenge, you informly chosen from some challenge space, and then provable responds with message Z. Then, finally, verifier accepts or rejects provable's proof. And it is well known that such a three-round scheme can be made non-interactive by applying so-called Fiat Shamiya transform. And here, the signer derives a challenge by itself, simply by hashing this first message and a message to be signed. And then this is also a random fact. So if the underlying identification scheme is special on a certified zero-knowledge and also special sound, in other words, if it's a sigma protocol, then the resulting signature scheme is provable-secure. And this paradigm has been applied to so many schemes in the past. For instance, Schnorr or Ziloki's character may be the most typical classic examples. And if you implement this Fiat Shamiya type signature in practice, you really have to be careful about the randomness used in the signer. So here, so if the signature is relying on some random number generator, then, of course, this R really has to follow the uniform distribution of a subset. Because otherwise, the security proof doesn't hold. Not only that, but also there's actually a concrete attack exploiting the randomness bias. And in practice, this randomness failure is a very, very common vulnerability. For instance, of course, if you are using some bad random number generator, then you could easily fail. Or if you are running the signing operation on some virtual machine, then if you reuse the same snapshot, then you may end up using the same randomness seed, so the randomness repeats. Or if there's some side-channel leakage from the signing operation, they adversely learned some part of the randomness with which adversely could recover a secret key. And there are a bunch of more attacks exploiting randomness failure. And actually, there was even some real-world incidents. For instance, the PlayStation 3 was actually relying on the ECDSA signature, which reused the same randomness every time. So using this fact, some attackers were able to recover the PlayStation 3's signing key using only a few signatures as input. And there are many other incidents. For instance, the Bitcoin has been stolen because of the randomness failure as well, and so on. So this kind of stuff indeed happens in practice. Really, really, really have to mitigate the risk of randomness failure. So because of this, several researchers or practitioners have been proposing a countermeasure. And this is the most typical one, which is called a deterministic randomness generation. So here, instead of using the random number generator, you simply hash the signing key together with the message. And this is nice because you don't really have to rely on the quality of the random number generator. As long as you securely implement the hash function, then you can make sure that the randomness follows the uniform distribution. And this is already widely implemented in real-world. For instance, the ECDSA signature employs this deterministic randomness generation. Also, there's a deterministic variant of ECDSA, and there are many others as well. So it looks like we already solved the issue, but doesn't really solve. Actually, it doesn't, because we also have to take into account the more advanced model of the attackers, which we analyze in this paper. So if you think about the security of the implementation, you also have to think about the risk of fault attacks, in which attacker tries to modify the internal state of the target device, so that attacker could steal some internal secret information that shouldn't have been leaked. And usually, the fault attacker requires some physical access to the device, but recently, I turned out that the attacker could even remotely mount fault attacks. For instance, this Robohammer attack might be the most typical and famous example of the remote fault attack. And so using such techniques, there have been many recent fault attacks against deterministic Fiat-Chameotype signatures. And there are many differences, but the essential ideas are very similar to each other. So basically, the fault attacks against deterministic signatures tries to exploit the fact that determinism could be used to rewind the prove. So basically, we can classify those attacks into two categories. The first one is so-called special soundless attack. So here, the adversely first queries the signing protocol with some message M and obtains the legitimate signature on that. And for the second query, again, adversely queries with the same message M, but this time, the adversely injects some faults into, for instance, the input to the challenge hash function or the output of the challenge hash function, or it could be the commitment output. And by doing so, so again, we know that the deterministic property makes sure that the randomness R is reused as long as the message to be signed is the same. However, by injecting faults into later operations of the signing, then those lateral values E and Z are different. So this is essentially the situation of the special soundless, in which, if you are given two transcripts, sharing the same commit message, the first commitment message, then you can efficiently recover the signing key. So that was the one type of attack. The other type of attack is a large randomness bias attack. This is also similar to the prior one. So again, the adversely queries with the message and get the legitimate signature. And for the second query, this time, adversely tries to inject a fault into the output of the first hash function. So again, the adversely knows that the randomness is the same if the signer tries to sign the same message. But because of the fault, adversely slightly perturbed the randomness R. So using this adversely can artificially cause the very large randomness bias. In essence, like the adversely can make sure that the second randomness is a bit different from the previous one. So using this fact adversely efficiently recover the secret key. So we have to somehow try to mitigate the risk of such fault attacks. And actually, those papers have proposed countermeasure code, randomness hedging. So here, instead of just hashing the signing key and the message, this time we include some nonce to the input of the hash function. And this nonce could be from some low quality to the random number generator, or it could be just a counter. So we really don't have to make sure that this nonce strictly follows the uniform distribution. And this is nice because again, we don't really rely on the good random number generator. But at the same time, the randomness R doesn't really repeat even if you sign the same message. So it seems secure, but unfortunately, there have been no formal analysis so far. So in this context, we got a question. To what extent are the hedged fiat-shami signatures secure against fault attacks? So in this work, we answer this question. So our contributions in the paper can be summarized as follows. So first, in this paper, we presented the formal attacker model and security notions to capture the corrupted nonces and the previous fault attackers. And using these, we proved that the hedged fiat-shami schemes in general are secure or insecure against certain class of fault attacks. And then using the generic results, we have two applications. The first one is X-EDDSA signature scheme, which is a variant of the EDDSA signature using the signal messaging protocol. The other application is Picnic 2 post-quantum signature scheme. So let's have a look at our attacker model. So our approach is like this. So as a formal security notion, we define unforgability against faults, chosen message, and nonce attacks. So this security notion first models the hedged construction as well as the corrupted nonces. So adversely is allowed to somehow corrupt the nonces in the signing operation. And on top of that, we allow adversely to tamper with the internal operations using some bit tampering fault attack functions. And our security notion is especially tailored to the fiat-shami type signatures so that we could really capture the concrete fault attacks against the fiat-shami schemes. So what are the functions to model the fault attacks? So in this work, we provide two types of fault attacks. The first one is flip-bit function, which does a logical negation of the certain position of the target bit string. The second one is set-bit, and this one allows adversely to fix certain position of the bit strings. And in this work, we focus on the single bit faults. And this is mostly sufficient for characterizing the recent fault attacks we surveyed, which are about the deterministic fiat-shami signatures. And these functions model most basic transient fault attacks on the date flow. For instance, you could model the bit flip on the CPU resistor values, date buses, or memory cells. So using these functions, adversely queries some faulty signing protocol. So first, the adversely is allowed to choose the nonces. So this model is some kind of randomness failure. Adversely can somehow control the nonce n. And then on top of this, adversely chooses some fault function. And then adversely is able to specify which position the adversely wants to inject the fault into. For instance, if you'd like to model the special soundness attack, then adversely may inject the fault into the challenge hash input. Or adversely could inject the fault into the output of the hash function. And then we say that the scheme is UFFCM and SQR, if the advantage of the adversely in this experiment is negligible. So using this notion, we analyze the security. So our security proof of a view is like this. So our starting point is the most basic security notion for the signature schemes. So this is the unforgeability against the key-only attack, in which adversely is not given any signing protocol. And from this notion, we show the reduction to UFFCM and SQR for a certain set of fault positions. And we basically require two conditions. The first one is nothing special. So as required for normal Fiat-Changet type signatures, we need the special on SQR for the underlying identification scheme. So that we can simulate the faulty H-signing protocol by invoking the special on SQR simulator. And the other property required is the non-repeating message and non-spare. And this is important because if the adversely is able to repeat the message and non-spare, this is basically the same as the deterministic signature scheme. So that's the only constraint. And using this, we are able to prove the security for the many value values. So this is the overview of our results. So as you can see here, many value values are resilient to basic bit tampering fault attacks. And also on top of those check marks, if you assume some additional property, you can show the resilience of more wires. And here I'm going to explain about this subset revealing case. So what is a subset revealing identification protocol? So here the prover commits to something and outputs a set of states. And then depending on the challenge value from the verifier, prover simply opens a subset of states. And intuitively these states, a set of states, is resilient to faults because it doesn't really rely on any secret key. So in the security proof, we can show that we can simulate the signing, for designing Oracle even if the adversely is able to tamper with those states. Also in the paper, we have some negative results. So basically, we cannot really prove the security for the faults against those value values. For instance, if the adversely is able to fault the input to the first hash function, then again, you can cause the repeating non-signed message pair. So this degenerates to the deterministic signature. Also, if the adversely is directly able to fix some value in the randomness R, then in that situation, we cannot really prove the security because the randomness R is directly modified by the adversely. However, we remarked that even if we cannot prove the security, this hatching is still better than the deterministic signing because in the deterministic signing, as we saw, the large randomness bias attack could occur. But here, even if the adversely fix some bits of the random value, it's not really a very large randomness bias. So even if you don't prove the security, it's somewhat better. Okay, so using these generic results, we analyzed the security of the concrete schemes. So the first scheme we analyzed is the XEDDSA. So first, the EDDSA is an essentially deterministic version of the Shino signature scheme. And this XEDDSA could be considered as a hatched version of the Shino signature scheme. So using our result, we can show that XEDDSA is more photoresilient than EDDSA or Shino signature scheme. And this XEDDSA scheme is already deployed in the signal protocol. Also, we analyzed Picnic 2, which is a post-contam signature scheme derived from the zero-knowledge proof based on the MPC-HEDD paradigm. And this Picnic 2 also follows the Fiat-Shamiya paradigm. So of course, we shouldn't use the deterministic signing. So instead, if we use the hatched signing for the Picnic 2, as we saw since... So actually, the Picnic 2's underlying zero-knowledge protocol is subset revealing. So we can show that a hatched Picnic 2 has more photoresilience than playing normal Fiat-Shamiya type signatures. And the specification of the Picnic 2 already recommends the randomness hatching count measure so that the practitioners should use the randomness hatching for the Picnic 2. So to conclude, in this work, we defined the formal model and the security notions tailored to the Fiat-Shamiya type signatures. And then we proved the security and also insecurity of the hatched Fiat-Shamiya signatures against the basic fault attacks together with corrupted noses. And our conclusion is that the hatching is probably more resilient than the randomized or deterministic Fiat-Shamiya signatures. However, it's not perfect. Perfect. Because as we saw, we had some negative results, especially we should really focus on protecting the input or output to the first hash function, which does the hatching. So after this analysis, we've got a bunch of questions. For instance, like if we didn't cover the effect of multiple faults in the analysis, or what if adverse is able to fault within the functions like commitment or response, or public parameters. In this work, we focused on the analysis in the classical random model. What if adverse is able to inject a fault together with the quantum access to the random model? Also, we'd like to extend our result to the Fiat-Shamiya with awards type signature schemes, which nowadays many lattice-based signature schemes follow. Okay, so that's it from me. Thank you very much for your attention. I'm looking forward to discussing with you at the online conference. If you are interested in more details about our paper, you can find our e-print in this address. So, see you.