Method for signature verification of a falcon signature

Abstract

The method for signature verification of a Falcon signature comprises steps as claimed. The devices are configured to carry out the above-mentioned method.

Description

[0001] 202402080 1 Description Method for signature verification of a Falcon signature The invention relates to a method for signature verification of a Falcon signature and to a computer program product and a device configured to carry out this method. Embedded devices rely heavily on the verification of digital signatures to ensure the authenticity and integrity of data. During the boot process, the device verifies the digital signature of the firmware to ensure that it has not been tampered with or modified. Similarly, software updates are also verified using digital signatures to ensure that only authorized and unaltered software is installed. Moreover, digital signatures are also used to verify the authenticity of a communication party. When two devices communicate with each other, they exchange digital certificates that include digital signatures. These signatures are then verified to confirm that both parties are authentic and have not been impersonated. However, if an attacker manages to bypass or compromise the signature verification process, they can inject malicious code into the device or impersonate a legitimate communication party. This can lead to severe consequences, including data breaches, financial losses, and reputation damage. Therefore, it is crucial to ensure that signature verification is implemented securely and robustly in embedded devices. In July 2022, the U.S. Department of Commerce’s National Institute for Standard and Technology (NIST) selected three algorithms DILITHIUM [2], FALCON [3] and SPHINCS+ [4] for digital signatures as a replacement for RSA and elliptic curve based digital signatures [5]. In particular, FALCON is a good candidate for general purpose applications, because it offers smaller signatures than SPHINCS+. However, there may be non-obvious attacks for FALCON verification routines that developers are likely to overlook. Consequently, these vulnerabilities may not be adequately protected by appropriate countermeasures in practice. This is especially important for post-quantum signature schemes, as they are relatively new and may not have been subject to the same level of scrutiny as more established schemes. By identifying and testing these attack vectors, we can help improve the security of these schemes and prevent potential attacks in the future. 202402080 2 Hence, in this context, it is the problem of the invention to provide an improved method for signature verification of a Falcon signature. In particular, this method is desired to be less affected by malicious attacks. Furthermore, it is a problem of the invention to provide a computer program product and to devices which are configured to carry out this method. This problem of the invention is solved by methods with the features as claimed in claims 1, a computer program product as claimed in claim 4 and by a device as claimed in claim 5. Preferred aspects of the invention are contained in the respective dependent claims and the subsequent description. The method for signature verification of a Falcon signature according to the invention comprises the steps of - considering a message with a Falcon signature with a bitstream signature component and one polynomial signature component, - considering a public Falcon key, that corresponds to the Falcon signature, with a bitstream public key component - in which an first auxiliary polynomial, that depends on the bitstream signature component is considered and an second auxiliary polynomial, that depends on the polynomial signature component is considered and - in which an evaluation of a difference of the first auxiliary polynomial and a product of the second auxiliary polynomial and the bitstream public key component is substituted by an evaluation of a difference of a sum of the first auxiliary polynomial and a further summand in form of a random polynomial and a sum of the product of the second auxiliary polynomial and the bitstream public key component and the further summand in form of the random polynomial. Advantageously, the previously described method for signature verification of a Falcon signature according to the invention is less affected by fault injection attacks compared to previously known methods. 202402080 3 The evaluation of a difference of the first auxiliary polynomial and a product of the second auxiliary polynomial and the bitstream public key component may be subject to a fault injection attack such, that the evaluation of the difference is stopped and the subtraction of the product of the second auxiliary polynomial and the bitstream public key component is omitted. With such an attack, the verification of a malicious Falcon signature may be erroneously carried out. In the invention, however, the addition of the random polynomial would distort the calculation if the evaluation of the difference is stopped and the minuend is not decreased by the subtrahend. Since to both the minuend and the subtrahend in the afore-mentioned difference, the same random polynomial is added in the method according to the invention, the random polynomial cancels out of the calculation if the difference is evaluated without injection attacks. In the case of an injection attack, that prohibits the subtraction of the subtrahend, the random polynomial does not cancel out. This leads to the inability to verify malicious Falcon signatures with such an attack. Thus, according to the invention, the method for signature verification is more robust against fault injection attacks and thus improved. In another advantageous and optional aspect of the invention, the random polynomial is a pseudo-random polynomial. Alternatively, and also preferably, in the method according to the invention, the random polynomial is a physically derived, preferably a noise-based or noise-derived, random polynomial. The device according to the invention comprises a processor, preferably a microprocessor, and is configured to carry out the method according to the invention as described above. In a preferable and optional aspect of the invention, the device is an embedded device. In an advantageous and optional aspect of the invention, the device is a manufacturing device and / or a logistics device and / or an Internet-of-things device, preferably an industrial-internet-of- things device. In the following, specific embodiments for carrying out the invention are described. This application shows as examples a number of non-trivial, yet in practice simple and realistic fault injection attacks against the verification routines of the post-quantum signature schemes. 202402080 4 FALCON. The attacks target parts of the code which even an experienced developer would not necessarily consider protecting against, making it difficult to defend against such attacks. Consequently, an attacker can trick a device into processing arbitrary unauthenticated data, and hence possibly even into installing software supplied by the attacker. If signature verification during the establishment of a secure communication session is attacked, the attacker can force the device to communicate with an unauthenticated party. The following description gives a description of the FALCON signature scheme. Subsequently, we show how to attack FALCON signature verification. A practical evaluation of the proposed attacks is provided thereafter. Possible countermeasures to protect against the proposed fault attacks with the methods according to the invention are described subsequently. FALCON SIGNATURE VERIFICATION We describe the signature verification procedure of FALCON. For a full description of the FALCON signature scheme, we refer the reader to the specification of FALCON in [3]. There are two variants of FALCON, namely FALCON-512 and FALCON-1024. The two variants target different security levels. Their mathematical descriptions differ only in the choice of some parameters. Most mathematical operations in FALCON signature verification are happening in a truncated polynomial ring ℤq[x] / (ϕ). Here, q = 12289 (a prime number) and ϕ(x) = xn+ 1. We have n = 512 for FALCON-512 and n = 1024 for FALCON-1024. Another parameter is a rejection bound, which is ⌊β2⌋ = 34034726 for FALCON-512 and ⌊β2⌋ = 70265242 for FALCON-1024. A message m in FALCON is simply a string of bytes. A FALCON signature is a pair (r,s), where r is a random 320 bit string and s is the representation of a polynomial s2∈ ℤq[x] / (ϕ). A FALCON public key is a polynomial h ∈ℤq[x] / (ϕ). As auxiliary functions for signature verification we will need a function HashToPoint that maps a byte string to a polynomial in ℤq[x] / (ϕ) and a function Decompress that recovers a polynomial ℤq[x] / (ϕ) from its representation as a string of bytes. Algorithm 2 FALCON.VERIFY(m, sig, pk) Require: A message m, a signature sig = (r,s), a public key pk = h ∈ℤq[x] / (ϕ) 202402080 5 Ensure: Accept or reject 1: c ← HashToPoint(r∥m) 2: s2← Decompress(s) 3: if s2=⊥ then 4: reject 5: s1← c − s2h mod q 6: if ∥(s1,s2)∥2≤⌊β2⌋ then 7: accept 8: else 9: reject FAULT ATTACKS AGAINST FALCON SIGNATURE VERIFICATION The most obvious target for fault attack against FALCON signature verification is the comparison ∥(s1,s2)∥ < β2. The goal of the attack is to inject a fault such that the test passes for an arbitrary (s1,s2). However, because this is the most obvious place to attack, it is also a part of the code that a careful designer most likely implements with appropriate countermeasures against this type of attack. In this section, we are considering attacks which are less obvious and less likely to be prevented by countermeasures in the implementation. We assume the attacker has a valid signature (r,s) for some message m. Every attack starts with the attacker choosing a message m′. All attacks aim at constructing a (forged) signature such that it only takes a fault that can be injected with high probability to force the verifying device into accepting the signature and hence processing m′. A. Skipping the inclusion of the message hash For our first attack against FALCON signature verification, the attacker performs the following steps: 1) The attacker chooses r′to be an arbitrary string of 320 bits and sets s′:= Compress(0,n − 328), where n = 512 for FALCON-512 and n = 1024 for FALCON-1024. So s′is the compressed representation of the zeropolynomial. 2) The attacker sends the message m′and the purported signature (r′,s′) to the device for verification. 202402080 6 3) During the verification procedure, the attacker injects a fault to suppress the inclusion of c in algorithm 2, line 5. So the device computes s’1← − s’2h mod q = 0, because is 0 by construction.If the fault injection is successful, the check in line 6 becomes a check that⌊βଶ⌋^ |^^^^ᇱ, ^^ଶᇱ ^| ൌ 0.This check obviously passes, and the device accepts the signature and starts processing m′. Alternatively, the attacker could force the parameter logn in a respective computer code to 0 as it is transferred to a parameter register or pushed onto the stack just before the function call. This could be achieved by skipping the corresponding instruction (if the parameter register happens to be 0 anyway) or by a data fault rather than an instruction fault. We note that this attack does not work when FALCON is operated in key-recovery mode, see the FALCON-specification, section 3.12 in [3]. B. Fault injection during the computation of the Euclidean norm This fault injection attack targets the computation of the Euclidean norm in algorithm 2, line 6. Now let i > 0 be the smallest index such that hi≠ 0. Please note that such an i exists unless the public key h consists only of a constant term. So the public key h has the form: We first explain how the attacker proceeds and then show why the attack works: 1) The attacker chooses a polynomial ^^ଶᇱ∈ and s2,j= 0 for j ≠ i. 2) The attacker chooses a random 320 bit string r′ and sets s′ := Compress( ^^ᇱଶ , 8 ∗ sbytelen െ328) and sends the chosen message m′ together with the purported signature (r′,s′) to thedevice for processing. 3) The attacker injects a fault such that the computation of the Euclidean length in line 6 stops after processing the 0-th coefficient. We have described examples of suitable faults at the beginning of this section. To understand why this attack works (assuming, of course, that the fault injection is successful), we carefully follow the steps of the signature verification process. First, the device computes 202402080 7 c′← HashToPoint(r′∥m′,q,n) and decompresses s′to recover the ^^ଶᇱthe attacker has constructed in the first step of the attack. Next, the device computes ← ^^ᇱെ ^^ᇱℎ. If we look at the 0-th coefficientᇱ ଶof the polynomial ^^^, we see that because of the way the attacker has constructed ^^ଶᇱ. If the fault injection in the last step of the attack is successful, then the device computes the Euclidean norm of (s1′,s2′) as ^^^ᇱଶ,^^ ^^ଶᇱଶ,^ൌ 0 ^ 0 ൌ 0, (6) because the fault terminates the loop after the first iteration and other coefficientsᇱ and ^^ଶare ignored. Hence, the norm is short enough for the device to accept the purported signature, and the device will process m′like a valid message. Of course, ^^^ᇱ,^does not have to be zero, it is sufficient if ^^^ᇱଶ,^^ ⌊ ^^ଶ⌋. This is the case with some probability anyway. So, instead of constructing ^^ଶᇱas above, an attacker can also choose ^^ଶᇱൌ 0 and then try different r′until ^^^ᇱଶ^\⌊^^ଶ⌋, with c′= HashToPoint(r′∥m′). We see from line 5 in algorithm 2 that then ^^^ᇱଶ,^ൌ ^^^ᇱଶ^ ⌊ ^^ଶ⌋. Because ⌊β2⌋ is larger for FALCON-1024 than for FALCON-512, this simplified version of the attack is easier for FALCON-1024. More precisely, we see that for FALCON-512 we have to have ^^^ᇱଶ^ 34 034 726 and hence 0 ^ ^^^ᇱ^ 5 833 and for FALCON-1024 we have to have ^^^ᇱଶ^ 70 265 242 and hence 0 ^ ^^^ᇱ^ 8 382. Note that 0 ^ ^^^ᇱ^ ^^ ൌ 13329 anyway. COUNTERMEASURES Obviously, generic countermeasures against manipulation of the control flow, e.g., hardware instruction skip, make most of the attacks presented in this application more difficult to realize in practice. However, there are also more specific countermeasures that can be implemented to thwart our attacks. 202402080 8 For instance, against the attack described previously, one can proceed as follows: A countermeasure can be used against the attack described in the previous description. We modify the implementation of algorithm 2 to generate a random u ∈ ℤq[x] / (ϕ). Then u is added to c and to s2h. Consequently, line 5 in algorithm 2 becomes s1← (c + u) − (s2h + u) mod q. (8) If the attacker skips the inclusion of c + u in this operation, then the test in line 6 will fail with very high probability. Finally, by checking the integrity of function parameters and introducing redundant loop counters seem to be efficient countermeasures against the attack described above. The countermeasures as described in equations (7) and (8) implement the methods according to the invention. As an example, these modified signature verification methods are implemented in an embedded device that is configured to carry out these steps for the modified signature verification as a computer program running on a microprocessor.

[0002] 202402080 9 Prior Art References [1] J. A. Muir, “Seifert’s RSA fault attack: Simplified analysis and generalizations,” in ICICS 06, ser. LNCS, P. Ning, S. Qing, and N. Li, Eds., vol.4307. Springer, Heidelberg, Dec.2006, pp. 420–434. [2] V. Lyubashevsky, L. Ducas, E. Kiltz, T. Lepoint, P. Schwabe, G. Seiler, D. Stehle, and S. Bai, “CRYSTALS-DILITHIUM,” Na-´ tional Institute of Standards and Technology, Tech. Rep., 2022, available at https: / / csrc.nist.gov / Projects / post-quantum-cryptography / selected- algorithms-2022. [3] T. Prest, P.-A. Fouque, J. Hoffstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Ricosset, G. Seiler, W. Whyte, and Z. Zhang, “FALCON,” National Institute of Standards and Technology, Tech. Rep., 2022, available at https: / / csrc.nist.gov / Projects / post-quantum-cryptography / selected-algorithms-2022. [4] A. Hulsing, D. J. Bernstein, C. Dobraunig, M. Eichlseder, S. Fluhrer,¨ S.-L. Gazdag, P. Kampanakis, S. Kolbl, T. Lange, M. M. Lau-¨ ridsen, F. Mendel, R. Niederhagen, C. Rechberger, J. Rijneveld, P. Schwabe, J.-P. Aumasson, B. Westerbaan, and W. Beullens, “SPHINCS+,” National Institute of Standards and Technology, Tech. Rep., 2022, available at https: / / csrc.nist.gov / Projects / post-quantumcryptography / selected-algorithms-2022. [5] NIST, “NIST announces first four quantum-resistant cryptographic algorithms,” https: / / www.nist.gov / news-events / news / 2022 / 07 / nistannounces-first-four-quantum-resistant- cryptographic-algorithms, 2022, accessed 2022-12-21. [6] N. Moro, K. Heydemann, E. Encrenaz, and B. Robisson, “Formal verification of a software countermeasure against instruction skip attacks,” Cryptology ePrint Archive, Report 2013 / 679, 2013, https: / / eprint.iacr.org / 2013 / 679. [7] J.-M. Dutertre, T. Riom, O. Potin, and J.-B. Rigaud, “Experimental analysis of the laser- induced instruction skip fault model,” accessed 202305-03. [Online]. Available: https: / / hal.science / hal-02379754 / document [8] A. Menu, J.-M. Dutertre, O. Potin, J.-B. Rigaud, and J.-L. Danger, “Experimental analysis of the electromagnetic instruction skip fault model,” accessed 2023-05-03. [Online]. Available: https: / / hal.science / hal-02572398 / document [9] J.-P. Seifert, “On authenticated computing and rsa-based authentication,” in Proceedings of the 12th ACM Conference on Computer and Communications Security, ser. CCS ’05. New York, NY, USA: Association for Computing Machinery, 2005, p.122–127. [Online]. Available: https: / / doi.org / 10.1145 / 1102120.1102138 202402080 10

[0010] L. G. Bruinderink and P. Pessl, “Differential fault attacks on deterministic lattice signatures,” IACR TCHES, vol. 2018, no. 3, pp. 21–43, 2018, https: / / tches.iacr.org / index.php / TCHES / article / view / 7267.

[0011] S. McCarthy, J. Howe, N. Smyth, S. Brannigan, and M. O’Neill, “BEARZ attack FALCON: Implementation attacks with countermeasures on the FALCON signature scheme,” Cryptology ePrint Archive, Report 2019 / 478, 2019, https: / / eprint.iacr.org / 2019 / 478.

[0012] S. Bauer and F. D. Santis, “A differential fault attack against deterministic falcon signatures,” Cryptology ePrint Archive, Paper 2023 / 422, 2023, https: / / eprint.iacr.org / 2023 / 422. [Online]. Available: https: / / eprint.iacr.org / 2023 / 422

[0013] N. Bindel, J. Buchmann, and J. Kramer, “Lattice-based signature¨ schemes and their sensitivity to fault attacks,” Cryptology ePrint Archive, Report 2016 / 415, 2016, https: / / eprint.iacr.org / 2016 / 415.

[0014] P. Ravi, A. Chattopadhyay, and A. Baksi, “Side-channel and faultinjection attacks over lattice- based post-quantum schemes (kyber, dilithium): Survey and new results,” Cryptology ePrint Archive, Report 2022 / 737, 2022, https: / / eprint.iacr.org / 2022 / 737.

[0015] P. Ravi, B. Yang, S. Bhasin, F. Zhang, and A. Chattopadhyay, “Fiddling the twiddle constants - fault injection analysis of the number theoretic transform,” IACR TCHES, vol.2023, no. 2, pp.447–481, 2023.

[0016] NIST, “Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,” 2016, accessed 2023-05-09. [Online]. Available:https: / / csrc.nist.gov / CSRC / media / Projects / Post-Quantum- Cryptography / documents / call-for-proposals-final-dec-2016.pdf

[0017] M. J. Kannwischer, J. Rijneveld, P. Schwabe, and K. Stoffelen, “pqm4: Testing and benchmarking NIST PQC on ARM cortex-M4,” Cryptology ePrint Archive, Report 2019 / 844, 2019, https: / / eprint.iacr.org / 2019 / 844.

[0018] G. Seiler, T. Lepoint, B. Hess, M. Baentsch, P. Schwabe, B. Westerbaan, V. Hanquez, M. J. Kannwischer, oittaa, J. Schanck, and zanxu-blackhorse, “Dilithium reference implementation v3.1 on github,” accessed 2023-04-28. [Online]. Available: https: / / github.com / pq-crystals / dilithium / tree / v3.1

[0019] T. Pornin, “Falcon source files (reference implementation) vrfy.c,” accessed 2023-05-03. [Online]. Available: https: / / falcon-sign.info / impl / vrfy.c.html

[0020] D. Lazar, C. Peikert, and algoidan, “Deterministic falcon implementation,” https: / / github.com / algorand / falcon, Accessed 2022-11-17. 202402080 11

[0021] O. M. Guillen, M. Gruber, and F. De Santis, “Low-cost setup for localized semi-invasive optical fault injection attacks - how low can we go?” in COSADE 2017, ser. LNCS, S. Guilley, Ed., vol.10348. Springer, Heidelberg, Apr.2017, pp.207–222.

[0022] T. Espitau, P.-A. Fouque, F. Gerard, M. Rossi, A. Takahashi, M. Ti-´ bouchi, A. Wallet, and Y. Yu, “Mitaka: a simpler, parallelizable, maskable variant of falcon,” Cryptology ePrint Archive, Report 2021 / 1486, 2021, https: / / eprint.iacr.org / 2021 / 1486.

[0023] C. Chuengsatiansup, T. Prest, D. Stehle, A. Wallet, and K. Xagawa,´ “ModFalcon: Compact signatures based on module-NTRU lattices,” in ASIACCS 20, H.-M. Sun, S.-P. Shieh, G. Gu, and G. Ateniese, Eds. ACM Press, Oct.2020, pp.853–866.

Claims

202402080 12 Claims 1. Method for signature verification of a Falcon signature, comprising the steps of - considering a message with a Falcon signature with a bitstream signature component and one polynomial signature component, - considering a public Falcon key, that corresponds to the Falcon signature, with a bitstream public key component - in which an first auxiliary polynomial, that depends on the bitstream signature component is considered and an second auxiliary polynomial, that depends on the polynomial signature component is considered and - in which an evaluation of a difference of the first auxiliary polynomial and a product of the second auxiliary polynomial and the bitstream public key component is substituted by an evaluation of a difference of a sum of the first auxiliary polynomial and a further summand in form of a random polynomial and a sum of the product of the second auxiliary polynomial and a sum of the bitstream public key component and the further summand.

2. Method according to claim 1, in which the random polynomial is a pseudo-random polynomial.

3. Method according to claim 2, in which the random polynomial is a physically derived, preferably a noise-based or noise-derived, random polynomial.

4. Computer program product, comprising program commands, that, when run on a computer, are configured to carry out the method according to one of the previous claims.

5. Device, comprising a processor, preferably a microprocessor, configured to carry out the method according to one of the preceding claims.

6. Device according to one of the previous claims with a computer program product according to claim 4, that is configured to run on the processor.202402080 13 7. Device according to claim 5 or 6, which is an embedded device.

8. Device according to claim 5, 6 or 7, which is a manufacturing device.

9. Device according to one of the claims 5 to 8, which is a logistics device.

10. Device according to one of the claims 5 to 9, which is an Internet-of-things device, preferably an industrial-internet-of-things device.

Images