CN111492359B

CN111492359B - Dongle and method for providing digital signatures

Info

Publication number: CN111492359B
Application number: CN201880081447.2A
Authority: CN
Inventors: T.弗尔斯特纳
Original assignee: Riddle and Code GmbH
Current assignee: Riddle and Code GmbH
Priority date: 2017-12-19
Filing date: 2018-12-18
Publication date: 2024-01-16
Anticipated expiration: 2038-12-18
Also published as: WO2019121751A1; US20210167964A1; JP7037655B2; SG11202004937XA; KR20200100640A; CA3083382C; JP2021507616A; EP3502941A1; EP3502941B1; CA3083382A1; CN111492359A; US11646889B2; AU2018387790A1; KR102440825B1

Abstract

For providing a digital signature (S _i ) Is provided, wherein each dongle (a, b, c) holds a secret key (K _i ) Wherein each dongle (a, b, c) is configured to receive a message (M), configured to use a secret key (K _i ) Calculating (28, 36) a digital signature (S) of the received message (M) _i ) And is configured to transmit the calculated digital signature (S _i ) Characterized in that at least one (a) of the dongles is configured to, in calculating (28) a digital signature (S _a ) Previously verifying (26) the presence of at least one other dongle (b, c) belonging to said set (S) and configured to calculate (28) a digital signature (S) only if the presence of one or more other dongles (b, c) is successfully verified _a )。

Description

Dongle and method for providing digital signatures

The invention relates to a set of two or more dongles and a method for providing a digital signature with dongles belonging to the set, wherein each dongle holds a secret key, wherein each dongle is configured to receive a message, to calculate a digital signature of the received message using the secret key, and to send the calculated digital signature, wherein the method comprises: the method includes receiving a message to be signed, calculating a digital signature of the message using a secret key, and transmitting the calculated digital signature.

Here, the term "secret key" refers to any secret information held by or stored on the respective dongle that can be used to sign a message. The secret key of each dongle is typically different, i.e. no two dongles share the same secret key. In particular, the secret key may be a private signature key; it is preferably stored in a secure element or tamper-proof memory within the respective dongle holding it. The secure element is preferably a secure cryptographic processor (e.g. of the type used in smart cards), i.e. a dedicated computer or microprocessor on a chip for performing cryptographic operations, embedded in a package with various physical security measures, which makes it tamper-resistant to some extent. In general, the set may also include dongles that do not hold secret keys and are not configured to sign messages themselves, but only act as witneszers whose presence needs to be verified by at least two dongles that do the actual signature. The message to be signed, or "message" in general, may be any signal or data structure that may be received and signed by the dongle. The invention relates in particular to the preparation and provision of multiple signature transactions (multi-signature transaction) for general blockchain applications; in this application, the message may be a transaction (a data structure that holds transaction details) that includes a so-called "redemption script". The multiple signature preferably includes signatures from at least two dongles in the set. Messages may be received from a host connected to the dongle via a data connection (USB, bluetooth, etc.), and the calculated digital signature may be sent back to the host using the same data connection or a different data connection, or sent together to different hosts. Calculating the digital signature of the received message using the secret key corresponds to signing the message using the secret key. Depending on the cryptographic implementation of the digital signature, the digital signature may be verified, for example, with a public key derived from a secret key.

A generic blockchain application allows for the generation of addresses where any outgoing transaction requires multiple signatures. Generating a valid outgoing transaction from such a multi-signed address requires multiple secret keys (or private keys). The number M of required secret keys is typically less than or equal to the number N of authorized private keys. Thus, an effective outgoing transaction is also referred to as an M-of-N multi-signed transaction. To generate such a multiple signature address, the public key of all N authorized private keys needs to be provided, as well as the M number of signatures required for a valid outgoing transaction.

When the transaction requires agreement by multiple persons, a multi-signed address is used, where each person controls one authorized private key, and/or when multiple factors are required for a valid transaction, where each authorized private key is differently protected (e.g., stored on a different storage device and maintained in a different location). However, conventional digital signatures or "single-signature" must compromise security for reliability (e.g., key loss may be avoided by backups that otherwise introduce new attack vectors), but digital multiple signatures allow any desired level and balance of security and reliability to be achieved. They are therefore particularly suitable for protecting safety-critical transactions.

One drawback of existing methods for providing digital multiple signatures is that a single signature may be generated at any of a variety of points in time and later compiled into a valid multiple signature.

The object of the present invention is to overcome this drawback and to increase the security of the generation process for providing digital signatures.

The invention solves this object by a set of dongles of the kind mentioned at the outset, wherein at least one of the dongles is configured to verify the presence of at least one other dongle belonging to the set before calculating the digital signature and to calculate the digital signature only if the presence of one or more other dongles is successfully verified. If and only when the presence of one or more other dongles has been verified (i.e. successful), the dongle continues to calculate a digital signature of the received message.

Accordingly, the present invention solves the above object with a method of the kind mentioned at the outset, comprising: verifying the presence of at least one other dongle belonging to the set prior to calculating the digital signature; and only computes the digital signature if the verification is successful.

By verifying the presence of at least one other dongle, the first dongle ensures that at least two secret keys (one for each dongle) must be present and available for simultaneous signing. The signature process of at least two dongles must be coordinated. An adversary attempting to generate a valid multiple signature would need to control at least two dongles simultaneously, which is generally more difficult to achieve (especially undetected) than controlling each dongle in turn.

Preferably, at least one of the dongles verifies the presence of at least one other dongle belonging to the set by requiring zero knowledge proof. Accordingly, the step of verifying the presence of at least one other dongle belonging to the set in the present method may require zero knowledge proof, comprising: the method includes sending a request to at least one other dongle to provide a zero-knowledge proof, receiving the zero-knowledge proof from the at least one other dongle, and verifying the received zero-knowledge proof, wherein if verification of the received zero-knowledge proof is successful, verifying the presence of the at least one other dongle. In principle, zero knowledge proof is used as proof of presence because only at least one other dongle can provide the proof and only when it is present (i.e. reachable from at least one dongle requesting proof of presence). The zero knowledge proof may be implemented by a challenge-response protocol, wherein at least one other dongle (prover) and at least one dongle (verifier (s)) are connected. The challenge may be a temporary (preferably disposable) token with time-limited validity. The connection between the two dongles may be a direct connection, such as a bluetooth, zigBee or Wi-Fi (WPAN) connection, or routed via one or more hosts that coordinate the collaborative signature process.

In a preferred embodiment of the method, verifying the received zero-knowledge proof comprises verifying the received proof with a set of stored identities of all other dongles belonging to the same set.

Advantageously, at least one other dongle (prover) is configured to receive the signature trigger and to provide the required zero knowledge proof only within a limited time frame (timeframe) after receiving the signature trigger. Accordingly, the method may comprise: before receiving a message to be signed, the dongle (prover) first receives a signature trigger, wherein the signature trigger switches the dongle to signature mode for a limited time frame after receiving the signature trigger, wherein after the time frame has elapsed the dongle switches to standby mode, wherein the dongle sends a zero knowledge proof of its existence to the other dongles and uses the secret key to calculate the digital signature only in signature mode. The signature trigger is preferably a physical trigger on the respective dongle, e.g. a physical button pressed by a user controlling the dongle, for signaling approval of the collaborative signature process. After a time frame (e.g., five minutes) after the signature trigger has elapsed, at least one other dongle will enter standby mode and not provide zero knowledge proof of any request until another signature trigger occurs and the dongle reenters signature mode. Requests for zero knowledge proof received outside of the time frame (i.e., in standby mode) may be stored as pending requests and notified to users of the respective dongles. This notification can serve two purposes: it signals the user of the signature attempt and alerts them to operate the signature trigger if the collaborative signature process is approved.

The above-mentioned zero-knowledge proof may be a zero-knowledge proof of knowledge of a secret key, which may be a secret key for signing (a secret signing key) or another secret key (a secret presence key). Preferably, each dongle holds a further secret key (a secret presence key), and the zero knowledge proof relates to possession of the further secret key. Each dongle has a different further secret key or secret presence key. The secret key additionally represents the private identity of the dongle holding it. Thus, the further secret key may be locked within each dongle during provisioning by the manufacturer of the set of dongles. The secret signing keys may then be generated by each of the dongle owners independently of the manufacturer's control without compromising the encrypted links between dongles established by the further secret keys. The dongle owner then provides only the public signature key for subsequent verification of its signature and for example for building up a multiple signature address.

Preferably, at least one of the dongles stores the identity of all other dongles belonging to the same set. The identity may be stored as secret derived information, such as a public key or a private identity corresponding to a secret presence key. The identity may preferably be stored with the secret key (secret signing key) in a secure element or tamper-proof memory inside the dongle. Accordingly, verifying the presence of at least one other dongle preferably includes verifying the identity of the current other dongle by comparison with the stored identity. The stored identities may be used to verify a proof of presence provided by at least one of the other dongles, for example by verifying that the challenge is signed with a secret presence key, wherein the corresponding public presence key is (or is included in) one of the identities stored by the verification dongle.

In a preferred embodiment of the set, at least one of the dongles stores a lower limit on the number of other dongles whose presence must be certified prior to computing the digital signature. Accordingly, the method may comprise: the total number of dongles whose presence has been verified (after receiving the message) is required to be greater than or equal to a predetermined lower limit before the signature of the received message is calculated. Thus, in this case, the dongle uses its own secret key to calculate the signature of the received message only if the dongle has successfully verified the presence of at least as many dongles as defined by the lower bound (optionally including those dongles in signature mode). Other dongles must belong to the same set so that the presence meets the requirement that they must be "signature dongles" that participate in the same multiple signature as the current verification dongle. In addition, the presence of other dongles is verified during the same session during which messages received will be signed. The lower limit may be between 1 and the total number of dongles belonging to the same set minus 1 (for the authentication dongles themselves). By implementing the presence of a sufficient number of signature dongles, the feasibility of a valid M-of-N multiple signature can be tested before any signature is actually computed. Where N is the total number of dongles belonging to the same set (the total number of signature dongles), and M is the number of signatures required for a valid multiple signature. If M is less than N, the lower limit will be between 1 and M minus 1.

Furthermore, it has proven to be advantageous that at least one dongle is configured to measure the time required to verify the presence of at least one other dongle belonging to the set and to calculate the digital signature only if the presence of one or more other dongles is successfully verified within a predetermined time frame for each of the one or more other dongles. Accordingly, the present method advantageously comprises: during verification of the presence of at least one other dongle belonging to the set, the time required to verify the presence is measured and required for each of the one or more other dongles to be within a predetermined time frame before calculating the signature of the received message. In particular, the verification dongle may be configured to measure round-trip (trip-trip) delay time between the request and receipt of a proof of presence (e.g., zero knowledge proof). By implementing an upper bound on the round trip delay time, the maximum physical distance of the direct (non-intervening) connection and dongle can be tested. The acceptable predetermined time frame may be selected based on a measurement of the actual dongle's round trip delay time during the initialization process. An adversary attempting to spoof the presence of a dongle needs to ensure that the round trip delay time does not exceed a predetermined time frame. For remote dongles and/or connections routed through the network, this may not be physically possible, effectively excluding such an attack medium.

Preferably, the dongles are configured to establish a direct wireless connection between each other to verify presence, wherein at least one dongle is configured to measure the signal strength of a wireless connection to at least one other dongle belonging to the set and to calculate the digital signature only if the signal strength exceeds a predetermined minimum signal strength or a distance measurement derived from the signal strength is below a maximum distance of each of the one or more other dongles. Accordingly, the method preferably comprises: the signal strength of the wireless connection to at least one other dongle belonging to the set is measured and the measured signal strength is required to exceed a predetermined minimum signal strength and/or the distance measurement derived from the measured signal strength is below a predetermined maximum distance for each of the one or more other dongles before calculating the signature of the received message. Thus, the verification dongle will use its own secret key to calculate the signature of the received message only if the signal strength of one or more of the other dongles from the set is above a threshold minimum signal strength, or only if the distance measure derived from the signal strength is below a threshold maximum distance. The wireless connection may be, for example, a bluetooth, NFC, RFID, google Thread, zigBee or WPAN connection, or generally any connection from the 802.15.4 protocol group (mesh network connection). A physical signal strength (RX value) measured in milliwatts or decibel milliwatts (dBm) or a received signal strength indication (received signal strength indication, RSSI) measured in percent may be used as a measure of signal strength. By implementing a lower limit on signal strength or distance, a maximum physical distance of the dongle can be ensured, wherein the maximum physical distance can be defined more accurately than the upper limit of the round trip delay time. Preferably, these two measurements are combined to achieve both safety and accuracy.

According to a preferred embodiment of the present invention, at least one of the dongles may be configured to verify the presence of the mobile terminal before confirming its own presence with any other dongle. Accordingly, the method may comprise: the presence of a mobile terminal connected to the dongle is verified before calculating the signature of the received message or providing zero knowledge proof. The mobile terminal may be any mobile computer terminal, such as a smart phone, a smart watch or a tablet computer. Verification of the presence of the mobile terminal may be similar to verification of the presence of one or more other dongles belonging to the set. In one example, the presence of a mobile terminal (or more specifically, its proof) may be required before calculating the signature of a received message; under and independent of the second instance, the presence of the mobile terminal may be necessary for the presence of the dongle itself, i.e. the presence of the mobile terminal may be required before the dongle enters the signature mode. In these embodiments, the mobile terminal acts as a second factor in using the dongle in the collaborative signing process. This is based on the insight that a mobile terminal that is often used by its user will be more noticeable than a dongle that is lacking that may be used infrequently. An adversary will need to grasp control of the dongle as well as the mobile terminal, which is likely to be noticed by the corresponding owner, thus increasing the security of the overall setup.

In this case, it has proven advantageous if the mobile terminal is configured to confirm its presence only within a limited time frame after authentication (preferably biometric authentication) of the user of the mobile terminal. Accordingly, verifying the presence of the mobile terminal during the present method may comprise authenticating the user of the mobile terminal, preferably at least in part using the biometric credential. In the above, the term "presence" is often used to denote "availability of a signature" (e.g., in "signature mode"). Thus, the signing process requires that any user participating in the mobile terminal have indicated that they agree to the signature by providing (optionally biometric) authentication credentials. The advantage of using biometric authentication credentials is that it facilitates auditing the collaborative signature process about the participating individuals.

Preferably, at least one of the dongles stores a whitelist for identifying acceptable messages and is configured to verify that the received message is an acceptable message in accordance with the whitelist and to calculate the digital signature only if the received message is successfully verified. Accordingly, the method may comprise: the received message is required to be an acceptable message according to a white list stored on the dongle before the signature of the received message is calculated. A whitelist may be a collection of attributes of acceptable messages. For example, when the invention is applied to signing transactions, the whitelist may contain received addresses, and only transactions on the whitelist at one of those received addresses are considered acceptable. The secret key is used to calculate a digital signature of a message or transaction only after the message or transaction has been tested and found to be acceptable. Thus, an adversary must be able to compromise the whitelist (the whitelist is preferably stored in a tamper resistant memory inside the security element or dongle using it) or control one of the received addresses on the whitelist.

Hereinafter, preferred embodiments of the set and method according to the invention will be defined, as well as preferred combinations thereof:

1. a set of two or more dongles for providing digital signatures,

wherein each dongle holds a secret key,

wherein each dongle is configured to receive messages, to calculate a digital signature of the received messages using a secret key, and to send the calculated digital signature,

wherein at least one of the dongles is configured to verify the presence of at least one other dongle belonging to the set prior to calculating the digital signature and is configured to calculate the digital signature only if the presence of one or more other dongles is successfully verified.

2. The collection of embodiment 1, wherein at least one of the dongles is configured to verify the presence of at least one other dongle belonging to the collection by requiring zero knowledge proof.

3. The set of embodiment 2 wherein the at least one other dongle is configured to receive the signature trigger and provide the required zero knowledge proof only within a limited time frame after receiving the signature trigger.

4. The set of embodiments 2 or 3, wherein each dongle holds a further secret key and the zero knowledge proof relates to possession of the further secret key.

5. The set according to one of the preceding embodiments, characterized in that at least one of the dongles stores the identities of all other dongles belonging to the same set.

6. The set of one of the foregoing embodiments, wherein at least one of the dongles stores a lower limit on the number of other dongles, the presence of which has to be verified, before calculating the digital signature.

7. The set according to one of the foregoing embodiments, wherein at least one of the dongles is configured to measure the time required to verify the presence of at least one other dongle belonging to the set and to calculate the digital signature only if the presence of one or more other dongles is successfully verified within a predetermined time frame for each of the one or more other dongles.

8. The set according to one of the foregoing embodiments, characterized in that the dongles are configured to establish a direct wireless connection between each other for verifying the presence, wherein the at least one dongle is configured to measure the signal strength of the wireless connection to at least one other dongle belonging to the set, and to calculate the digital signature only if the signal strength of each of the one or more other dongles exceeds a predetermined minimum signal strength and/or a distance measurement derived from the signal strength is below a predetermined maximum distance.

9. The set of one of the foregoing embodiments, wherein at least one of the dongles is configured to verify the presence of the mobile terminal before confirming its presence with any other dongle.

10. The set of embodiments 9, characterized in that the mobile terminal is configured to confirm its presence, preferably biometric authentication, only within a limited time frame after authentication of the user of the mobile terminal.

11. The collection of one of the foregoing embodiments, wherein at least one of the dongles stores a whitelist for identifying acceptable messages and is configured to verify that a received message is an acceptable message based on the whitelist and is configured to calculate a digital signature only if the received message is successfully verified.

12. The method according to one of embodiments 1 to 11 for providing a digital signature with a dongle belonging to a set, wherein the dongle holds a secret key, the method comprising the steps of:

-receiving a message to be signed;

-verifying the presence of at least one other dongle belonging to the set;

-if the verification is successful, calculating a digital signature of the message using the secret key; and

-transmitting the calculated digital signature.

13. The method of embodiment 12 wherein the step of verifying the presence of at least one other dongle belonging to the set is characterized by requiring zero knowledge proof, comprising:

transmitting a request to provide a zero knowledge proof to at least one other dongle,

-receiving a zero knowledge proof from at least one other dongle, and

-verifying the received zero-knowledge proof of knowledge,

wherein if the verification of the received zero knowledge proof is successful, the presence of at least one other dongle is verified.

14. The method of embodiment 13 wherein verifying the received zero-knowledge proof includes verifying the received proof with a set of stored identities of all other dongles belonging to the same set.

15. The method according to one of the embodiments 12 to 14, characterized in that before receiving the message to be signed, the dongle first receives a signature trigger, wherein the signature trigger switches the dongle to signature mode for a limited time frame after receiving the signature trigger, wherein after the time frame has elapsed, the dongle switches to standby mode, wherein the dongle sends a zero knowledge proof of its existence to the other dongles, and uses the secret key to calculate the digital signature only when in signature mode.

16. The method according to one of embodiments 12 to 15, characterized in that the total number of dongles whose presence has been verified is required to be greater than or equal to a predetermined lower limit before the signature of the received message is calculated.

17. The method according to one of embodiments 12 to 16, characterized in that: during verification of the presence of at least one other dongle belonging to the set, the time required to verify the presence is measured and required for each of the one or more other dongles (b, c) to be within a predetermined time frame before calculating the signature of the received message.

18. The method according to one of embodiments 12 to 17, characterized in that: the signal strength of the wireless connection to at least one other dongle belonging to the set is measured and the measured signal strength of each of the one or more other dongles is required to exceed a predetermined minimum signal strength and/or the distance measurement derived from the measured signal strength is below a predetermined maximum distance before calculating the signature of the received message.

19. The method according to one of embodiments 12 to 18, characterized in that: the presence of a mobile terminal connected to the dongle is verified before calculating the signature of the received message or providing zero knowledge proof.

20. The method according to embodiment 19, characterized in that: verifying the presence of the mobile terminal includes authenticating a user of the mobile terminal, preferably using at least in part the biometric credential.

21. The method according to one of embodiments 12 to 20, characterized in that: the received message is required to be an acceptable message according to a white list stored on the dongle before the signature of the received message is calculated.

Referring now to the drawings wherein the showings are for the purpose of illustrating the invention and not for the purpose of limiting the same:

FIG. 1 schematically illustrates a use case of a set of three dongles according to the present invention;

FIG. 2 is a sequence diagram illustrating a process of providing a digital signature using two of the dongles shown in FIG. 1 according to the present invention; and

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.

The use case schematically shown in fig. 1 relates to a set s of three dongles a, b, c. Each of the dongles a, b, c is configured to provide a digital signature S of the message M _i (M) (compare FIG. 2), where S _i (M)＝S(M，K _i ) And K is _i Is a secret key held by dongle i, and where i is one of a, b or c. Secret key K _i Is secret information securely stored on the corresponding dongle i. It may be randomly generated locally on dongle i during the initialization process and preferably never leave dongle i. Thus, each dongle i typically holds a different secret key K _i 。

Dongles a, b, c are pocket-portable (battery-powered) mobile devices. Generally, it is required for high security applicationsOwner O of dongle of (1) _i (i.e. O _a ，O _b ，O _c ) All the while carrying their corresponding dongles i with them. This is to ensure that each dongle i remains subject to its respective owner O _i Is a proprietary control of (c). This is illustrated in FIG. 1 by limiting the control range C for each dongle i _i Indicated by circles of (a). This applies basically to host h, its owner O _h And control range C _h 。

As shown in fig. 1, each dongle i is connected to a host h, which is a separate computer, such as a workstation or portable computer. The connections 1, 2, 3 are wireless connections, for example using bluetooth technology. Alternatively, one or more of dongles i may be connected to host h using a wired connection, such as a USB connection. Dongles i are connected to each other by additional direct wireless connections 4, 5, for example also using bluetooth technology. Although only the direct connection 4 between dongle a and dongle b and the direct connection 5 between dongle a and dongle c are indicated in fig. 1, there may be additional direct connections between dongle b and dongle c. Each dongle i includes a key that can be used by its respective owner O _i The physical button 6 is pressed. Dongle c has access to mobile terminal T associated with dongle c _c Is provided for the additional (third) wireless connection 7. Mobile terminal T _c Owner O of dongle c _c Is a personal smart phone. Mobile terminal T _c Comprising a screen 8 and a fingerprint sensor 9. Other biometric sensors may be associated with the mobile terminal T _c Together, such as sensors for performing facial recognition and/or voice recognition. Typically, those biometric sensors are configured to authenticate the owner O of dongle c _c 。

The host h is connected to the database 11 via the network 10. 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 for securing transactions.

Each dongle i is configured to receive from the host h over a wireless connection 1, 2, 3 using a suitable wireless transmission component of the widely available type (e.g. bluetooth transceiver)Message M. Similarly, each dongle i is configured to sign a calculated digital signature S over a wireless connection 1, 2, 3 _i (M) (with or without a copy of message M) is sent back to host h. Furthermore, each dongle i is configured to use the secret key K _i Calculating a digital signature S of a received message M _i (M). Typically, the secret key K _i Stored in a secure element configured to accept the message M and return a corresponding signature S _i (M) the signature is derived from the received message M and the secret key K _i Derived cryptographically. Thus, the secret key K _i It is per se known that it is never necessary to disengage the security element or to be outside the security element. The secure element is preferably a secure cryptoprocessor.

Each dongle i is also 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 in case the process of verifying the presence succeeds, since all the required conditions have been tested and found to be met, dongle i will continue to calculate digital signature S _i (M). Preferably, some or all of these conditions are tested within the secure element of the respective dongle i. In this example, dongle a is configured to verify the presence of dongle b belonging to the same set s by requiring zero knowledge proof. The required zero knowledge proof is the random challenge R generated by dongle a and sent to dongle b over connection 4 _a Digital signature S (R) _a ，I _b ) And use private identity I of dongle b _b . Dongle b is configured to provide the required zero knowledge proof and to calculate the digital signature S (R) only within a limited time frame 12 after receipt of the signature trigger 13 _a ，I _b ). Private identity I _b Is a further secret key, preferably with the secret key K _b Stored within the same secure element of dongle b. Owner O of dongle b _b Signature trigger 13 may be activated by pressing button 6 of dongle b. Dongle a stores requiring zero knowledge proof belong to the same set (i.e., P (I _b ) And P (I) _c ) Other two dongles b and c) identity P (I _i ). Here, identity P (I _i ) Is corresponding toCorresponding private identity I _i And derived cryptographically therefrom. Since the presence is a calculation of the digital signature S _a The condition of (M), the digital signature S (R) is therefore preferably verified by the secure element _a ，I _b ) Zero knowledge proof of form. Thus, it is preferable to include a method for verifying the signature S (R _a ，I _b ) Identity P (I) _i ) Identity P (I) _b ) Is stored in association with a secret key K _a Within the same security element. In order to avoid any external control of the authentication of the presence, it is also preferred that a random challenge R is generated by the secure element _a The random challenge R _a Will verify the signature S (R _a ，I _b )。

In general, not all dongles i need to be present and any one dongle i need to verify their presence to provide the digital signature S _a (M); the presence of a subset may be sufficient, for example, in the case of M-of-N multiple signatures, where M is less 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 a dongle before providing the signature of the request; i.e. in this case dongle c does not need to provide dongles a and b with their respective signatures S _a (M) and S _b (M) exists for host h. Alternatively, dongle a and/or dongle b may store a lower limit on the number of other dongles before computing the digital signature, the presence of which must be verified. In the use case shown in fig. 1, the lower limit may be 1 or 2. If dongle a stores the lower limit of 2, it will attempt to verify the other dongles b and c and only after verifying the presence of both (e.g., both are signed with digital signature S (R _a ，I _b ) Or S (R) _a ，I _c ) Providing proof of existence in the form of a) to calculate a digital signature S _a (M)。

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 time when a random challenge R is sent _a And receiving a digital signature S (R _a ，I _b ) Round trip delay time D (a, b) between. Only when the delay time D (a, b) is Within a predetermined time frame (e.g., 2 milliseconds (ms)) and digitally sign S (R) _a ，I _b ) When it is valid, dongle a will continue to calculate digital signature S _a (M). Since this situation is preferably tested within the secure element, the secure element preferably comprises a clock and optionally an internal power supply to reliably power the clock. If signed with a digital signature S (R _a ，I _b ) Later arrival of the proof of existence of the form of (a), for example after 3ms, dongle a will not calculate the digital signature S of message M _a (M). This time frame is actually the upper limit of the round trip delay time D (a, b) and serves as a distance measure between the security elements of dongles a and b. Due to the limited information transfer speed (typically the speed of light), the physical distance affects the round trip delay time. In practice, however, the round trip delay time will be governed by the delay in the transmitting electronic device that mediates the connection between the secure elements of the two dongles a and b. In particular, the implementation of the predetermined time frame will make it difficult or impossible to relay the connection between dongles without notification.

Further, dongle a is configured to measure the signal strength of the direct wireless connection 4 to dongle b. Dongle a is configured to calculate the digital signature S of the received message M only if the measured signal strength of the direct wireless connection 4 exceeds a predetermined minimum signal strength, for example 4dBm (equivalent to an estimated 10 meter range of the bluetooth signal) _a (M)。

As will be explained in more detail in connection with fig. 3, dongle c is configured to authenticate the mobile terminal T before confirming its own presence to dongle a or dongle b _c Is present. Meanwhile, the mobile terminal T _c Configured to be used only at the owner O by entering a valid and authorized fingerprint on the fingerprint sensor 9 _c Confirm its presence for a limited time after authentication.

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

If some functions have been described above for a single dongle a, b or c, it will be apparent to a person skilled in the art that each such function may be similarly implemented by any or all of the respective other dongles and with similar effects (typically further improving security).

To further explain the present method, an exemplary and relatively simple embodiment will be discussed in terms of a time sequence in conjunction with the sequence diagram shown in fig. 2. The initial situation in FIG. 2 is that owner O _a And O _b Has agreed to perform a certain transaction and invites owner O of host h _h To coordinate, prepare and upload transactions to the database 11, thereby acting as a coordinator. Two owners O _a And O _b Bringing their respective dongles a and b which are initially in standby mode and configured and initialized as described above in connection with figure 1. Of course, any owner O _a 、O _b It is also possible to own and operate the host h. However, for the sake of clarity, three separate owners O are assumed here _h 、O _a 、O _b 。

First, coordinator (i.e., owner O of host h _h And operator) asks for dongle a owner O in step 14 _a Signature triggering to activate dongle a. Owner O _a Pressing button 6 of dongle a activates signature trigger 15 of dongle a and switches dongle a to signature mode for a limited time frame 16 (e.g. for five minutes) indicated by the left vertical bar parallel to the timeline of dongle a. In step 17, owner O _h Owner O of dongle b _b The signature triggering of the activation dongle b. Owner O _b Pressing button 6 of dongle b activates signature trigger 13 of dongle b and switches dongle b to signature mode for a limited time frame 12 indicated by the left vertical bar parallel to the timeline of dongle a. Now, both dongles a, b are in signature mode.

In step 18, the coordinator enters the required transaction parameters into the host h. In step 19, the host h compiles the entered transaction parameters into a sketch transaction (draft transaction) corresponding to the message M that needs to be signed with the 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 redemption script to which the previous transaction was cryptographically linked, a transaction target address and a transaction amount (transaction amount). The status 20 of the transaction is indicated by a vertical bar parallel to the timeline of host h.

Once the message M is ready, the host h sends the message M to dongle a via connection 1 (see fig. 1), which receives the message M. Dongle a finds itself in signature mode during time frame 16, and therefore continues to generate random challenge R in step 21 _a Random challenge R _a Locally as shown at 22. Dongle a sends a random challenge R to dongle b over connection 4 _a As provision of private identity I _b And at the same time starts an internal stopwatch. Dongle B receives the random challenge R generated by dongle A _a Store 23 random challenge R _a And uses its private identity I since it finds itself in signature mode during the time frame 12 _b To calculate 24 a random challenge R _a Digital signature S (R) _a ，I _b ). It stores 25 digital signatures S (R _a ，I _b ) And sends it back to dongle a. Dongle a receives digital signature S (R) from dongle b _a ，I _b ) This forms a zero knowledge proof of the request and stops the internal stopwatch, which now reads the delay time D (a, b). Dongle a checks whether the delay time D (a, b) is within a predetermined time frame, whether the signal strength of the connection 4 measured by dongle a exceeds a predetermined minimum signal strength, and the digital signature S (R _a ，I _b ) Based on locally stored identity P (I _b ) Whether valid, i.e. verifies the received zero knowledge proof, verifies 26 the presence of dongle b. If all three conditions are met, the presence of dongle b is thus successfully verified, dongle a unlocks 27 the secret key K _a And uses the secret key K _a Calculating 28 a digital signature S of a message M _a (M), and the calculated digital signature S _a (M) to host h.

Host h stores 29 digital signature S _a (M) as part of a signature portion (e.g., part of a "script signature") of a sketched transaction. Suppose that the transaction defined by the redemption script is a 2-of-3 multi-signed transaction. Thus, host h requires an additional signature from the second dongle i of set s. Thus, host h sends message M to dongle b via connection 2. Since dongle b is still in signature mode during time frame 12, it continues to generate 30 a random challenge R _b And stores it locally 31. To verify the presence of dongle a, dongle b will random challenge R _b Is sent to dongle a as part of the zero knowledge protocol. Dongle a stores 32 the received random challenge R _b And still in signature mode during time frame 16 with its private identity I _a For random challenge R _b Signature 33 is performed to generate digital signature S (R _b ，I _a ) The digital signature is stored 34 and sent back to dongle b as a proof of zero knowledge of existence. Dongle b uses the locally stored identity P (I _a ) Verifying 35 the digital signature S (R) _b ，I _a ). (alternatively, identity P (I _a ) Certification authority z, which may be trusted by dongle b, signs up with and uses its private identity I with the certification authority _z And using digital signature S (R _b ，I _a ) Calculated digital signature S (R _b ，I _a ) Together from dongle a to dongle b. In this case, dongle b stores only the identity P (I _z ) With digital signature S (P (I _a )，I _z ) Verifying the identity P (I of the received dongle a _a ) Then digitally sign S (R _b ，I _a ) And received identity P (I _a ) Is to verify the presence of dongle a. ) If the received digital signature S (R _b ，I _a ) If the certificate is valid, the dongle b unlocks the secret key K _b And calculates 36 a digital signature S _b (M) and signing the digital signature S _b (M) to host h.

Host h nowAfter having received the signature S from both dongles a, b _a (M)、S _b (M) thus holding the complete signature section 37. With this complete signature section 37, the host h compiles 38 a valid transaction 39. It then submits 40 a valid transaction 39 to the database 11. The database 11 (or indeed a network of nodes participating in a distributed public transaction directory) verifies 41 the submitted transaction. Coordinator verification 42 the submitted transaction is included in database 11 and is therefore valid.

Fig. 3 shows a partial sequence diagram which can extend the process described in connection with fig. 2, if a dongle a, b stores the lower limits of two other dongles, its presence must be verified before providing the signature of the message M. In this case, at time IIIa in fig. 2, after verifying 26 the presence of dongle b, the sequence shown in section IIIa of fig. 3 may be inserted. Dongle a will random challenge R _a To dongle c, while the dongle is still in standby mode, but still stores 43 the random challenge R _a . Dongle c informs 44 its owner O _c An ongoing collaborative signature process and its required proof of existence. In response to this notification, owner O _c If they agree to sign, signature trigger 45 is activated by pressing button 6 on dongle c, placing dongle c in signature mode for a limited period of time 46. Dongle c holds only private identity I _c Is the first part I of (1) _c1 Wherein the private identity I _c Is a second part I of _c2 By mobile terminal T _c Holding. Thus, dongle c will receive a stored random challenge R from dongle a over connection 7 in order to provide a valid proof of presence _a Sent to the mobile terminal T _c To perform partial signature. Mobile terminal T _c While still in standby mode and store 47 the received random challenge R _a . Mobile terminal T _c Notifying 48 of the owner O of its ongoing signing process _c And requests authentication by inputting a fingerprint on the fingerprint sensor 9. Owner O _c Inputting 49 the requested fingerprint, thereby connecting the mobile terminal T _c Switch to signature mode for a limited time frame 50. Now in signature mode, the mobile terminal T _c Using private identity I _c Is a second part I of _c2 Calculate 51 and store 52 the random challenge R _a Part of the digital signature S (R _a ，I _c2 ) And part of the digital signature S (R _a ，I _c2 ) To dongle c. Dongle c that remains in signature mode during time frame 46 stores 53 the received partial digital signature S (R _a ，I _c2 ) And use private identity I _c Is the first part I of (1) _c1 Computing 54 a random challenge R _a Is a complete digital signature S (R) _a ，I _c1 ，I _c2 )＝S(R _a ，I _c ). Dongle c stores the complete digital signature S (R _a ，I _c ) And sends it back to the dongle through connection 5. Dongle a then uses the locally stored identity P (I _c ) Validating the received signature S (R _a ，I _c ) To verify 56 the presence of dongle c and implicitly to verify the mobile terminal T _c Is present. If successful, dongle a continues to calculate 27 the digital signature S described in connection with FIG. 2 _a (M)。

At time IIIb in fig. 2, after verifying 35 the presence of dongle a by dongle b, the sequence shown in section IIIb of fig. 3 may be inserted. At this time, dongle c and mobile terminal T _c Still in signature mode during the time frames 46, 50. Thus, when dongle b sends a random challenge R to dongle c _b Dongle c stores 57 and immediately random challenge R at this time _b Forwarded to mobile terminal T _c For partial signatures. Mobile terminal T _c The store 58 receives the random challenge R _b And use private identity I _c Is a second part I of _c2 Computing 59 and storing 60 a random challenge R _b Part of the digital signature S (R _b ，I _c2 ). Mobile terminal T _c Part of the digital signature S (R _b ，I _c2 ) Is sent back to dongle c which stores 61 the received partial digital signature S (R _b ，I _c2 ) And use private identity I _c Is the first part I of (1) _c1 Computing 62 a random challenge R _b Is a complete digital signature S (R) _b ，I _c1 ，I _c2 )＝S(R _b ，I _c ). Dongle c stores 63 the complete digital signature S (R _b ，I _c ) And sends it back to dongle b through the direct wireless connection between dongles b and c. Dongle b then transmits the data by using the locally stored identity P (I _c ) Validating the received signature S (R _b ，I _c ) To authenticate 64 dongle c and mobile terminal T _c Is present. If successful, dongle b continues to calculate 36 the digital signature S described in connection with FIG. 2 _b (M)。

At the end of the limited time frame 12, 16, 46, 50 (i.e. a predetermined period of time after they have entered signature mode), dongles a, b, c and mobile terminals T _c Will autonomously switch 65 from signature mode to standby mode.

The parallel diagonal 66 intersecting the time lines in fig. 2 and 3 indicates that any amount of time has elapsed during which other steps and state changes may occur.

Claims

1. A method for providing a digital signature (S _i ) Is a system of two or more dongles (a, b, c),

wherein each dongle (a, b, c) holds a secret key (K _i )，

Wherein each dongle (a, b, c) is configured to receive a message (M) using a secret key (K _i ) Calculating (28, 36) a digital signature (S) of a received message (M) _i ) And transmits the calculated digital signature (S _i )，

Characterized in that at least one (a) of the dongles is configured to, in calculating (28) a digital signature (S _a ) Previously, verifying (26) the presence of at least one other dongle (b, c) belonging to the set (S) and configured to calculate (28) a digital signature (S) only if the presence of one or more other dongles (b, c) is successfully verified _a )。

2. The system according to claim 1, wherein at least one of the dongles (a) is configured to verify the presence of at least one other dongle (b, c) belonging to the set(s) by requiring zero knowledge proof.

3. The system according to claim 1 or 2, characterized in that, after computing (28) the digital signature (S _a ) Previously, at least one of the dongles (a) stored a lower limit on the number of other dongles (b, c) whose presence must be certified.

4. The system according to claim 1 or 2, characterized in that at least one dongle (a) is configured to measure the time required to verify the presence of at least one other dongle (b, c) belonging to the set (S) and to calculate (28) the digital signature (S _a )。

5. The system according to claim 1 or 2, characterized in that the dongles (a, b, c) are configured to establish a direct wireless connection (4, 5) between each other for verifying the presence, wherein at least one dongle (a) is configured to measure the signal strength of the wireless connection (4) to at least one other dongle (b) belonging to the set (S), and to calculate (28) the digital signature (S) only if the signal strength of each of the one or more other dongles (b) exceeds a predetermined minimum signal strength and/or the distance measurement derived from the signal strength is below a predetermined maximum distance _a )。

6. A system according to claim 1 or 2, characterized in that at least one (c) of the dongles is configured to verify that the mobile terminal (T _c ) Is present.

7. System according to claim 6, characterized in that the mobile terminal (T _c ) Is configured to be used only when the mobile terminal (T _c ) Confirm its presence within a limited time frame after authentication of the user.

8. According to the weightsSystem according to claim 6, characterized in that the mobile terminal (T _c ) Is configured to be used only when a mobile terminal (T _c ) Confirm its presence within a limited time frame after biometric authentication of the user.

9. Providing a digital signature (S) using a dongle (a) belonging to the system according to one of claims 1 to 8 _i ) Wherein dongle (a) holds secret key (K _a ) The method comprises the following steps:

-receiving a message (M) to be signed;

-verifying (26) the presence of at least one other dongle (b, c) belonging to the set(s);

-if the authentication is successful, using the secret key (K _a ) Calculating (28) a digital signature (S) of the message (M) _a ) The method comprises the steps of carrying out a first treatment on the surface of the And

-transmitting the calculated digital signature (S _a )。

10. The method according to claim 9, wherein the step of verifying (26) the presence of at least one other dongle (b, c) belonging to the set(s) is characterized by requiring zero knowledge proof, comprising:

transmitting a request to at least one other dongle (b, c) providing zero knowledge proof,

-receiving a zero knowledge proof from at least one other dongle (b, c), and

verifying (26) the received zero-knowledge proof,

wherein the presence of at least one other dongle (b, c) is verified if the verification of the received zero-knowledge proof is successful.

11. The method according to claim 9 or 10, characterized in that: during verification (26) of the presence of at least one other dongle (b, c) belonging to the set (S), the time required to verify (26) the presence is measured and the signature (S) of the received message (M) is calculated (28) _a ) Previously, the time required for each of the one or more other dongles (b, c) was required to be within a predetermined time frame.

12. The method according to claim 9 or 10, characterized in that: measuring the signal strength of a wireless connection (4, 5) to at least one other dongle (b, c) belonging to the set (S), and calculating (28) the signature (S) of the received message (M) _a ) Previously, it was required that the measured signal strength of each of the one or more other dongles (b, c) exceeds a predetermined minimum signal strength and/or that the distance measurement derived from the measured signal strength is below a predetermined maximum distance.

13. The method according to claim 9 or 10, characterized in that: before computing the signature of the received message or providing zero knowledge proof, the mobile terminal (T) connected to the dongle (c) is verified (56) _c ) Is present.

14. The method according to claim 13, wherein: validating (56) the mobile terminal (T _c ) The presence of (c) comprises authenticating the mobile terminal (T _c ) Is a user of (a).

15. The method according to claim 13, wherein: validating (56) the mobile terminal (T _c ) Including authenticating the mobile terminal (T) at least in part using the biometric credential _c ) Is a user of (a).