EFFICIENT MEMORY USAGE FOR STORING CRYPTOGRAPHIC KEYS

Abstract

Generating a lattice-based signature includes: determining an uncorrected signature; determining hints based on a verification of the uncorrected signature, and providing the uncorrected signature and the hints as a lattice-based signature.

Description

In lattice-based cryptography, keys and ciphertexts and/or signatures are usually large, in particular, larger than their RSA/ECC counterparts.

A lattice-based signature algorithm utilizes a sender (also referred to as a signer) that conveys a signature to a receiver (also referred to as a verifier). The receiver has to be able to determine whether or not the signature is valid.

To decrease the size of the public key, the lattice-based digital signature scheme Dilithium [LDK+21] splits an uncompressed public key element t into two parts: A first portion t₁ contains the high-order bits of the coefficients of t and a second portion t₀ contains the low-order bits of the coefficients. Only t₁ is part of the public key, which decreases the required memory size compared to returning the uncompressed public key t.

However, for the returned signatures to be valid, the omission of t₀ in the public key needs to be taken into account during signing. During each signing operation, the effect caused by omitting t₀ is computed, and this effect is included in the signature. The verifier then uses so-called hints to correct the missing part t₀.

Computing the hints using the method described in the current Dilithium specification requires knowledge of t₀, which requires to t₀ be stored as part of the key. This could be a problem for devices with small memory since t₀ can be quite large (i.e., up to 3.25 kB). The public component t₁, though not directly required for signing, also needs to be stored on the device for several applications. For example, the device may have to transmit its public key (in the form of a signed certificate) to a verifier. Hence, with regard to the memory limitations, the signing device does not benefit from the public-key separation into t₀ and t₁.

SUMMARY

Hence, it is an objective to provide a more efficient way to save memory space when handling keys on a device.

This is solved according to the features of the independent claims. Further embodiments result from the depending claims.

The examples suggested herein may, in particular, be based on at least one of the following solutions. Combinations of the following features may be utilized to reach the desired result. The features of the method could be combined with any feature(s) of the device, apparatus, or system or vice versa.

It is noted that a cryptographic key may be used for any key used in a cryptographic context. It may, e.g., be any private, secure, or public key. The cryptographic key may, in particular, be a key used in combination with post-quantum cryptography.

A method is suggested for generating a lattice-based signature (σ) comprising

• • determining an uncorrected signature ({tilde over (c)},z),
  • determining hints (h) based on a verification of the uncorrected signature ({tilde over (c)},z),
  • providing the uncorrected signature ({tilde over (c)},z) and the hints (h) as lattice-based signature (σ).

Advantageously, the hints can be computed using a part of the public key, in the example described herein, the part t₁, instead of a part of the secret key t₀, which is larger than t₁. Hence, only the part t₁ needs to be stored locally on the device (but not t₀).

It is yet another advantage that all additional computations are conducted on public data, which results in a reduced security overhead.

Also, as verification is part of the signature generation, this solution can be used to detect faults or errors that may occur during the signing process.

Instead of computing the effects of omitting t₀ in the forward direction (using t₀ to compute the difference), the effects of omitting t₀ are computed in the backward direction: The uncorrected signature received is processed by the verification (using t₁). The observed difference between this outcome and intermediates computed during signing can be used to compute the hints h.

According to an embodiment, the signature generation is based on or interworks with the lattice-based digital signature scheme Dilithium.

According to an embodiment, the verification is based on a first portion (t₁) of an uncompressed public key element (t), wherein the second portion (t₀) of the uncompressed public key element (t) is not used during signature generation.

According to an embodiment, the second portion (t₀) of the uncompressed public key element is longer than the first portion (t₁) of the uncompressed public key element.

According to an embodiment, the second portion (t₀) of the uncompressed public key element is not stored locally.

Locally may, in particular, refer to a particular device. It can also be a device (or on several devices) which are connected via a network.

According to an embodiment, the second portion (t₀) of the uncompressed public key element is not made publicly available.

According to an embodiment, the verification is used to determine whether a fault has occurred during the generation of the lattice-based signature.

According to an embodiment, the compression function is at least partly conducted on one of the following:

• • a security device,
  • a secured cloud,
  • a secured service,
  • an integrated circuit,
  • a hardware security module,
  • a trusted platform module,
  • a crypto unit.
  • a field programmable gate array (FPGA),
  • a processing unit,
  • a controller, and
  • a smart card.

Also, a device is provided for generating a lattice-based signature (σ), wherein the device is arranged to execute the following steps:

• • determining an uncorrected signature ({tilde over (c)},z),
  • determining hints (h) based on a verification of the uncorrected signature ({tilde over (c)},z),
  • providing the uncorrected signature ({tilde over (c)},z) and the hints (h) as lattice-based signature (σ).

According to an embodiment, the device is one of the following or comprises at least one of the following:

• • a security device,
  • a secured cloud,
  • a secured service,
  • an integrated circuit,
  • a hardware security module,
  • a trusted platform module,
  • a crypto unit,
  • a field programmable gate array (FPGA),
  • a processing unit,
  • a controller, and
  • a smart card.

Further, a computer program product is provided, which is directly loadable into a memory of a digital processing device, comprising software code portions for performing the steps of the method as described herein.

BRIEF DESCRIPTION OF THE FIGURES

Embodiments are shown and illustrated with reference to the drawings. The drawings serve to illustrate the basic principle so that only aspects necessary for understanding the basic principle are illustrated. The drawings are not to scale. In the drawings, the same reference characters denote like features.

FIG. 1 shows a pseudo-code taken from [LDK+21] for deterministic and randomized versions of Dilithium.

FIG. 2 shows an exemplary block diagram of a modified signature procedure that can, in particular, be used in a Dilithium environment.

FIG. 3 shows an exemplary arrangement of a processing device comprising a CPU, RAM, non-volatile memory, a crypto module, an analog module, an input/output interface, and a hardware-random number generator; and

FIG. 4 shows an alternative arrangement with a hardware security module (HSM).

DETAILED DESCRIPTION

The examples described herein allow for an efficient computation of the hints using the public key t₁ instead of t₀. Hence, t₁ is stored locally on a device, but not t₀. This is advantageous because t₁ is required for verification purposes anyway.

It is also an advantage that all added computations are conducted on public data, which results in a reduced security overhead. Also, the approach can be used for fault detection purposes.

Instead of computing the effects of omitting t₀ in the forward direction (using t₀ to compute the difference), the effects of omitting t₀ are computed in the backward direction: The uncorrected signature received is processed by parts of the verification process (using t₁). The observed difference between this outcome and intermediates computed during signing can then be used to compute the hints that allow correcting the signature.

Introduction to Dilithium

Hereinafter, a brief and simplified description of the involved parts of the Dilithium signature scheme is provided. For more details, reference is made to [LDK+21].

Dilithium operates on vectors and matrices comprising polynomials with coefficients modulo q. Polynomials are denoted using plain letters, e.g., a, whereas vectors and matrices are denoted by bold lowercase a and uppercase A letters, respectively.

FIG. 1 shows a pseudo-code taken from [LDK+21], page 13, for deterministic and randomized versions of Dilithium.

This pseudo-code comprises three sections: a key generation portion, a sign (signature generation) portion, and a verify portion. These will be described next with reference to the line numbers, as shown in FIG. 1.

Dilithium: Key Generation

• • Line 1: A random number ζ is generated. This number serves as a seed for the key generation.
  • Line 2: Three further seeds (ρ,ρ′, K) are derived from the random number ζ.
  • Line 3: The seed ρ is used to deterministically generate (function ExpandA) a matrix A. The seed ρ is also included in the public and private keys so that all participants can generate the matrix A.
  • Line 4: A function ExpandS is used to derive secret key elements (s₁, s₂) from the seed ρ′. The coefficients of (s₁, s₂) are uniformly distributed across an interval [−η,η].
  • Line 5: An uncompressed public key element t is computed by multiplying the matrix A with the first secret key element s₁ and then adding the second secret key element s₂.
  • Line 6: The uncompressed public key element t is split into two parts t₁ and t₀ using a function Power2Round. The element t₁ contains the higher-order bits of the coefficients of the uncompressed public key element t, and the element t₀ contains the lower-order bits of the coefficients of the uncompressed public key element t.
  • Line 7: The seed ρ and the compressed public key element t₁ are hashed to a value tr.
  • Line 8: A public key pk is provided, which comprises the seed ρ and the element t₁.

A secret key sk comprises the seeds ρ and K, the hash value tr of the public key, the secret key elements s₁ and s₂, and the lower-order bits t₀ of the uncompressed public key element t.

It is noted that ρ, tr, and to are required for signing and are therefore included in the private key, but they do not need to be kept secret and can be revealed. On the other hand, K, s₁, and s₂ need to be kept secret.

Dilithium Sign(ature Generation)

• • Line 9: The matrix A is determined based on the seed ρ, which is included in the secret key sk.
  • Line 10: The hash value tr of the public key is hashed together with a message M, which is to be signed. The result is stored in μ.
  • Line 11: A counter variable K is initialized to 0. Signature output elements (z,h) are initialized to the invalid symbol ⊥.
  • Line 12: The seed ρ′ is determined: If deterministic signing is used, ρ′ is derived as the hash of the secret value K together with the value μ. If randomized signing is used, ρ′ is set to a random number.
  • Line 13: Start of rejection loop: As long as no valid signature is found (i.e., while (z,h) is set to the invalid signal ⊥, Dilithium keeps restarting the signing (starting from this line).
  • Line 14: A value γ is derived in a deterministic manner utilizing a function ExpandMask, which uses the seed ρ′ and the counter K. The value γ follows a distribution {tilde over (S)}_γ1, i.e., the coefficients are uniformly distributed in an interval determined by the parameter γ₁.
  • Line 15: A vector w is determined by multiplying the matrix A with the value γ.
  • Line 16: A function HighBits decomposes each coefficient of the vector w (such that, for each coefficient x, x=x₁α+x₀) and returns a higher-order value w₁. The value of α is set to 2_γ2 the specific value of which is defined in the parameter set.
  • Line 17: This value w₁ is hashed together with μ resulting in a hash value {tilde over (c)}.
  • Line 18: A function SampleInBall turns the hash value {tilde over (c)} into a polynomial c for which the values of the coefficients have a certain distribution.
  • Line 19: The output value s is computed based on γ, c, and s₁.
  • Line 20: A value w-cs₂ is computed and decomposed, and the lower bits are returned as r₀.
  • Line 21: Each coefficient of z and r₀ is checked and tested if it falls in a certain range, i.e., if

${z}_{\infty }\ge {\gamma }_1-\beta$

is true, then at least one coefficient of z falls outside the open interval (−(γ₁, −β), (γ₁, −β)). If this is the case for either z or r₀ (for their respective range parameters), the signature output (z,h) is set to invalid ⊥ and the loop starting at line 13 enters another iteration.

• • Line 22: “else” refers to the case that all coefficients of z and r₀ fall within the specified respective range. In this case, signature generation continues in line 23:
  • Line 23: Run a function MakeHint, which computes the effect of omitting t₀ from the public key (cf. Equation (2)), resulting in a so-called hints vector h. This hints vector h describes for each coefficient if this omission causes an incorrect recovery of HighBits(w-cs₂) during verification. These incorrectly recovered coefficients are then corrected in the verification procedure.
  • Line 24: This line includes two further checks, both are needed to verify that the error induced by omitting t₀ from the public key can later be corrected during verification.

First, if the value of ct₀ exceeds a predefined threshold (i.e., becomes too large) at any coefficient, the functions MakeHint and UseHint are no longer capable of correcting the error, meaning that the current signature needs to be rejected.

Second, the vector h is encoded such that up to ω coefficients of

$\mathrm{High}\mathrm{Bits}\left(w-c{s}_2\right)$

can be corrected during verification. If this number is exceeded, i.e., more than w coefficients need to be corrected, this information cannot be properly encoded anymore, and thus the errors cannot be corrected during verification. Hence, the current signature needs to be rejected.

If the checks show that the signature needs to be rejected, then the signature output (z,h) is set to invalid ⊥ resulting in another iteration of the loop starting in line 13.

• • Line 25: In the (potentially needed) next iteration of the rejection loop starting in line 13, fresh values for γ need to be generated. This is achieved by increasing the counter κ. This is done regardless of whether another iteration is needed (which is the case if (z,h)=⊥).
  • Line 26: The signature σ, comprising {tilde over (c)}, z and h is returned.

Dilithium: Verify

• • Line 27: The matrix A is determined based on the seed ρ, which is included in the public key pk.
  • Line 28: Reference is made to line 10 above. However, the hash value tr is recomputed tr=H(ρ∥t₁), because it is not part of the public key.
  • Line 29: This line corresponds to line 18, i.e., the hash value {tilde over (c)} is deterministically converted to a polynomial c whose coefficients follow a specific distribution.
  • Line 30: First, Az−ct₁·2^d is computed (cf. Equation (2)). The function UseHints then uses the hints vector h to correct the error caused by omitting t₀ from the public key and ensures that the output w′₁ equals the value of w₁ computed during signing (line 16).
  • Line 31: Three tests are performed to check the validity of the signature: The first and third tests ensure that the signer has performed the rejection steps. The second test verifies the validity of the signature. It computes H(μ∥w′₁): this value must be identical to the value {tilde over (c)} which was included in the signature (cf. line 17 of signing).

If the full vector t was included in the public key, the verifier could compute

$\begin{array}{cc}\mathrm{Az}-\mathrm{ct}=A\left(y-c{s}_1\right)+c\left({\mathrm{As}}_1+s_2\right)=Ay+Ac{s}_1-Ac{s}_1-c{s}_2=w-c{s}_2& \left(1\right)\end{array}$

Checks (or tests) performed during the signing portion ensure that the following applies:

$\mathrm{High}\mathrm{Bits}\left(w\right)=\mathrm{High}\mathrm{Bits}\left(w-c{s}_2\right)=w_1.$

The verifier can thus recompute

$\tilde{c}=H\left(\mu w_1\right)$

and the verifier can determine if this {tilde over (c)} matches the signature as provided.

As explained with regard to the Dilithium implementation above, only the portion t₁ (instead of the full vector t) is supplied to the verifier, which then actually computes (see line 30 of the pseudo-code shown in FIG. 1)

$\begin{array}{cc}Az-c{t}_1·2^d=A\left(y+c{s}_1\right)-c\left(t-t_0\right)=w-c{s}_2+c{t}_0.& \left(2\right)\end{array}$

Algorithm 1 MakeHint (simplified)
Input: “large” input r, “small” input z
1: r1 := HighBits(r)
2: v1 := HighBits(r+z)
3: if r1 ≠ v1 then return 1
4: else return 0·

To correct the added term ct₀, the signer computes hints h, which represent the effect of this addition, and the signer includes these hints in the signature. Actually, the hints describe if the addition of ct₀ causes a carry to ripple into the HighBits of w-cs₂ (see Algorithm 1, which is computed for each coefficient). Using the hints, the verifier can subtract the carry from the coefficients and thereby recover the correct

$\mathrm{High}\mathrm{Bits}\left(w-c{s}_2\right)=w_1.$

In the existing Dilithium approach, computing the hints requires the portion t₀ of the public key t.

Improvements Over Existing Solutions

The examples described herein do not require storing the vector to as part of the secret key.

In an exemplary embodiment, a (potential) signature output (z,c) is fed to a verification algorithm, which uses the vector t₁ to compute

$w-c{s}_2+c{t}_0$

(see Equation (2)). This term is then compared to

$w-{\mathrm{cs}}_2,$

which is computed during signing. By comparing the HighBits of these two terms, the hints h can be computed.

An exemplary implementation of a modified signature generation may comprise the following steps:

• • (1) Generate a valid signature (z,c), i.e., run all steps of the Dilithium sign algorithm except for line 23. However, keep the interim value w-Cs₂.
  • (2) Compute part of the verification algorithm using t₁:

$u:=\mathrm{Az}-c{t}_1·2^d=w-c{s}_2+c{t}_0.$

• • (3) Recover ct₀:

$v:={\mathrm{ct}}_0=\left(\mathrm{Az}-c{t}_1·2^d\right)-\left(w-c{s}_2\right)=$ $=u-\left(w-c{s}_2\right)$

• • (4) Compute the hints h:

$h=Mak\mathrm{eHint}\left(-{\mathrm{ct}}_0,w-c{s}_2+c{t}_0\right)=$ $=\mathrm{MakeHint}\left(-v,u\right).$

These steps are part of Algorithm 2, which shows a modified Dilithium signing algorithm by replacing line 23 of FIG. 1 with lines 16 to 18 of Algorithm 2.

Since the function MakeHint computes the sum of its two operands (when implemented according to the Dilithium specification or the simplified Algorithm 1), running

$\mathrm{MakeHint}\left(-v,u\right)$

corresponds to computing

$Hig\mathrm{hBits}\left(x\right)\left(=\mathrm{HighBits}\left(w-c{s}_2\right)\right)$ $\mathrm{and}\mathrm{HighBits}\left(u\right)\left(=\mathrm{HighBits}\left(w-c{s}_2+c{t}_0\right)\right)$

and comparing the results for equality (see Algorithm 1).

The hints h are set to 1 for coefficients where the results differ, and to 0 if they are equal. However, the variable v still needs to be computed to enable the check of ∥v∥∞.

FIG. 2 shows an exemplary block diagram of the modified signature according to Algorithm 2, which is summarized within the dashed block 201. A message M is fed to a block 202, which conducts the sign operation according to lines 1 to 15 of

Algorithm 2 Dilithium Sign (modified)
Input: Message M, private key sk = (ρ,K, tr, s1, s2, t0)
Output: Signature σ = ({tilde over (c)},z,h)
1:	A ∈ Rqk×   := ExpandA(ρ)
2:	μ ∈ {0,1}512 := H(tr | | M)
3:	κ := 0, (z,h) := ⊥
4:	ρ′ ∈ {0,1}512 := H(K | | μ) (or ρ′ ←{0,1}512 for randomized signing)
5:	while (z,h) = ⊥ do
6:	y ∈ {tilde over (S)}γ1   := ExpandMask(ρ′,κ)
7:	w := Ay
8:	w1 := HighBitsq(w,2γ2)
9:	{tilde over (c)} ∈ {0,1}256 := H(μ | | w1)
10:	c ∈ Bτ := SampleInBall({tilde over (c)})
11:	z := y+cs1
12:	r0 := LowBitsq(w−cs2,2γ2)
13:	if ||z||∞ ≥ γ1−β or ||r0||∞ ≥ γ2−β then
14:	(z,h) := ⊥
15:	else
16:	u := Az−ct1·2d	u ≙ w − cs2 + ct0, cf. Equation (2)
17:	v := u−(w−cs2)	v ≙ ct0
18:	h := MakeHintq(−v,u)	equivalent to MakeHintq(−ct0,w−cs2+ct0)
19:	if ||v||∞ ≥ γ2 or the # of 1's in h is greater than ω then (z,h) = ⊥
20:	end if
21:	κ := κ +
22:	end while
23:	return σ = ({tilde over (c)},z,h)

Algorithm 2 utilizing the private key sk.

A result w-cs₂ is conveyed from block 202 to block 203. The hash value {tilde over (c)} and the output value z are also determined by block 202 and are conveyed to block 204 as well as supplied as part of the signature σ.

Block 204 conducts a verification according to line 16 of Algorithm 2 based on the portion t₁ of the public key t. Further, block 204 outputs

$u=w-c{s}_2+c{t}_0$

according to Equation (2)) to the block 203 and to a block 206.

Block 203 computes a difference between the input from block 204 and block 202, i.e.,

$u-\left(w-c{s}_2\right)=w-c{s}_2+c{t}_0-\left(w-c{s}_2\right)={\mathrm{ct}}_0,$

which equals v and corresponds to line 17 of Algorithm 2. This vector v is supplied to block 206 and to block 205.

Block 205 conducts a check operation of

$v=c{t}_0$

according to line 19 of Algorithm 2, which may result in a restart of the loop, as explained above.

Block 206 calculates the hints h according to line 18 of Algorithm 2 utilizing the function MakeHintq based on the inputs −v and u.

Hence, at the output of block 201, the signature

$\sigma =\left(\tilde{c},z,h\right)$

of the Message M is available.

Integrated Sign-then-Verify Countermeasure

Although not the full verification is computed in this modified sign procedure, it allows an advantageous way of including a sign-then-verify fault countermeasure, which reveals faults that might have been inserted during the sign procedure.

The difference between

$Hig\mathrm{hBits}\left(w-c{s}_2\right)$ $\mathrm{and}\mathrm{HighBits}\left(w-c{s}_2+c{t}_0\right)$

must not exceed 1 (in absolute value) for each coefficient. Since the magnitude of ct₀ lies within a certain range (this is verified in line 24 of FIG. 1), adding ct₀ to any other value x will never result in a larger difference in the functions HighBits(x) and HighBits(x+ct₀).

The current solution does not compute the quantity

$w-c{s}_2+c{t}_0$

by adding ct₀ to w-cs₂, but instead by evaluating a portion of the verification procedure. If, e.g., a fault is injected in the computation w=Ay during signing, then the corrupted w-cs₂ will likely significantly differ from u:=Az-ct₁·2^d (which is equivalent to w-cs₂+ct₀ in the undisturbed case). Thus, by testing if the difference between HighBits(w-cs₂) and HighBits(u) is at most one, certain faults can be detected.

Further Embodiments and Advantages

The solution presented allows a significant reduction of memory space, which allows existing memory to be used for other purposes. A device supporting both signing and verification for a keypair may, therefore, advantageously only store the vector t₁ instead of both vectors t₁ and t₀, allowing savings of up to 3.25 kB per key. A device merely supporting signing for a keypair also benefits because t₁ can be stored instead of t₀, and t₁ requires less memory space than t₀.

Another advantage is that the approach presented has built-in fault detection capability (if required).

It is also an advantage that the solution operates on public data (public key, signature output), which may not require additional security measures like side-channel protection.

While the computation is part of the rejection loop and certain conditions require restart signing (see [LDK+21] for details), the conditions are checked last and are thus unlikely to fail. Hence, the additional computations suggested in the modified sign procedure are likely to be computed only once.

The current reference implementation of Dilithium suggests a function MakeHint that uses

$w_0-c{s}_2-c{t}_0\mathrm{and}{w}_1$

as input. In this case, ct₀ can be recovered first before computing

$r_0-c{t}_0=w_0-c{s}_2-{\mathrm{ct}}_0.$

The following refers to further examples of processing devices that can be used to implement the invention as described herein.

FIG. 3 shows a processing device 500 comprising a CPU 501, a RAM 502, a nonvolatile memory 503 (NVM), a crypto module 504, an analog module 506, an input/output interface 507, and a hardware-random number generator 512.

In this example, the CPU 501 has access to at least one crypto module 504 over a shared bus 505, to which each crypto module 504 is coupled. Each crypto module 504 may, in particular, comprise one or more crypto cores to perform certain cryptographic operations. Exemplary crypto cores are:

• • an AES core 509,
  • a SHA core 510,
  • an ECC core 511, and
  • a lattice-based crypto core 508.

The CPU 501, the hardware random number generator 512, the NVM 503, the crypto module 504, the RAM 502, and the input/output interface 507 are connected to the bus 505. The input-output interface 507 may have a connection to other devices, which may be similar to the processing device 500.

The crypto module 504 may or may not be equipped with hardware-based security features.

The bus 505 itself may be masked or plain. Instructions to process the steps described herein may, in particular, be stored in the NVM 503 and processed by the CPU 505. The data processed may be stored in the NVM 503 or the RAM 502.

Supporting functions may be provided by the crypto module 504 (e.g., expansion of pseudo-random data).

Steps of the method described herein may exclusively or at least partially be conducted on the crypto module 504, e.g., on the lattice-based crypto core 508.

The processing device 500 may be a chip card powered by direct electrical contact or through an electromagnetic field. The processing device 500 may be a fixed circuit or based on reconfigurable hardware (e.g., Field Programmable Gate Array, FPGA). The processing device 500 may be coupled to a personal computer, microcontroller, FPGA, or smartphone.

The solution described herein may be used by a customer who intends to provide a secure implementation of lattice-based cryptography on a smart card or any secure element.

FIG. 4 shows another example of a processing device 600. The processing device 600 comprises a hardware security module 601, a non-volatile memory (NVM) 606, a random access memory (RAM) 609, an interface 610 for communication with other devices, and an application processor 607, which is coupled with the hardware security module (HSM)601, the RAM 609, the NVM 608 and the interface 610.

The HSM 601 comprises a controller 602, a hardware-random number generator (HRNG) 606, and at least one crypto module 603. The crypto module 603 exemplary comprises an AES core 604 and a lattice-based crypto (LBC) core 605.

According to one embodiment, the HSM 601 and the application processor 607 may be fabricated on the same physical chip with a tight coupling. The HSM 601 delivers cryptographic services and secured key storage while the application processor may perform computationally intensive tasks (e.g., image recognition, communication, motor control). The HSM 601 may be only accessible by a defined interface and considered independent of the rest of the system in a way that a security compromise of the application processor 607 has only a limited impact on the security of the HSM 601. The HSM 601 may perform all tasks or a subset of tasks described with respect to the processing device 600 by using the controller 602, the LBC 605, supported by, exemplary, an AES 604, and the HRNG 606. It may execute the procedures described herein (at least partially) either controlled by an internal controller or as a CMOS circuit. Moreover, the application processor 607 may perform the procedures described herein (at least partially, e.g., in collaboration with the HSM 601).

The processing device 600 with this application processor 607 and HSM 601 may be used as a central communication gateway or (electric) motor control unit in cars or other vehicles.

In one or more examples, the functions described herein may be implemented at least partially in hardware, such as specific hardware components or a processor. More generally, the techniques may be implemented in hardware, processors, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media, including any medium that facilitates the transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory, or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and/or data structures for the implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium, i.e., a computer-readable transmission medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Instructions may be executed by one or more processors, such as one or more central processing units (CPU), digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor,” as used herein, may refer to any of the foregoing structures or any other structure suitable for the implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding or incorporated in a combined codec. Also, the techniques could be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a single hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

Although various exemplary embodiments of the invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made that will achieve some of the advantages of the invention without departing from the spirit and scope of the invention. It will be obvious to those reasonably skilled in the art that other components performing the same functions may be suitably substituted. It should be mentioned that features explained with reference to a specific figure may be combined with features of other figures, even in those cases in which this has not explicitly been mentioned. Further, the methods of the invention may be achieved in either all software implementations, using the appropriate processor instructions, or in hybrid implementations that utilize a combination of hardware logic and software logic to achieve the same results.

Such modifications to the inventive concept are intended to be covered by the appended claims.

REFERENCES

• • [LDK+21] Vadim Lyubashevsky, LéDucas, Eike Kiltz, Tancréde Lepoint, Peter Schwabe, Gregor Seiler, and Damien Stehlé. CRYSTALS—Dilithium: Algorithm specification and supporting documentation (version 3.1). Submission to the NIST Post-Quantum Cryptography Standardization Project [NIS16], 2021. Specification Document:https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf. Website: https://pq-crystals.org/dilithium.
  • [NIS16] NIST Computer Security Division. Post-Quantum Cryptography Standardization, 2016. Website: https://csrc.nist.gov/Projects/Post-Quantum-Cryptography.

Claims

1. A method for generating a lattice-based signature comprising: determining an uncorrected signature;determining hints based on a verification of the uncorrected signature; andproviding the uncorrected signature and the hints as the lattice-based signature.

2. The method according to claim 1, wherein the lattice-based signature generation is based on or interworks with lattice-based digital signature scheme Dilithium.

3. The method according to claim 1, wherein the verification is based on a first portion of an uncompressed public key element, and a second portion of the uncompressed public key element is not used during signature generation.

4. The method according to claim 3, wherein the second portion of the uncompressed public key element is longer than the first portion of the uncompressed public key element.

5. The method according to claim 3, wherein the second portion of the uncompressed public key element is not stored locally.

6. The method according to claim 3, wherein the second portion of the uncompressed public key element is not made publicly available.

7. The method according to claim 1, wherein the verification is used to determine whether a fault has occurred during the generation of the lattice-based signature.

8. The method according to claim 1, wherein a compression function is at least partly conducted on one of a security device, a secured cloud, a secured service, an integrated circuit, a hardware security module, a trusted platform module, a crypto unit, a field programmable gate array (FPGA), a processing unit, a controller, and a smartcard.

9. A device for generating a lattice-based signature, wherein the device is arranged to: determine an uncorrected signature;determine hints based on a verification of the uncorrected signature; andproviding the uncorrected signature and the hints as the lattice-based signature.

10. The device according to claim 9, wherein the device is or comprises one of a security device, a secured cloud, a secured service, an integrated circuit, a hardware security module, a trusted platform module, a crypto unit, a field programmable gate array (FPGA), a processing unit, a controller, and a smartcard.

11. A non-transitory computer program product directly loadable into a memory of a digital processing device, comprising software code portions for performing the steps of the method of claim 1.