Dongles and method for providing a digital signature

Abstract

Set of two or more dongles for providing a digital signature, wherein each dongle holds a secret key, wherein each dongle is configured to receive a message, to compute a digital signature of the received message using the secret key, and to transmit the computed digital signature, wherein at least one of the dongles is configured to, before computing the digital signature, verify the presence of at least one other dongle belonging to the set, and to compute the digital signature only upon successful verification of the presence of one or more other dongles.

Claims

1. A set of dongles for providing a digital signature, wherein the set comprises a first dongle and at least one other dongle, wherein the first dongle and the at least one other dongle each hold a secret key, wherein the first dongle and the at least one other dongle are each configured to receive a message, to compute a digital signature of the received message using the secret key, and to transmit the computed digital signature, wherein the first dongle is configured to, before computing the digital signature, verify the presence of the at least one other dongle, wherein the first dongle is configured to compute the digital signature responsive to a successful verification by the first dongle of the presence of the at least one other dongle, and wherein the first dongle stores a lower limit of the number of other dongles, the presence of which must be proven, before computing the digital signature.

2. The set according to claim 1, wherein the first dongle is configured to verify the presence of the at least one other dongle by requiring a zero-knowledge proof.

3. The set according to claim 1, wherein the first dongle is configured to measure the time required for verifying the presence of the at least one other dongle and to compute the digital signature only upon successful verification of the presence of the at least one other dongle within a predefined timeframe for each of the at least one other dongle.

4. The set according to claim 1, wherein the first dongle and the at least one other dongle are configured to establish direct wireless connections between each other for verification of presence, and wherein the first dongle is configured to measure the signal strength of the wireless connection to the at least one other dongle and to compute the digital signature in response to the signal strength exceeding a predefined minimum signal strength and/or a distance measure derived from the signal strength being below a predefined maximum distance for each of the at least one other dongle.

5. The set according to claim 1, wherein the at least one other dongle is configured to verify the presence of a mobile terminal before confirming its own presence to the first dongle.

6. The set according to claim 5, wherein the mobile terminal is configured to confirm its presence only within a limited timeframe after authentication of a user of the mobile terminal.

7. A method for providing a digital signature with a first dongle belonging to a set of dongles for providing a digital signature, wherein the set comprises the first dongle and at least one other dongle, and wherein the first dongle and the at least one other dongle each hold a secret key, the method comprising the following steps carried out by the first dongle: receiving a message to be signed; verifying the presence of a total number of the at least one other dongle, the total number being greater or equal to a predefined lower limit; computing a digital signature of the message using the secret key responsive to a successful verification of the presence of as many of the at least one other dongle as defined by the predefined lower limit; and transmitting the computed digital signature.

8. The method according to claim 7, wherein the step of verifying the presence of the at least one other dongle requires a zero-knowledge proof, including: sending a request for providing the zero-knowledge proof to the at least one other dongle, receiving a zero-knowledge proof from the at least one other dongle, verifying the received zero-knowledge proof, and completing a successful verification of the received zero-knowledge proof.

9. The method according to claim 7, wherein: measuring, during verifying the presence of the at least one other dongle, the time required for verifying the presence, and computing the digital signature of the received message responsive to determining that the measured time is within a predefined timeframe for each of the at least one other dongle.

10. The method according to claim 7, comprising: measuring the signal strength of a wireless connection to the at least one other dongle, and computing the digital signature of the received message responsive to determining that the measured signal strength exceeds a predefined minimum signal strength and/or a distance measure derived from the measured signal strength is below a predefined maximum distance for each of the at least one other dongle.

11. The method according to claim 8, comprising the following steps carried out by a second dongle, wherein the second dongle is one of the at least one other dongle: verifying the presence of a mobile terminal connected to the second dongle; and sending a reply to the request for providing a zero-knowledge proof to the first dongle responsive to a successful verification by the second dongle of the presence of the mobile terminal.

12. The method according to claim 5, comprising: authenticating a user of the mobile terminal; and sending the reply to the request for providing a zero-knowledge proof to the first dongle responsive to a successful authentication of the user of the mobile terminal.

13. The set according to claim 5, wherein the mobile terminal is configured to confirm its presence only within a limited timeframe after a biometric authentication of a user of the mobile terminal.

14. The method according to claim 12, comprising: authenticating a user of the mobile terminal using at least partially biometric credentials.

15. The set according to claim 1, wherein the first dongle is configured to verify the presence of a mobile terminal before computing the digital signature and wherein the first dongle is configured to compute the digital signature responsive to a successful verification by the first dongle of the presence of one or more of the other dongles as well as the presence of the mobile terminal.

16. The set according to claim 15, wherein the mobile terminal is configured to confirm its presence only within a limited timeframe after a biometric authentication of a user of the mobile terminal.

17. The method according to claim 7, comprising the following steps carried out by the first dongle: verifying the presence of a mobile terminal connected to the first dongle, and computing the digital signature of the message responsive to a successful verification by the first dongle of the presence of one or more of the other dongles as well as the presence of the mobile terminal.

18. The method according to claim 17, comprising: authenticating a user of the mobile terminal, and computing the digital signature of the message responsive to a successful verification by the first dongle of the presence of one or more of the other dongles as well as a successful authentication of the user of the mobile terminal.

19. The method according to claim 18, comprising: authenticating a user of the mobile terminal using at least partially biometric credentials.

Description

BRIEF DESCRIPTION OF THE FIGURES

(1) Referring now to the drawings, wherein the figures are for purposes of illustrating the present invention and not for purposes of limiting the same:

(2) FIG. 1 schematically shows a use-case of a set of three dongles according to the present invention;

(3) FIG. 2 shows a sequence diagram of the procedure for providing a digital signature according to the present invention using two of the dongles shown in FIG. 1; and

(4) FIG. 3 shows a partial sequence diagram illustrating an extension of FIG. 2 using the third dongle and the mobile terminal shown in FIG. 1.

DETAILED DESCRIPTION

(5) The use-case schematically illustrated by FIG. 1 involves a set s of three dongles a, b, c. Each of the dongles a, b, c is configured to provide a digital signature S.sub.i(M) of a message M (compare FIG. 2), wherein S.sub.i(M)=S(M,K.sub.i) and K.sub.i is a secret key held by dongle i and wherein i is one of a, b or c. The secret key K.sub.i is a secret information that is securely stored on the respective dongle i. It can be generated at random locally on the dongle i during an initialisation procedure and preferably never leaves the dongle i. Therefore, each dongle i in general holds a different secret key K.sub.i.

(6) The dongles a, b, c are mobile (battery-powered), portable devices that fit into a pocket. Typically, owners O.sub.i (i.e. O.sub.a, O.sub.b, O.sub.c) of dongles i used for high-security applications are required to carry their respective dongle i with them at all times. This is to ensure that each dongle i remains under the exclusive control of its respective owner O.sub.i. This situation is indicated in FIG. 1 by circles limiting the scope of control C.sub.i of each dongle i. The same applies essentially to a host h, its owner O.sub.h and scope of control C.sub.h.

(7) As is shown in FIG. 1, each dongle i is connected to the host h, which is a separate computer, for example a workstation or laptop. The connections 1, 2, 3 are wireless connections, for example using Bluetooth technology. Alternatively, one or more of the dongles i may be connected to the host h using a wired connection, such as a USB connection. The dongles i are connected to each other by additional, direct wireless connections 4, 5, for example also using Bluetooth technology. Although only a direct connection 4 between dongle a and dongle b as well as a direct connection 5 between dongle a and dongle c are indicated in FIG. 1, there can be an additional direct connection between dongle b and dongle c. Each dongle i comprises a physical button 6 that can be pressed by its respective owner O.sub.i. Dongle c has an additional (third) wireless connection 7 to a mobile terminal T.sub.c associated with this dongle c. The mobile terminal T.sub.c is a personal smartphone of the owner O.sub.c of dongle c. The mobile terminal T.sub.c comprises a screen 8 and a fingerprint sensor 9. Other biometric sensors might be included with the mobile terminal T.sub.c, such as sensors for performing face recognition and/or voice recognition. In general, those biometric sensors are configured to authenticate the owner O.sub.c of the dongle c.

(8) The host h is connected over a network 10 with a database 11. The database 11 represents a public transaction directory that is accessible online, i.e. via the Internet. The database 11 is preferably a distributed public transaction directory, preferably a distributed blockchain of the type used for securing transactions of digital currencies (e.g. Bitcoin or Ethereum).

(9) Each dongle i is configured to receive a message M from the host h over a wireless connection 1, 2, 3 using suitable wireless transmission components (e.g. a Bluetooth transceiver) of a type widely available. Similarly, each dongle i is configured to transmit a computed digital signature S.sub.i(M) with or without a copy of the message M back to the host h over a wireless connection 1, 2, 3. Moreover, each dongle i is configured to compute a digital signature S.sub.i(M) of the received message M using the secret key K.sub.i. Typically, the secret key K.sub.i is stored in a secure element that is configured to accept messages M and return corresponding signatures S.sub.i(M), which are cryptographically derived from the accepted message M and the secret key K.sub.i. The secret key K.sub.i itself therefore never has to leave the secure element or become known outside the secure element. The secure element is preferably a secure cryptoprocessor.

(10) Each dongle i is further configured to verify the presence of one or both of the two other dongles i as will be explained in more detail in connection with FIG. 2. Only if this procedure of verification of presence is successful, because all required conditions have been tested and are found to be met, the dongle i will proceed to compute the digital signature S.sub.i(M). Preferably, some or all of those conditions are tested within the secure element of the respective dongle i. In the present example, dongle a is configured to verify the presence of dongle b belonging to the same set s by requiring a zero-knowledge proof. The required zero-knowledge proof is a digital signature S(R.sub.a,I.sub.b) of a random challenge R.sub.a generated by dongle a and transmitted to dongle b over connection 4, and using the private identity I.sub.b of dongle b. Dongle b is configured to provide the required zero-knowledge proof and compute the digital signature S(R.sub.a,I.sub.b) only within a limited timeframe 12 following reception of a signing trigger 13. The private identity I.sub.b is a further secret key that is preferably stored within the same secure element of the dongle b as the secret key K.sub.b. The signing trigger 13 can be activated by the owner O.sub.b of dongle b by pressing button 6 of the dongle b. The dongle a requiring the zero-knowledge proof stores the identities P(I.sub.i) of the other two dongles b and c belonging to the same set, i.e. P(I.sub.b) and P(I.sub.c). Here the identities P(I.sub.i) are public keys corresponding to the respective private identity I.sub.i and cryptographically derived therefrom. Since the presence is a condition for computing the digital signature S.sub.a(M), the zero-knowledge proof in the form of the digital signature S(R.sub.a,I.sub.b) is preferably verified by the secure element. Hence, the identities P(I.sub.i) including the identity P(I.sub.b) required for verifying the signature S(R.sub.a,I.sub.b) is preferably stored inside the same secure element as the secret key K.sub.a. In order to avoid any outside control over the verification of presence, also the random challenge R.sub.a is preferably generated by this secure element, which will verify the signature S(R.sub.a,I.sub.b).

(11) Generally, not all dongles i of a set s need to be present and have their presence verified for any one dongle i to provide a digital signature S.sub.a(M); the presence of a subset might be sufficient, e.g. in case of an M-of-N multi-signature where M is smaller than N and N is the total number of dongles i within the same set s. In the example shown in FIG. 2, dongles a and b verify and require the presence of one dongle before providing the requested signature; i.e. in this situation, dongle c need not be present for dongles a and b to provide their respective signatures S.sub.a(M) and S.sub.b(M) to the host h. Alternatively, dongle a and/or dongle b may store a lower limit of the number of other dongles, the presence of which must be proven, before computing the digital signature. In the use-case shown in FIG. 1, this lower limit may be either one or two. If dongle a stores a lower limit of two, it will attempt verification of both other dongles b and c and will compute the digital signature S.sub.a(M) only after the presence of both of them has been verified (e.g. both have provided a proof of presence in the form of a digital signature S(R.sub.a,I.sub.b) or S(R.sub.a,I.sub.c) respectively).

(12) Dongle a is also configured to measure the time required for verifying the presence of dongle b. In detail, it is configured to measure the round-trip delay time D(a,b) between sending the random challenge R.sub.a and receiving the digital signature S(R.sub.a,I.sub.b). Only if the delay time D(a,b) is within a predefined timeframe, for example 2 milliseconds (ms), and the digital signature S(R.sub.a,I.sub.b) is valid, will dongle a proceed to compute the digital signature S.sub.a(M). As this condition is preferably tested within the secure element, the secure element preferably comprises a clock and—optionally—a internal power supply to reliably power the clock. If the proof of presence in the form of the digital signature S(R.sub.a,I.sub.b) arrives later, for example after 3 ms, dongle a will not compute the digital signature S.sub.a(M) of the message M. The timeframe is effectively an upper limit on the round-trip delay time D(a,b) and functions as a distance measure between the secure elements of the dongles a and b. The physical distance effects the round-trip delay time due to the limited speed for transmission of information (generally the speed of light). In practice, the round-trip delay time will however be dominated by delays in the transmission electronics mediating the connection between the secure elements of the two dongles a and b. In particular, the enforcement of a predefined timeframe will make it difficult or impossible to relay the connection between the dongles without notice.

(13) Moreover, dongle a is configured to measure the signal strength of the direct wireless connection 4 to dongle b. Dongle a is configured to compute a digital signature S.sub.a(M) of a received message M only if the measured signal strength of the direct wireless connection 4 exceeds a predefined minimum signal strength, for example 4 dBm (equivalent to an estimated 10-meter range of a Bluetooth signal).

(14) As will be explained in more detail in connection with FIG. 3, dongle c is configured to verify the presence of the mobile terminal T.sub.c before confirming its own presence to either dongle a or dongle b. At the same time, the mobile terminal T.sub.c is configured to confirm its presence only within a limited timeframe after authentication of the owner O.sub.c by entering a valid and authorised fingerprint on the fingerprint sensor 9.

(15) Finally, dongle a stores a white list for identifying acceptable messages M. If the message M is a transaction, the white list contains for example five acceptable transaction targets (receiving addresses). If the host h requests signature of a message M comprising a transaction to a different target, dongle a denies to sign such a message M. The white list will preferably be stored inside the secure element of dongle a.

(16) If in the above some functionality has been described with respect to a single dongle a, b or c, it will be apparent to those skilled in the art, that each such functionality may be implemented by any or all of the respective other dongles analogously and to a similar effect (often further increased security).

(17) In order to further explain the present method, an exemplary and relatively simple embodiment will be discussed in chronological order along with the sequence diagram shown in FIG. 2. The initial situation in FIG. 2 is that the owners O.sub.a and O.sub.b have come to agree on performing a certain transaction and have invited the owner O.sub.h of the host h to coordinate, prepare and upload the transaction to the database 11, thus acting as coordinator. The two owners O.sub.a and O.sub.b have brought their respective dongles a and b, which are initially in standby mode and configured and initialised as described above in connection with FIG. 1. Of course, it would also be possible that any of the owners O.sub.a, O.sub.b owns and operates the host h. However, for the sake of clarity, three separate owners O.sub.h, O.sub.a, O.sub.b are assumed here.

(18) To begin with, the coordinator (that is, the owner O.sub.h and operator of the host h) in step 14 asks the owner O.sub.a of dongle a to activate the signing trigger of dongle a. Owner O.sub.a pushes the button 6 of dongle a, thereby activates the signing trigger 15 of dongle a and switches dongle a into signing mode for a limited timeframe 16 indicated by the left vertical bar parallel to the timeline of dongle a (e.g. for five minutes). In step 17 the owner O.sub.h asks the owner O.sub.b of dongle b to activate the signing trigger of dongle b. Owner O.sub.b pushes the button 6 of dongle b, thereby activates the signing trigger 13 of dongle b and switches dongle b into signing mode for a limited timeframe 12 indicated by the left vertical bar parallel to the timeline of dongle a. Now both dongles a, b are in signing mode.

(19) The coordinator in step 18 enters the desired transaction parameters into the host h. Host h in step 19 compiles the entered transaction parameters into a draft transaction, which corresponds to the message M that needs to be signed with a multi-signature in order to form a complete and valid transaction. In detail, the message M comprises for example an identifier of at least one previous (source) transaction, a redeem script, to which said previous transaction is cryptographically linked, a transaction target address and a transaction amount. The status 20 of the transaction is indicated by a vertical bar parallel to the timeline of the host h.

(20) Once the message M is prepared, the host h via connection 1 (see FIG. 1) transmits the message M to dongle a, which receives the message M. Dongle a finds itself in signing mode during the timeframe 16 and therefore proceeds to generate in step 21 a random challenge R.sub.a, which is stored locally as indicated by 22. Dongle a transmits the random challenge R.sub.a over connection 4 to dongle b as a request for providing a zero-knowledge proof of the private identity I.sub.b and simultaneously starts an internal stopwatch. Dongle B receives the random challenge R.sub.a generated by dongle a, stores 23 the random challenge R.sub.a, and, since it finds itself in signing mode during the timeframe 12, computes 24 a digital signature S(R.sub.a,I.sub.b) of the random challenge R.sub.a using its private identity I.sub.b. It stores 25 the digital signature S(R.sub.a,I.sub.b) and transmits it back to dongle a. Dongle a receives the digital signature S(R.sub.a,I.sub.b) from dongle b, which forms the requested zero-knowledge proof, and stops the internal stopwatch, which now reads the delay time D(a,b). Dongle a verifies 26 the presence of dongle b by checking, if the delay time D(a,b) is within the predefined timeframe and the signal strength of connection 4 measured by dongle a exceeds the predefined minimum signal strength and whether the digital signature S(R.sub.a,I.sub.b) is valid according to the locally stored identity P(I.sub.b), i.e. verifying the received zero-knowledge proof. If all three conditions are met, the presence of dongle b is thus successfully verified, dongle a unlocks 27 the secret key K.sub.a and computes 28 the digital signature S.sub.a(M) of message M using the secret key K.sub.a and transmits the computed digital signature S.sub.a(M) to the host h.

(21) The host h stores 29 the digital signature S.sub.a(M) as a partial signature portion (e.g. a partial “scriptSig”) of the draft transaction. It is assumed, that the transaction as defined by the redeem script is a 2-of-3 multi-signature transaction. Thus, host h requires an additional signature from a second dongle i of the set s. Consequently, host h transmits via connection 2 the message M to dongle b. As dongle b is still in signing mode during the timeframe 12, it proceeds to generate 30 a random challenge R.sub.b, which it stores 31 locally. In order to verify the presence of dongle a, dongle b transmits the random challenge R.sub.b to dongle a as part of a zero-knowledge protocol. Dongle a stores 32 the received random challenge R.sub.b and, also still being in signing mode during timeframe 16, signs 33 the random challenge R.sub.b with its private identity I.sub.a, yielding the digital signature S(R.sub.b,I.sub.a), which is stored 34 and transmitted back to dongle b as a zero-knowledge proof of presence. Dongle b verifies 35 the digital signature S(R.sub.b,I.sub.a) with a locally stored identity P(I.sub.a). (Alternatively, the identity P(I.sub.a) may be signed by a certification authority z trusted by dongle b and transmitted together with the digital signature S(P(I.sub.a),I.sub.z) computed by the certification authority with its private identity I.sub.z and with the digital signature S(R.sub.b,I.sub.a) from dongle a to dongle b. Dongle b in this case stores only the identity P(I.sub.z) of the certification authority, verifies the received identity P(I.sub.a) of dongle a with the digital signature S(P(I.sub.a),I.sub.z) and then verifies the presence of dongle a with the digital signature S(R.sub.b,I.sub.a) and the received identity P(I.sub.a).) If the digital signature S(R.sub.b,I.sub.a) received as a zero-knowledge proof of presence turns out valid, dongle b unlocks the secret key K.sub.b and computes 36 the digital signature S.sub.b(M) and transmits the digital signature S.sub.b(M) to the host h.

(22) The host h now has received signatures S.sub.a(M), S.sub.b(M) from two dongles a, b therefore holds a complete signature portion 37. With this complete signature portion 37, host h compiles 38 a valid transaction 39. It then submits 40 the valid transaction 39 to the database 11. The database 11 (or effectively a network of nodes participating in the distributed public transaction directory) validates 41 the submitted transaction. The coordinator verifies 42 that the submitted transaction is included in the database 11 and therefore effective.

(23) FIG. 3 shows a partial sequence diagram, which may extend the procedure described in connection with FIG. 2, if dongles a, b store a lower limit of two other dongles, the presence of which must be verified before a signature of a message M is provided. In this case, at the moment IIIa in FIG. 2 after verifying 26 the presence of dongle b, the sequence shown in section IIIa of FIG. 3 can be inserted. Dongle a transmits the random challenge R.sub.a to dongle c, which at this point is still in standby mode, but stores 43 the random challenge R.sub.a nevertheless. Dongle c notifies 44 its owner O.sub.c of the ongoing concerted signing procedure and its required proof of presence. In reaction to this notification, owner O.sub.c if they agree with the signing, activate a signing trigger 45 by pressing button 6 on dongle c, thereby putting dongle c into signing mode for a limited timeframe 46. Dongle c holds only a first part I.sub.c1 of a private identity I.sub.c, wherein the second part I.sub.c2 of the private identity I.sub.c is held by the mobile terminal T.sub.c. Therefore, for providing a valid proof of presence, dongle c transmits over connection 7 the stored random challenge R.sub.a received from dongle a to the mobile terminal T.sub.c for partial signing. The mobile terminal T.sub.c at this point is still in standby mode and stores 47 the received random challenge R.sub.a. Mobile terminal T.sub.c notifies 48 its owner O.sub.c of the ongoing signing procedure and asks for authentication by entering a fingerprint on the fingerprint sensor 9. Owner O.sub.c enters 49 the requested fingerprint, thereby switching the mobile terminal T.sub.c into signing mode for a limited timeframe 50. Now in signing mode, mobile terminal T.sub.c computes 51 and stores 52 a partial digital signature S(R.sub.a,I.sub.c2) of the random challenge R.sub.a using the second part I.sub.c2 of the private identity I.sub.c and transmits the partial digital signature S(R.sub.a,I.sub.c2) to dongle c over connection 7. Dongle c, which is still in signing mode during timeframe 46, stores 53 the received partial digital signature S(R.sub.a,I.sub.c2) and computes 54 the complete digital signature S(R.sub.a,I.sub.c1,I.sub.c2)=S(R.sub.a,I.sub.c) of the random challenge R.sub.a using the first part I.sub.c1 of the private identity I.sub.c. Dongle c stores 55 the complete digital signature S(R.sub.a,I.sub.c) and transmits it back to dongle a over connection 5. Dongle a then verifies 56 the presence of dongle c—and implicitly of mobile terminal T.sub.c—by verifying the received signature S(R.sub.a,I.sub.c) with a locally stored identity P(I.sub.c). If successful, dongle a proceeds with computing 27 the digital signature S.sub.a(M) as described in connection with FIG. 2.

(24) At the moment IIIb in FIG. 2 after verifying 35 the presence of dongle a by dongle b, the sequence shown in section IIIb of FIG. 3 can be inserted. At this point, dongle c and mobile terminal T.sub.c are still in signing mode during the timeframes 46, 50. Therefore, when dongle b transmits the random challenge R.sub.b to dongle c, dongle c stores 57 and immediately forwards the random challenge R.sub.b to the mobile terminal T.sub.c for partial signing. The mobile terminal T.sub.c stores 58 the received random challenge R.sub.b and computes 59 and stores 60 a partial digital signature S(R.sub.b,I.sub.c2) of the random challenge R.sub.b using the second part I.sub.c2 of the private identity I.sub.c. The mobile terminal T.sub.c transmits the partial digital signature S(R.sub.b,I.sub.c2) back to dongle c, which stores 61 the received partial digital signature S(R.sub.b,I.sub.c2) and computes 62 the complete digital signature S(R.sub.b,I.sub.c1,I.sub.c2)=S(R.sub.b,I.sub.c) of the random challenge R.sub.b using the first part I.sub.c1 of the private identity I.sub.c. Dongle c stores 63 the complete digital signature S(R.sub.b,I.sub.c) and transmits it back to dongle b over a direct wireless connection between dongles b and c. Dongle b then verifies 64 the presence of dongle c and of mobile terminal T.sub.c by verifying the received signature S(R.sub.b,I.sub.c) with a locally stored identity P(I.sub.c). If successful, dongle b proceeds with computing 36 the digital signature S.sub.b(M) as described in connection with FIG. 2.

(25) At the end of the limited timeframes 12, 16, 46, 50 (i.e. a predefined time period after they have entered signing mode), the dongles a, b, c and the mobile terminal T.sub.c will autonomously switch 65 from signing mode into standby mode.

(26) The parallel diagonal lines 66 crossing the timelines in FIG. 2 and FIG. 3 indicate, that an arbitrary amount of time has passed, during which other steps and state changes may have happened.