Nested threshold signatures

Abstract

1. A computer-implemented method for requiring at least one of a subgroup of a group of participants to contribute to a threshold optimal signature scheme, where a valid signature includes a first signature component and a second signature component, where each participant has a respective private key share of a shared secret key, a respective ephemeral private key share of a shared ephemeral private key, and the first signature component, and where the shared secret key can only be generated using at least a first threshold number of the respective private key shares.

Description

[Technical Field]

[0001] This disclosure relates to threshold digital signatures, and more specifically, to a method for requiring (i.e., ensuring) that at least one specific participant contributes to a threshold signature scheme in order to generate a threshold digital signature. [Background technology]

[0002] Public-key cryptography is a type of cryptographic system that uses a pair of keys: a private key known only to the owner of the private key, and a public key generated based on the corresponding private key, which can be distributed without compromising the security of the private key.

[0003] Public-key cryptography allows a sender to encrypt a message using the recipient's public key (i.e., a public key corresponding to a private key known only to the recipient). Therefore, an encrypted message can only be decrypted using the recipient's private key.

[0004] Similarly, a sender can sign a message using their private key, for example, to prove that the message was sent by them and / or to indicate that the sender agrees to the message. A signer (i.e., the party generating the signature) uses their private key to create a digital signature based on the message. Creating a digital signature based on a message means supplying the message and the private key to a function that generates a signature based on both the message and the private key. The signature is added to the message (e.g., tagged) or otherwise associated with the message. Anyone with the signer's corresponding public key can use the same message and the digital signature on the message to verify whether the signature was validly created, i.e., whether the signature was actually created using the signer's private key. Digital signatures not only guarantee the authenticity of a message but also its integrity and non-repudiation. That is, a digital signature can be used to prove that a message has not been altered since it was signed and that the creator of the signature cannot deny in the future that they created the signature.

[0005] A digital signature scheme typically involves three steps, or algorithms. A key generation algorithm is used to generate a random private key and its corresponding public key. A signature algorithm is used to generate a signature based on the message and the private key. A verification algorithm is used to verify, given the public key and message, whether the signature was generated using the corresponding private key and according to the signature algorithm.

[0006] Generally, a shared secret can be used to share a data item that is distributed among a group of participants. Each participant has a different share of the secret. Typically, a secret can only be reconstructed when a certain number of participants (called a "threshold") can combine their respective shares to compute the secret, for example. A common use of a shared secret is as a shared secret key in a private-public key pair. That is, the private key can be distributed among a group of participants in such a way that no single participant can access it. Therefore, no single participant can generate a valid signature for a message. Instead, some or all of the participants must generate the private key together for a signature to be generated.

[0007] Instead of participants sharing their private key shares to generate signatures, they may use a threshold signature scheme. A threshold signature scheme allows a threshold number of participants in a group to create a digital signature on a message using their individual shares of a shared private key, without making the private key available to any single participant. Here, the digital signature is the signature generated on the message to be signed. In such a scheme, a signature can only be created if a threshold number of participants agree to generate a signature on the message. Attempting to generate a signature using fewer participants will not produce a valid signature. Thus, a valid signature by a group (i.e., a signature generated using the message and the shared private key) proves that a threshold number of people have agreed to generate the signature. This also means that any adversary would need to obtain a threshold number of shares of the private key in order to forge a signature using that private key.

[0008] A threshold signature scheme is said to be threshold-optimal if the threshold for generating a valid signature is the same as the threshold for the shared secret key. [Overview of the Initiative]

[0009] Threshold signature schemes require a certain number of participants to contribute, or participate, in order to generate a valid signature. For example, a certain number of signature shares must be contributed by a group of participants. There are scenarios where it is desirable to require not just a certain number of participants to contribute, but a certain number of specific participants to contribute. For example, in a 3-of-5 signature scheme, it may be desirable not just to require any three participants to contribute, but to require one of the three participants to be a specific participant, so that the remaining four participants cannot generate a valid signature unless that participant contributes.

[0010] According to one embodiment disclosed herein, a computer implementation method is provided which requires that at least one of a subgroup of a group of participants contributes to a threshold-optimal signature scheme, wherein a valid signature comprises a first signature component and a second signature component, each participant has a private key share of a shared private key, an ephemeral private key share of a shared ephemeral private key, and a first signature component, the shared private key can only be generated using at least a first threshold number of private key shares, the method is a step of obtaining at least a second threshold number of shares of the message-independent component (MIC) of the second signature component by a first participant belonging to a subgroup, each share of the MIC is generated by the respective participant based on their respective ephemeral private key share, their respective private key share, and the first signature component, the MIC can only be generated using at least a second threshold number of shares of the MIC, and the first share of the MIC is A method is provided that includes the steps of: generating an MIC by a first participant, where each share of the MIC is available only to one or more participants in a subgroup; generating an MIC based on each share of a second threshold number obtained; a) making the MIC available to a coordinator to generate a second signature component based on the MIC and each share of a second threshold number of message-dependent components (MDCs) of the second signature component, where each share of the MDC is generated based on each ephemeral secret key share and a hash of the message; and / or b) dividing the MIC into a plurality of secondary MIC shares, where a third threshold number of secondary MIC shares are required to generate the MIC, and distributing one or more of each secondary MIC shares to each participant in the group for the third threshold number of participants to generate the MIC, and making the MIC available to a coordinator to generate the second signature component.

[0011] This scheme is used to require the presence of a specific set of participants in the signature protocol of a threshold-optimal signature scheme. In this scheme, a valid signature consists of two components: a first signature component, sometimes called the r component, and a second signature component, sometimes called the s component. The s component is based on a message-independent component (MIC) and a message-dependent component (MDC). According to this scheme, a valid signature (specifically, a valid second signature component) requires a threshold number of shares of MDC contributed by a threshold number of participants, and a valid MIC. It is recognized that by restricting the generation of MICs to subgroups of participants, it is guaranteed that at least one of the participant subgroups must contribute to this scheme. If no subgroups participate, a valid MIC cannot be generated, and therefore a valid signature cannot be generated. Conversely, if a valid signature is generated (which can be checked using the public key corresponding to the message and shared secret key), it means that at least one of the subgroups must have contributed.

[0012] This method creates "nested thresholds" among participants within a threshold signature scheme. That is, within each group of participants capable of generating an MDC share, there are subgroups of participants capable of generating an MIC and therefore required to generate a valid signature.

[0013] Following the 3-of-5 example described above, this method can be used within a company, for example, to generate signatures on important documents such as contracts. Two participants can be managers, and only those managers have knowledge of the MIC, so at least one of the three participants creating the signature must be a manager. The three participants who do not have knowledge of the MIC cannot create the signature. On the other hand, if all three participants have knowledge of the MIC, then only two do not. To create the signature, any subset of the three participants must include at least one participant with knowledge of the MIC, and therefore, in this example, there is no restriction on who can sign.

[0014] In some embodiments, once the MIC is calculated by the first participant, it is then divided into multiple “secondary shares,” for example, using Shamir’s Secret Sharing (SSSS). These secondary shares are distinct from the shares of the MIC received by other participants and are used by the first participant to generate the MIC. To clarify, the shares of the MIC are generated by the participants and then used to generate the MIC (for example, by interpolating across the shares of the MIC). The resulting MIC is then divided into secondary shares. Reconstructing the MIC requires secondary shares of a threshold number of the MIC. The shares are then distributed among the participants. In this case, instead of requiring the first participant to contribute to the MIC, the MIC may be reconstructed using secondary shares of a threshold number of the MIC and then provided to the coordinator. In this way, multiple hierarchies can be created. For example, the owner of a company may distribute the MIC among the CEO, CTO, and CSO, requiring all three to be present to sign. They could also divide it with a separate SSSS algorithm and give the secondary share to seven different managers, of which at least five must be present in place of three of the executive-level managers. [Brief explanation of the drawing]

[0015] To aid in understanding embodiments of this disclosure and to illustrate how such embodiments may be carried out, the accompanying drawings are referenced merely as examples. [Figure 1] An exemplary system for generating message-independent components of threshold signatures is schematically shown. [Figure 2] Another exemplary system for generating message-independent components of threshold signatures is schematically shown. [Figure 3] An illustrative method for generating message-independent components of threshold signatures is outlined. [Modes for carrying out the invention]

[0016] 1. The concept of cryptography The following examples illustrate elliptic curve cryptography, but the present invention is not limited to any one specific cryptographic scheme and can generally be applied to any cryptographic scheme, such as RSA or other public-key cryptography schemes.

[0017] Elliptic curves The elliptic curve E satisfies the following equation: y 2 =x 3 +ax+b mod p Here,

number

number

[0018] This group operation can be used to define another operation on elements called point multiplication, represented by ·.

number

[0019] In elliptic curve cryptography, the secret key is:

number

number

[0020] Elliptic Curve Digital Signature Algorithm To create a signature for a message msg using the private key a, the following steps are performed: 1. Here, a message digest e = hash(msg) is calculated, which can be any hash function. For example, in some cases, hash(msg)=SHA256(SHA256(msg)), where

Number

[0021] The ephemeral key must be kept secret; otherwise, given the message and signature, the secret key could be computed. Additionally, a different ephemeral key must be used each time a signature is generated. Otherwise, given two different signatures and their corresponding messages, it would be possible to derive the secret key 'a'.

[0022] Given a message msg, a public key P=a·G, and a corresponding signature (r,s), the signature can be verified by completing the following steps: 1. Calculate the message digest e = hash(msg), for example, e = SHA256(SHA256(msg)). 2. The reciprocal of s, s -1 Calculate this modulo n. 3.j1=es -1 mod n and j2=rs -1 Calculate modulo n. 4. Calculate point Q = j1·G + j2·P. 5. If Q = O (point at infinity), the signature is invalid. 6. If Q ≠ O,

number

[0023] In a threshold signature scheme, this private key a is divided into key shares that are distributed among the participants in the threshold scheme group.

[0024] Co-verifiable random secret distribution Assume that N participants want to create a shared secret that can only be regenerated by at least (t+1) of the participants in this scheme. The following steps are taken to create the shared secret. 1. Participants agree on a unique label i for each participant. Each participant i is assigned (t+1) random numbers.

number

number

number

number

[0025] Shared secrets are in the format (i,a i The point is that i is the participant label in the scheme. The method for creating a secret share of a is as described in steps 1-3 herein, and in this specification a for participant i. i=JVRSS(i). Note that "JVRSS" typically stands for "Joint Verification Random Secret Sharing" and includes steps 4 and 5. However, throughout this document, JVRSS is interpreted as meaning that at least steps 1-3 are performed, with steps 4 and 5 being optional steps.

[0026] Since the participants generate a shared polynomial, each participant can verify that the other participants have shared the correct information with all participants, and that all participants have the same shared polynomial. This is done as follows: 4. Each participant i has an obfuscated coefficient for k=0,...,t. a ik ·G Broadcast this to all participants. 5. Each participant i is f j (i)Calculate G and verify that each participant j is a polynomial point f j Check that (i) was calculated correctly:

number

[0027] If all participants find that this equation holds for each polynomial, then the group can be collectively certain that they have all created the same common polynomial.

[0028] Reconstructing shared secrets Assume that the participants desire to reconstruct a shared secret a, which is a zero-degree shared polynomial.

number

number

[0029] public key calculation The public keys a of the N zero-degree secret polynomial coefficients for i=1,...,N, shared in Step 4 of JVRSS i0 Given G, each participant will have a shared secret corresponding to a

number

[0030] Add a shared secret To compute two additional shared secrets shared among a group of N participants without any entity knowing the individual secrets (where each secret polynomial has degree t), the following steps are taken: 1. Generate the first shared secret a. Here, the share of participant i is a threshold at (t+1) for i=1,...,N. i = Given by JVRSS(i). 2. Generate a second shared secret b. Here, participant i's share is given by the threshold b at (t+1). i = Given by JVRSS(i). 3. Each participant i calculates their own additive share: ν i =a i +b i mod n 4. All participants will have their own additive share ν i Broadcast this to all other participants. 5. Each participant will calculate the following: Share ν i Interpolate over at least (t+1): ν=interpolate(ν1,...,ν t+1 ) = a + b

[0031] This method for adding a shared secret is represented by ADDSS(i) for participant i, so that each participant i knows ν=(a+b).

[0032] Product of shared secrets To compute the product of two shared secrets shared among a group of N participants (where each secret polynomial has degree t), the group performs the following steps: 1. Generate the first shared secret a. Here, the share of participant i is a for i=1,...,N. i = Given by JVRSS(i). The shared secret polynomial has degree t, which means that (t+1) participants are needed for its recreation. 2. Generate a second shared secret b. Here, participant i's share is b. i = Given by JVRSS(i), the shared secret polynomial also has degree t in this case. 3. Each participant uses the following to determine their multiplication share μ i Calculate. μ i =a i b i 4. All participants share their multiplication by μ. i Broadcast this to all other participants. 5. Each participant calculates the following: Share μ in 0 i Interpolate over at least (2t+1) of these: μ = interpolate(μ1, ..., μ 2t+1 )=ab

[0033] This method for calculating the product of two shared secrets is expressed herein as μ = ab = PROSS(i) for participant i.

[0034] The reciprocal of a shared secret To calculate the reciprocal of the shared secret a, the following steps are taken: 1. All participants calculate the product PROSS(i) of the shared secrets, and the result is μ = ab mod n. 2. Each participant calculates the modular reciprocal of μ, which results in the following: μ -1 =(ab) -1 mod n 3. Each participant i calculates their inverse secret share by calculating the following:

number

[0035] This method for calculating the reciprocal of a shared secret can be expressed as follows for participant i:

number

[0036] Generation and verification of shared secret keys To compute a shared private key a among N≧2t+1 participants (of which t+1 are required to create the signature), each participant runs JVRSS with a threshold of t+1 and performs public key computation as described above. As a result, all participants i=1,...,N share the private key a. i And it will have the corresponding shared public key P=(a·G).

[0037] Generation of ephemeral key shares To generate the ephemeral key share and corresponding r required for signing, a group of size N with a shared secret key a at threshold (t+1) performs the following steps: 1. Shared Secret

number

Number

[0038] Adding Secrets with Different Thresholds When adding secrets of degrees t and t´, adding two secrets requires max(t, t´)+1 shares to compute it. The reason behind this is that the share addition step of the shared secret creates shares of a new polynomial. This new additive polynomial is equivalent to the result of adding the individual polynomials of the two shared secrets. Adding two polynomials is adding the corresponding coefficients at each degree of x. Therefore, the degree of the additive polynomial must be the same as the highest degree of the two polynomials. This can be generalized to the addition of more than two polynomials, where the degree of the resulting polynomial is the same as the degree of the highest individual polynomial.

[0039] When the addition of two secrets with different thresholds is computed, the security of the secret with the higher threshold is reduced. Because if we know the result (a + b) at respective thresholds t, t´, and assume t < t´, we can compute a using t shares and then (a + b)-a = b, so we can compute the value b using only t shares. This lower threshold is hereinafter referred to as the "implicated threshold" of b.

[0040] Multiplication of Secrets with Different Thresholds In the case of multiplying two secrets with thresholds t and t', the multiplication calculation requires t + t' + 1 shares. In this case, the multiplication of the shares of two polynomials yields shares on a new polynomial. This new polynomial is the result of multiplying the two individual polynomials, and thus the degree of the result is the addition of the degrees of the two individual polynomials.

[0041] Multiplication can also be generalized to any number of shared secrets, and the resulting threshold is the sum of the individual thresholds plus 1, Σ ρ t ρ + 1, where ρ is performed over the individual shared secrets.

[0042] Similar to addition, the multiplication of two secrets with different thresholds yields the relevant threshold of the higher-threshold secret. As before, if ab is known (a has a threshold of t and b has a threshold of t'), and t < t', then it is possible to calculate both a and b with t shares. First, a can be calculated, and using (ab)a -1 it is possible to obtain b with only t shares of the secret.

[0043] Combining addition and multiplication of shared secrets in one step It is possible to generalize the above to calculate any combination of addition and multiplication in one step. Assume a group of N participants wishes to calculate the result ab + c. Here, a, b, c are shared secrets with thresholds (t a + 1), (t b + 1), (t c + 1) respectively. There is a condition that max(t a + t b , t c ) < N, that is, the number of participants in this scheme must be greater than the maximum between the degree of the secret c and the degree of the result of the multiplication of the secrets a and b. 1. Each participant i has thresholds (t a + 1), (t b + 1), (t cUsing (+1), their secret shares a i = JVRSS(i), b i = JVRSS(i), c i Calculate = JVRSS(i). 2. Each participant i has a share λ i = a i b i + c i Calculate it. 3. Each participant i shares the result λ i with other participants. 4. Each participant determines the result λ = int(λ1,..., λ i ,...) = ab + c by interpolating over max(t a + t b , t c ) + 1 shares.

[0044] This is done in the calculation of the shared signature according to some of the following embodiments. That is, s i = k i -1 (e + a i [[ID=;41]]r) has interpolation. This is essentially the case where a i b i = k i -1 a i r and c i = k i -1 e. In this case, t a + t b = 2t and t c = t, and the interpolation is over max(t a + t b , t c ) + l = 2t + 1 shares.

[0045] 2. Nested thresholds Figure 1 shows an exemplary system 100 for generating threshold signatures, more specifically, message-independent components (MICs) of the components of a threshold signature. As shown in the figure, system 100 includes multiple (i.e., group) participants (e.g., users, machines, etc.) 102. Participants are sometimes referred to as parties or entities. Each of the participants 102 operates its own computing device.

[0046] Each computing device of each participant 102 comprises one or more processors, for example, one or more central processing units (CPUs), accelerator processors (GPUs), application-specific processors, and / or field-programmable gate arrays (FPGAs). Each computing device may also comprise memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives. Each computing device may comprise at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Alternatively or additionally, each computing device may comprise one or more other networked resources, such as cloud computing resources, accessed via the user terminal (cloud computing resources include resources from one or more physical server devices implemented at one or more sites). Any action described as being performed by a party to System 100 may be performed by the respective computing device operated by that party.

[0047] Each participant 102 is configured to transmit data to one, some, or all of the other participants 102 via the Internet using a LAN or WAN connection, or via alternative wired or wireless communication means. Unless the context indicates otherwise, a reference to a participant 102 transmitting data may be understood as, for example, individually transmitting data to the other participants 102 via a secure communication channel between the two participants, or broadcasting to the entire group via, for example, email or other means. Again, unless the context indicates otherwise, each participant 102 may transmit data in raw or encrypted form. For example, data may be encrypted using the public key of the receiving participant before being transmitted to that participant.

[0048] In Figure 1, the group of participants includes five participants. This is for illustrative purposes only, and it should be understood that, in general, a group can contain any number of participants. Figure 1 also shows subgroups of the group of participants (outlined by dotted lines). In this example, the subgroup consists of the first and second participants, but this is also for illustrative purposes only. Note that, unless the context requires a different interpretation, terms such as "first," "second," etc., are used simply as distinguishing labels and do not necessarily imply order, hierarchy, or anything of that sort.

[0049] System 100 also includes a coordinator 101. The coordinator may be one of the subgroups of participants, for example, the first participant. Alternatively, coordinator 101 may be a separate entity. The coordinator operates the respective computer equipment as described above with respect to participant 102.

[0050] Coordinator 101 is the party that initiates signing using a threshold number of signature shares generated by each participant in the group of participants 102 (described later). That is, Coordinator 101 generates a signature for the message to be signed (i.e., for the message). Note that, in this case as well, generating a signature for a message is interpreted as meaning that the signature depends on the message to be signed, or in other words, that the signature is a function of the message to be signed. Coordinator 101 may also be the party that sends the signature and optionally the message to Third Party 103, or otherwise outputs the signature. For example, Third Party 103 may be a Certificate Authority or other form of authority, or another user. In other examples, the signature may be recorded in a database or other document, for example. In some examples, the signature may be made public and recorded in a website or other publicly accessible medium, for example.

[0051] Coordinator 101 may send a message to be signed to participant 102. The message may be sent to all participants 102, or to a subset of participants, for example, a threshold number of participants. Coordinator 101 may send the message to one participant, who then forwards the message to one, some, or all of the other participants. The message may be transmitted over the Internet using a LAN or WAN connection, or via alternative wired or wireless communication means. The message may be sent individually to each participant 102, for example, via a secure communication channel between Coordinator 101 and each participant 102, or it may be broadcast to the entire group, for example, via email or other means. The message may be transmitted in raw form or in encrypted form. For example, the message may be hashed one or more times.

[0052] One or more of the participants 102 may obtain a message through an alternative means, i.e., from a source other than the coordinator 101. For example, the message may be generated by one of the participants 102, or it may be made available by another means, e.g., publicly available. One or more participants 102 may receive a message from a third party 103. A participant 102 who obtains a message may send the message (raw or in encrypted form) to one or more other participants 102. For example, a first participant 102 may send a message to other participants.

[0053] Each participant in the group has their own share of the shared secret key (for example, stored in memory). The shared secret key is actually a data item.

[0054] Techniques for generating shares of a secret key are well known to those skilled in the art. As an exemplary example, each participant may participate in JVRSS (joint verifiable secret sharing scheme) to generate their respective shares of a shared secret key. For example, a first participant 102a may be configured to generate a first secret key share a1 of secret key a using the JVRSS technique described above. That is, the first participant 102a has an index of 1 and can generate a first secret key share for participant 1 using a1 = JVRSS(1), where the secret key is represented by a. Each participant 102 has their respective secret key share a i This can be generated. For example, a second participant 102b can generate a second secret key share for participant 2 using a2=JVRSS(2), and so on.

[0055] Generating the first secret key share a1 using a joint secret sharing scheme is a numerical set

number

[0056] The first participant 102a may calculate the corresponding public key a·G based on the set of obfuscated coefficients, where the coefficients are the respective secret key shares a i [[ID=​​​​​​11 ·G, a 12 ·G etc. can be broadcast. Then, the public key corresponding to the private key can be calculated as follows:

number

[0057] Share private key a i To generate this, it is not necessary to generate a corresponding public key, and therefore, this will be understood as an optional feature that participant 102 can implement if they choose.

[0058] Share private key a i It should be noted that this can be generated using alternative methods, i.e., without using the JVRSS method described above. Methods for generating a share of a private key are known in the art. Similarly, methods for distributing a share of a private key (or other such data) are known in the art. That said, a private key share a i It can be generated in several ways. For example, using a dealer (e.g., one trusted or independent party among the 102 participants), for example, using Shamir's secret sharing scheme, to generate a secret key share a i One, some, or all of these can be generated and distributed. (Private key share a) i One such scheme that could be used to generate and distribute is described in WO2017145010A1.

[0059] Regardless of the specific method used to generate the private key share, each of the 102 groups of first participants will have their own private key share a of private key a. i It has (for example, it remembers).

[0060] Each participant in the group also has their respective share of the shared ephemeral key k. iIt has (for example, stored in memory). For example, the first participant has the first ephemeral key share k1, the second participant has the second ephemeral key share k2, and so on. Shares of a shared ephemeral key can be generated using JVRSS, Shamir's secret sharing scheme, or alternative techniques.

[0061] Each group of participants also possesses (for example, stores in memory) a first component of the threshold signature, as well as each private key share and each ephemeral key share. This is sometimes known as the r value. For completeness, a second signature component may be known as the s value, which will be described in detail below. The first signature component is based on the public key corresponding to the shared ephemeral key, more specifically, on the x component of the public key corresponding to the shared ephemeral key. For example, the first signature component can be calculated as r = x mod n, as described above in the Preliminaries section.

[0062] In addition to remembering each share of the shared ephemeral key, some or all of the group of participants also remember the inverse share of the shared ephemeral key k i -1 Note that it is possible to remember this. In some cases, this is k i -1 It is calculated as =INVSS(i).

[0063] Next, we return to the second signature component. According to the threshold signature scheme, the second signature component is based on a message-independent component (MIC) and a message-dependent component (MDC). A valid signature can only be generated if a threshold number of shares of the MDC are available, where the threshold number is the same as the threshold number of the shared secret key, due to the threshold-optimal nature of the scheme. Therefore, at least a threshold number of participants are required in the group in order to generate each share of the MDC and make those shares available to the coordinator 101. Each share of the MDC generated by each participant is based on at least their respective ephemeral key share and the hash of the message to be signed. Since each participant has the necessary data (i.e., the ephemeral key share and the message to be signed, or its hash), any of the group of participants can generate a valid share of the MDC. In some examples, each participant is s i =k i -1 A share of the MDC can be generated as e, where e is a hashed message. The coordinator can then generate the MDC by interpolating, for example, over the shares of the MDC, based on at least a threshold number of shares of the MDC.

[0064] Therefore, in order to restrict which participants must contribute to the signing scheme, i.e., to restrict the participants in the signing scheme, restrictions are imposed on which participants can generate MICs (recall that an MIC is necessary to generate a valid signature). Specifically, only participants within a subgroup ("nested threshold") can generate MICs. Below, we will describe the case where the first participant 102a generates an MIC, but in general, any participant within a subgroup (e.g., the second participant 102b) can generate an MIC in the same way.

[0065] The first participant 102a generates a share of the MIC based on the first ephemeral key share k1, the first secret key share a1, and the first signature component r. For example, the first participant has λ1=k1 -1 a1r can generate the first share of MIC, where generally each participant (including each participant in the group) is λ i =k i -1 a i Each share of MIC can be generated as r.

[0066] Since each share of MIC is based on two threshold shares (i.e., ephemeral key share and private key share), MIC needs to calculate a second threshold number of shares, the second threshold being different from the private key share threshold. Thus, the first participant 102a receives each share of MIC from the other participants until the first participant 102a obtains at least a second threshold number of shares of MIC, including the first share of MIC generated by the first participant 102a. The first participant 102a then uses the obtained shares of MIC to generate MIC, for example, by interpolating over at least a second threshold number of shares of MIC.

[0067] Restrictions are imposed on who can generate an MIC by requiring that only participants in a subgroup can receive their respective share of the MIC. That is, participants in groups that do not belong to a subgroup (i.e., a nested threshold) send their respective share of the MIC only to participants within that subgroup. In some examples, those participants send their respective share only to the first participant 102a. This may be true regardless of whether the first participant is the only participant in the subgroup. If the subgroup contains multiple participants, the first participant 102a may choose to send its share of the MIC (the first share of the MIC) to one or more other participants in the subgroup. It may be preferable that each participant in the subgroup receives all of their share of the MIC so that each participant in the subgroup can generate an MIC. This works to prevent a single point of failure.

[0068] It should be noted that since MIC does not require knowledge of the message, MIC can be pre-calculated. In other words, MIC can be generated before the message is received. Therefore, multiple different MICs can be pre-calculated, each used to generate a different signature share s1' for signing different messages, where prime(') indicates that it is a different instance of the first signature share.

[0069] In some examples, each participant 102 may have their respective share of the shared blind key (for example, stored in memory). Blind key shares are used to obfuscate or otherwise "blind" or "hide" another key share or data item. That is, a blind key share may be applied to a first key share to hide the first key share, allowing the resulting key share to be shared without revealing the first key share. In a simple example, the first key share might be 100 and the blind key share might be 74, thus allowing the number 174 to be shared. Here, the receiver cannot be certain of knowing the first key share unless they know that the blind key share is 74. In practice, it will be understood that key shares can be much larger numbers. Blind key shares can be generated using JVRSS or alternative techniques. In these examples, each share of MIC and each share of MDC are generated based on their respective shares of the shared blind key. For example, the first participant 102a has λ1=k1 -1 The first share of MIC is generated as a1r + β1, and s1 = k1 -1 A first share of the MDC can be generated as e-β1. To see how blind key shares work, we take the first share of the MDC as an example. Assuming the coordinator has access to the message or its hash, if the coordinator receives the first share of the MDC and blind key shares are not used, the coordinator can derive the reverse ephemeral key share. There may be scenarios where this is problematic. Conversely, there may be scenarios where this is not a problem, and therefore the use of blind key shares is not necessary.

[0070] In some embodiments, the first participant 102a sends the MIC to the coordinator 101 to generate a second signature component based on the MDC and MIC. It is also possible that the first participant 102a acts as the coordinator 101, in which case the MIC does not need to be sent to a different entity. A complete valid signature is then generated using the first and second signature components (r,s), for example, (r,s=interpolate(s1,...,s t+1 )+λ), in this case the first threshold is t+1.

[0071] The coordinator 101 may then broadcast or transmit the signature to one or more other entities. Additionally or alternatively, the coordinator may store the signature and / or record the signature as part of a digital record, for example, in an email or other document. For example, the message may be part or all of a blockchain transaction. The signature may be included in that blockchain transaction (if the message is only part of a blockchain transaction) or in a different blockchain transaction.

[0072] In other embodiments, as shown in Figure 2, instead of sending the MIC to the coordinator 101 (or generating a second signature component), the first participant 102a divides the MIC into multiple secondary MIC shares. Note that the secondary MIC shares are distinct from the shares of the MIC generated by each participant (which may be called primary MIC shares to distinguish them from the secondary MIC shares generated by the first participant 102a). The secondary MIC shares may be divided using a (key) partitioning scheme such as Shamir's secret sharing scheme. Alternatively, an alternative scheme may be used. The MIC is divided such that at least a third threshold number of secondary MIC shares are required to reconstruct the MIC.

[0073] After dividing the MIC into multiple secondary MIC shares, the first participant 102a sends some or all of each secondary MIC share to the respective participants of the second subgroup. In some examples, the first participant 102a retains at least one secondary MIC share. In some examples, the first participant may delete some or all of the secondary MIC shares, in addition to those that the first participant 102a may retain.

[0074] In these embodiments, a second subgroup is created so that the MIC can be created by a third threshold number of participants in the second subgroup. The second subgroup may be separate from the first subgroup (as shown in Figure 2), or one or more participants in the first subgroup may belong to the second subgroup. At least a third threshold number of participants in the second subgroup can, as described above, reconstruct the MIC together so that the coordinator 101 can use the MIC to generate the second signature component. The second subgroup may appoint a leader to collect the required number of secondary MIC shares.

[0075] Figure 3 shows an exemplary method 300 for generating message-independent components of a threshold signature. In step S301, the first participant 102a generates a share of the MIC. In step S301, the first participant 102a receives each share of the MIC from each participant in the group until the first participant 102a obtains a share sufficient to generate the MIC. In step S303, the first participant 102a generates the MIC. In step S304, the first participant 102a sends the MIC to the coordinator 101. Alternatively, in step S305, the first participant 102a divides the MIC into secondary MIC shares. Then, in step S306, the first participant 102a distributes the secondary shares to participants in a second subgroup.

[0076] From here, a specific example of the described embodiment will be described with reference to the threshold-optimal ECDSA signature scheme disclosed in GB2005953.1, where a threshold of t+1 participants from a group of N≧2t+1 participants is required to create the signature. Optimality is achieved by taking advantage of the fact that the signature can be divided into message-dependent and message-independent components. The message-independent term is pre-calculated, and as a result, only a threshold equal to the number of participants' private keys is required to create the signature, thus achieving optimality. In one version of this scheme, the message-independent components may be pre-calculated and added to individual signature shares containing message-dependent components (MDCs) that are interpolated to create a valid signature. Alternatively, the addition of MICs may be performed after the interpolation of the signature shares themselves. Explicitly, the MIC is λ=k -1 ar + β, which is λ i =k i -1 a i r+β i 2t+1 shares and s i =k i -1 e-β i It is calculated by interpolating over signature shares defined as follows: In that case, the signature is: (r,s=interpolate(s1,...,s t+1 )+λ)

[0077] This scheme does not describe who knows the MIC, only that it is used for signing. To create a normal signing scheme where t+1 out of N people can sign, we assumed that this MIC is shared by all participants. However, by sharing this MIC in a specific way, we can create a requirement that a specific participant exists at the time of signing. In the following scenario, since participants receive shares and compute the result λ, at least one participant always has knowledge of the MIC.

[0078] The objective is to create a subset of participants, of which at least one must be present at the time of signing. The size of the subset is called the nested threshold of the scheme, and it is assumed that the size of this subset is at most N-(t+1), otherwise every subset would contain one of these required participants. To achieve this nested subset of participants, all participants have their share λ i It is sent only to nested subsets. Each participant in the subset can then compute MICλ using explicit interpolation across shares. Then, in order to create a signature, at least one of the nested subsets of participants must be present in the signature protocol and share the value λ with a signature coordinator who can compute the signature using: (r,s=interpolate(s1,...,s t+1 )+λ), where s i =k i -1 e-β i That is the case.

[0079] The size of this nested subgroup may be as small as one participant. However, it must be noted that in this case, a single point of failure arises in the scheme, and if this value λ is lost, the protocol must be repeated to recreate λ.

[0080] To illustrate this concept of nested thresholds, let's consider the example of a 3-of-5 system used within a company. Two participants can be managers, and only these two participants possess knowledge of the MIC, so that at least one of the three participants must be a manager when creating a signature. Even if there are three participants, they cannot create a signature if they do not possess the MIC. On the other hand, if all three participants possess knowledge of the MIC, only two do not. In order to create a signature, any subset of the three participants must include at least one participant who possesses knowledge of the MIC. Therefore, there is no restriction on who can sign, just as in the usual method where all participants possess knowledge of the MIC.

[0081] Multiple nested subsets of participants can be created. As mentioned above, at least one participant always has complete knowledge of the MIC. Anyone with knowledge of the MIC can use Shamir's Secret Sharing (SSSS) to divide the MIC into several shares and distribute them among the other participants. In this case, either the participant with the complete MIC must be present in the signature, or at least the threshold of the SSSS scheme must be present in a lower tier. In this way, multiple tiers can be created. This reduces reliance on authorities by introducing majority voting for making joint decisions. For example, the owners of a company could distribute the MIC among the CEO, CTO, and CSO, so that all three must be present in the signature. They could also divide it using separate SSSS algorithms and give it to seven different managers, five of whom must be present in place of two of the executive-level managers.

[0082] The following describes an exemplary method for generating a signature for a message and how it can be adapted to request participation from specific participants according to embodiments of the present invention. Steps S401-S408 are performed by each of the threshold number of participants 102 (including the first participant 102a) in this example. Step S409 is performed by the coordinator 101, who may be one of the participants performing steps S401-S408. It should be understood that some of the steps may be omitted or performed in a different order.

[0083] The exemplary method 400 allows the creation of a shared secret with a threshold of (t+1) in a group of N ≥ 2t+1 participants, where the signature threshold is also (t+1).

[0084] set up: In step S401, each participant 102 shares a shared secret key a i ′ and compute the corresponding public key. Private key share a i ′ The generation of is explained above. At this point, each participant i shares the secret key and the public key (a i ′ The shared secret key has a threshold of (t+1).

[0085] Pre-calculation: In step S402, each participant 102 computes a shared ephemeral key share and a corresponding public key. For example, each participant 102 may compute a shared ephemeral key using the public key computed in JVRSS and Preliminary. Then, each participant 102 may compute a reverse share based on the ephemeral secret key. As a result, each participant has a reverse share (k) with a threshold (t+1). i -1 It will have ,r).

[0086] In step S403, each participant 102 creates two different shared blind key shares. For example, each participant 102 creates a share α. i =JVRSS(i) and β i Two shared secrets can be created such that =JVRSS(i), each shared secret having a threshold (t+1). Note that in some examples, not all shared secrets need to have the same threshold.

[0087] In step S404, participant 102 calculates the intermediate share and broadcasts those intermediate shares to the other participants. For example, each participant i calculates the intermediate share λ i =k i -1 a i ′ r+β i This value can be calculated. This value has a threshold of (2t+1).

[0088] In step S405, the first participant 102a calculates the median value based on at least the median shares. For example, the first participant 102a calculates the median value based on (2t+1) shares λ = interpolate(λ1,...,λ 2t+1 )=k -1 Intermediate values ​​can be calculated using interpolation over ar+β.

[0089] In step S406, the first participant 102a is (r,k i -1 ,λ,β i ) possesses knowledge of this, and uses it for private key sharing and the corresponding public key (a i Remember it together with P).

[0090] Since a different ephemeral key is used for each signature, it should be noted that multiple ephemeral keys can be set up at once, i.e., by repeating steps S402 to S406, multiple ephemeral keys can be created during pre-computation and stored for later use. These can be performed simultaneously, so no additional rounds of communication occur. It should be noted that, preferably, different values ​​for α and β should be used for each signature.

[0091] Signature generation: To sign the message msg, at least (t+1) participants must perform steps S407 and S408. In step S407, at least a threshold number of participants 102 take the message to be signed and compute the message digest. For example, the coordinator 101 may send a request to (t+1) participants to create a signature share for the message msg. Each participant i may compute the message digest e = hash(msg). In some examples, this hash function is a double SHA-256 hash function. An alternative hash function may be used.

[0092] In step S408, at least a threshold number of participants 102 calculate their signature shares and send them to the coordinator 101. For example, each participant i calculates their signature shares s i =k i -1 e-β i Then calculate this signature share (r,s i ) can be sent to the coordinator. It was noted that the value r does not need to be sent by all participants.

[0093] In step S409, the coordinator 101 calculates the signature. For example, the coordinator 101 calculates s = interpolate(s1,...,s t+1 ) + λ = k -1 e+k -1We can compute ar and finally the signature (r,s). As a result, the β term is canceled out, and the expected signature share is obtained. (kα) -1 If and r are included in the calculation, a similar variation of this protocol can be made as described above.

[0094] It should be noted that secret thresholds can vary. That is, the thresholds for a, k, α, and β do not necessarily have to be the same in order to execute the signature generation scheme. For example, if there is a group of 6 people and 3 people are needed to create the signature and / or private key, strictly speaking, the calculation can be performed with a threshold of 4 for k and a threshold of 3 for the other shared secrets, and it will still be a threshold-optimized scheme.

[0095] It should be noted that the present invention can be applied to any threshold signature scheme (whether or not it is optimal) and is not limited to the example shown in Figure 4 above.

[0096] In general, embodiments of the present invention can be used to generate a signature for any message. In a particular exemplary use case, the message may be part or all of a blockchain transaction. That is, the signature may be used to sign one or more inputs and / or one or more outputs of a blockchain transaction. For example, the generated signature may be used at least in part to unlock the output of a blockchain transaction. In a particular example, the output of a previous transaction may be a P2PKH (pay-to-public-key-hash) output locked to a hash of a public key. For unlocking, the input of a subsequent transaction referencing the P2PKH output must include the (unhashed) public key and a signature generated based on the private key corresponding to the public key.

[0097] In script form, a "locking script" and an "unlocking script" can take the following forms:

[0098] Locking script = OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0099] Referring to the embodiments described above,<Public Key> This can also be equal to P=a·G, <signature>This includes threshold signatures s, where the previous transaction is the message to be signed. Note that, as mentioned above, ECDSA signatures are in the form (r,s).

[0100] It should be noted that the signature generation method described is not limited to any specific use case and can generally be used to generate signatures based on any message. Signing all or part of a blockchain transaction is just one example. The method described could be used, for example, to sign and / or authorize legal documents (e.g., wills, deeds, or other contracts), communications between one or more parties, digital certificates (e.g., those issued by a certification authority), medical prescriptions, bank transfers or financial products, mortgages or loan applications, etc.

[0101] As a specific example, a group of participants (e.g., a total of 5 participants) may form a company's board of directors. Company voting matters may require the agreement of a majority of the board members (i.e., at least 3 participants) on a particular vote. The board can use the described signature generation method to prove that at least 3 board members agreed to vote in favor of a particular outcome. In this example, the threshold for the signature generation method is 3. That is, for the coordinator to successfully generate signatures, at least 3 of the board members must provide their respective signature shares. If signature generation is successful, at least the threshold number (i.e., 3) of board members must have agreed to vote in favor of the outcome. Therefore, successful signature generation serves as a record of the vote, proving that a majority of the board voted in a particular manner.

[0102] Another use case of the present invention lies in the field of digital certificates, for example, digital certificates issued according to the X.509 standard. Digital certificates contain a signature that signs certain data. The data can generally be any data, but one specific example of data included in a digital certificate is a public key. The public key in a digital certificate is often called a “certified public key.” The issuer of a digital certificate (“certificate authority”) can perform one or more checks on the owner of the public key (e.g., a know-your-customer check), and if the checks are successful, the certificate authority issues a digital certificate containing the certified public key. A user can use the certified public key to prove their identity, for example, by signing a message with the private key corresponding to that certified public key.

[0103] One specific use of a Certificate Authority (CA) is to sign certificates used for HTTPS, which is essential for secure browsing on the internet. Another common use is for national governments to issue identity cards for use when electronically signing documents. A CA uses its private key to sign a public key (or any other data to be certified).

[0104] 3. Conclusion It will be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0105] Statement 1. A computer implementation method that requires at least one of the subgroups of a group of participants to contribute to a threshold-optimal signature scheme, wherein a valid signature includes a first signature component and a second signature component, each participant has a private key share of a shared private key, an ephemeral private key share of a shared ephemeral private key, and a first signature component, and the shared private key can only be generated using at least a first threshold number of private key shares, and the method is provided by a first participant belonging to a subgroup. A step of obtaining each share of at least a second threshold number of message-independent components (MICs) of a second signature component, wherein each share of the MIC is generated by each participant based on their respective ephemeral private key share, their respective private key share, and the first signature component, the MIC can only be generated using each share of at least a second threshold number of the MIC, the first share of the MIC is generated by the first participant, and each share of the MIC is available to only one or more participants in a subgroup, A step of generating MIC based on each share of the acquired second threshold number, a) Making the MIC available to the coordinator to generate a second signature component based on the MIC and each share of a second threshold number of message-dependent components (MDCs) of the second signature component, wherein each share of the MDC is generated based on the respective ephemeral secret key share and the hash of the message, and / or b) Divide the MIC into multiple secondary MIC shares, where a third threshold number of secondary MIC shares are required to generate the MIC, and distribute one or more of these secondary MIC shares to each participant in the group for a third threshold number of participants in order to generate the MIC, and make the MIC available to the coordinator to generate the second signature component. A method that includes this.

[0106] Statement 2. The steps include generating the first share of MDC, The steps include: enabling the coordinator to utilize the first share of the MDC to generate the second component of the signature; The method of statement 1, including the method described in statement 1.

[0107] Statement 3. The method of Statement 1 or Statement 2, wherein the first participant includes a coordinator, and the method includes the step of generating a second signature component.

[0108] Statement 4. The coordinator is one of the participants or a third party, in the manner of Statement 1 or Statement 2.

[0109] Statement 5. Each participant has their respective blind key share of the blind key, each share of the MIC is generated based on their respective blind key share, and each share of the MDC is generated based on their respective blind key share, in any of the manner of the preceding statements.

[0110] Statement 6. A subgroup includes multiple participants, and a) any of the methods in any of the preceding statements, including making available to one, some, or all of the other participants in the subgroup the first share of the MIC.

[0111] Statement 7. A subgroup may include multiple participants, and each participant within the subgroup may receive their respective share of the MIC, in any of the manner of the preceding statement.

[0112] Statement 8. Subgroups are formed from the first participant using one of the methods described in Statements 1-5.

[0113] Statement 9. A message is any preceding statement that includes at least a portion of a blockchain transaction.

[0114] Statement 10. The size of the group is N ≥ 2t + 1, the size of the subgroup is N - (t + 1), where t is the degree of the polynomial used to derive each participant's private key share, 2t + 1 is the first threshold number, and t + 1 is the second threshold number, in any of the preceding statements.

[0115] Statement 11. Each participant generates their respective secret key share and their respective ephemeral secret key share using JVRSS (joint verifiable random secret sharing scheme) in any of the preceding statements.

[0116] Statement 12. Each participant shall generate their respective blind key share using JVRSS, in the manner of Statement 5 or any statement subordinate thereto.

[0117] Statement 13. The method includes the step of dividing the MIC into multiple secondary MIC shares, wherein the step of dividing the MIC is performed using Shamir's secret sharing scheme, as described in any of the preceding statements.

[0118] Statement 14. The signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) signature, which is one of the methods of the preceding statement.

[0119] Statement 15. Each share of MIC is:

number

number

[0120] Statement 16. Computer equipment, A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising: memory, which stores code configured to be executed on the processing unit; and the code, when on the processing unit, which is configured to execute any of the methods of the preceding statements.

[0121] Statement 17. A computer program that is embodied on computer-readable storage and, when executed on a computer device, is configured to perform any of the methods described in Statements 1 through 15.

[0122] According to another aspect disclosed herein, a method may be provided that includes actions of a first participant and a coordinator.

[0123] In another aspect disclosed herein, a system may be provided comprising a computer device of a first participant and a coordinator.

[0124] According to other embodiments disclosed herein, a method may be provided that includes the actions of each participant.

[0125] In another aspect disclosed herein, a system comprising each participant's computer equipment may be provided.

[0126] Other variations or use cases of the techniques disclosed may be apparent to those skilled in the art if the disclosure herein is given. The scope of this disclosure is not limited by the embodiments described herein, but only by the appended claims.< / signature> < / signature>

Claims

1. A computer implementation method that requires at least one subgroup of a group of participants to contribute to a threshold-optimal signature scheme, wherein a valid signature includes a first signature component and a second signature component, each participant has a private key share of a shared private key, an ephemeral private key share of a shared ephemeral private key, and the first signature component, the shared private key can only be generated using at least a first threshold number of private key shares, and the method is performed by a computer device of a first participant belonging to the subgroup. A step of obtaining each share of at least a second threshold number of message-independent components (MICs) of the second signature component, wherein each share of the MIC is generated by each participant based on their respective ephemeral private key share, their respective private key share, and the first signature component, the MIC can only be generated using each share of at least the second threshold number of the MIC, the first share of the MIC is generated by the first participant, and each share of the MIC is available only to one or more participants of the subgroup, The steps include generating the MIC based on the respective shares of the second threshold numbers obtained, a) A step to enable the coordinator to use the MIC to generate the second signature component based on the MIC and the respective shares of the second threshold number of message-dependent components (MDCs) of the second signature component, wherein each share of the MDC is generated based on the respective ephemeral secret key share and the hash of the message, and / or b) Dividing the MIC into a plurality of secondary MIC shares, where a third threshold number of secondary MIC shares are required to generate the MIC, distributing one or more of each secondary MIC share to each participant in the group with respect to the third threshold number of participants in order to generate the MIC, and making the MIC available to the coordinator in order to generate the second signature component. A method that includes this.

2. The steps include generating the first share of the MDC, The steps include enabling the coordinator to utilize the first share of the MDC in order to generate the second signature component of the signature, and The method according to claim 1, including the method described in claim 1.

3. The method according to claim 1 or 2, wherein the first participant includes the coordinator, and the method includes the step of generating the second signature component.

4. The method according to claim 1 or 2, wherein the coordinator is one of the participants or a third party.

5. The method according to any one of claims 1 to 4, wherein each participant has their respective blind key share of the blind key, each share of the MIC is generated based on their respective blind key share, and each share of the MDC is based on their respective blind key share.

6. The method according to any one of claims 1 to 5, wherein the subgroup includes multiple participants, and a) enables one, some, or all of the other participants in the subgroup to utilize the first share of the MIC.

7. The method according to any one of claims 1 to 6, wherein the subgroup includes multiple participants, and each participant within the subgroup receives their respective share of the MIC.

8. The method according to any one of claims 1 to 5, wherein the subgroup consists of the first participant.

9. The method according to any one of claims 1 to 8, wherein the message includes at least a portion of a blockchain transaction.

10. The method according to any one of claims 1 to 9, wherein the size of the group is N ≥ 2t + 1, the size of the subgroup is N - (t + 1), where t is the degree of the polynomial used to derive each participant's respective secret key share, 2t + 1 is the first threshold number, and t + 1 is the second threshold number.

11. The method according to any one of claims 1 to 10, wherein each participant generates the respective secret key share and the respective ephemeral secret key share using JVRSS (joint verifiable random secret sharing scheme).

12. The method according to claim 5 or any one of claims 6 to 11 dependent on claim 5, wherein each participant generates their respective blind key share using JVRSS.

13. The method according to any one of claims 1 to 12, comprising the step of dividing the MIC into a plurality of secondary MIC shares, wherein the step of dividing the MIC is performed using Shamir's secret sharing scheme.

14. The method according to any one of claims 1 to 13, wherein the signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) signature.

15. The respective shares of the aforementioned MICs are: [Math 1] It is generated as, here, k i These are the respective ephemeral secret key shares, and a i These are the respective private key shares, and β i is the respective blind key share, r is the first signature component, and each share of the MDC is [Math 2] The method according to claim 14, which is dependent on claim 5, wherein e is generated as, where e is the hash of the message.

16. Computer equipment, A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising, wherein the memory stores code configured to be executed on the processing device, and the code is configured to perform the method according to any one of claims 1 to 15 when it is on the processing device.

17. A computer program that is implemented on computer-readable storage and, when executed on a computer device, is configured to perform the method according to any one of claims 1 to 15.

Images