Computer-implemented method for secure communication, computer-readable medium, and system for secure communication

Abstract

The invention relates to a Computer-implemented method for secure communication between a first entity (A) and a second entity (B), wherein the first entity (A) is associated with a first public key (PKA) and a corresponding first private key (SKA), and the second entity (B) is associated with a second public key (PKB) and a corresponding second private key (SKB), and wherein the method comprising the following steps: a) requesting, by the second entity (B), the first public key (PKA) from a communication network security database, in particular hosted on a server (20); b) receiving, by the second entity (B), at least the following data: - the first public key (PKA); - a first key verification mechanism (IPA) associated with the first public key (PKA); - database integrity data (RH) related to the communication network security database; c) verifying, by the second entity (B), the first public key (PKA) using the first key verification mechanism (IPA); d) sending, by the second entity (B) to the first entity (A), at least the following data: - the first key verification mechanism (IPA); - the database integrity data (RH); and - a first message (M1) being asymmetrically encrypted with the first public key (PKA) and signed with the second private key (SKB); e) verifying, by the first entity (A), the first public key (PKA) using the first key verification mechanism (IPA); f) decrypting, by the first entity (A), the first message (M1) using the first private key (SKA); g) verifying, by the first entity (A), an integrity and authenticity of the first message (M1) using the second public key (PKB).

Description

[0001] Computer-implemented method for secure communication, computer-readable medium, and system for secure communication

[0002] Description

[0003] The present invention relates to a computer-implemented method for secure communication, a computer-readable medium, and a system for secure communication.

[0004] Online communication, in particular via e-mail or instant messaging - but also communication independent of human users, like car-to-car or cloud-service-to- cloud-service - has long become indispensable, both in professional and private applications. Since users of these online communication services often share sensitive information over the communication channels, securing these communication channels is of upmost importance, but also technically challenging, in particular in view of the increase of highly sophisticated attacks as server compromise, man-in-the-middle attacks or identity fraud like phishing. Ideally, a secure communication channel between a first and a second entity should satisfy at least the following properties:

[0005] - Confidentiality: messages are not available or disclosed to any other parties except for the first and second entities;

[0006] - Authenticity: the first entity can trust that it communicates with no one else than second entity, and vice versa;

[0007] - Integrity: both entities can be sure that the messages are transmitted without modifications; - Availability: the security properties are always available to both sides, so the communication channel itself is available.

[0008] A fundamental building block for establishing confidentiality, authenticity and integrity are asymmetric cryptographic methods. In an asymmetric cryptographic method, each of the communication partners (in the following exemplarily: Alice and Bob) owns two keys, a public key and a corresponding private key, and only public keys are exchanged between the communication partners. For sending an encrypted message to Bob, Alice only needs to know Bob's public key, not his private key. Having received the encrypted message, Bob is able to decrypt the message using his private key. In additional, to ensure the message really comes from Alice, asymmetric cryptography can also be used to sign the message: Alice uses her private key to sign the message, and Bob can use the public key of Alice to check if the message really came from Alice.

[0009] However, the problem of exchanging the public keys in a way the exchange is trustworthy is not solved by asymmetric cryptography itself. Multiple approaches have been developed in the past, for instance, using a separate secured and trusted channel or trusting an independent third party.

[0010] For obvious reasons, using a separate channel simply transfers the trust problem to a different channel, and using an independent third party requires that both parties trust this third party.

[0011] If someone would provide a self-generated public key to Alice claiming to be Bob, Alice could not be sure that the received public key is in fact associated with Bob, and not to a malicious third party (Charlie). In the latter case, Charlie would be able to decrypt all messages that Alice sends to Bob, while Alice assumes that only Bob is able to decrypt her messages.

[0012] One approach for establishing trust is out-of-band trust establishment, in which the users use a separate, trusted communication channel to verify each other's identities. Users may meet in person to confirm that the keys they already exchanged belong to them. While offering a large degree of security, obviously, the out-of-band approach is not a viable solution in large-scale online settings, at least not as the only pillar for trust establishment. In-person meetings are not an option for users that live far away from each other, and a separate, trusted communication channel may also not available, in particular if users have never met before.

[0013] Against this background, most of today's online communication systems engage a third party with the trust establishment, e.g., the provider of the communication service. In its simplest form, the third party provides a key database maintaining the public keys of the users, so that users can obtain the desired public keys from the third party on request. However, even under the assumption that the third party is trustful in principle, it is a single point of failure, since a malicious party may compromise the key database (principle of integrity could be violated), or it could be unavailable (principle of availability violated).

[0014] A related approach are public key infrastructures (PKIs), which can be considered institutions that bind public keys with respective identities. The binding is established through a process of registration at a registration authority (RA) and issuance of a digital certificate on the key binding by a certification authority (CA), wherein the certificates issued by the CAs can be verified using validation authorities (VAs). This way, a complex chain of certificates can be established, however, users ultimately need to rely on the last certificate of the chain. However, each of the abovementioned components of the PKI (RA, CA, VA) may be undermined by malicious attackers to compromise the PKI.

[0015] Even though all relevant online communication providers have long started providing services as end-to-end encryption and identity management to their users based one or more of the abovementioned techniques, there is still a huge demand for solutions that provide a high degree of security, are eligible for implementation at a high scale, and is easily accessible for the users.

[0016] Given this prior art, it is an object of the present invention to provide an improved method for secure communication, in particular for establishing trust to allow sender's to mutually identify and authenticate them.

[0017] The solution to the respective problem is given by a computer-implemented method for secure communication according to Claim 1, a computer-implemented method for determining a security score according to Claim 16, a computer-readable medium according to Claim 17 and a system according to Claim 18. In particular, the problem is solved by a computer-implemented method for secure communication between a first entity and a second entity, wherein the first entity is associated with a first public key and a corresponding first private key, and the second entity is associated with a second public key and a corresponding second private key, and wherein the method comprising the following steps: a) requesting, by the second entity, the first public key from a communication network security database, in particular hosted on a server; b) receiving, by the second entity, at least the following data:

[0018] - the first public key;

[0019] - a first key verification mechanism associated with the first public key;

[0020] - database integrity data related to the communication network security database; c) verifying, by the second entity, the first public key using the first key verification mechanism; d) sending, by the second entity to the first entity, at least the following data:

[0021] - the first key verification mechanism;

[0022] - the database integrity data; and

[0023] - a first message being asymmetrically encrypted with the first public key and signed with the second private key; e) verifying, by the first entity, the first public key using the first key verification mechanism; f) decrypting, by the first entity, the first message using the first private key; g) verifying, by the first entity, the integrity and authenticity of the first message using the second public key.

[0024] From a high-level perspective, the above method describes the sending of an encrypted and sender-authenticated message from the second entity to a first entity, wherein the second entity requests a public key associated to the first entity from a communication network security database before sending the message, and the first entity, after receiving the message, decrypts the message and verifies its authenticity.

[0025] However, at the same time, the method implements an automated trust establishment between the communication partners, which does not require relying solely on the trustworthiness of a third party, for example, of the server providing the public keys, nor a direct trust between the first and the second entity. This is established by several aspects, which are discussed in more detail in the following.

[0026] In step a), the second entity (= sender) requests a public key of the first entity (= recipient) to the communication network security database, which maintains a mapping of user identifiers (e.g., e-mail addresses) to public keys. In particular, the request may include or consist of a user identifier of the first entity.

[0027] Now, in step b), the second entity receives not only the first entity's public key (= first public key), but also a first key verification mechanism associated with the first public key, and database integrity data related to the communication network security database. By means of the first key verification mechanism and the database integrity data, it is possible to verify that the first public key is consistent with the communication network security database in an efficient manner. For example, if the communication network security database maintains a Merkle tree with hashes of the public keys, the database integrity data can be a root hash of the Merkle tree, and the first key verification mechanism may be an inclusion proof of the first public key with respect to the Merkle tree.

[0028] In step c), the second entity verifies the first public key using the first key verification mechanism. If the verification is successful, the second entity can have a first level of assurance about the first entity's public key and can use the first public keys to send encrypted messages to the first entity.

[0029] In step d), the second entity sends a first message, which is encrypted with the first public key and signed with the second private key, to the first entity. At the same time, in particular attached to the encrypted message, the second entity sends the first key verification mechanism and the database integrity data to the first entity.

[0030] In step e), having received the data sent by the second entity, the first entity performs the first key verification mechanism using a (local) copy of its own public key. In case the verification fails, this indicates an inconsistency of the communication network security database, and the first entity may decide to discard the message sent by the second entity. In step f), the first entity decrypts the first message using the first entity's private key .

[0031] Finally, in step g), the first entity verifies the integrity and authenticity of the message. For verifying the integrity, the first entity may check if the message has been properly signed by the second entity. For verifying the authenticity, the first entity may request the second public key from the communication network security database, compute a signed hash of the message, and compare it with a signed hash added to the message by the second entity.

[0032] Within the context of the present invention, when used in connection with public or private keys, the term "corresponding" indicates that the public key and the private key build a key pair for an asymmetric cryptographic method. In particular, a message that is encrypted by the asymmetric cryptographic method using the public key can only be decrypted using the corresponding private key. Conversely, a message can also be signed with a private key and the signature can be verified by anyone using the corresponding public key.

[0033] Overall, the described method implements an automated trust management between users that neither requires out-of-band key exchange, nor relying on certification authorities or any other third parties. Instead, according to the above method, the entities establish secure communication from the first message on, even when they never communicated with each other before. Importantly, the key verification enables checking consistency (over time as well as over different users) of the communication network security database rather than checking correctness thereof. This way, while attacks compromising the communication network security database cannot be avoided, they can be detected easily and efficiently by the users.

[0034] In one embodiment, the first key verification mechanism is or comprises a key transparency mechanism and / or a sign-off by a trusted user.

[0035] Key transparency is a framework for establishing a key database that user can verify easily and efficiently. For this purpose, each public key is provided together with a proof that the public key is consistent with the current state of the key database. Thus, by implementing a key transparency mechanism, all users of the system can verify that they are provided with the same view of the directory. This way, users can detect provider equivocation attacks.

[0036] Alternatively or additionally, the first key verification may be or comprise a sign- off by a trusted user. This way, a second entity that received a first public key may establish trust by verifying that a third entity, which is trusted by the second entity, provided a sign-off of the first public key before. For example, if Bob has so far not established trust in Alice's public key, but Bob trusts Charlie, and Charlie has established trust in Alice's public key, Bob can assume at least a minimum level of trust in Alice's public key.

[0037] Further, alternatively or additionally, the first key verification mechanism may be or comprise verifying a certificate of a trusted certification authority, in particular of a PKI, as well as for instance the reputation of government organization, or established business organization.

[0038] In one embodiment, the communication network security database is implemented by a centralized database.

[0039] In one embodiment, the communication network security database is implemented by a distributed ledger. This allows not only accessing the current state of the communication network security database, but also tracking the updates and changes to the communication network security database over time.

[0040] In one embodiment, the communication network security database comprises

[0041] - a key database for mapping user identities to public keys; and

[0042] - a hash data structure for verifying an integrity state of the key database.

[0043] As explained above, for detecting that the key database is compromised, it is of upmost importance that an integrity state of the key database can be verified efficiently, which is enabled by the hash data structure.

[0044] In one embodiment, the hash data structure is a Hash tree, in particular a Merkle tree, wherein leaves of the Hash tree correspond to hash values of public keys maintained in the key database. A hash tree is a tree data structure, wherein each leaf node is labelled with a hash value of a piece of data, and every inner node is labelled with a hash value of the combined (e.g., concatenated) labels of its child nodes. A Merkle tree is a specific type of hash tree, in which every node can have at most two child nodes.

[0045] Due to their structure, a hash tree allow efficient verification of its integrity state. In particular, hash trees enable to verify efficiently that a certain leaf node is included in the hash tree, by the concept of inclusion proofs. An inclusion proof comprises essentially a list of hash values that are necessary to re-compute the root hash starting from the leaf node. Verifying the inclusion proof for a certain leaf node thus corresponds to re-computing a root hash using the leaf node and the hash values given in the inclusion proof. The verification is considered successful if the re-computed hash root equals a given hash root.

[0046] By this technique, the integrity state of the communication network security database can be efficiently verified. In particular, any entity that is provided with an inclusion proof (as key verification mechanism) and a root hash (as database integrity data), by verifying the inclusion proof using the own public key, the entity can determine whether the network security database has been manipulated. A recipient of a message can verify that a service or an entity providing his public key (e.g., a key server) did not trick the sender of the message (see step e).

[0047] Therefore, in one embodiment, the first key verification mechanism is or comprises verifying an inclusion proof of the first public key in the Merkle tree; and the database integrity data is or comprises a root hash of the Merkle tree.

[0048] In one embodiment, the communication network security database further comprises a data structure that stores, for at least one pair of entities, an explicitly defined trust statement between the pair of entities and / or a computed trust statement based on communication activities of the pair of entities or explicit trust statements or implicit but acknowledged trust assertions.

[0049] In one embodiment, the method further comprises the following steps, in particular performed after steps a) to g): h) requesting, by the first entity, the second public key, from the communication network security database, given the key database integrity data; i) receiving, by the first entity, at least the following data:

[0050] - the second public key;

[0051] - a second key verification mechanism associated with the second public key; j) verifying, by the first entity, the second public key using the second key verification mechanism; k) sending, by the first entity to the first entity, at least the following data:

[0052] - the second key verification mechanism;

[0053] - the database integrity data; and

[0054] - a second message being asymmetrically encrypted with the second public key and signed with the first private key; l) verifying, by the second entity, the second public key using the second key verification mechanism; m) decrypting, by the second entity, the second message using the second private key; n) verifying, by the second entity, an integrity and authenticity of the second message using the first public key.

[0055] The additional steps h) to n) describe the process of the first entity sending an answer to the message received by the second entity (see steps a) to g) of the method described above).

[0056] That is, the additional steps h) to n) essentially complement the steps a) to g) of the method described above, except for steps h) and i), which take into account that the data received by the first entity relate to a certain state of the network security database, which is specified by the database integrity data. Therefore, in step h), the first entity requests the second public key and a second key verification mechanism for the given database integrity data, and in step i), there is no need to receive the database integrity data.

[0057] After the first entity successfully verified the second public key in step j), the first entity has established trust with respect to the second entity. After the second entity successfully verified the received information in step I), the second entity has established trust with respect to the first entity. That is, after step m), both entities can trust each other.

[0058] In one embodiment, the method further comprises the following steps: rl) creating, by the first entity, a key pair including the first public key and the first private key; r2) sending, by the first entity to the server, a request for key registration and / or key update, wherein the request includes an identifier of the first entity, in particular an e-mail address, and the first public key; r3) adding, by a server, the request to a queue; and r4) updating, by the server, the communication network security database according to each request in the queue.

[0059] In particular, the above steps rl) to r4) may be performed when the first entity initially registers at the server, or then a user requests to update his / her public key.

[0060] Between steps r2) and r3), the server may implement an additional verification step to verify that the first entity can validly claim the first public key and the identifier.

[0061] Step r4) may include at least one of the following:

[0062] - updating the key database to include / update a key-identity pair according to each request; and

[0063] - updating the hash data structure, in particular re-computing a hash tree.

[0064] In one embodiment, step r4) is deferred until a size of the queue exceeds a threshold value, in particular in terms of number of requests. According to this embodiment, not every request for registration / updating a key triggers a computationally expensive updating of the hash data structure. Instead, this step is performed in epochs, i.e., whenever a certain amount of requests has been collected in the queue.

[0065] In one embodiment, the method further comprises:

[0066] - generating a plurality of trust words, based on the first public key and the second public key; - manually comparing, by the first entity and the second entity, the plurality of trust words, in particular via out-of-band communication; and

[0067] - updating, by the first entity and / or the second entity, a trust level associated with the second entity and / or the first entity.

[0068] In this context, a trust word can be understood as any piece of data, in particular a string of characters, that is uniformly generated for both the first and the second entity based on a combination of their public keys.

[0069] Trust words may be generated by applying a cryptographic hash function, in particular RIPEMD-160, to a combination of the first public key and the second public key, or hash values thereof. Preferably, trust words should be newly generated for each trust word check.

[0070] Manually comparing the trust words may be handled by the first and the second entity via out-of-band communication, e.g., in a personal meeting. Equal trust words indicate that both entities obtained an authentic copy of the public keys from the communication network security database.

[0071] Therefore, this embodiment enables that each entity can, in particular after having established a minimum level of trust, further improve the trust level of the respective peer by manually comparing trust words, which leads to an improved trust level.

[0072] Alternatively or additionally to comparing trust words, any other method for out- of-band verification of public keys between the two communication devices may be used. In particular, such methods may be based on the physical proximity of the two communication devices, and may involve

[0073] - scanning, by one communication device, a QR code displayed by the other communication device;

[0074] - detecting, by one communication device, an audio signal played by the other communication device;

[0075] - detecting, by one communication device, a vibration or motion pattern performed by the other communication device. The respective code (e.g., QR code, audio signal, vibration or motion pattern) may encode one of the public keys or a combination of both public keys.

[0076] In one embodiment, the method further comprises:

[0077] - computing, by the first entity, a first security score associated with the first message; and / or

[0078] - computing, by the second entity, a second security score associated with the second message.

[0079] By means of the abovementioned security scores, a recipient of a message can be provided with a further indicator for the trustworthiness of the message. In addition, the computed security scores may be processed by the respective communication software, e.g., e-mail clients, to automatically filter messages whose security score does not exceed a security score threshold.

[0080] In one embodiment, computing the first and / or the second security score includes computing one or more of the following scores, related to a message sent from a sender to a recipient:

[0081] - a sender identity score;

[0082] - a message cryptography score;

[0083] - a message content score; and

[0084] - a message context score.

[0085] In particular, all of the abovementioned scores may be a (normalized) numeric value, e.g. in an interval between 0 and 100. Moreover, for each of the abovementioned scores, respective trust levels may be defined, which correspond to intervals of score values.

[0086] The sender identity score may indicate the trustworthiness of the sender, e.g. based on information indicating whether the sender's public key is marked as reset, malicious, trusted by third parties, trusted personally by successfully comparing trust words, etc.

[0087] For example, the sender identity score may be determined according to the following criteria:

[0088] The message cryptography score may indicate a cryptography state of the message, e.g. based on the types of encryption and signatures used.

[0089] For example, the cryptography score may be determined according to the following criteria:

[0090] The message content score may indicate whether the message appears trustworthy due to its content as such, e.g., based on information whether the mail contains links to malicious URLs, suspicious attachments, problematic calls for action, etc.

[0091] For example, the message content score may be determined according to the following criteria:

[0092] The message context score may indicate metadata like the sending time / date of the message, location, etc.

[0093] In particular, the first and / or the second security score may be calculated as a weighted sum of one or more of: the sender identity score, the message cryptography score, the message content score, and the message context score.

[0094] In one embodiment, the sender identity score is computed based on the result of verifying a public key using a key verification mechanism. As explained earlier, within the framework of the method described above, using the key verification mechanism is an efficient way to establish trust, at least to a certain level, and this trust level can be considered in computing the sender identity score, which can be part of the first and / or the second security score.

[0095] In one embodiment, as already outlined above, the sender identity score can be computed based on the result of a comparison of trust words.

[0096] In one embodiment, computing the sender identity score includes:

[0097] - accessing a trust network of the recipient, wherein the trust network includes signed trust information of one or more members of the trust network, the trust information indicating a verification state of the public key of the sender; and

[0098] - computing the sender identity score based on the trust information.

[0099] This embodiment enables a first entity to establish trust w.r.t. the second entity, at least to a certain level, by incorporating a (personal) trust network of the first entity, wherein the trust network indicates trust information w.r.t. the second entity of other entities, as well the relation between the first entity and the other entities. For example, if Bob has so far not established trust in Alice's public key, but the trust network indicates that Bob trusts Charlie and that Charlie has established trust in Alice's public key, Bob can assume at least a minimum level of trust in Alice's public key.

[0100] The object of the present invention is further solved by a computer-implemented method for determining a security score based on a trust network. In particular, the method may be implemented to determine security scores or levels within one of the methods described above.

[0101] The method for determining a security score comprises the following steps: loading a trust network, in particular as a directed acyclic graph, wherein the trust network includes a plurality of signed trust statements, wherein each trust statement indicates that a first entity has established trust in a public key of a second entity;

[0102] - computing a path from a source entity to a target entity in the trust network;

[0103] - determining a security score based on trust statements included in the path. By this method, the present invention also provides a solution for the issue of establishing trust between communication partners even if they are directly unknown to each other and have not communicated and directly exchanged public keys before. For this, a first entity (source entity) checks the trustworthiness of the public key from a second entity (target entity) on the trust network and infers indirect trust by computing the trustworthiness of a directed acyclic graph derived from the trust statements between individuals that are persisted on the network, which is then used to determine the security score.

[0104] In one embodiment, the process to determine the trust between communication partners if they have not directly communicated before is defined as follows, with a third entity having trusted the public key of the second entity before: h) sending, by the second entity, a message to the first entity, including the message payload and the public key of the second entity and a key verification mechanism; i) requesting, by the first entity, to the network server, a directed acyclic graph with a path from the first entity to the second entity. If such a graph can be directly constructed out of the data on the network server, this will result in at least sending to the first entity a response that shows that there is a connection between the first entity and the second entity via the third entity. If such a connection cannot be computed, the network server computes the closest possible distance between the two entities based on a mapping of the two entities to a weight based on factors. In one possible implementation, the factors may be computed by a reenforced machine learning algorithm; j) verifying, by the first entity, the public key of the third entity and the trust assertion by the third entity regarding its trust towards the second entity and the trust data provided by the network server so that the first entity can also verify the integrity of the data; k) using, by the first entity, the trust assertion of the third entity towards the second entity to compute a derived trust statement and updating the security score accordingly; l) updating, by the first entity, the trust graph on the network server to express that the first entity used a derived trust assertion.

[0105] The method described above may be modified for use in a trust system that provides assurances about identities without revealing the entities that make statements. Here, a protocol is required that maintains privacy (not disclosing information about relationship between communication entities) while at the same time can reliably be used to determine direct and indirect trust by inferring information from a directed acyclic graph.

[0106] In one embodiment, in the above protocol, in step i)-j), if the network server can construct a direct acyclic graph between the first entity and the second entity, the network server does not reveal to the first entity that the third entity trusts the second entity by applying the following protocol: i'.l) the second entity queries the network server to request statements that issue proof about the identity of the second entity; i'.2) the network server provides such a proof by handing out a previously certified public keys of the second entity certified by a third entity, or more entities, if available, including a reputation factor that is derived from the amount of trust statements for each individual third or more identity, stored on the network server and signed by the third or more identity and published to the hash tree of the server; i'.3) the second entity uses the certified proof to construct a non-interactive zero knowledge proof (for instance: zk-SNARK) and sends its public key alongside the zk-SNARK proof about any additional third or more identity including the reputation factor derived from the third or more identity to the first entity; j'.l) verifying, by the first entity, the public key of the second entity and the zk-SNARK proof trust towards the second entity and the trust data provided by the network server so that the first entity can also verify the integrity of the data;

[0107] In one embodiment, for the above protocol to work, whenever any entity makes a trust assertion about any other entity, the following protocol is applied to persist data on the network server so that it can be used to determine a trust relationship between entities on the directed acyclic graph: r4) the trust statement that a third entity makes about a second entity is persisted on the network server in a way that the third entity signs with its private key a certification statement about the public key of the second entity, including a reputation factor of the third entity in regards to trust statement that third entity owned from a forth identity, or any more identities, over the course of time.

[0108] The object is further solved by a computer-readable medium comprising for implementing a method for secure communication as described above, in particular when being executed by at least one processor.

[0109] In one embodiment, the computer-readable medium comprises instructions for implementing a method for secure communication as described above when being executed by at least a first processor and a second processor.

[0110] In particular, the first processor may belong to a first communication device associated with the first entity, and the second processor may belong to a second communication device associated with the second entity. This way, the method for secure communication described above may be implemented in a distributed way.

[0111] Moreover, the object is solved by a system for secure communication between a first entity and a second entity, wherein the system comprises:

[0112] - a first communication device associated with the first entity;

[0113] - a second communication device associated with the second entity; and

[0114] - a server configured to maintain a communication network security database, wherein the system is configured to implement the method as described above. With respect to the computer-readable medium and the system, the resulting advantages and technical effects are similar to the advantages and technical effects of the method as described above.

[0115] It should be understood that the features and advantages resulting therefrom that have been described with respect to the method according to the present invention are applicable or transferable to the computer-readable medium and to the system according to the invention and vice versa. Specifically, the components of the system are designed to perform the method steps according to the invention. Likewise, the functions of the components of the system according to the invention described above are applicable as method steps of the method according to the invention.

[0116] In the following, embodiments of the invention are described with respect to the figures, wherein

[0117] Fig. 1 shows the high-level structure of a system according to one embodiment;

[0118] Fig. 2a-b show a key database and a corresponding Merkle tree;

[0119] Fig. 3 shows the registration of a user at the communication network security database according to one embodiment;

[0120] Fig. 4 shows the communication between a first and a second entity with automated trust management according to one embodiment.

[0121] In the following figures, the same reference characters are used for the same parts or parts with the same function. For the sake of readability, the terms "first entity" and "second entity" are synonymously for "first communication device" and "second communication device", respectively.

[0122] Figure 1 shows the high-level structure of a system for secure communication according to one embodiment of the present invention.

[0123] According to this embodiment, the network security database is provided by a server 20.

[0124] The system further comprises the first and second communication devices 10A, 10B associated first and second entities A, B, respectively. Both communication devices are configured to communicate via e-mail on the communication channel 30.

[0125] Moreover, both communication devices 10A and 10B are configured to implement the method of the present invention, in particular by means of a plugin installed in the e-mail clients of both communication devices 10A and 10B. Both communication devices 10A and 10B are configured to communicate with the server 20.

[0126] The server 20 maintains the communication network security database, which includes two data structures: the key database 21, which includes a mapping of e- mail addresses to public keys, and the Merkle tree 22, which enables to verify efficiently an integrity state of the key database 21, in particular the inclusion of a certain public key.

[0127] Exemplarily contents of the key database 21 and the corresponding Merkle tree 22 are shown in Figure 2a and Figure 2b.

[0128] Figure 2a shows the key database 21 including the mapping of e-mail addresses to public keys for four users: For example, the public key PKA is mapped to the user having the e-mail address alice@planck.security, the public key PKB is mapped to the user having the e-mail address bob@planck.security, and so on.

[0129] Figure 2b shows the Merkle tree 22 corresponding to the contents of the key database 21 from Figure 2a.

[0130] In the shown example, the Merkle tree 22 is a labeled binary tree, wherein each node is labeled with the value of a hash function h().

[0131] Each of the four leaf nodes corresponds to one public key stored in the key database 21 and is labeled with the hash value of the respective public key. That is, the four leaf nodes are labeled with the hash values h(PKA), h(PKB), h(PKC), and h(PKD).

[0132] Each internal node (parent node) is labeled with a hash value of a concatenation of the hash values of its children node's hashes. For example, the parent node of the leaf nodes h(PKA) and h(PKB) is labeled with the hash value of h(PKA) + h(PKB), that is, h(h(PKA)+h(PKB)), wherein '+' denotes any suitable function for concatenation.

[0133] The label of the tree root, which is h(h(h(PKA)+h(PKB))+h(h(PKC)+h(PKD))), is called the root hash of the Merkle tree.

[0134] As described in the following, the integrity state of the Merkle tree 22, in particular the inclusion of a certain public key, can be efficiently verified by means of inclusion proofs. Inclusion proofs can be considered a minimum list of hash nodes from the Merkle tree together with supplementary information that allow recreation of a branch of the Merkle tree.

[0135] For instance, an inclusion proof for the public key PKA in the Merkle tree 22 comprises the following hash values and, for each node except the root, a piece of information ([L] or [R]) indicating whether the node is the left (L) or right (R) children of its parent node. That is, for the Merkle tree 22 shown in Figure 2b, the inclusion proof for the first public key PKA is:

[0136] • h(PKA) [L]

[0137] • h(PKB) [R]

[0138] • h(h(PKC)+h(PKD)) [R]

[0139] • h(h(h(PKA)+h(PKB))+h(h(PKC)+h(PKD)))

[0140] Based on this information and the construction method described above, it is possible to recreate the left branch of the Merkle tree 21.

[0141] In particular, given the above inclusion proof, it is possible for the first entity to verify whether the Merkle tree 22 includes its true public key, by replacing h(PKA) by a local (trustworthy) copy of its public key in the inclusion proof, and recomputing the Merkle tree 22 using the inclusion proof. If the recomputed root hash equals the root hash provided together with the inclusion proof, this proves that the true public key was included in the Merkle tree 22. Figure 3 shows the registration of a user, namely the first entity A, at the server 20 according to an embodiment.

[0142] In step Rl, the first entity A creates a key pair of the first public key PKA and the first private key SKA.

[0143] In step R2, the first entity A sends a registration request to the server 20, wherein the registration request includes the first public key PKA and the first entity's e-mail address EA as a user identifier.

[0144] In step R3, the server 20 adds the registration request of the first entity A to a queue for registration or update requests to be processed for the next epoch.

[0145] In step R4, the server 20 processes the requests in the queue. Specifically, the server 20 adds the first public key PKA and the first entity's e-mail address EA to the key database 21, and re-computes the Merkle tree 22 for the updated key database 21.

[0146] Figure 4 shows the communication between the first entity A and the second entity with automated trust management according to an embodiment of the method of the present invention.

[0147] In particular, the communication shown in Figure 4 may be the first communication between both entities A and B ever, so that each of the entities is unknown to the other. However, for this example, it is assumed that both entities A and B are registered at the server, for example, as explained in Figure 3 above.

[0148] For ease of presentation, the sequence diagram shown in Figure 4 is divided into a first phase (steps SI to S5) and a second phase (steps S6 to S10) by the dashed line. On a high level, in the first phase, the second entity B sends a first encrypted and signed message to the first entity A after having established trust in the first entity A, at least to the degree of a basic trust level; in the second phase, in response to the received first message, the first entity A sends a second encrypted and signed message to the second entity B after having established trust in the second entity B, at least to the degree of a basic trust level. More specifically, steps SI to S10 are as follows: In step SI, the second entity B requests a public key of the first entity A from the server 20. For this purpose, the request includes the e-mail address EA of the first entity A.

[0149] In step S2, the server 20 performs a lookup in its key database using the e-mail address EA, and sends the first entity's public key (= first public key) PKA to the second entity B, together with an inclusion proof IPA for the first public key and a root hash RH of the Merkle tree.

[0150] In step S3, the second entity B verifies the received first public key PKA by verifying the inclusion proof IPA using the root hash RH. If this was successful, the second entity B has established a basic level of trust in the first entity as the second entity B can be sure that the received public key PKA is consistent with the key database on the server 20.

[0151] In step S4, the second entity B sends a first message Ml to the first entity A, the first message Ml being encrypted with the first public key PKA and signed with the second entity's private key SKB. Together with the message Ml, in particular as attachment of the e-mail or in a header thereof, the inclusion proof IPA and the root hash RH are sent to the first entity A.

[0152] In step S5, the first entity A verifies the received data, in particular, the first entity verifies the inclusion proof IPA using a local (i.e., authentic) copy of the first public key PKA. This way, the first entity can assure that the first public key PKA provided to the second entity B by the server 20 was not manipulated.

[0153] Moreover, the first entity A verifies the integrity and authenticity of the first message Ml. For this purpose, the first entity checks whether the first message includes a signed hash of the first message, and compares it with a recomputed hash. Moreover, verifies that the signature of the hash is valid, in particular by requesting the sender's public key from the server 20.

[0154] At that time (i.e., at the end of the first phase), assuming that all verification steps have been successful, the first entity A may decrypt the first message Ml using the first private key corresponding to the first public key. The steps of the second phase (S6 to S10) essentially complement the steps SI to S5.

[0155] In step S6, the first entity requests a public key of the second entity B from the server 20 using the second entity's e-mail address EB as user identifier. Besides EB, the request also includes the root hash RH.

[0156] In step S7, the server 20 performs a lookup in its key database using the e-mail address EB and for the given root hash RH. This way, it is ensured that the first entity A is provided with the second entity's public key (= second public key) PKB as it was contained in the key database at the state where the second entity B obtained the first entity's public key PKA. In other words, it is ensured that both entities A and B are provided with the same view on the server 20. As a result of step S7, the server 20 sends the second public key PKB together with a corresponding inclusion proof IPB to the first entity A.

[0157] In step S8, the first entity A verifies the received second public key PKB by verifying the inclusion proof IPB using the root hash RH. If this was successful, also the first entity A has established a basic level of trust in the second entity B as the first entity A can be sure that the received public key PKB is consistent with the key database on the server 20.

[0158] In step S9, the first entity A sends a second message M2 (in particular, a response to the first message Ml) to the second entity B, the first message M2 being encrypted with the second public key PKB and signed with the first private key SKA. Together with the message M2, in particular as attachment of the e-mail or in a header thereof, the inclusion proof IPB and the root hash RH are sent to the second entity B.

[0159] In step S10, the second entity B verifies the received data, in particular, the second entity B verifies the inclusion proof IPB using a local (i.e., authentic) copy of the second public key PKB. This way, the second entity can assure that the second public key PKB provided to the first entity A by the server 20 was not manipulated.

[0160] Moreover, the second entity B verifies the integrity and authenticity of the second message M2 analogous to the corresponding process described above. At that time (i.e., at the end of the second phase), assuming that all verification steps have been successful, the second entity B may decrypt the second message M2 using the second private key corresponding to the first public key PKA; moreover, the first entity A can consider the second entity B as trusted.

[0161] It will be understood that, while various aspects of the present disclosure have been illustrated and described by way of example, the invention described herein is not limited thereto, but may be otherwise variously embodied as suggested by the disclosure.

[0162] At this point it should be pointed out that all parts described above are to be regarded as independent embodiments or further developments of the invention, in each case on their own and in combination or any sub-combination, even without the features additionally described in the respective context, even if these have not been explicitly identified individually as optional features in the respective context, for example by using: "in particular", "preferably", "for example", "e.g.", "possibly" , round brackets, etc. Deviations therefrom are possible. Specifically, it should be noted that the word "in particular" or round brackets do not indicate features that are mandatory in the respective context.

[0163] List of reference numerals

[0164] A first entity

[0165] B second entity

[0166] 10A first communication device (associated with first entity A)

[0167] 10B second communication device (associated with second entity B)

[0168] 20 server

[0169] 21 key database

[0170] 22 Merkle tree

[0171] EA e-mail address of first entity (A)

[0172] EB e-mail address of second entity (B)

[0173] IPA inclusion proof of first public key

[0174] IPB inclusion proof of second public key Ml first message

[0175] M2 second message

[0176] PKA first public key (associated with first entity A)

[0177] PKB second public key (associated with second entity B)

[0178] R1 generating key pair

[0179] R2 sending registration request

[0180] R3 adding registration request to queue

[0181] R4 re-computing Merkle tree

[0182] RH root hash

[0183] 51 requesting first public key

[0184] 52 sending first public key, root hash, and inclusion proof

[0185] 53 verifying first public key

[0186] 54 sending first message

[0187] 55 verifying first public key

[0188] 56 requesting second public key for given root hash

[0189] 57 sending second public key, inclusion proof

[0190] 58 verifying second public key

[0191] 59 sending second message

[0192] S10 verifying second public key

[0193] SKA first private key (associated with first entity A)

[0194] SKB second private key (associated with second entity B)

Claims

Claims1. Computer-implemented method for secure communication between a first entity (A) and a second entity (B), wherein the first entity (A) is associated with a first public key (PKA) and a corresponding first private key (SKA), and the second entity (B) is associated with a second public key (PKB) and a corresponding second private key (SKB), and wherein the method comprising the following steps: a) requesting, by the second entity (B), the first public key (PKA) from a communication network security database, in particular hosted on a server (20); b) receiving, by the second entity (B), at least the following data:- the first public key (PKA);- a first key verification mechanism (IPA) associated with the first public key (PKA);- database integrity data (RH) related to the communication network security database; c) verifying, by the second entity (B), the first public key (PKA) using the first key verification mechanism (IPA); d) sending, by the second entity (B) to the first entity (A), at least the following data:- the first key verification mechanism (IPA);- the database integrity data (RH); and- a first message (Ml) being asymmetrically encrypted with the first public key (PKA) and signed with the second private key (SKB); e) verifying, by the first entity (A), the first public key (PKA) using the first key verification mechanism (IPA); f) decrypting, by the first entity (A), the first message (Ml) using the first private key (SKA); g) verifying, by the first entity (A), an integrity and authenticity of the first message (Ml) using the second public key (PKB).

2. Method according to claim 1, wherein the first key verification mechanism (IPA) is or comprises a key transparency mechanism and / or a sign-off by a trusted user.

3. Method according to any one of the previous claims, wherein the communication network security database is implemented by- a centralized database; and / or- a distributed ledger.

4. Method according to any one of the previous claims, wherein the communication network security database comprises- a key database (21) for mapping user identities to public keys; and- a hash data structure (22) for verifying an integrity state of the key database (21).

5. Method according to any one of the previous claims, in particular to Claim 4, wherein the hash data structure (22) is a Hash tree, in particular a Merkle tree, wherein leaves of the Hash tree correspond to hash values of public keys maintained in the key database (21).

6. Method according to any one of the previous claims, in particular according to Claim 5, wherein the first key verification mechanism (IPA) is or comprises verifying an inclusion proof of the first public key (PKA) in the Merkle tree; and the database integrity data (RH) is or comprises a root hash of the Merkle tree.

7. Method according to any one of the previous claims, further comprising the following steps, in particular performed after the steps a) to g): h) requesting, by the first entity (A), the second public key (PKB) from the communication network security database, given the key database integrity data (RH); i) receiving, by the first entity (A), at least the following data:- the second public key (PKB);- a second key verification mechanism (IPB) associated with the second public key (PKB); j) verifying, by the first entity (A), the second public key (PKB) using the second key verification mechanism (IPB);k) sending, by the first entity (A) to the first entity (B), at least the following data:- the second key verification mechanism (IPB);- the key database integrity data (RH); and- a second message (M2) being asymmetrically encrypted with the second public key (PKB) and signed with the first private key (SKA); l) verifying, by the second entity (B), the second public key (PKB) using the second key verification mechanism (IPB); m) decrypting, by the second entity (B), the second message (M2) using the second private key (SKB); n) verifying, by the second entity (B), an integrity and authenticity of the second message (M2) using the first public key (PKA).

8. Method according to any one of the preceding claims, further comprising the following steps: rl) creating, by the first entity (A), a key pair comprising the first public key (PKA) and the first private key (SKA); r2) sending, by the first entity (A) to a server (20), a request for key registration and / or key update, wherein the request includes an identifier of the first entity (A), in particular an e-mail address, and the first public key (PKA); r3) adding, by the server (20), the request to a queue; and r4) updating, by the server (20), the communication network security database according to each request in the queue.

9. Method according to any one of the preceding claims, in particular according to Claim 8, wherein step r4) is deferred until a size of the queue exceeds a threshold value.

10. Method according to any one of the preceding claims, further comprises:- generating a plurality of trust words, based on the first public key (PKA) and the second public key (PKB);- manually comparing, by the first entity (A) and the second entity (B), the plurality of trust words, in particular via out-of-band communication; and- updating, by the first entity (A) and / or the second entity (B), a trust level associated with the second entity (B) and / or the first entity (A).

11. Method according to any one of the preceding claims, further comprising:- computing, by the first entity (A), a first security score associated with the first message (Ml) and / or a sender thereof; and / or- computing, by the second entity (B), a second security score associated with the second message (M2) and / or a sender thereof.

12. Method according to any one of the preceding claims, in particular according to Claim 11, wherein computing the first and / or the second security score includes computing one or more of the following scores, related to a message (Ml, M2) sent from a sender to a recipient:- a sender identity score;- a message cryptography score;- a message content score; and- a message context score.

13. Method according to any one of the preceding claims, in particular according to Claim 12, wherein the sender identity score is computed based on the result of verifying a public key (PKA, PKB) using a key verification mechanism (IPA, IPB).

14. Method according to any one of the preceding claims, in particular according to any one of Claims 11 to 13, wherein the sender identity score is computed based on the result of a comparison of trust words.

15. Method according to any one of the preceding claims, in particular according to any one of Claims 12 to 14, wherein computing the sender identity score includes:- accessing a trust network of the recipient, wherein the trust network includes signed trust information of one or more members of the trust network, the trust information indicating a verification state of the public key (PKA, PKB) of the sender; and- computing the sender identity score based on the trust information.

16. Computer-implemented method for determining a security score based on a trust network, in particular as part of the method of any one of Claims 1 to 15, comprising the following steps:- loading a trust network, in particular as a directed acyclic graph, wherein the trust network includes a plurality of signed trust statements, wherein each trust statement indicates that a first entity has established trust in a public key of a second entity;- computing a path from a source entity to a target entity in the trust network;- determining a security score based on trust statements included in the path.

17. Computer-readable medium comprising instructions for implementing a method according to any one of the preceding claims, in particular when being executed by at least one processor.

18. System for secure communication between a first entity (A) and a second entity (B), wherein the system comprises:- a first communication device (10A) associated with the first entity (A);- a second communication device (10B) associated with the second entity (B); and- a server (20) configured to maintain a communication network security database, wherein the system is configured to implement the method of any one of the claims 1 to 16.

Images