Efficient signature generation process including enhanced crypto agility for limited-resource devices
Patent Information
- Application Number
- PCT/EP2026/053772
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-28
- Filing Date
- 2026-02-12
- Publication Date
- 2026-09-03
Smart Images
Figure EP2026053772_03092026_PF_FP_ABST
Abstract
Description
[0001] 202503451 Foreign version
[0002] 1
[0003] Description
[0004] Efficient signature generation including improved crypto agility for devices with limited resources.
[0005] The invention relates to a method and a system for the secure transmission of data from a sender to a receiver using a signing service.
[0006] IoT devices are increasingly networked these days. This also applies to devices with limited resources (processing power, storage, etc.). Therefore, there is a need for security concepts for such devices that require moderate computing power and are as simple as possible.
[0007] Typically, the security of cryptographic methods is based on symmetric cryptography (e.g., AES (Advanced Encryption Standard), AES-GCM (Advanced Encryption Standard (AES) in Galois Counter Mode (GCM)), etc.) and asymmetric cryptography (e.g., Elliptic Curve Digital Signature Algorithm (ECDSA), RSA (Rivest-Shamir-Adleman), etc.). Asymmetric cryptography algorithms offer support for important functionalities such as digital signatures or key exchange procedures (e.g., in the context of Diffie-Hellman), but are significantly more computationally intensive than symmetric cryptographic methods.
[0008] Furthermore, the development of quantum computers poses a particular threat to asymmetric cryptography, as the underlying mathematical problem is considered to be solved. In contrast, quantum computers can halve the security of symmetric keys for symmetric algorithms, meaning that doubling the key length while keeping the algorithm the same is currently considered sufficient. To control the risks associated with asymmetric encryption, the use of new algorithms for digital signatures has been proposed, which are significantly more computationally intensive than classical asymmetric algorithms. Similarly, key exchange algorithms (e.g., Diffie-Hellman) must be replaced with Key Encapsulation Mechanisms (KEMs) for post-quantum cryptography (PQC).
[0009] Therefore, the security of devices with limited resources is often based only on symmetric encryption methods, but not on asymmetric encryption methods, which makes secure communication over insecure networks difficult, e.g., for a key update. 202503451 Foreign version
[0010] 2
[0011] The known methods of symmetric cryptography only provide partially satisfactory solutions in this regard.
[0012] Symmetric cryptography methods are used, which rely on hash values generated by a hash function, e.g. methods based on hash trees (Merkle Tree).
[0013] It is also known that one-time signature methods, or OTS methods (OTS: one time signature), such as Lamport's, are suitable for post-quantum cryptography (PQC).
[0014] There are also PQC standards for hash-value-based signature algorithms (which are based on hash trees), e.g.
[0015] • XMSS: https: / / www.rfc-editor.org / rfc / rfc8391.html
[0016] • LMS: https: / / www.rfc-editor.org / rfc / rfc8554.html
[0017] The use of tickets or tokens as authentication information is also known. Furthermore, session-related information (i.e., the client-server connection) can be used when a third party (typically an authentication server) is involved. The following methods, which employ different symmetric cryptographic techniques, are designed accordingly:
[0018] — TESLA
[0019] TESLA (Timed Efficient Stream Loss-tolerant Authentication protocol, see IETF RFC 4082) allows for source authentication in multicast scenarios. TESLA is an efficient protocol with low communication overhead and moderate computational effort, scaling well with the number of receivers and tolerating packet loss. TESLA is based on loose time synchronization between sender and receiver. For source authentication, TESLA uses Message Authentication Code (MAC) chaining. The key feature of the chain is that after one key in the chain has been authenticated, the authentication of further keys in the chain is simplified. Digital signatures are used to authenticate the original message (see http: / / www.ece.cmu.edu / ~adrian / projects / tesla-cryptobytes / tesla-cryptobytes.pdf).
[0020] — pTESLA
[0021] pTESLA targets networks of sensors and optimizes TESLA for such scenarios. The general setup assumes a base station that has an authenticated connection to sensor nodes based on a shared secret. Since the digital signature 202503451 foreign version
[0022] 3
[0023] Since initial message protection in TESLA is too costly for the sensor nodes, this is solved in pTESLA by using the authenticated channel between the node and the base station to initiate the authenticated transmission. The rest of the protocol is similar to the original TESLA approach (see http: / / www.ece.cmu.edu / ~adrian / projects / mc2001 / mc2001.pdf).
[0024] Kerberos (IETF RFC 4120):
[0025] Kerberos uses symmetric cryptography only for authenticating clients and servers to a Kerberos server's authentication service. This service employs a Ticket Granting Service to issue symmetrically encrypted tickets containing session information for a specific service usage. The session information can include the identities of the participating peers and session key information. Because no asymmetric cryptography is used, Kerberos cannot leverage the advantages of digital signatures. However, it's worth noting that extensions to Kerberos exist, as described in RFC 4556, that allow the use of X.509 certificates for initial client authentication.
[0026] US patent 2015 / 006899 A1 discloses a method for verifying the integrity of data using a Merkle tree. A sender generates a Merkle tree from a multitude of data objects and signs the root of the Merkle tree. The sender transmits the data objects, the signature, and a Merkle proof to a receiver.
[0027] A combined digital signature is known from US 2002 / 0184504 A1. According to the document, a combined digital signature is a method for generating a single digital signature with one public key for multiple messages, whereby individual combined signatures can be extracted and presented separately. The mechanism of a combined digital signature consists of a combination of a hash tree, whose leaves correspond to the messages, together with a cryptographic signature applied to the root of this hash tree.
[0028] From US patent 2017 / 0004168 A1, a method for processing a data signature-based hash tree structure is known. The method is executed in a first device and comprises:
[0029] - Receiving a request to generate a data signature from a second device, wherein the request includes information on how the generated data signature will be stored;
[0030] - Generating data signature B in response to the request using a data signature-based hash tree method; and202503451 Foreign version
[0031] 4
[0032] - Providing a reference C to the generated data signature to the second device, whereby the generated data signature can be retrieved using the reference C.
[0033] There is a need for additional low-cost solutions suitable for supporting digital signatures, even on devices with limited resources, for both pre- and post-quantum applications. The object of the invention is to contribute to this need.
[0034] The problem is solved by a method according to claim 1, a signing service according to claim 12 and a system according to claim 13.
[0035] According to the invention, a method for the secure transmission of data from a sender to a receiver using a signing service is proposed. The signing service according to the invention is implemented, for example, by means of a device that can function as a server. However, a virtual implementation based on the allocation of resources from a pool of hardware resources is also conceivable. In particular, load balancing between the pool resources is then also possible.
[0036] According to the invention, data or a hash value of the data is sent from the sender to the signing service. For communication within the scope of the invention, symmetric encryption can be agreed upon between the sender and the signing service, and the communication can be protected by this encryption. For this purpose, for example, a symmetric key can be exchanged in advance between the sender and the signing service (pre-shared key), with which the hash value of the data or the data itself can be encrypted by the sender and / or protected with an authentication tag with regard to integrity. A symmetric algorithm for authenticated encryption, such as ASCON or AES-GCM, can be used for this. Generally, the communication between the sender and the signing service is preferably protected. This is not necessarily achieved by means of a key. For example,The connection can be secure for physical reasons (intrinsically secure communication carrier or communication channel).
[0037] The signing service creates a hash tree using the received hash value or a hash value generated based on the data. Creating a hash value would be done by applying a hash function to the data. There are various hash algorithms. Some are more secure than others for post-quantum applications. For example, SHA-3 is recommended as a hash algorithm for post-quantum applications. Depending on whether the invention's concept is intended for classical or post-quantum applications, [202503451 Foreign version]
[0038] 5
[0039] Preferably, a suitable hash algorithm with a sufficient level of security is used throughout.
[0040] The hash tree is preferably constructed using hash values of data from multiple senders. Multiple leaves of the hash tree can also be created, each containing different data from the same sender, if several signing requests are received from that sender before enough data from other senders has been received to construct the hash tree. In extreme cases, all leaves may be associated with the same sender. Generally, it is more efficient to generate or order the leaves chronologically than to order them by sender.
[0041] It is also conceivable that the hash tree is constructed using additional dummy values if insufficient data is available from various senders (including potentially multiple different data sets from the same sender). "Data" here can also refer to hash values of data to be transmitted from a sender to a receiver. For example, the use of dummy values can be timed. That is, if a complete hash tree cannot be constructed with the sender data within a specified time period, dummy values are used. Dummy values would be necessary when the volume of signing requests is low. Generally, the hash tree can also be adjusted to the volume by dynamically adapting its size according to the number of signing requests from senders (this number can be based on a predefined time period).
[0042] According to the invention, preferably only the root hash value of the hash tree is signed with a private key of the signing service. That is, the key belongs to an asymmetric signing method. According to one embodiment, this method can also be updated by an authorized entity and does not require support for asymmetric methods on end devices.
[0043] The signed root hash value and values from an authentication path in the hash tree assigned to the sender (typically, the authentication path includes the values required for calculating the root hash) are transmitted from the signing service to the sender (preferably via a secure channel). This transmission preferably occurs via a single message, but can also be implemented using multiple messages. 202503451 Foreign version
[0044] 6
[0045] Alternatively, the signed root hash values and / or the values of an authentication path associated with the sender can be sent directly from the signing service to the recipient after transmission of address information relating to the recipient.
[0046] Examples of methods that fall under this alternative of direct sending include publishing the hash tree separately, e.g., by the signing service, or sending it to each recipient.
[0047] The sender then transmits the data, the signed root hash value, and the values of the sender's associated authentication path in the hash tree to the receiver. This transmission preferably occurs via a single message, but can also be accomplished using multiple messages. The receiver verifies the signature of the root hash value using the verification means associated with the signature (e.g., a public key and / or a certificate belonging to the signing service, which may be sent along with the message or provided separately) and the data by generating a hash value of the data and subsequently calculating a root hash value from the data hash value and the values of the sender's associated authentication path in the hash tree.
[0048] According to one implementation, the sender transmits identification information to the signing service (either along with the data or its hash value, or beforehand). The hash tree is then constructed using this identification information (the leaves of the hash tree are then designed, for example, as a duple or concatenation of the hash value and the identification information). Using the data, the signed root hash values, and the values of the authentication path assigned to the sender in the hash tree, identification information can then be sent from the sender to the receiver, and the sender can verify this identification information (e.g., by calculating the root hash: because the hash tree is constructed from hash values of the data and the identification information, an error in either will result in an incorrect root hash).
[0049] According to a further embodiment, when sending the data or a hash value of the data to the signing service, freshness information (e.g., nonce, random number, or timestamp) is also sent. When sending the signed root hash value and values from an authentication path of the hash tree assigned to the sender, this information is sent back from the signing service to the sender. This provides a certain degree of protection against replay attacks. 202503451 Foreign version
[0050] 7
[0051] The invention enables low-effort signing, especially for transmitters with limited resources. The method is suitable for pre- and post-quantum applications and a wide range of applications (e.g., IT and OT applications).
[0052] The invention will now be explained in more detail using exemplary embodiments and the accompanying figures. These figures show...
[0053] Fig. 1: instances involved in the exemplary embodiment (here with four transmitters and four receivers),
[0054] Fig. 2: an example of the structure of a signed message to a recipient,
[0055] Fig. 3: an example of a hash tree with four leaves,
[0056] Fig. 4: a flow diagram for a first embodiment of the method according to the invention,
[0057] Fig. 5: a flow diagram for a second embodiment of the method according to the invention,
[0058] Fig. 6: a flow diagram for a third embodiment of the method according to the invention and
[0059] Fig. 7: a comparison of cryptographic operations of the concept according to the invention and a variant of the prior art in which a signing service generates a signature individually for each message of the clients.
[0060] The concepts of this invention are particularly (but not exclusively) interesting for devices with limited resources. As an example application to understand this invention, consider a system comprising several resource-limited devices that do not support asymmetric cryptography. According to the invention, a powerful party (signing service server) handles the creation of digital signatures.
[0061] A key idea behind this invention is that the number of signatures used can be reduced with the help of a Merkle (hash) tree and a signing service. The concept is also interesting because calculating digital signatures is more computationally intensive and / or expensive than calculating the hash functions for a hash tree, especially when it comes to post-quantum signatures. The signing service is responsible for collecting data from multiple client devices and digitally signing it using an asymmetric method. The exchange of data between [202503451 foreign version]
[0062] 8
[0063] The signing service and the clients should operate in a trusted environment. Alternatively, data exchange between the signing service and the clients can occur via secure communication based on a symmetric method and pre-shared keys. This means the clients only need to support a symmetric cryptographic method, which is less complex than asymmetric methods.
[0064] The concepts of this invention can be applied very efficiently to post-quantum applications because the number of signatures is reduced by using a hash tree, and post-quantum signatures are very complex (more complex than classical signature methods). The invention also offers advantages for migrating to post-quantum applications because not all participating parties need to sign, or only the signing service is responsible. If necessary, only the signing service and the recipient need to be migrated to post-quantum signature methods. In contrast, the need to migrate the sender is eliminated.
[0065] Depending on the cryptographic algorithms used, the presented solutions for secure data exchange are suitable for applications with both pre-quantum and post-quantum encryption, with the proposed concept significantly increasing efficiency for post-quantum applications.
[0066] Figure 1 shows a (simple) configuration used as an example for illustration in the exemplary embodiments. Four transmitters are shown, each sending data to a receiver. The individual receivers are distinct from one another. To protect the data transmission, the transmitters use a signing service. The transmission paths between the transmitters and the signing service belong to a trusted network; that is, the security requirements between the transmitters and the signing service are lower than those between the transmitters and the receivers. A method according to the invention can proceed as follows (where the transmitter is also referred to as the "client"):
[0067] 1. Client 1, or sender 1, wants to send signed data to recipient 1. Since client 1 does not have an asymmetric signature method, e.g., due to limited resources, it cannot sign the data itself.
[0068] 2. Client 1 sends data-related information via a secure channel to a signing service (a powerful and, from the client's perspective, trustworthy computing unit) located on the network. Preferably, a hash value is first generated from the data.
[0069] 9
[0070] Data from Client 1 is calculated and transmitted to the signing service via the secure channel (alternatively, the entire data set can be sent instead of the hash value – the hash value is then calculated by the signing service). The secure channel (protecting integrity and / or confidentiality) can be implemented by the client protecting the transmitted data with authenticated encryption (Authenticated Encryption with Associated Data (AEAD), e.g., AES-GCM or Advanced Encryption Standard (AES) in Galois Counter Mode (GCM), or a cryptographic algorithm of the ASCON type) before sending it to the signing service. (The terminology is not entirely consistent. Sometimes the term "authenticated encryption" is used. Experts will arrive at the correct technical understanding regardless of the specific term.)The required symmetric key ksym,1 is a pre-shared key that was previously exchanged or negotiated between Client 1 and the signing service during a trusted provisioning phase. The signing service should, of course, support the same symmetric method and be able to decrypt or verify the data using the pre-shared key.
[0071] 3. The previous step is repeated for clients 2-4. The number of clients required, or the number of data to be signed, can be any natural number greater than or equal to one.
[0072] 4. In the present example, the signing service then calculates a hash tree from the data received from clients 1-4 (ideally from the calculated hash value derived from it – i.e., a composition of the hash values transmitted by the clients into a hash tree) (see Fig. 3). The hash values – referred to as "data hash" in Fig. 3 – of this respective data are the leaves of the hash tree. These hash values (the leaves of the hash tree) can be calculated by the respective client or by the signing service, depending on the variant of this invention and as mentioned above. Accounts are determined from the leaves ("node 10" and "node 11" in Fig. 3), respectively. At the end of the hash tree calculation, the tree contains the root hash (the root of the hash tree, "root hash" in Fig. 3).
[0073] 5. The root hash is digitally signed by the signing service using its private key kpriv, signingservice.
[0074] 6. The root hash, signature, and respective authentication path are sent back to clients 1-4, ideally individually protected (with regard to integrity and / or confidentiality) by the pre-shared key (authenticated encryption) of the respective client. 202503451 Foreign version
[0075] 10
[0076] 7. The clients can then send their data, including the asymmetric signature, to the respective recipients. For example, Client 1 would send the following to Recipient 1, as shown in Fig. 5 (see Fig. 2 - example of the structure of a signed message based on the concept of this invention):
[0077] o data 1: The data that is to be signed (by the signing service) and transmitted from client 1 to recipient 1.
[0078] o id 1 : The identity of Client 1. If the signature of the root hash is successfully verified, Recipient 1 can assume the correctness of the identity of Client 1, since Recipient 1 trusts the signing service.
[0079] o root hash: the root hash as plaintext.
[0080] o signature of root note: The signature of the root hash. The recipient possesses the public key or certificate of the signing service for verification. The certificate can, for example, be issued by a trusted certificate authority. Alternatively, the certificate can be attached and sent along as shown in Fig. 2. o data hash 2 | node 11: the necessary authentication path to verify the root hash.
[0081] 8. The recipient can then verify the received data. For example, to verify the signed data from Client 1, Recipient 1 must perform the following steps:
[0082] o Verification of the signature from the root hash (the exact steps depend on the signature method). For this, the receiver needs the digital certificate of the signing service, which is trusted, for example, via a PKI. Alternatively, the public key of the signing service must be known and trusted by the recipient.
[0083] The data (data 1) and identity (id 1) are verified by recalculating the hash tree. This is done using the authentication path (data hash 2 | id 2, node 11). If the same root hash is determined as the one received, recipient 1 can assume that the data originated from client 1 and retains its integrity.
[0084] The prerequisite is that he trusts the signing service and that the signing service (based on the public key or associated certificate) trusts client 1 (based on the pre-shared key).
[0085] Modifications and extensions:
[0086] • In another variant, in step 2 the client should not only send the data (or the calculated hash value from it) to the signing service. Additionally, the client appends its identity to the data or to the hash value of the data, e.g., "data hash 1 | id 1", protects this combination (regarding integrity and / or confidentiality) based on the pre-shared key, and then sends this combination to the signing service. The added identity id1 (a foreign version)
[0087] 11
[0088] Unique identification information (e.g., MAC address, serial number, barcode...) in this variant offers additional possibilities and simplifications for the signing service.
[0089] For example, the signing service can use a client's identity to more efficiently and uniquely identify the matching locally (and securely) stored pre-shared symmetric key, see for example the leaves in Fig. 3.
[0090] • In another variant, the client appends a nonce, a random number, or a timestamp to the data (or the calculated hash value derived from it), protects it together (regarding integrity and / or confidentiality) based on the pre-shared key, and then sends it to the signing service. This achieves so-called freshness (security regarding a realistic duration) and protection against replay attacks. This variant can be combined with the previous one.
[0091] • In our example above, Client 1 would have to wait for the signature from the signing service until four clients request a signature. To reduce the waiting time, the signing service can, after a defined period, populate the (predefined number of) leaves of its hash tree with dummy data, calculate the root hash, and make it available to Client 1.
[0092] • In another variant, the size (number of leaves) of the hash tree can be dynamically changed or adjusted by the signing service. For example, if there is high network load (or many clients are sending requests to sign data), the signing service can calculate a larger tree, for example, with 16 leaves. Under normal circumstances, or as a default setting, the signing service can calculate a tree with only 4 leaves. Ideally, the clients don't need to be aware of this. The clients receive the correct verification path to the signed root hash. The length of this path changes depending on the size of the tree.
[0093] • The signature process of the signing service can be updated by an authorized authority.
[0094] • The signature method can be, for example, a pre-quantum or a post-quantum signature method. A combination of both is also possible.
[0095] • Multiple leaves of the hash tree can come from the same client.
[0096] • In one variant, the channels between the clients and the receivers do not need to be protected with pre-shared keys and symmetric cryptography. These can be physically trustworthy, for example (e.g., with a fixed cable connection).
[0097] • The concept of this invention is flexible. This means it can easily be applied to multiple signing service units, which distribute the effort required to process requests from all clients (pool of signing service resources).
[0098] Figures 4 to 6 show three variants of a method according to the invention as a flowchart of actions and messages exchanged between sender, signing service and receiver. 202503451 Foreign version
[0099] 12
[0100] The following is shown. These variants have in common that symmetric encryption is used between the signing service and sender 1 (hereinafter: sender), for which the key ksym,1 is exchanged or the encryption method is agreed upon. A hash function to be used can also be specified simultaneously or via a separate message exchange. This hash function should also be known to the recipient or communicated to them (not shown in the figures). The sender preferably sends a protected hash value Ksym,1(Hash(Data1)) of the data to be sent to the recipient or the encrypted data Ksym,1 (Data1) itself. The signing service calculates a hash tree using the hash value of the data Data1 - Data4 from the four senders (see Fig. 1). The root hash RootHash is then signed with a private key Kpriv.SD.The signed root hash RootHash / SIG and the required authentication path information AUTHPfadl are sent to the sender, protected by the symmetric key Ksym,1. The sender sends the data Datenl, their identity ID1, the signed root hash RootHash / SIG, and the required authentication path information AUTHPfadl to the receiver. The receiver verifies the signature SIG, the data Datenl, and the identity ID1. For the verification of the signature SIG, the necessary verification means Verifikationsmittel_SIG are used, e.g., the public key of the signing service Kpub.SD, information about the signature method used, the associated certificate, etc., which may have been previously communicated by the signing service (this does not necessarily have to occur at the time suggested in the figure, but could, for example, have occurred before the procedure was carried out).The verification of the data (Datal) and the identity (ID1) is carried out by calculating the root hash (RootHash) from the data (Datal) or its hash value and the authentication path information (AUTHPfadl). If the signature of the root hash is successfully verified, recipient 1 can assume the correctness of the identity (ID1).
[0101] The second variant shown in Fig. 5 differs in that the sender's identity, ID1, is communicated along with the data (Datal) or its hash value (Hash(Datal)). This identity is then used to construct the hash tree (see Fig. 3), meaning the leaves are formed by concatenating the hash value and the identity. The authentication path information (AUTHPfadl) also contains the necessary identity information, e.g., ID2 (see Fig. 2).
[0102] In the third variant, a freshness information XX is appended to the information transmitted between the sender and the signing service. This could be, for example, a nonce, a random number, or a timestamp.
[0103] The individual versions can also be combined with each other. 202503451 Foreign version
[0104] 13
[0105] The invention has numerous advantages:
[0106] • The clients themselves do not require signature functionality, but only support for symmetric cryptographic methods (e.g. AEAD, AES, AES-GCM, ASCON, ...).
[0107] • Overall, fewer signatures are needed than if each data record from each client were signed individually. This reduces the computational overhead, especially for post-quantum applications (with computationally intensive signature algorithms).
[0108] • Updating the signature method (e.g., relevant if weaknesses emerge in a signature method over time, or if new quantum computers pose a threat to classical signature methods) can be significantly simplified, since only the signing service needs to change its signature method, and not every single client (or device). This results in high crypto-agility.
[0109] • The size of the hash tree used can be dynamically adjusted, thus reducing the number of required signatures (from the signing service) as much as possible. This saves computational effort, especially if the signature process is very computationally intensive, such as with a post-quantum signature method.
[0110] • The size of the hash tree used can be adjusted at runtime by AI (artificial intelligence) methods that monitor the workload and use this to estimate the speed of signature generation.
[0111] A comparison of cryptographic operations between the concept according to the invention and a variant (prior art) in which the signing service generates a signature individually for each message from the clients is shown in Fig. 7.
Claims
202503451 Foreign version 14 Patent claims 1. A method for the secure transmission of data from a sender to a receiver using a signing service, comprising the steps - Sending the data or a hash value of the data from the sender to the signing service, - Building a hash tree by the signing service using the received hash value or a hash value generated based on the data, - Signing the root hash value of the hash tree with a private key of the signing service, - Sending the signed root hash value and values of an authentication path of the hash tree associated with the sender from the signing service to the sender, - Sending the data, the signed root hash value, and the values of the authentication path of the hash tree associated with the sender from the sender to the receiver, - Verifying the signature of the root hash value using the verification means associated with the signature by the receiver, and - Verifying the data by creating a hash value of the data and calculating a root hash value from the hash value of the data and the values of the authentication path of the hash tree assigned to the sender.
2. Method according to claim 1, characterized by the fact that the signed root hash values and / or the values of an authentication path of the hash tree associated with the sender are not processed by the steps - Sending the signed root hash value and values of an authentication path of the hash tree associated with the sender from the signing service to the sender, and - The data, the signed root hash value and the values of the authentication path of the hash tree assigned to the sender are not sent from the sender to the recipient, but are sent directly from the signing service to the recipient after transmission of address information related to the recipient.
3. Method according to claim 1 or 2, characterized by the fact that - a symmetric encryption is agreed upon between the sender and the signing service and a key is exchanged, and - the communication between sender and signing service within the procedure is protected using the exchanged key. 202503451 Foreign version 15 4. Method according to one of the preceding claims, characterized in that the verification means associated with the signature comprise a public key belonging to the signing service and / or a certificate belonging to the signing service.
5. Method according to any one of the preceding claims, characterized by the fact that - the sender transmits identification information to the signing service, and - the hash tree is formed using the identification information.
6. Method according to one of the preceding claims 3 or 5, characterized by the fact that - along with the data, the signed root hash values and the values of the authentication path of the hash tree assigned to the sender, identification information is also sent from the sender to the receiver, and - the sender verifies the identity information.
7. Method according to any of the preceding claims, characterized by the fact that - when sending the data or a hash value of the data to the signing service, freshness information is included, and - when the signed root hash value and values of an authentication path of the hash tree assigned to the sender are sent back by the signing service to the sender, the freshness information is returned.
8. Method according to any one of the preceding claims, characterized by the fact that The hash tree is formed using hash values of data from a plurality of different senders.
9. Method according to claim 8, characterized by the fact that Multiple leaves of the hash tree with different data from the same sender can be formed if several signing requests are received from that sender before enough data from other senders has been received to form the hash tree.
10. Method according to claim 8 or 9, characterized by the fact that 202503451 foreign version 16 The hash tree is formed with additional dummy values if insufficient data from different senders is available.
11. Method according to any of the preceding claims, characterized by the fact that The size of the hash tree is dynamically adjusted according to the number of signing requests from senders.
12. Method according to any one of the preceding claims, characterized by the fact that The signature procedure of the signing service for signing the root hash value by an authorized instance can be updated.
13. Signing service device, which is designed to form a hash tree according to signing requirements received from senders for the secure transmission of data from the respective senders to receivers using the signing service according to a method according to one of claims 1 to 11.
14. Arrangement comprising a signing service according to claim 13, consisting of one or more devices on which the signing service is implemented.
15. System comprising a signing service according to claim 13, a sender and a receiver, which is configured to carry out a method according to any one of claims 1 to 12.
16. System according to claim 15, comprising a plurality of senders and receivers, wherein the signing service comprises a hash tree formed with data from the plurality of senders.