METHOD FOR SECURING DATA EXCHANGE IN A DISTRIBUTED INFRASTRUCTURE

Description

Field of the invention

[0001] The invention relates to a method for enabling secure data exchange in a distributed infrastructure. A distributed infrastructure is a network of computers or servers, which may be spatially separated from one another and connected via a communications network. In this context, the individual computers or servers are referred to as network nodes. Each network node can consist of one or more computers. The term "node" is used collectively below to refer to a computer, server, or a network of computers. Background of the invention

[0002] To ensure secure data exchange between multiple nodes in a network, it is well known that data exchange should be encrypted. Each node generates a cryptographic key pair consisting of a private key and a public key. The private key remains with the node where it was generated and is stored there. The public key is transmitted or distributed to the other nodes in the network using well-known key exchange procedures. The other nodes in the computer network can then use this public key to encrypt the transmission of data to that node or to encrypt the data itself.

[0003] The disadvantage here, however, is that each node in the computer network generates its own key pair, so that each node must exchange the public keys with all other nodes in the network (or at least with those nodes in the network with which data exchange is to be carried out). In a network with n Nodes would therefore n different key pairs are generated. If each node wants to securely exchange data with every other node in the network, each node must provide its public key to all other nodes in the network, so that up to n 2< -n Key exchanges must be carried out, which requires a considerable amount of time and resources.

[0004] In addition, for data transmission from a first node to a second node in the computer network, the first node must select the correct public key assigned to the second node in order to encrypt the data to be transmitted in a way that the second node can decrypt. For this purpose, significant resources and security measures must be provided or implemented at the nodes to ensure at all times that the data to be transmitted is correctly encrypted for the respective receiving node, i.e., that the respective correct public key is used for encryption.

[0005] A further disadvantage arises when a key pair needs to be renewed at a node in the network. In this case, the corresponding public key must be distributed to all other nodes in the network or made available to all other nodes. This so-called key update can be very time-consuming, meaning that encrypted data cannot be transmitted to the node that generated the new key pair until the key update is complete. During the key update, no data can be transmitted to this node, or the other nodes use the old and therefore incorrect public key to encrypt the data.

[0006] If the key or key exchange is provided with a digital certificate, this delay is compounded by the delay in issuing the corresponding certificate, so that the key exchange takes correspondingly longer, resulting in even longer downtimes.

[0007] The patent US 2006 / 023887 discloses a key management based on Shamir's "Threshold Secret Sharing", where each node derives its own key pair. Object of the invention

[0008] The object of the present invention is therefore to provide a method which enables secure data exchange in a distributed infrastructure consisting of a number of nodes without having to accept the disadvantages known from the prior art with regard to key management. Inventive solution

[0009] This problem is solved by a method according to the independent patent claim. Advantageous embodiments of the method are specified in the dependent patent claims.

[0010] A method is therefore provided for enabling secure data exchange between a number of nodes of a network of nodes, wherein each node has a sealing module (SSM), wherein a master node generates a secret (S) and distributes the secret to several secret holders, whereby each secret holder is in possession of a partial secret, the sealing module (SSM) of each node is provided with at least two partial secrets from at least two secret holders, a cryptographic key pair is automatically generated in each node using the respective provided partial secrets and using a key generation algorithm, wherein the partial secrets provided to the nodes and the key generation algorithm are selected such that identical cryptographic key pairs are automatically generated in each node, wherein the sealing module of each node reconstructs the secret (S) from the partial secrets,wherein in each node, the secret (S) reconstructed in the node is used to generate the cryptographic key pair, and wherein in each node, the same key generation algorithm is used to generate the cryptographic key pair, the generation of the cryptographic key pair takes place in a secure storage area (DCU) of the node, and the cryptographic key pair is stored exclusively in the secure storage area, and encryption and / or decryption of data takes place exclusively in the secure storage area (DCU) of the node, and the secure storage area (DCU) is designed in such a way that it has only volatile storage media, and in the event of unauthorized access to the secure storage area (DCU), the cryptographic key pair is deleted.

[0011] The at least two partial secrets can each be made available to the nodes by a trusted authority.

[0012] The trusted instances can be people.

[0013] It is further advantageous if each node generates a master secret using the respective secrets provided, with which the cryptographic key pairs are generated, wherein the secrets are generated by the master node in such a way that the master secret can be generated from different but equally sized subsets of the secrets. Short description of the characters

[0014] Details and features of the invention, as well as specific embodiments of the invention, will become apparent from the following description taken in conjunction with the drawings, although the invention is not limited to the embodiments described below. It shows: Fig. 1 shows an embodiment with four nodes of a network, using which a variant of the method according to the invention is described; and Fig. 2 shows an embodiment of the method according to the invention, using which the addition of a new node to a network of nodes is described. Detailed description of the invention

[0015] According to the invention, each node in a network generates identical cryptographic key pairs, consisting of a private key and a public key. This ensures that all nodes in the network can use the same public key for secure data exchange, regardless of which node the data is to be encrypted for. A key advantage of this is that no measures need to be taken at the individual nodes to ensure that a node uses the correct public key of another node in the network for encrypted communication.

[0016] When setting up the network for the first time, it is only necessary to ensure that all nodes participating in the network have the appropriate authorization, i.e., are authorized to "participate" in the network. "Participate" in this context means that the nodes can or are permitted to conduct encrypted data exchange with each other.

[0017] When adding a new node to the network, you only need to ensure that this new node also has the appropriate authorization.

[0018] These two processes, i.e. checking the authorization when setting up the network for the first time and checking the authorization when adding a new node to the network, only need to be carried out once, so that there is no idle time or downtime during network operation due to new / changed keys.

[0019] Although all nodes have identical key pairs, according to the invention these must be generated anew in each respective node. This is because the invention prevents the private key, which is required to decrypt data encrypted with the public key, from being distributed from one node to the other nodes in the network. This means that the private key may not leave the node in which it was generated. For this purpose, the nodes are adapted according to the invention so that the respective private key does not have to leave a secure area of ​​the node, the so-called data clean-up area. To ensure this, the data is decrypted exclusively in this data clean-up area. The key pair is also generated exclusively in the data clean-up area.

[0020] According to the invention, identical key pairs are newly generated in each node. To ensure that identical key pairs are generated in each node, the same secret is used in each node to generate the cryptographic key pair. Furthermore, the same cryptographic method (key generation algorithm) is used in each node to generate the cryptographic key pair. The secret can, for example, be a large random number that is made available to each node for generating the cryptographic key pair. The private key therefore no longer needs to leave the node, while at the same time ensuring that each node can encrypt data for every other node in the network (using its own generated public key).A positive side effect is that the public keys no longer need to be exchanged, which significantly reduces the risk of calculating the corresponding private key from a public key.

[0021] The secret itself can be generated by a designated node in the network and made available by this designated node to the other nodes. This designated node is also referred to as the master node. The exchange of the secret with the other nodes can also be encrypted. For the purpose of the encrypted exchange of the secret, each node can (once) - with the exception of the master node, which generates the secret itself and thus also knows it - generate a temporary cryptographic key pair consisting of a temporary private key and a temporary public key. Each node then communicates its public key to the master node, so that the master node can encrypt the secret with the respective public key and transmit the encrypted secret to the respective node.The encrypted secret can then be decrypted by the respective node using its private key to generate the cryptographic key pair. Since the temporary cryptographic key pair is only needed for the (one-time) secure transmission of the secret, the temporary cryptographic key pair can subsequently be destroyed or deleted.

[0022] An alternative, even more secure method for exchanging the secret is described with reference to Fig. 1 This with reference to Fig. 1 The method described also has the additional advantage that each node must be provided with several secrets, which the respective node uses to generate the key pair. This prevents a single entity, e.g., a single person, from generating a key pair in a node or causing the node to generate the key pair. This is because a single entity only possesses one of several secrets.

[0023] Although a key pair can be generated using this single secret, it would not be accepted by the other nodes, or the other nodes would use a public key that does not match the private key, so that an incorrectly generated key pair is ultimately useless.

[0024] Alternatively, the secret can also be generated outside the network, whereby it must only be ensured that each node is provided with such secrets that lead to identical keys when generating the cryptographic key pairs.

[0025] With the method described so far, encryption already ensures a high level of security during data exchange. This security is further increased because the public keys used to encrypt data transmission no longer need to be exchanged.

[0026] Overall, the highest possible level of security is achieved, because the key pairs are automatically generated exclusively in a data clean-up area of ​​the respective node, the encryption of data preferably takes place exclusively in the data clean-up area so that the public key does not have to leave the data clean-up area during network operation, the decryption of the data takes place exclusively in the data clean-up area so that the private key does not have to leave the data clean-up area, to generate the key pair and thus also the respective private key, several secrets are necessary, which are distributed among several secret holders, so that a single instance cannot generate the key pair required in the network on its own, or cannot cause the node to generate such a key pair on its own.

[0027] After each node has generated a cryptographic key pair using the secret, in principle every node in the network can exchange encrypted data with all other nodes in the network, whereby each node can use the same public key to encrypt the data, regardless of the recipient.

[0028] The trustworthiness of the individual nodes is ensured by the fact that a node can only be in possession of the public key required for encryption if it has generated the cryptographic key pair using the secret itself, whereby the secret itself can also be exchanged in encrypted form or according to the Fig. 1 described procedure can be distributed among several secret holders, who then have to make their secrets available to the respective node.

[0029] In order to further increase or improve trustworthiness, the invention can provide for each node to request a corresponding digital certificate (public key certificate) from a trusted certification authority for its generated public key, which confirms ownership and other properties of the respective public key. For this purpose, the public key only needs to be made available to the trusted certification authority once. The digital certificate issued by the trusted certification authority is then transmitted to the respective node and can be stored there. As a result, a node in the network can then authenticate itself to the other nodes with its own certificate before exchanging encrypted data with other nodes in the network. The public key itself does not need to be transmitted.

[0030] The certificate prevents a node from conducting encrypted data exchange with other nodes in the network if it has unauthorized access to the cryptographic key pair, as the cryptographic key pair alone is not sufficient for this. Appropriate organizational measures can prevent the issuance of certificates that could be used to fake the node's identity. For example, by requiring that a qualified certificate be issued only by an accredited certification authority and only upon presentation of an official identification document. This data is stored in the certificate, allowing the other nodes to verify it and only allow encrypted communication if the certificate is valid from their perspective.

[0031] The initial setup of a network consisting of multiple nodes has been described above. Adding one or more additional nodes to an existing network is described with reference to Fig. 2 described in more detail.

[0032] Fig. 1 shows a block diagram of a network with four nodes, based on which a variant of the method according to the invention is described.

[0033] It should be noted that the method according to the invention can also be used in networks with more than four nodes or with fewer than four nodes.

[0034] According to the invention, a secure, i.e. encrypted, data exchange is to be enabled in the network, which here consists of the four nodes 1 to 4. The communication channels through which the encrypted data exchange is to be carried out are Fig. 1 shown with bold double arrows. Accordingly, the Fig. 1 In the example shown, each node can exchange encrypted data with each other. Node 1 is a so-called master node, whose functionality is explained below.

[0035] Each of the four nodes 1 to 4 has a sealing module SSM (Sealing Software Module) that is adapted to generate a cryptographic key pair consisting of a private key and a public key PK using a secret S. As explained above, all nodes generate identical cryptographic key pairs.

[0036] The SSM sealing module is part of a so-called secure storage area (DCU), also known as the Data Clean-Up Area (DCU). The SSM sealing module itself is executed exclusively in the Data Clean-Up Area (DCU). Furthermore, the cryptographic key pairs generated by the SSM sealing module are stored exclusively in the Data Clean-Up Area (DCU), and data encryption and decryption also occur exclusively in the Data Clean-Up Area (DCU). The key pair therefore does not need to leave the Data Clean-Up Area (DCU), effectively preventing misuse of the key pair.

[0037] The Data Clean-Up Area (DCU) is designed so that in the event of unauthorized access to the Data Clean-Up Area, all data stored there, in particular any unencrypted data and the key pair, are deleted. The Data Clean-Up Area is particularly distinguished by the absence of any persistent storage media. This measure ensures that in the event of a power interruption to the Data Clean-Up Area (e.g., if unauthorized access to the Data Clean-Up Area is detected), the data is no longer lost. no unencrypted data can leave the Data Clean-Up Area DCU, no data is left in the Data Clean-Up Area DCU, and the key pair stored exclusively in the Data Clean-Up Area DCU is deleted, because only volatile storage types or storage media are used.

[0038] Using redundant data cleanup areas in a node, the cryptographic key pairs can be secured so that, for example, after a power outage in a data cleanup area, the cryptographic key pair can be restored from a replicated data cleanup area. Communication between redundant data cleanup areas is also preferably encrypted.

[0039] The Trusted Platform Modules (TPMs) shown in nodes 1 to 4 can also be part of the respective Data Clean-Up Area (DCU). Alternatively, but not recommended, the Trusted Platform Modules (TPMs) can also be located outside of the respective Data Clean-Up Area (DCU). In this case, the data is preferably exchanged encrypted between the Trusted Platform Module and the Data Clean-Up Area (DCU).

[0040] In order for the sealing modules SSM of the individual nodes 1 to 4 to each generate an identical key pair, it can be provided, as explained above, that the master node 1 generates a secret S and passes this secret, preferably encrypted, to the other nodes 2 to 4, which then generate the respective key pair using this secret.

[0041] At the Fig. 1 In the configuration shown, the secret S is generated by the master node. However, the secret S is not transmitted directly to the other nodes 2 through 4, but is distributed among several secret holders. Each secret holder thus possesses a portion of the secret S (also called a partial secret).

[0042] In the Fig. 1 In the example shown, 12 secret holders are provided, among which the secret S generated by the master node is divided. The generation of the secret S and the division of the secret S among the multiple secret holders is carried out in such a way that only a certain subset of the secret holders is needed to reconstruct the secret S, ie only some of the partial secrets are needed to reconstruct the secret S. According to the Fig. 1 In the example shown, the secret S can be reconstructed based on the partial secrets of three secret holders. The Shamir Secret Sharing method, for example, can be used to divide and reconstruct the secret.

[0043] According to the invention, the secret S is divided among at least two secret holders, and at least two partial secrets are required to reconstruct the secret. This effectively ensures that at least two secret holders—usually particularly trustworthy individuals—are required to instruct a node to generate a valid key pair.

[0044] After the master node has distributed the generated secret S among the secret holders 1 to 12, the secret holders 1 to 3 go to node 2, the secret holders 5 to 6 go to node 4, and the secret holders 9 to 11 go to node 3.

[0045] Secret holders 1 to 3 provide their partial secrets to node 2, i.e., the sealing module SSM of node 2, so that the sealing module SSM of node 2 can first reconstruct the secret S from the partial secrets and then generate the cryptographic key pair using the secret S. Nodes 3 and 4 perform the same process with the partial secrets of secret holders 9 to 11 and 5 to 7, respectively.

[0046] To ensure secure output of the secret by the master node and secure input of the partial secrets by the secret holders, the nodes provide a secure interface. The secret or partial secrets for the reconstruction of the secret are transmitted via this interface in encrypted form. For this purpose, the respective nodes or the SSM sealing modules of the respective nodes can generate a temporary key pair with which the data to be output or input is encrypted.

[0047] After nodes 1 to 4 have generated their respective cryptographic key pairs, each node initiates certification of its respective public key (PK) by a certification authority (CA). For this purpose, the respective public key (PK) is transmitted to the certification authority (CA) (which can also be encrypted). The certification authority (CA) generates a corresponding digital certificate (Z) (public key certificate) and transmits it to the respective node. The public key transmitted to the certification authority (CA) can be deleted there. According to the invention, the public key (PK) only needs to leave the node in which it was generated once, namely for the creation of a certificate by the certification authority (CA).For encrypted data exchange with other nodes, public keys do not need to be exchanged, as all nodes generate identical key pairs and thus identical public keys (PKs). The certificate itself can be stored in the respective Data Clean-Up Area (DCU).

[0048] As already mentioned, a node no longer needs to be provided with the public key of another node in order for that node to be able to encrypt data for that other node. In particular, nodes do not need to take measures to ensure that the correct public key is used for encrypted communication with the other nodes. This is particularly advantageous when several thousand accounts are involved in the network. This advantage becomes impressively clear when a new node is added to a network consisting of several thousand nodes. This is because the public key would then have to be distributed to all other nodes in the network in a complex manner so that these other nodes can communicate with the new node in encrypted form.

[0049] To further increase security, it is intended that a node must identify itself to the other nodes as a trusted node before this node can exchange encrypted data with the other nodes. For this purpose, the certificate Z, which the nodes have requested from the certification authority for their respective public key PK, is used. For example, before node 3 transmits data encrypted with the public key PK to node 4, node 3 must transmit its certificate Z to node 4. Node 4 can then check certificate Z and, if the certificate is recognized as valid, allow communication. It is advantageous here if the certification authority CA issues a qualified certificate and only upon presentation of an official identification document (e.g. from a responsible manager of the node operator).This data is stored in the certificate, allowing the other nodes to verify it. The remaining nodes only need to verify whether the certificate was issued by an authorized certification authority and who is listed as the certificate holder. This eliminates the need to share the public key, which is known to every node anyway. Certificate validation can be performed efficiently and in a resource-efficient manner.

[0050] Except for the certification of the respective public keys, the public keys do not have to leave the respective node or the respective SSM sealing module, which enables particularly secure operation of the network.

[0051] Fig. 2 shows a block diagram with a node 1 to which another node (here called slave) is added.

[0052] Of course, a new slave node can also be added to a network that includes more than one, especially several thousand nodes.

[0053] In a first step S1, the sealing module SSM of the slave node generates a temporary cryptographic key pair. This temporary cryptographic key pair is required only for the purpose of adding the node to the network and can be discarded afterwards. This temporary cryptographic key pair does not need to be generated using the secrets used to generate the key pairs of the other nodes in the network. Likewise, this temporary cryptographic key pair does not necessarily need to be generated using the sealing module SSM.

[0054] In a further step S2, the public key PK t of the temporary cryptographic key pair is transmitted to a number of entities, for example, a number of people. These people must confirm that the account slave from which they received the public key PK t of the temporary cryptographic key pair is actually to be added to the network. Confirmation can be achieved by these people signing the public key PK t of the temporary cryptographic key pair with their personal key in step S3 and sending the signed public key PKt of the temporary cryptographic key pair as certificate Z in step S4 to a master node (which is in Fig. 2 which is node 1).

[0055] The entities that confirm the public key PKt of the temporary cryptographic key pair can also be technical devices, such as computers that are not part of the network or are part of the network.

[0056] In step S5, the master node checks the transmitted certificates Z against the respective public keys of the individuals and, if the check is successful, initiates the inclusion of the slave node in the network. A positive check may also require that a certain number of individuals have transmitted corresponding certificates Z to the master node. For example, if the temporary public key PK t is transmitted to 6 individuals in step S1, it may be stipulated that 4 of the 6 individuals must send a corresponding certificate Z to the master node so that the new slave node can be definitively added to the network. This is equivalent to 4 individuals having approved the inclusion of the new node in the network.

[0057] With the certificates Z transmitted in step S4, the temporary public key PK t of the slave node to be added is also made known to the master node, since the temporary public key PK t is part of the certificates.

[0058] If the check in step S5 was successful, i.e., if a sufficient number of people have transmitted a valid certificate Z to the master node, the master node transmits the key pair required for communication between the new slave node and the other nodes in the network to the new slave node in step S6. This transmitted key pair is identical to the key pairs generated in the other nodes in the network.

[0059] The transmission of this key pair to the new slave node is encrypted, whereby the temporary public key PK t of the node to be added is preferably used for encryption.

[0060] The new slave node stores the key pair in the Data Clean-Up Area (DCU) or in the Trusted Platform Module of the slave node. This completes the addition of the new slave node to the network. The temporary key pair generated in step S1 can be deleted. For the new node to exchange data with the other nodes in the network, neither the public key nor the private key of the new node needs to leave the network, specifically the Data Clean-Up Area (DCU) of the new node.

[0061] Overall, this also avoids the need to distribute the public key of a new node added to the network to all other nodes in the network. Reference symbol:

[0062] CA Certification Authority TPMTrusted Platform Module DCUsecured storage area (Data Clean-Up Area) SSecrets S1 to S6Steps SSMSealing Software Module ZCertificate (digital) PKpublic key PK t temporary public key 1 to 10Secret holders, e.g., trusted persons

Claims

1. Method for enabling a secure data exchange between a number of nodes of a network of nodes, wherein each node has a sealing module (SSM), wherein - a master node generates a secret (S) and distributes the secret to a plurality of secret holders, whereby each secret holder is in possession of a partial secret, - the sealing module (SSM) of each node is provided with at least two partial secrets from at least two secret holders, - a cryptographic key pair is automatically generated in each node by using the respective partial secrets provided and by using a key generation algorithm, wherein the partial secrets provided to the nodes and the key generation algorithm are selected such that identical cryptographic key pairs are automatically generated in each node, wherein the sealing module of each node reconstructs the secret (S) from the partial secrets, wherein the secret (S) reconstructed in the node is used in each node for generating the cryptographic key pair, and wherein the same key generation algorithm is used in each node for generating the cryptographic key pair, the cryptographic key pair is generated in a secure storage region (DCU) of the node and the cryptographic key pair is stored exclusively in the secure storage region and data is encrypted and / or decrypted exclusively in the secure storage region (DCU) of the node, and the secure storage region (DCU) is designed such that it exclusively contains volatile storage media and in the event of unauthorized access to the secure storage region (DCU), the cryptographic key pair is deleted.

2. Method according to the preceding claim, wherein the cryptographic key pair is generated by the sealing module (SSM) which is executed in the secure storage region.

3. Method according to claim 1, wherein the secret holders are persons.

4. Method according to any of the preceding claims, wherein the at least two partial secrets are generated by the master node.

5. Method according to claim 4, wherein each node generates the secret (S) by using the respective partial secrets provided, with which secret the cryptographic key pairs are generated, wherein the partial secrets are generated by the master node such that the secret (S) can be generated from different but equally large partial quantities of the partial secrets.