Composite elliptic-curve digital signatures

Abstract

The present disclosure relates to a method of securely generating, between a first device and a second device, a composite elliptic curve digital signature Wherein the first device has stored thereon cryptographic means for retrieving a first part of a first elliptic curve secret key share based on a user authentication factor, wherein the second device has stored thereon a second part of the first elliptic curve secret key share, and a second elliptic curve secret key share, wherein the first and second elliptic curve secret key shares are combinable to provide a composite elliptic curve secret key, and wherein respective values of the first part and the second part are determined by splitting the first elliptic curve secret key share such that the first part is retrievable using the cryptographic means and the user authentication factor. The method performed at the first device and comprising: receiving a user input from a user of the first device, the user input corresponding to the user authentication factor; retrieving the first part of the first elliptic curve secret key share using the cryptographic means and the user input; generating a zero-knowledge proof of knowledge of the retrieved first part of the first elliptic curve secret key share; sending, to the second device, the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; receiving, from the second device and responsive to verification of validity of the zero-knowledge proof of knowledge, a masked version of the second part of the first elliptic curve secret key share; generating a first party elliptic curve signature using the first part of the first elliptic curve secret key share and the masked version of the second part of the first elliptic curve secret key share; sending, to the second device, the first party elliptic curve signature; and receiving, from the second device, a composite elliptic curve digital signature generated using the first party elliptic curve signature and the second elliptic curve secret key share.

Description

[0001] Composite elliptic-curve digital signatures Technical Field The present disclosure relates to methods of securely creating, between two devices, a composite elliptic curve digital signature, in particular, signature generation schemes for elliptic curve digital signatures in which the secret key is distributed across multiple devices. Background A digital signature is a scheme for demonstrating the authenticity of a digital message or document(s). If a recipient is able to confirm that a digital signature appended to a digital message is valid then that recipient can reasonably believe that the message was created by a known or trusted sender, that the sender cannot deny having sent the message, and that the message was not altered in transit. Often digital signatures employ asymmetric cryptography in which a sender’s secret key is used to generate a digital signature and in which the sender’s public key is used by a recipient to verify that the digital signature, and any message to which the digital signature relates, originated with the sender. In order for digital signature schemes to work, a sender must be able to store one or more secret keys securely. A sender may, for example, store the one or more secret keys in special hardware, such as a separate memory device or a smart-card. However, in a world in which the use of digital signatures is becoming more prevalent, this proves an expensive and inefficient solution for wide employment of digital signatures. Furthermore, there is a desire to integrate digital signatures with modern technologies such as mobile devices including mobile phones, which a lot of people use for communicating every day. However, mobile devices may not have the capability to physically connect to a card-reader, the connection interfaces often change rapidly, and connecting a card-reader with a mobile phone is inconvenient for a user. Furthermore, the cryptographic algorithms used for digital signatures may become insecure and the key size insufficient. Changing the algorithm or the key size would mostly mean physical replacement of all smart-cards in use. Software is much easier to update. Mobile devices update their software automatically so that the users often do not even notice the updating process. From an economic perspective, digital signature solutions based solely on software are appealing. The hardest thing to solve in software-based digital signature solutions is secret key management. Keys stored in the static memory of a mobile device or any other type of a computer can easily be cloned by attackers who gain access to the memory. With a cloned key, an attacker can create an unlimited amount of forged signatures that are indistinguishable from the genuine signatures used by a genuine sender. Even if secret keys are stored in encrypted form, using passwords as encryption keys, it is possible for attackers to find the right key by using a so-called dictionary attack. With a dictionary attack, an attacker has a dictionary of passwords which they try one by one until the right password is found. For such an 1

[0002] attack to succeed, one needs only for there to be a relatively small number of passwords, and a reference point such that the attacker will know when he has been successful. Practice has shown that human memorisable passwords are too weak to withstand dictionary attacks. The issues outlined above are at least as pronounced when multi-party protocols are considered. For example, a sender may send a (digitally signed) message to a receiver and receive a response. The response may be, for example, an indication that the digitally signed message has been received and understood by the receiver. The sender may accordingly want to verify that the receiver did indeed receive the original digitally signed message (and not some other message) and that the response did indeed come from the receiver. Alternatively, for commercial reasons or otherwise a sender may wish to send a message to a third party such that the third party can rest assured that the message has been verified by a second party. Accordingly, a secure method for co-signing messages is desired. Elliptic curve digital signature algorithms (ECDSAs) are often used in modern cryptography, because they provide a desirable combination of robust security and computational efficiency. ECDSAs are digital signature algorithms (DSAs) which employ elliptic curve cryptography (ECC). One key advantage of ECC is key size relative to cryptographic strength. For example, ECC-based keys can provide cryptographic strength that is equivalent to that obtained with much longer keys in an Rivest–Shamir–Adleman (RSA) cryptosystem. ECDSA protocols for threshold signing in distributed systems exist, in which key distribution schemes help to further improve security. However, the use of such key distribution schemes in existing distributed ECDSA protocols may compromise important security properties for the purposes of electronic identity verification, such as the user retaining sole control of the user’s own secret key material. This property is, for example, required for compliance with the European Union’s Regulation on electronic identification and trust services for electronic transactions in the internal market (eIDAS). In other words, previous work on multi-party ECDSA signatures fail to prevent exhaustive offline guessing attacks. The subject matter of the present disclosure has been developed to address at least some of the problems described above. Summary In a first aspect there is provided a method of securely generating, between a first device (e.g. client device) and a second device (e.g. server device), a composite elliptic curve digital signature, wherein the first device has stored thereon a first part of a first elliptic curve secret key share, wherein the second device has stored thereon a second part of the first elliptic curve secret key share, and a second elliptic curve secret key share, wherein the first and second elliptic curve secret key shares are combinable to provide a composite elliptic curve secret key (e.g. a composite elliptic curve secret key having a corresponding composite elliptic curve public key), and wherein respective values of the first part and the second part are determined by 2

[0003] splitting the first elliptic curve secret key share, wherein the first part is retrievable using a user authentication factor; the method performed at the first device and comprising: receiving a user input from a user of the first device, the user input corresponding to the user authentication factor; based on the user input, retrieving the first part of the first elliptic curve secret key share; generating a zero-knowledge proof of knowledge of the retrieved first part of the first elliptic curve secret key share; sending, to the second device, the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; receiving, from the second device and responsive to verification of validity of the zero-knowledge proof of knowledge (e.g. as verified by the second device), a masked version of the second part of the first elliptic curve secret key share; generating a first party elliptic curve signature (e.g. partial elliptic curve signature) using the first part of the first elliptic curve secret key share and the masked version of the second part of the first elliptic curve secret key share; sending, to the second device, the first party elliptic curve signature; and receiving, from the second device, a composite elliptic curve digital signature generated using the first party elliptic curve signature and the second elliptic curve secret key share. The first elliptic curve secret key share may be split such that the first part and the second part multiplicatively and additively combinable to recover the first elliptic curve secret key share. For example, the first part and the second part may comprise multiplicative or additive shares of the first elliptic curve secret key share. A number of advantages of the present disclosure will be made apparent to the skilled person. For example, in a scenario in which the first device is compromised, an attacker would be unable to carry out a dictionary attack without communicating with the second device. In particular, the splitting of the first secret key share (i.e. the user device’s secret key share) into two parts that are distributed between the first and second device means that what is stored at the first device (i.e. the user device) is not sufficient to perform an exhaustive offline guessing attack. This is because there is an inherent need for communication with the second device (e.g. a secure server device) in order to utilise the full first share of the secret key, and the second device may limit the number of attempts the first device has before all communication is terminated and / or the first device is blacklisted. For example, the second device may initialise a counter; then increase the counter each time an attempt by the first device to utilise or recover the full first share of the secret key fails. Once the counter reaches a threshold value (e.g. three attempts), the first device may be suspended from making further attempts for a period of time, or permanently blocked. Furthermore, the method provided herein integrates verification of a user authentication factor in the cryptographic protocol itself. This integration ensures that the user retains sole control of the first secret key share at all times, which is an important security property in the context of threshold cryptographic signatures and is, for example, required for compliance with the European Union’s Regulation on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation). In a preferred embodiment illustrated herein, this security property is further strengthened with the integration of clone detection techniques in the cryptographic protocol for prevention of replay attacks. The resulting composite digital signature, based on elliptic curve cryptography, may be applied to a message. In such a way, the signature may be used to authenticate the message. The message may comprise data in any digital format. Further, the data may be encoded, for example, according to a known encoding standard for electronic communication. 3

[0004] The user authentication factor may comprise one or more authentication factors, such as a knowledge factor, a biometric or inherence factor, a possession factor, a location factor, a behaviour factor, and / or any other suitable authentication factor. In some implementations, multi-factor authentication may be used, in which case the user authentication factor comprises a combination of multiple authentication factors. In one example, multiple user authentication factors may be used, for example a knowledge factor and a biometric factor, optionally in combination with multi-factor authentication. For example, the user authentication factor may comprise a PIN in combination with a fingerprint scan and facial recognition. The knowledge factor may, for example, comprise a personal identification number (“PIN”) or a password. The biometric factor may comprise, for instance, a fingerprint scan, facial recognition, iris recognition, vein recognition, voice recognition, or any combination thereof. The user authentication factor may be comprised of any combination of knowledge and biometric factors. Therefore, the user input may comprise input associated with one or more authentication factors, such as a knowledge factor, a biometric or inherence factor, a possession factor, a location factor, a behaviour factor, and / or any other suitable authentication factor. In one example, the user input may comprise a knowledge input (e.g. a PIN input) and a biometric input (e.g. a fingerprint scan input). The user input may be deleted upon use, e.g. deleted immediately following its use. For example, the user input may be deleted once the first part of the first elliptic curve secret key share has been retrieved and / or decrypted. The splitting may be done randomly. In this case, the first part of the first elliptic curve secret key share may be securely stored on the first device in encrypted form. The retrieving of the first part of the first elliptic curve secret key share may comprise decrypting the first part of the elliptic curve secret key share based on the user input. The decrypted first part of the first elliptic curve secret key share may be deleted upon use, e.g. deleted immediately following its use. For example, the decrypted first part of the first elliptic curve secret key share may be deleted following generation of the zero-knowledge proof of knowledge of the retrieved first part of the first elliptic curve secret key share. The splitting may comprise splitting based on inputting the user authentication factor into a pseudorandom function. In this case, the pseudorandom function (or a corresponding function, e.g. inverse) may be stored on the first device alongside any additional input parameters to the function, such as a seed or a salt, for recomputing the first part of the first elliptic curve secret key share using the user authentication factor. In such a way, the retrieving of the first part of the first elliptic curve secret key share comprises recovering the first part of the first elliptic curve secret key share based on the user input and the pseudorandom function (or the corresponding function). Retrieval of the first part of the first elliptic curve secret key share may fail. This may happen if the user of the first device is unable to authenticate themselves, e.g. the user input does not correspond to the user authentication factor as is required for successful authentication. In one example, when user authentication is unsuccessful, decryption of the encrypted first part of the first elliptic curve secret key share may fail or return junk data that does not correspond to the first part of the first elliptic curve secret key share. 4

[0005] The first device may have stored thereon a first clone detection bitstring. The second device may have stored thereon a second clone detection bitstring. Sending the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share may further comprise: sending, to the second device, the first clone detection bitstring. The masked version of the second part of the first elliptic curve secret key share may be received from the second device upon verifying, by the second device, the first clone detection bitstring using the second clone detection bitstring. Verifying the first clone detection bitstring using the second clone detection bitstring may comprise verifying that the first clone detection bitstring corresponds to the second clone detection bitstring. The composite elliptic curve secret key may be associated with a corresponding composite elliptic curve public key. The composite elliptic curve public key may be usable to verify the composite elliptic curve digital signature. The first device may have generated a first elliptic curve public key share before initiation of the signing protocol. The first elliptic curve public key share may have been deleted immediately after key generation and before initiation of the signing protocol. The second device may have stored thereon a second elliptic curve public key share. The first and second elliptic curve public key shares may be combinable to provide the composite elliptic curve public key. The method of the first aspect may further comprise receiving, from the second device, the second elliptic curve public key share. The method may further comprise generating the composite elliptic curve public key from the first and second elliptic curve public key shares. The method may further comprise verifying validity of the composite elliptic curve digital signature using the composite elliptic curve public key. The method may further comprise preliminary steps. The preliminary steps may be used to establish the secret key shares and parts thereof which are stored on the device(s). The preliminary steps may comprise: generating the first elliptic curve secret key share and a corresponding first elliptic curve public key share; splitting the first elliptic curve secret key share into the first part and the second part wherein the first part is retrievable using a user authentication factor; sending, to the second device, the second part of the first elliptic curve secret key share; and deleting the first part of the first elliptic curve secret key share and the first elliptic curve public key share. If the splitting is done randomly, the first part of the first elliptic curve secret key share may be securely stored on the first device in encrypted form, which may be decrypted using the user authentication factor. The first part of the first elliptic curve secret key share is not stored in unencrypted form. If the splitting is based on inputting the user authentication factor into a pseudorandom function, the pseudorandom function (or a corresponding function, e.g. inverse) for retrieving the first part of the first elliptic curve secret key share is stored on the first device. The first part of the first elliptic curve secret key share can then be retrieved using the user authentication factor and the pseudorandom function (or the corresponding function). 5

[0006] The preliminary steps may further comprise receiving a user input, the user input corresponding to the user authentication factor. When the user input is initially received in the preliminary steps, it may thereby establish the user authentication factor used as reference for subsequent authentication. The user input may be deleted upon completion of the partitioning of the first elliptic curve secret key share. The preliminary steps may further comprise receiving, from the second device, the first clone detection bitstring. Receiving the composite elliptic curve digital signature may further comprise: receiving, from the second device, a new first clone detection bitstring to replace the previous first clone detection bitstring, and storing the new first clone detection bitstring. In this way, the bitstring(s) may be refreshed, which may in turn improve security against cloning. In a second aspect there is provided a first device configured for securely generating, with a second device, a composite elliptic curve digital signature, the first device comprising a memory and a processor, the processor configured to perform a method according to the first aspect. The first device may for example be a client device. In a third aspect there is provided a computer readable medium having instructions stored thereon which, when executed by a processor, cause the processor to perform a method according to the first aspect. In a fourth aspect there is provided a method of securely generating, between a first device and a second device, a composite elliptic curve digital signature, wherein the first device has stored thereon a first part of a first elliptic curve secret key share, wherein the second device has stored thereon a second part of the first elliptic curve secret key share, and a second elliptic curve secret key share, wherein the first and second elliptic curve secret key shares are combinable to provide a composite elliptic curve secret key (e.g. a composite elliptic curve secret key having a corresponding composite elliptic curve public key), and wherein respective values of the first part and the second part are determined by splitting the first elliptic curve secret key share wherein the first part is retrievable using a user authentication factor; the method performed at the second device and comprising: receiving, from the first device a zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; validating the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; upon determining that the zero- knowledge proof of knowledge of the first part of the first elliptic curve secret key share is valid, sending, to the first device, a masked version of the second part of the first elliptic curve secret key share; receiving, from the first device, a first party elliptic curve signature; generating the composite elliptic curve digital signature using the first party elliptic curve signature and the second elliptic curve secret key share; sending, to the first device, the composite elliptic curve digital signature. As the skilled reader will understand, the method according to the fourth aspect is the complement of the method according to the first aspect. That is, the method according to the first aspect is performed by a first device in communication with a second device configured to perform the method according to the fourth 6

[0007] aspect, and vice versa. Therefore, as the skilled reader will understand, the optional features which apply to the first aspect apply in a corresponding manner to the fourth aspect as well, and vice versa. The method of the fourth aspect may further comprise terminating the method upon determining that the zero-knowledge proof of knowledge is invalid. Accordingly, the signing protocol is not completed, and no signature is generated, if it is determined that the first device does not know the first part of the first secret key share. This may happen, for example, if the first device is acting maliciously, e.g. by attempting to incorrectly guess or pass off junk data as the first part of the first secret key share, or if the user of the first device is unable to authenticate themselves, e.g. the user input does not match or satisfy the reference user authentication factor. In one example, when user authentication is unsuccessful, decryption of the encrypted first part of the first elliptic curve secret key share by the first device may return junk data that does not correspond to the first part of the first elliptic curve secret key share. In another example, when user authentication is unsuccessful, upon attempting to retrieve the first part of the first elliptic curve secret key share using the user input and the pseudorandom function, the function may return junk data that does not correspond to the first part of the first elliptic curve secret key share. The first device may have stored thereon a first clone detection bitstring. The second device may have stored thereon a second clone detection bitstring. Receiving the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share may further comprise: receiving, from the first device, the first clone detection bitstring; and verifying the first clone detection bitstring using the second clone detection bitstring. The masked version of the second part of the first elliptic curve secret key share may be sent to the first device upon verifying the first clone detection bitstring using the second clone detection bitstring. Verifying the first clone detection bitstring using the second clone detection bitstring may comprise verifying that the first clone detection bitstring corresponds to the second clone detection bitstring. The method of the fourth aspect may further comprise terminating the method upon failing to establish a correspondence between the first and the second clone detection bitstrings. The method of the fourth aspect may further comprise: receiving, from the first device, the first elliptic curve public key share; generating the composite elliptic curve public key from the first and second elliptic curve public key shares; verifying validity of the composite elliptic curve digital signature using the composite elliptic curve public key. The method may further comprise preliminary steps. The preliminary steps may be used to establish the secret key shares and parts thereof which are stored on the device(s). The preliminary steps may comprise: generating the second elliptic curve secret key share and a corresponding second elliptic curve public key share; receiving, from the first device, the second part of the first elliptic curve secret key share; and storing the second part of the first elliptic curve secret key share and the second elliptic curve public key share. 7

[0008] The preliminary steps may further comprise: generating the first and second clone detection bitstrings; sending, to the first device, the first clone detection bitstring. The method may further comprise: upon generation of the composite elliptic curve digital signature using the first party elliptic curve signature and the second elliptic curve secret key share, generating a new first clone detection bitstring and a new second clone detection bitstring to replace the previous first and second clone detection bitstrings; sending, to the first device, the new first clone detection bitstring; and storing, at the second device, the new second clone detection bitstring. In a fifth aspect there is provided a second device configured for securely generating, with a first device, a composite elliptic curve digital signature, the second device comprising a memory and a processor, the processor configured to perform a method according to the fourth aspect. The second device may comprise a server device. In a sixth aspect there is provided a computer readable medium having instructions stored thereon which, when executed by a processor, cause the processor to perform a method according to the fourth aspect. In a seventh aspect there is provided a system comprising a first device according to the second aspect and a second device according to the fifth aspect, the first device being in communication with the second device. Brief Description of the Drawings Specific examples of the present disclosure will now be described, with reference to the accompanying drawings, in which: Figure 1 shows an example device architecture of a first party, or client device, and of a second party, or server; Figure 2 shows an example system architecture for generating a composite cryptographic signature between a client device and a server device according to one or more embodiments described herein; Figure 3 is a flowchart of a method for signature creation between a first party and a second party for generating a composite cryptographic signature according to one or more embodiments described herein; and Figure 4 is a flowchart of a method for distributed key generation between a first party and a second party for generating a composite cryptographic signature according to one or more embodiments described herein. Like reference numerals are used for like features throughout the drawings. 8

[0009] Detailed Description Whilst various embodiments of the invention are described below, the invention is not limited to these embodiments, and variations of these embodiments may be made without departing from the scope of the invention. In the below discussion, the terms "client" and "server" are used. These terms are purely to distinguish between two parties that interact, i.e. the client is a first party and the server is a second party. The skilled person would therefore understand that the terms "client" and "server" are not restrictive. In the discussion below, the terms "public" and "secret" are used. In the context of asymmetric key pairs, the skilled person would understand that the public key and the secret key perform inverse operations, and accordingly, a device may use the secret key to sign a message, and another device may use the public key to verify the signature. The skilled person would understand that the secret key is a key that is not openly communicated to other parties, and the skilled person would also understand that a public key is a key that is not a secret key. While a secret key is securely stored, a public key may be knowable to third parties, and may sometimes be openly communicated. For example, a public key may be published in a directory or openly broadcast, or may be a key that an adversary may obtain. A key may be shared between two or more parties, where each party holds a share. In such a scenario, a key can only be reconstructed when a sufficient number (of possibly different types) of shares are combined together. Accordingly, a single share of a key on its own cannot be used to reconstruct the key unless combined with a sufficient number of further shares. A key may be "additively shared" if one or more components of shares must be added together to reconstruct the key. A key may be "multiplicatively shared" if one or more components of shares are multiplied together to reconstruct the key. The skilled person would appreciate that other types of shares exist and are applicable to the following methods. Fig.1 illustrates the hardware components in the architecture of an example system 10. The system 10 comprises a client device 100 and a server device 150. The system 10 further comprises a communication channel 20. The communication channel 20 may be a direct channel or an indirect channel over a communications network. For example, the communication channel 20 may comprise the Internet. A communication channel may be considered secure if an adversary does not have access to data communicated via the communication channel, e.g. communication within a secure environment. As shown in Fig. 1, the client device 100 includes a number of user interfaces including a visual display 110 and a virtual or dedicated user input device 102. The client device 100 further includes a processor 104, a memory 106 and a power system 108. The client device 100 further comprises a communications module 112 for sending and receiving communications between processor 104 and remote devices such as server device 150. For example, the communications module 112 is used for sending and receiving communications across communications channel 20 to a communications module 162 of the server device 9

[0010] 150. The client device further comprises a port 114 for connecting to further systems, or devices, for example a secondary memory device such as a USB stick. The processor 104 is configured to receive data, access the memory 106, and to act upon instructions received either from said memory 106, from communications module 112 from user input device 102. The processor 104 is further configured to process instructions pertaining to encryption and decryption. In this respect, the processor 104 is capable of retrieving one or more secret keys from memory 106 or from some other source such as via communications module 112 or port 114. The processor is further configured to control the display 110 and to control communications to remote parties such as server device 150 via communications module 112. The processor 104 may execute instructions stored in memory 106 in order to encrypt data prior to sending via communications module 112 or in order to decrypt data received from communications module 112. In operation the processor 104 can execute computer-executable instructions stored in the memory 106 and the results of the processing can be displayed to a user on the display 110. User inputs for controlling the operation of the computer may be received via input device(s) 102. Server device 150 comprises a user inputs device 152 a processor 154, a memory 156, a power system 158, a visual display 160, a communications module 162 and a port 164. The communications module 162 is used by the server device to send and receive communications from one or more client devices 100. The processor 154 is configured to receive data, access the memory 156, and to act upon instructions received either from said memory 156, from communications module 162, or from input device 152. The processor 154 is further configured to process instructions pertaining to encryption and decryption. For example, the processor 154 it configured to retrieve public and / or secret keys from memory 156. In operation the processor 154 can execute computer-executable instructions stored in the memory 156 and the results of the processing can be displayed to a user on the display 150. User inputs for controlling the operation of the computer may be received via input device(s) 152. Other architectures to that shown in Figure 1 may be used as will be appreciated by the skilled person. The client device, or first device, and the server device, or second device, may be, for example, a computer, a mobile phone, a tablet, or other device capable of performing a method according to computer-executable instructions.A user of the client device 100 may desire to send a message^^to the server device 150 (which may bein communication with a Relying Party 200 e.g. as shown in Fig.2) in such a way that the server device 150 is able to verify that the message ^^ originated with the client device 100. However, the user of the client device 100 may also desire to receive an acknowledgement that the message ^^ was received by the server device 150 and to be secure in the knowledge that the acknowledgement originated with the server device 150 and not with an adversarial party. For such a purpose, a composite elliptic curve digital signature may be generated using a method such as that set out below, in which the composite elliptic 10

[0011] curve digital signature is generated by the server device 150 from a partial signature of the client device 100. If the client device 100 is able to send message ^^ and information pertaining to its digital signature to server device 150, and to receive an acknowledgement, then the client device 100 may be able to verify that the acknowledgement came from the server device 150 and that the acknowledgement was created using the partial signature of the client device 100. Fig. 2 illustrates the software components of an example system architecture. The system architecture comprises: a client 210, which is operated by a user; a relying party 200, who requests a digital signature from the user; and a digital identity provider 220. More specifically, the digital identity provider 220, as shown in Fig.2, may be comprised of a core server 222 in communication with a core database 240 and with a secure zone server 232. The secure zone server 232 is located within a secure environment 230. The secure zone server 232 is in communication with a secure zone database 234, which is also located within the secure environment 230. In certain implementations, the digital identity provider 220 may instead be comprised of a single server with a secure component, e.g. the secure zone server also acting as core server. In different embodiments, the core server 222, the secure zone server 232, and / or the digital identity provider 220 as a whole may be implemented by server device 150 or, for example, by multiple server devices configured like server device 150. The core server 222 may comprise a relying party service component 224, which handles communication with the relying party 200 (e.g. with provision of APIs servicing the relying party), and a client service component 226, which handles communication with the client 210 (e.g. via APIs servicing the client). As shown in Fig.2, the client 210 may comprise a threshold signature engine component 212. The client 210 may be implemented by client device 100. The threshold signature engine component 212 within the client 210 may interact with the user and allow the user to input a knowledge factor (in the form of a PIN, an alphanumeric password, a drawn pattern or some other form of secret knowledge input) and, possibly, an inherence factor (e.g. the user’s facial image and / or depth measurements, a scan of the user’s fingerprint, etc.). The threshold signature engine component 212 may also generate and store the user’s part of the cryptographic key material. This is the client share of the cryptographic key material which, along with the server’s share, make up the secret key. The secure zone server 232 within the digital identity provider backend may generate the server’s share of the cryptographic key material, which may be stored in the secure zone database 234. The components of Fig.2 communicate with each other and execute the cryptographic protocols for key generation and cryptographic signature creation. Methods performed by the devices of Figs.1 and 2 will now be described. Unless otherwise stated, in the following description, a secret key share is in reference to a secret elliptic curve key share; public key share is in reference to a public elliptic curve key share; a secret key is in reference to a composite secret elliptic 11

[0012] curve key; a public key is in reference to a composite public elliptic curve key; a partial signature is in reference to a partial elliptic curve signature; and a composite signature is in reference to a composite elliptic curve signature. Fig.3 is a flowchart illustrating some of the high-level operations of a method for generating a composite digital signature between a first party (P1) and a second party (P2). P1 may be implemented, for example, by client device 100 according to Fig.1, for example a client device 100 implementing client 210. P2 may be implemented, for example, by server device 150 according to Fig.1, for example by a server device 150 implementing digital identity provider 220. The signature creation protocol presented in Protocol 6 is an example implementation of the method shown in Fig.3. At operation 310, P1 receives the user authentication factor in the form of a PIN as input from the user. Prior to operation 310, P1 may have generated a client random nonce and subsequently used the client random nonce to determine a point R1 on an elliptic curve, as seen in step 1(a) of Protocol 6. At operation 312, P1 retrieves and decrypts the first part of the client secret key share using the received PIN. Operation 312 may be implemented, for example, as step 1(b) of Protocol 6. P1 may additionally determine a corresponding first part of the client public key share based on the first part of the client secret key share, wherein the public key is associated with the secret key, as seen at the first operation in step 1(c) of Protocol 6. At operation 314, P1 generates a zero-knowledge proof of knowledge of the first part of the client secret key share. Operation 314 may be implemented, for example, as step 1(c) of Protocol 6. The proof of knowledge may be, for example, a non-interactive zero-knowledge proof and may be generated directly or via a subroutine (e.g. ℱ ^in Protocol 6). P1 may additionally compute a zero-knowledge commitment of a client share of the composite digital signature using: (i) the point R1 on the elliptic curve, (ii) the client’s clone detection bitstring, and (iii) the message to be signed. The client’s clone detection bitstring may be received from P2 during key generation or at the end of a previous iteration of the method. Where non-interactive zero-knowledge proofs of knowledge are described in the present application, the skilled person will understand that these could be implemented as Schnorr non-interactive zero-knowledge proofs, or as another type of non-interactive zero-knowledge proof, as appropriate. At operation 316, P1 sends to P2 data comprising the client’s clone detection bitstring, and the zero- knowledge proof of knowledge of the first part of the client secret key share. The data may be encrypted. The data may additionally comprise the client’s commitment to the first party share of the composite digital signature. Operation 316 may be implemented, for example, as step 1(d) of Protocol 6. At operation 318, upon receipt of the data sent by P1, P2 proceeds to verify the client’s clone detection bitstring. The client’s clone detection bitstring may be verified by comparing it against the server’s clone detection bitstring. If the verification is unsuccessful, all communication with P1 is ended and, thereafter, 12 P1 may be treated as a malicious party. Operation 318 may be implemented, for example, as step 2(b) of Protocol 6. At operation 320, P2 verifies the validity of the received zero-knowledge proof of knowledge of the first part of the client secret key share. If the proof is not valid, then user must have entered an incorrect PIN and communication with P1 is interrupted. Additionally, a failed authentication attempt may be recorded by P2 by increasing or decreasing the value of a counter. When the counter reaches a predetermined threshold value, the key pair may be revoked to prevent any further authentication attempts by P1. Operation 320 may be implemented, for example, as step 2(a) of Protocol 6. At operation 322, P2 masks the second part of the client secret key share. The second part of the client secret key share is received from the P1 during key generation, and is securely held by P2. Operation 322 may be implemented, for example, as steps 3(a), 3(b), 4(a) and 4(b) of Protocol 6. Hence, masking of the second part of the client secret key share may include: generating a server reshare of the secret key; determining a server reshare of the public key based on the server reshare of the secret key; providing the server reshare of the secret key as P2’s input to a protocol subroutine (e.g. ℱ^^^^^^in Protocol 6) to convert multiplicative shares into additive shares, wherein the subroutine is invoked jointly with P1, who provides input multiplicatively related to P2’s input; receiving P2’s output from the subroutine, P2’s output additively related to P1’s output; generating a masking value (e.g. value ^^ in Protocol 6); computing a hash identifier (e.g. value hid in Protocol 6) based at least in part on the masking value and P2’s output from the subroutine; generating a second party random nonce; and using the first party random nonce to determine a point R2 on the elliptic curve. The server reshare of the secret key may be a further server share of the secret key different from the server secret key share. The server reshare of the secret key may be generated according to a key sharing schedule comprising different round key shares for each round of communication. At operation 324, P2 sends to P1 data corresponding to the masked version of the second part of the client secret key share. Operation 324 may be implemented, for example, as step 4(c) of Protocol 6. Hence, © data sent to P1 may include: the point R2 on the elliptic curve; the server reshare of the public key; the masking value; the hash identifier. The data may be encrypted. P2 may additionally generate a non- interactive zero-knowledge proof of knowledge of the second party random nonce and send it to P1 (directly, or via a subroutine, e.g. ℱ^^^^^^^^^^in Protocol 6). At operation 326, upon receiving the data sent by P2, a partial signature is generated by P1 using the received data corresponding to the masked version of the second part of the client secret key share. Operation 326 may be implemented, for example, as steps 5(a)-5(e) of Protocol 6. Hence, the partial signature may be generated using a client reshare of the secret key obtained from the first part of the client secret key share and the hash identifier. The client reshare of the secret key may be a further client share of the secret key different from the client secret key share. The client reshare of the secret key may be generated according to the key sharing schedule. Before generation of the partial signature, P1 may additionally verify the zero-knowledge proof of knowledge of the second party random nonce received from 13 P2 (directly, or via a subroutine, e.g. ℱ^^^^^^^^^^in Protocol 6). If the verification fails, P1 may abort the generation of the partial signature. At operation 328, P1 sends to P2 data comprising the partial signature generated by P1. Operation 328 may be implemented, for example, as step 5(f) of Protocol 6. The data may be encrypted. The data may additionally include: the point R1 on the elliptic curve; the client clone detection bitstring; and the message to be signed. P1 may additionally generate a non-interactive zero-knowledge proof of knowledge of the first party random nonce and send it to P2 (directly, or via a subroutine, e.g. ℱ^^^^^^^^^^in Protocol 6). At operation 330, P2 generates a composite digital signature using the client-generated partial signature and the server secret key share. Operation 330 may be implemented, for example, as steps 6(a)-6(d) (not including the signature verification in 6(d), but only the generation of the signature value) of Protocol 6. The composite digital signature may be generated only after P2 successfully verifies that there has been no tampering with the point R1 on the elliptic curve, the client clone detection bitstring, and the message to be signed. This can be verified by, for example, verifying the commitment opening of the client share of the composite digital signature previously received from P1. Before generation of the composite digital signature, P2 may additionally verify the zero-knowledge proof of knowledge of the first party random nonce received from P1 (directly, or via a subroutine, e.g. ℱ^^^^^^^^^^in Protocol 6). If any of the verifications fail, P2 may abort the generation of the composite digital signature and terminate all communication with P1. At operation 332, upon generation of the composite digital signature, P2 may verify with the composite public key that the composite digital signature was correctly generated. P2 may additionally generate a new clone detection bitstring to replace the client’s clone detection bitstring. Operation 332 may be implemented, for example, as steps 6(d)-6(e) (not including the signature generation in 6(d), but only the verification) of Protocol 6. At operation 334, P2 sends to P1 data comprising the composite digital signature generated by P2. The data may additionally include the new clone detection bitstring. The data may be encrypted. Operation 334 may be implemented, for example, as step 6(f) of Protocol 6. At operation 336, upon receipt of the data sent by P2, P1 may verify the composite digital signature using the composite public key. The composite public key may be obtained by combining the client public key share and the server public key share. P1 may additionally replace the client’s clone detection bitstring with the new clone detection bitstring received from P2, as seen in step 6(g) of Protocol 6. Variations of the described arrangements are envisaged. For example, the features of all of the disclosed arrangements may be combined in any way. In the examples provided above, the server has been described as sending the composite digital signature to the client device. However, other scenarios are envisaged. For example, the server may send the composite signature to a digital repository for storage or may send the composite signature to a third party. For example, one may consider that a first party, or client, device may operate to send a 14

[0013] message to a third party device, and that the third party will only accept the message if it has been verified by a second party, or server. Accordingly the first party and second party may generate a composite signature according to any method as described herein, and the trusted second party may communicate the composite signature to the third party. The third party may use a public key to verify the composite signature and thereby trust that the message from the first party has indeed been verified by the second party. The skilled person would envisage other scenarios in which such operation would be useful. It is envisaged that in some circumstances no verification takes place at the server and / or the client device. For example, the server may simply process data received and issue a purported composite signature in accordance with a method as disclosed herein with no verification that the original received data originated at the client device. For convenience, in the descriptions provided above, a message ^^ was sent across a communication channel. The communication channel may be any suitable communication channel such as a radio connection or the internet. The communication channel may involve a level of encryption. The message ^^ may be a hashed and / or padded message. Any suitable hash function may be used. The message may be in any suitable format understood by a computing device. Fig 4 is a flowchart of a method for distributed key generation between a first party (P1) and a second party (P2). P1 may be implemented, for example, by client device 100 implementing client 210. P2 may be implemented, for example, by server device 150 implementing digital identity provider 220. Fig.4 illustrates some of the high-level operations carried out during key generation. The key generation protocol presented in Protocol 5 is an example implementation of the key generation method shown in Fig.4. The method of Fig 4 may be performed during manufacture to configure the distributed system for generating a composite digital signature, or may be performed at the time of signing. The method of Fig.4 may therefore precede the method of Fig.3. For example, the method of Fig.3 may be performed using distributed elliptic curve public and secret key shares which themselves were determined using a method according to Fig.4. At operation 410, P1 randomly generates the client secret key share and computes the client’s corresponding public key share. Operation 410 may be implemented, for example, as step 1(a) of Protocol 5. At operation 412, P1 receives the reference user authentication factor (PIN) as input from the user, as seen at the first operation in step 1(b) of Protocol 5. At operation 414, P1 splits the client secret key share into a first part and a second part based on the reference PIN. Operation 414 may be implemented, for example, as step 1(b) of Protocol 5. P1 may additionally compute the corresponding first and second parts of the client public key share, as seen at the first operation in step 1(c) of Protocol 5. 15

[0014] At operation 416, P1 generates a zero-knowledge proof of knowledge of the first part of the client secret key share. Operation 416 may be implemented, for example, as the second operation in step 1(c) of Protocol 5. At operation 418, P1 send to P2 data associated with: the client public key share; the second part of the client secret key share; the proof of knowledge. In some implementations, the data may include only a commitment to the values of: the client public key share, the first part of the client public key share and the second part of the client secret key share. Such implementations feature additional steps that further improve security during key generation by performing additional checks. These additional steps, corresponding to steps 1(d), 3(a), 3(b) and 4(a) in Protocol 5, have been omitted in Fig.4. Operation 418 may be implemented, for example, as step 1(d) of Protocol 5. At operation 420, P2 randomly generates the server secret key share and computes the server’s corresponding public key share. Operation 420 may be implemented, for example, as step 2(a) of Protocol 5. At operation 422, P2 generates the client and server clone detection random bitstrings. In some implementations, the client and server clone detection bitstrings may be copies of the same bitstring. Operation 422 may be implemented, for example, as step 2(b) of Protocol 5. At operation 424, P2 verifies the proof of knowledge of the first part of the client secret key share sent by P1 at operation 418. Operation 424 may be implemented, for example, as step 4(b) of Protocol 5. In some implementations, there may be additional steps and security checks between operations 418 and 424. These additional steps, corresponding to steps 3(a), 3(b) and 4(a) in Protocol 5, have been omitted in Fig. 4. At operation 426, P2 initialises the counter for tracking the number of incorrect PIN guessing attempts made by the user. Operation 426 may be implemented, for example, as step 4(c) of Protocol 5. P2 may also set a threshold value for the counter after which no more attempts are allowed. For example, to allow a maximum of three consecutive incorrect attempts, the counter may be initialised at 3 and decreased each time an incorrect attempt is made until it reaches the threshold value of 0. The counter may be reset after a successful attempt. At operation 428, P2 sends to P1 data comprising: the server public key share; the client clone detection bitstring. The data may be encrypted. In those implementations with additional security checks, operation 428 may be executed prior to operation 424. This can be seen, for example, in Protocol 5, in which operation 428 is carried out at step 2(c). At operation 430, upon receipt of the data from P2, P1 may compute the composite ECDSA public key and store it in memory. P1 may also store in memory the client clone detection bitstring. Operation 430 may be implemented, for example, as step 5(a) of Protocol 5. 16

[0015] At operation 432, P2 may compute the composite ECDSA public key and securely store it in memory. Further, P2 may securely store: the second part of the client secret key share; the server secret key share; and the server clone detection bitstring. P2 may additionally delete other values received or generated during the key generation protocol. Operation 432 may be implemented, for example, as step 5(b) of Protocol 5. The described methods may be implemented by a computer program. The computer program, which may be in the form of a web or native application, comprises computer-executable instructions or code arranged to instruct or cause a computer or processor to perform one or more functions of the described methods. The computer program may be provided to an apparatus, such as a computer, on a computer readable medium or computer program product. The computer readable medium or computer program product may comprise non-transitory media such as a semiconductor or solid state memory, magnetic tape, a removable computer memory stick or diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disc, and an optical disk, such as a CD-ROM, CD-R / W, DVD or Blu-ray. The computer readable medium or computer program product may comprise a transmission signal or medium for data transmission, for example for downloading the computer program over the Internet. An apparatus or device such as a computer may be configured to perform one or more functions of the described methods. The apparatus or device may comprise a mobile phone, tablet, laptop or other processing device. The apparatus or device may take the form of a data processing system. The data processing system may be a distributed system. For example, the data processing system may be distributed across a network or through dedicated local connections. The apparatus or device typically comprises at least one memory for storing the computer-executable instructions and at least one processor for performing the computer-executable instructions. Example implementation Below is provided an example implementation of an ECDSA-based embodiment including a key generation protocol and a signature creation protocol. The protocols are run between a first party and a second party. The first party corresponds to the client 210 and is implemented as a mobile device (phone) operated by a user. The second party corresponds to the digital identity provider 220 and, for simplicity, is implemented by a single server device 150. In this simplified embodiment, the user authentication factor comprises a single user knowledge factor in the form of a PIN. Further, in this embodiment, clone detection bitstrings are used to implement the clone detection techniques used in preferred embodiments for prevention of replay attacks. Key generation protocol The formal description of this key generation protocol is presented in Protocol 5 and briefly summarised below. This key generation protocol is an example implementation of the method for distributed key generation between a first party and a second party shown in Fig.4. 17 The client (phone) C starts by generating its share of the secret key ^^1, computing a corresponding public key share ^^1, and producing ^^^^1as proof of knowledge . Next, the client splits ^^1into ^^′1(that isderived from PIN) and (that will be stored on the server), which ensures that adversariescannot perform offline guessing attacks on user’s PIN. The client receives the PIN as input from the userand derives key share^^′1using Algorithm 4 with PIN and bitstring^^as input. The client proceeds tocompute corresponding public key share ^^′1and to produce ^^′^^1as proof of knowledge of ^^′1. With thefirst message, the client commits to values ^^^^^^ = ^^1,^^′1,^^′′,^^^^1 ,^ ^ . The server generates its share ofthe secret key ^^2, public key ^^2, and produces ^^^^2as proof of knowledge of ^^2. The server then generates clone detection string ^^, which the client is supposed to send during the signing protocol to flag to the server when the client device’s memory has been copied by an adversary. The server sends ^^2, ^^, ^^^^2to the phone. The phone verifies proof ^^^^2and sends an opening to the commitment ^^^^^^. Upon receiving the opening, the server verifies the commitment, the proofs and that the relation between the public key shares holds. The server initiates a counter ^^ for tracking the number of incorrect PIN attempts made by the user. Finally, both client and server calculate the composite public key ^^. The client device stores only ^^, ^^, ^^ and must securely delete all the remaining values received or generated during the key generation protocol. This eliminates all values that an adversary could use to inform and improve any PIN guessing attempts, thereby preventing offline guessing attacks. 18 Signature creation protocol

[0016] The formal description of the signature creation protocol is presented in Protocol 6 and briefly summarised below. The signature creation protocol is an example implementation of the method for generating a composite digital signature between a first party and a second party shown in Fig. 3.

[0017] When establishing this channel, the server gets authenticated to the client, but the client does not get authenticated to the server. Therefore, with the first message of the signing protocol the client authenticates to the server by sending the proof of knowledge of x\, the secret key part derived from the user-supplied PIN. In case of abort message 1 sent by the server, the counter is increased T = T + 1. After one successful signature generation, server resets T = 0. In any case, if T = To, the server does not participate in any future communication with the client. Additionally, with the first message, the client sends w that was stored from the previous signing query. Next, the client and the server invoke a multiplicative- to-additive function with inputs k\ and x2, the function returning tcto client and tsto the server, such that tc+ ts= k^ - x*2- The server proceeds to calculate values for a consistency check (generating y, computing hid) and to send both values to the client. The client checks consistency by verifying that (tc+ hid) • G = (y + k±) • Qz ~ (JQ ~ Q'i)- If the consistency check passes and the proof of knowledge of k2also checks out, the client calculates a partial signature and sends it to the server along with as proof of knowledge of k^. If the commitment opening and the proof check out, the server computes final signature s using partial signature supplied by the client. After verifying signature (r, s), the server generates a new clone detection bitstring w' and sends it to the client along with the signature.

[0018] The skilled reader will appreciate that there could be multiple implementation options for the MtA function used in the protocol. In one example, the function is implemented using Paillier encryption. In another example, the function is implemented using Oblivious Transfer libraries. Annexes – schematic representations of example protocols 21

[0019] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to specific example implementations, it will be recognized that the disclosure is not limited to the implementations described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. 23

Claims

Claims 1. A method of securely generating, between a first device and a second device, a composite elliptic curve digital signature, wherein the first device has stored thereon cryptographic means for retrieving a first part of a first elliptic curve secret key share based on a user authentication factor, wherein the second device has stored thereon a second part of the first elliptic curve secret key share, and a second elliptic curve secret key share, wherein the first and second elliptic curve secret key shares are combinable to provide a composite elliptic curve secret key, and wherein respective values of the first part and the second part are determined by splitting the first elliptic curve secret key share such that the first part is retrievable using the cryptographic means and the user authentication factor; the method performed at the first device and comprising: receiving a user input from a user of the first device, the user input corresponding to the user authentication factor; retrieving the first part of the first elliptic curve secret key share using the cryptographic means and the user input; generating a zero-knowledge proof of knowledge of the retrieved first part of the first elliptic curve secret key share; sending, to the second device, the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; receiving, from the second device and responsive to verification of validity of the zero- knowledge proof of knowledge, a masked version of the second part of the first elliptic curve secret key share; generating a first party elliptic curve signature using the first part of the first elliptic curve secret key share and the masked version of the second part of the first elliptic curve secret key share; sending, to the second device, the first party elliptic curve signature; and receiving, from the second device, a composite elliptic curve digital signature generated using the first party elliptic curve signature and the second elliptic curve secret key share.

2. The method of claim 1, wherein: the splitting is done randomly; the cryptographic means comprise an encrypted version of the first part of the first elliptic curve secret key share, the encrypted version decryptable based on the user authentication factor; and the retrieving of the first part of the first elliptic curve secret key share comprises decrypting the encrypted version of the first part of the first elliptic curve secret key share based on the user input; or wherein: the splitting is based on the user authentication factor; the cryptographic means comprise a pseudorandom function for computing the first part of the first elliptic curve secret key share based on the user authentication factor; and 24the retrieving of the first part of the first elliptic curve secret key share comprises computing the first part of the first elliptic curve secret key share based on the user input and the pseudorandom function.

3. The method of any preceding claim, wherein the user input is deleted upon use.

4. The method of any preceding claim, wherein: the first device has stored thereon a first clone detection bitstring; the second device has stored thereon a second clone detection bitstring; and sending the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share further comprises: sending, to the second device, the first clone detection bitstring.

5. The method of claim 4, wherein the masked version of the second part of the first elliptic curve secret key share is received from the second device upon verifying, by the second device, the first clone detection bitstring using the second clone detection bitstring, and wherein verifying the first clone detection bitstring using the second clone detection bitstring comprises verifying that the first clone detection bitstring corresponds to the second clone detection bitstring.

6. The method of any preceding claim, wherein the composite elliptic curve secret key is associated with a corresponding composite elliptic curve public key, the composite elliptic curve public key usable to verify the composite elliptic curve digital signature.

7. The method of claim 6, wherein: the second device has stored thereon a second elliptic curve public key share, the second elliptic curve public key share combinable with a first elliptic curve public key share to provide the composite elliptic curve public key.

8. The method of claim 7, further comprising: receiving, from the second device, the second elliptic curve public key share; generating the composite elliptic curve public key from the first and second elliptic curve public key shares; verifying validity of the composite elliptic curve digital signature using the composite elliptic curve public key.

9. The method of any preceding claim, further comprising preliminary steps of: generating the first elliptic curve secret key share and a corresponding first elliptic curve public key share; splitting the first elliptic curve secret key share into the first part and the second part such that the first part is retrievable using the cryptographic means and the user authentication factor; sending, to the second device, the second part of the first elliptic curve secret key share; and 25storing the cryptographic means for retrieving the first part of the first elliptic curve secret key share.

10. The method of claim 9, wherein the preliminary steps further comprise: receiving, from the second device, the first clone detection bitstring.

11. The method of claim 10, wherein receiving the composite elliptic curve digital signature further comprises: receiving, from the second device, a new first clone detection bitstring to replace the previous first clone detection bitstring, and storing the new first clone detection bitstring.

12. A first device configured for securely generating, with a second device, a composite elliptic curve digital signature, the first device comprising a memory and a processor, the processor configured to perform a method according to any preceding claim.

13. A computer readable medium having instructions stored thereon which, when executed by a processor, cause the processor to perform a method according to any preceding claim.

14. A method of securely generating, between a first device and a second device, a composite elliptic curve digital signature, wherein the first device has stored thereon cryptographic means for retrieving a first part of a firstelliptic curve secret key share based on a user authentication factor,wherein the second device has stored thereon a second part of the first elliptic curve secret key share, and a second elliptic curve secret key share, wherein the first and second elliptic curve secret key shares are combinable to provide a composite elliptic curve secret key, and wherein respective values of the first part and the second part are determined by splitting the first elliptic curve secret key share such that the first part is retrievable using the cryptographic means and the user authentication factor; the method performed at the second device and comprising: receiving, from the first device a zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; validating the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share; upon determining that the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share is valid, sending, to the first device, a masked version of the second part of the first elliptic curve secret key share; receiving, from the first device, a first party elliptic curve signature; generating the composite elliptic curve digital signature using the first party elliptic curve signature and the second elliptic curve secret key share; 26sending, to the first device, the composite elliptic curve digital signature.

15. The method of claim 14, further comprising terminating the method upon determining that the zero-knowledge proof of knowledge is invalid.

16. The method of claim 14 or claim 15, wherein: the first device has stored thereon a first clone detection bitstring; the second device has stored thereon a second clone detection bitstring; and receiving the zero-knowledge proof of knowledge of the first part of the first elliptic curve secret key share further comprises: receiving, from the first device, the first clone detection bitstring; and verifying the first clone detection bitstring using the second clone detection bitstring.

17. The method of claim 16, wherein the masked version of the second part of the first elliptic curve secret key share is sent to the first device upon verifying the first clone detection bitstring using the second clone detection bitstring, and wherein verifying the first clone detection bitstring using the second clone detection bitstring comprises verifying that the first clone detection bitstring corresponds to the second clone detection bitstring.

18. The method of claim 17, further comprising terminating the method upon failing to establish a correspondence between the first and the second clone detection bitstrings.

19. The method according to any of claims 14 to 18, wherein the composite elliptic curve secret key is associated with a corresponding composite elliptic curve public key, the composite elliptic curve public key usable to verify the composite elliptic curve digital signature.

20. The method of claim 19, wherein: the second device has stored thereon a second elliptic curve public key share, the second elliptic curve public key share combinable with a first elliptic curve public key share to provide the composite elliptic curve public key.

21. The method according to any of claims 14 to 20, further comprising: receiving, from the first device, the first elliptic curve public key share; generating the composite elliptic curve public key from the first and second elliptic curve public key shares; verifying validity of the composite elliptic curve digital signature using the composite elliptic curve public key.

22. The method according to any of claims 14 to 21, further comprising preliminary steps of: generating the second elliptic curve secret key share and a corresponding second elliptic curve public key share; receiving, from the first device, the second part of the first elliptic curve secret key share; and 27storing the second part of the first elliptic curve secret key share and the second elliptic curve public key share.

23. The method of claim 22, wherein the preliminary steps further comprise: generating the first and second clone detection bitstrings; sending, to the first device, the first clone detection bitstring; and storing, at the second device, the second clone detection bitstring.

24. The method of claim 23, further comprising: upon generation of the composite elliptic curve digital signature using the first party elliptic curve signature and the second elliptic curve secret key share, generating a new first clone detection bitstring and a new second clone detection bitstring to replace the previous first and second clone detection bitstrings; sending, to the first device, the new first clone detection bitstring; and storing, at the second device, the new second clone detection bitstring.

25. A second device configured for securely generating, with a first device, a composite elliptic curve digital signature, the second device comprising a memory and a processor, the processor configured to perform a method according to any of claims 14 to 24.

26. A computer readable medium having instructions stored thereon which, when executed by a processor, cause the processor to perform a method according to any of claims 14 to 25. 28

Images