Secure communication method and device using a deterministically derived identifier
The method uses deterministic hierarchical wallets with asymmetric keys to minimize memory storage and enhance security in secure communication, particularly beneficial for devices with limited memory, such as drones, by deriving identifiers and keys offline and leveraging a distributed ledger for authentication.
Patent Information
- Application Number
- FR2024003444
- Authority / Receiving Office
- FR · FR
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-04-03
- Publication Date
- 2025-10-10
AI Technical Summary
Existing secure communication methods, such as identity-based cryptography, require significant memory storage for public keys and rely on a centralized trusted authority that can compromise security, while hierarchical deterministic wallets are limited to cryptocurrency transactions.
A secure communication method using a deterministic hierarchical wallet with asymmetric master keys, where identifiers and encryption/decryption keys are deterministically derived, allowing secure communication with minimal memory storage and offline configuration, and optionally utilizing a distributed ledger for authentication.
Reduces the memory requirements for secure communication by storing only minimal cryptographic elements and enhances security through offline key derivation and distributed ledger verification, suitable for devices with limited memory like drones.
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
Title of the invention: Secure communication method and device using a deterministically derived identifier TECHNICAL FIELD OF THE INVENTION
[0001] The subject of the invention is a secure communication method. More specifically, the invention relates to a secure communication method using a deterministically derived identifier. This secure communication takes place between devices, called peers in the present text.
[0002] The object of the invention is to reduce the volume of permanent memory of a peer necessary for securing the peer's communications. STATE OF THE ART
[0003] Many techniques allow the securing of communications between devices connected by a communication network. The most widespread generally involve the use of public key infrastructure (PKI). However, such techniques require each device to distribute and store numerous public keys. Identity-based cryptography, "Identity Based Encryption" (IBE), greatly simplifies key management by using the identifier of a device as a public key, which allows each device to store only identifiers in memory. However, identity-based cryptography has many disadvantages, in particular the need for a centralized trusted authority that generates private keys for user devices from their identifier when these devices need to encrypt a message before its transmission.This centralized trusted authority is a major point of compromise for the security of all devices because it is able to decrypt the communications of each user device and usurp their identity vis-à-vis other user devices.
[0004] Another technology, a priori incompatible with identity-based cryptography, has been described in the context of cryptocurrencies and standardized by the "Bitcoin Improvement Proposal BIP32" also called BIP32 standard, then by BIP39 and BIP44. These are hierarchical deterministic wallets "Hierarchical Deterministic Wallet" (HDW). These are an advanced form of wallet for cryptocurrencies that allows to create an organized structure of accounts and sub-accounts from a single initial seed.
[0005] This seed is a source of entropy from which keys will be generated and can be used to restore the wallet on another device. Using this seed, a derivation function creates a parent-child structure of keys and addresses hierarchically. That is, each key is capable of producing subkeys, which in turn can generate other subkeys, and so on. The first key generated from the seed is called the master key. It is at the top of the hierarchy and will be used to generate child keys. Keys are generated according to specific derivation paths that dictate how to navigate the key tree. This allows accounts to be organized for different uses or cryptocurrencies without co-mingling funds.
[0006] For each address in an HDW wallet, there is a corresponding public key that can be shared and used to receive funds, and a private key that must be kept secret and is used to authorize outgoing transactions.
[0007] Users can generate multiple addresses from their HDW wallet without having to back up each individual private key. A single seed can restore the entire wallet with all its associated keys and transactions.
[0008] Hierarchical deterministic wallets are dedicated to securing cryptocurrency transactions, particularly Bitcoin. They are used in decentralized communication networks. References
[0009] “Identity based encryption from the Weil pairing” by D. Boneh and M. Franklin, SIAM J. of Computing, Vol. 32, No. 3, pp. 586-615, 2003. Statement of the invention
[0010] The present invention aims to remedy all or part of the drawbacks of the state of the art cited above.
[0011] To this end, according to a first aspect, the invention relates to a secure communication method between a sending peer and a receiving peer. The communication method involves an external actor having a deterministic hierarchical wallet. The deterministic hierarchical wallet comprises a pair of asymmetric master keys, consisting of a master private key kmaster and a master public key Kmaster. The sending peer and the receiving peer comprise an electronic memory and a processing unit. The communication method comprises the following steps:
[0012] - the external actor assigns an index j to the receiving peer in the hierarchical portfolio deterministic archaic,
[0013] - the external actor determines an identifier Idj of the receiving peer in a definite manner terministic from the index j of the receiving peer and the master public key Kmaster,
[0014] - the external actor generates a decryption key IBE aDKey[Idj,kmaster] from the identifier of the receiving peer Idj and the master private key kmaster,
[0015] - the external actor configures the receiving peer by recording in the electronic memory electronics of the receiving peer the IBE decryption key aDKey[Idj,kmaster],
[0016] - the external actor configures the sending peer by recording in the electronic memory electronics of the sending peer the index j of the receiving peer and the master public key Kmaster,
[0017] - the sending peer deterministically determines the identifier Idj of the receiving peer from the index j of the receiving peer and the master public key Kmaster,
[0018] - the sending peer calculates an IBE encryption key aCKey[Idj,Kmaster] from the identifier of the receiving peer Idj and the master public key Kmaster
[0019] - the sending peer encrypts a message using the encryption key IBE aCKey[Idj, Kmaster]?
[0020] - the sending peer sends the encrypted message to the receiving peer,
[0021] - the receiving peer decrypts the encrypted message using the IBE key of de encryption aDKey[Idj, kmmaster].
[0022] A peer is understood to mean a device configured to communicate with other similar devices.
[0023] A deterministic hierarchical wallet is a system for generating cryptographic keys from an initial seed in a deterministic manner. The initial seed is used to generate parent keys which are then used to derive child keys. The cryptographic keys generated from a deterministic hierarchical wallet do not need to be saved; they can be regenerated identically for each use.
[0024] An external actor is understood to mean a peer device manufacturer or an entity responsible for configuring peer devices that will constitute the members of a decentralized communication network.
[0025] Such arrangements allow, when the steps performed by the external actor are performed offline (the peers are not connected to a communication network), secure communication between the receiving peer and the sending peer requiring only a few cryptographic elements to be stored in the electronic memory of the peers. Indeed, the identifier and the encryption key are calculated by the sending peer for sending a message and therefore do not need to be stored in the electronic memory of the sending peer.
[0026] In particular embodiments, the invention may further comprise one or more of the following characteristics, taken in isolation or in all technically possible combinations.
[0027] According to one embodiment, the steps of deterministically determining the identifier Idj are carried out using a derivation function using an HMAC-SHA512 hash function.
[0028] According to one embodiment, the communication method comprises the following additional steps:
[0029] - the sending peer calculates a public key Kih from a private key kih,
[0030] - the sending peer discloses the public key Kih to the receiving peer,
[0031] - the sending peer generates a signature of the message using the encrypted message and the private key kih,
[0032] - the sending peer sends the signature of the message to the receiving peer,
[0033] - the receiving peer verifies the signature of the message using the public key Kihet the encrypted message.
[0034] Such provisions allow the receiving peer to verify the authenticity of the received message.
[0035] According to one embodiment, the sending peer comprises a hardware security component and the private key kih is generated within the hardware security component.
[0036] The hardware security component makes it possible to additionally secure the private key of the sending peer and thus additionally limit in particular the risk that the identity of the sending peer is usurped.
[0037] According to one embodiment, the sending peer and the receiving peer are peers of a network of peers sharing a distributed ledger and the communication method comprises the following additional steps:
[0038] - the sending peer generates a hash of the encrypted message,
[0039] - the sending peer authenticates to the distributed ledger using a private key kih,
[0040] - the sending peer publishes in the distributed ledger a transaction comprising, the identifier of the receiving peer and the hash of the encrypted message,
[0041] - the receiving peer verifies that the hash of the encrypted message published in the registry distributed corresponds to the received encrypted message.
[0042] A peer network means several devices connected remotely by, for example, an internet or GSM network or a combination of several remote connection technologies. Each device, called a peer, in the peer network may include at least one processing unit, a memory and a communication module.
[0043] A distributed ledger is understood to mean a decentralized ledger or log shared between peers in the peer network, possibly replicated by each peer in the peer network, and in which operations or publications are recorded in a certain order and can no longer be modified once recorded. A decentralized ledger can be created using technology such as a blockchain or a decentralized database or a "Directed Acyclic Graph".
[0044] The use of a distributed ledger allows the receiving peer to verify the authenticity of the message without requiring the sending peer's public key to be stored in memory.
[0045] According to one embodiment, the distributed ledger is a blockchain distributed ledger and the blockchain comprises a smart contract issuing a notification to the receiving peer, the notification including the hash of the encrypted message.
[0046] Using a blockchain smart contract to transmit the hash of the encrypted message allows the transmission of the hash to be triggered by publishing the transaction in the ledger. The receiving peer will not need to retrieve the hash from the ledger to verify the authenticity of the message.
[0047] According to one embodiment, the external actor generates the private key kih and configures the sending peer by recording the private key kih in the electronic memory of the sending peer.
[0048] According to one embodiment, the private key kih is a strengthened extended child private key generated from the master private key kmaster using an index ih equal to the sum of an integer index i and 231.
[0049] When the private key kihest is generated according to the deterministic generation scheme standardized by the “Bitcoin Improvement Proposal BIP32”, the use of an index greater than 231 makes it possible to prevent a third party from deducing the master private key kmaster from the master public key Kmaster and the private key kih.
[0050] According to a second aspect, the invention relates to a paired device comprising an electronic memory and a processing unit. The processing unit is configured to, by executing instructions contained in the electronic memory, carry out the following steps:
[0051] - deterministically determine an identifier Idj of a receiving peer from of an index j of the receiving peer and a master public key Kmaster,
[0052] - calculate an IBE encryption key aCKey[Idj,Kmaster] from the identifier of the receiver pair Idj and the master public key Kmaster,
[0053] - encrypt a first message using the IBE encryption key aCKey[Idj, Kmaster ],
[0054] - send the first encrypted message to the receiving peer,
[0055] - decrypt a second encrypted message using an IBE decryption key aDKey[Idi, kmaster],
[0056] Such arrangements allow the peer device to implement the secure communication method according to the invention as a receiving peer and as a sending peer.
[0057] According to one embodiment, the device also comprises a hardware security component, and the hardware security component is configured to perform the following steps:
[0058] - deterministically determine an identifier Idj of a receiving peer from of an index j of the receiving peer and a master public key Kmaster,
[0059] - calculate an IBE encryption key aCKey[Idj,Kmaster] from the identifier of the receiver pair Idj and the master public key Kmaster,
[0060] - decrypt an encrypted message using a decryption IBE key aDKey[Id;, kmaster] •
[0061] The secure hardware component makes it possible to further increase the security of the communications of the peer device by reducing the risk of a third party obtaining one of the sensitive cryptographic elements which are the decryption key, the master public key Kmaster and the identifier of the receiving peer. PRESENTATION OF FIGURES
[0062] The invention will be better understood on reading the following description, given by way of non-limiting example, and made with reference to the figures:
[0063] [Fig. 1] a schematic representation of an example of the method according to the first aspect of the invention,
[0064] [Fig.2] a schematic representation of examples of identifier determination,
[0065] [Fig. 3] a schematic representation of an example of an embodiment of the method according to the first aspect of the invention,
[0066] [Fig. 4] a schematic representation of an example of another embodiment of the method according to the first aspect of the invention,
[0067] [Fig. 5] a schematic representation of an example of the pair device according to the second aspect of the invention.
[0068] In these figures, identical references from one figure to another designate identical or similar elements. For reasons of clarity, the elements represented are not necessarily on the same scale, unless otherwise indicated. DETAILED DESCRIPTION OF THE INVENTION
[0069] [Fig.l] is a schematic representation of an example of the method according to the first aspect of the invention. An external actor 2 is represented. This external actor 2 may be a manufacturer, a supplier or a user of a peer device who configures the peer devices according to the invention before they are put into service. The external actor 2 has a deterministic hierarchical wallet 1. The deterministic hierarchical wallet 1 comprises a master private key kmaster and a master public key Kmaster derived from an initial seed. The master public key Kmaster may for example be calculated from the master private key kmaster according to the elliptic curve operation:
[0070] [Math.l] ^-master master G (lïlOd II)
[0071] The external actor 2 carries out several steps aimed at the prior configuration of a sending peer 3 and a receiving peer 4. The external actor 2 assigns 101 an index, noted index j in the present text and in the figures, to the receiving peer 4. From the index j and the master public key Kmaster it determines 102 an identifier of the receiving peer noted Idj. This determination is deterministic, that is to say that from the same index and the same master public key Kmaster, the determined identifier will always be the same. Then, the external actor 2 generates 103 a decryption key aDKey[Idj, kmaster] for the receiving peer 4 using the identifier of the receiving peer and the master private key k master. The generation of decryption key aDKey[Idj, kmaster] can be carried out according to a prior art IBE generation scheme. The external actor 2 configures 104 the receiving peer 4 by recording in an electronic memory of the receiving peer the decryption key aDKey[Idj, kmaster]. The external actor 2 also configures 105 the sending peer 3 by recording in an electronic memory of the sending peer the index Index j of the receiving peer 4 and the master public key Kmaster.
[0072] The sending peer 3 can then communicate securely to the receiving peer 4 via a communication network. This communication is carried out as follows: The sending peer determines 106 the identifier Idj of the receiving peer 4 from the index j and the master public key. It calculates 107 an encryption key aCKey[Idj, Kmaster] from the identifier of the receiving peer 4 and the master public key Kmaster. This encryption key aCKey[Idj, Kmaster] is calculated according to a prior art IBE scheme making it possible to match the encryption key aCKey[Idj, Kmaster] to the decryption key aDKey[Idj, kmaster]. The sending peer encrypts 108 a message 60 using the key aCKey[Idj, Kmaster] and sends 109 the encrypted message 61 to the receiving peer 4. The receiving peer 4 will then decrypt 110 the received encrypted message 61.
[0073] The implementation of this method allows the sending peer to secure its messages to the receiving peer by only needing to permanently store in its electronic memory the index of the receiving peer and the master public key. A small volume of permanent electronic memory is therefore necessary to secure the exchanges between the peers using the method according to the invention.
[0074] The method according to the invention may, for example, be used to secure communications between the drones of a drone fleet. In this example, a drone will have the role of a peer of the method. Since drones are typically devices whose on-board electronic memory is of small volume, the method according to the invention is therefore particularly advantageous for securing their communications.
[0075] According to one embodiment, the determinations 102, 106 of the identifier Idj of the receiving peer are performed using a derivation function using an HMAC-SHA512 hash function. HMAC stands for "Hash-based Message Authentication Code". SHA512 represents the specific hash algorithm used in this process, which is part of the SHA-2 (Secure Hash Algorithm 2) family and produces a 512-bit digest.
[0076] [Fig.2] is a schematic representation of an example of generation of the identifier Idj of the receiving peer 4. In these examples, a cmaster code string is used in addition to the master public key Kmaster and the index j to determine 102, 106 a child public key Kchiidj and a code string cchiidj The code string cmaster allows to increase the entropy of the cryptographic elements generated. The child public key Kchiidj could be generated only from the master public key Kmaster and the index j. The child public key Kchiidj can also be used to generate an account name accountchiidj.
[0077] According to one embodiment, the identifier of the receiving peer Idj is the child public key Kchiidj.
[0078] According to one embodiment, the identifier Idj is the code string cchiidj.
[0079] According to one embodiment, the identifier Idj is the account name accountchiidj.
[0080] [Fig. 3] a schematic representation of an example of an embodiment of the method according to the first aspect of the invention. The steps of the embodiment described by [Fig. 1] are present. Additionally, in this embodiment, the sending peer 3 also has in its electronic memory a private key kih. In order to prove the authenticity of the message 60 sent to the receiving peer 4, the sending peer 3 calculates 111 a public key Kih corresponding to the private key kih. The keys Kih and kih constitute a pair of asymmetric keys. The public key Kih makes it possible to verify that a signature has been generated using the private key kih. The sending peer then discloses 112 its public key Kih. The receiving peer may temporarily or permanently record the public key Kih of the sending peer.Once the message 60 has been encrypted 108 by the sending peer 3 using the encryption key aCKey[Idj, Kmaster], the sending peer 3 generates 113 a signature 62 of the encrypted message 61 using its private key kih. The sending peer 3 sends 114 the signature 62 to the receiving peer 4. The sending of the signature 62 may, for example, be carried out jointly with the sending 109 of the encrypted message 61 by concatenating the encrypted message 61 and the signature 62 into a single message. The receiving peer 4 will then be able to verify 115 the signature 62 using the public key Kihet of the encrypted message, this verification can be carried out according to a standard asymmetric scheme of the prior art and makes it possible to ensure that the signature has indeed been generated using the private key kih and that it indeed corresponds to the encrypted message 61. In this way, the receiving peer will be able to ensure the authenticity of the encrypted message 61.
[0081] According to one embodiment, the sending peer comprises a hardware security component which makes it possible to generate the private key kih and will possibly accommodate the generation of the corresponding public key Kih. The use of a hardware security component for the generation of an asymmetric key pair makes it possible to increase the security of the peers by considerably reducing the risk of usurpation of the identity of a peer or the corruption of a peer. The hardware security component is, for example, a TPM component, in English, Trusted Platform Module using, the TPM 1.2 or TPM 2 protocol.
[0082] [Fig. 4] a schematic representation of an example of another embodiment of the method according to the first aspect of the invention. The steps of the method according to the invention described in [Fig. 1] are also shown. In this embodiment, the electronic memory of the sending peer 3 also includes a private key kih. The sending peer 3 and the receiving peer are members of a peer network, and share a distributed ledger 5. The distributed ledger 5 may possibly be decentralized and / or replicated by each peer in the peer network. Operations or publications are recorded in a certain order in the distributed ledger 5 and can no longer be modified once recorded. The distributed ledger 5 may be produced using a technology such as, for example, a blockchain or a decentralized database or a “Directed Acyclic Graph”.
[0083] The sending peer 4 authenticates 117 itself to the distributed ledger 5 using its private key kih. It generates 116 a hash 63 of the encrypted message 61 according to, for example, an HMAC hashing scheme. The sending peer 4 then publishes 118 a transaction in the distributed ledger 5, the transaction comprising the hash 63 and the identifier Idj of the receiving peer 4. Upon receipt of the encrypted message 61, the receiving peer will be able to verify 119 that the hash 63 corresponds to the encrypted message 61. Since the authentication 117 of the sending peer with the distributed ledger 5 is necessary for the publication 118, the receiving peer will be able to ensure the authenticity of the encrypted message 61 by verifying the correspondence between the hash 63 and the encrypted message 61. The use of the distributed ledger 5 makes it possible to avoid the step of calculating and publishing the public key Kihtout while maintaining the possibility of verifying the authenticity of the messages.
[0084] According to one embodiment, the distributed ledger 5 is a ledger, also called a ledger, of a blockchain such as for example an Ethereum chain. The blockchain comprises a smart contract which transmits the hash 63 of the encrypted message 61 by a notification to the receiving peer triggered by the publication 118 in the distributed ledger 5.
[0085] The smart contract could, for example, take the following form:
[0086] / / SPDX-License-Identifier: UNLICENSED
[0087] pragma solidity A0.8.0;
[0088] contract registration {
[0089] address receiver; / / identifier of the receiving peer
[0090] address owner; / / external actor identifier
[0091] uint256 hash;
[0092] mapping (address => hash) public attestation;
[0093] event Attest(address _receiver, uint256 _hash);
[0094] constructor() {
[0095] msg.sender = owner;
[0096] }
[0097] function attest(address _receiver, uint256 _hash) public {
[0098] require(status[msg.sender] == LEGITIMATE);
[0099] attestation[_receiver] = _hash;
[0100] emitted Attest(_receiver, _hash);
[0101] }
[0102] The sending peer constructs a transaction to the attest function of the smart contract that includes the hash of the previously encrypted message. Then, it sends on the one hand the encrypted message to the receiving peer via the peer-to-peer communication channel, and on the other hand the transaction to the blockchain ledger where the smart contract was previously deployed.
[0103] The receiving peer is notified by the smart contract that a message has been sent to it. The notification includes the hash 63 of this encrypted message 61. Upon receipt of the message, it can verify that the hash matches, before performing the decryption 110.
[0104] If desired, the receiving peer can also consult the blockchain to find out the account address, generally the identifier, of the sending peer 4. The use of a blockchain guarantees by construction that the digital signature of the transaction is valid and that the key used corresponds to the identifier of the sending account.
[0105] According to an embodiment not shown, the external actor 2 also configures the sending peer 3 by recording in the electronic memory of the sending peer 3 the private key kih. The private key kih may be a strengthened extended child private key generated from the master private key kmaster using an index ih equal to the sum of an integer index i and 231. The generation of the strengthened extended child private key may be carried out according to the generation scheme shown in [Fig.2]. This deterministic generation scheme, standardized by the “Bitcoin Improvement Proposal BIP32”, with the use of an index greater than 231 makes it possible to prevent a third party from deducing the master private key kmaster from the master public key Kmaster and the private key kih. The security of communications between the peers is therefore further reinforced.
[0106] [Fig. 5] is a schematic representation of an example of the peer device according to the second aspect of the invention. The peer device will be able to implement the method according to the first aspect of the invention as a receiver peer 4 and as a transmitter peer 3. The peer device comprises a processing unit, not shown, configured to, by executing instructions contained in an electronic memory, carry out several steps of the method according to the first aspect of the invention.
[0107] The even device of index i was previously configured to comprise in its electronic memory an index j of another peer device, a master public key K master and a decryption IBE key aDKey[Id;, kmaster]. The peer device of index i determines 106 deterministically the identifier Idj of the peer device of index j from the index j and the master public key Kmaster. Then the peer device of index i calculates 107 an encryption IBE key aCKey[Idj, Kmaster] according to an identity-based cryptography scheme using the identifier Idj and the master public key Kmaster. The peer device of index i encrypts 108 a first message 60, intended for the peer device of index j, using the encryption IBE key aCKey[Idj, Kmaster] and then sends 109 the first encrypted message 61 to the peer device of index j.The peer device of index i will also be able to receive a second encrypted message from the peer of the peer device of index j and decrypt 110 this second encrypted message 64 using the decryption key IBE aDKey[Id;, kmaster]. .
[0108] According to one embodiment, the messages exchanged between the peer devices may also be authenticated upon receipt. This authentication will be performed before decrypting the message in this way, if the message is not authentic, the computing resources necessary for decryption will be saved. The peer device i may have a private key kih in its electronic memory, from this key, the peer device i calculates 111 a corresponding public key Kih, the keys kih and Kih constituting a pair of asymmetric keys, and discloses 112 the public key Kih. When preparing to send a message 60, once the message 60 is encrypted, the peer device i may generate 113 a signature 62 of the encrypted message 61 using the private key kih and send 114 the signature 62 with the encrypted message 61.As a receiving peer, peer device i may receive and record a public key Kjh disclosed by peer device j. Peer device i may receive a second encrypted message 64 from peer device j and a signature corresponding to the second encrypted message 64. Before decrypting the second encrypted message 64, peer device i verifies 115 the received signature using the public key Kjh of peer device j. Verification of this signature ensures that it was generated using a private key kjh corresponding to the public key Kjh and that it was generated from the second encrypted message 64. Additionally, verification 115 of the signature may also ensure the integrity of the encrypted message 64. Message integrity means that the latter has not been modified between the generation of the corresponding signature and the verification of the corresponding signature.
[0109] The peer device may also include a hardware security component 31, the hardware security component 31 is configured to carry out some of the steps carried out by the peer device. The hardware security component may also be used to store cryptographic elements such as indices in memory. of the other peer devices associated with the peer device i, the master public key Kmaster, the decryption key aDKey[Id;,kmaster] and the private key kih. The hardware security component is configured to determine 106 the identifier Idj of the peer device of index j, to calculate 107 the encryption key IBE aDKey[Idj, Kmaster], to encrypt 108 a message intended for peer j and to decrypt 110 a received encrypted message. The hardware security component may also be configured to calculate 111 the public key Kih and generate 113 the signature of the encrypted message.
[0110] The hardware security component will further secure the peer device's communications by adding an additional barrier preventing third parties from observing steps and cryptographic elements necessary to secure communications.
[0111] According to an embodiment not shown, the peer device i may also implement the embodiment of the method according to the invention involving the use of a distributed ledger. The peer device i may authenticate itself 117 with the distributed ledger and publish 118 transactions aimed at enabling the verification of the authenticity and integrity of the encrypted messages sent.
Claims
Claims
1. Secure communication method between a sending peer (3) and a receiving peer (4), involving an external actor (2) having a deterministic hierarchical wallet (1), the deterministic hierarchical wallet (1) comprises a pair of asymmetric master keys, consisting of a master private key kmaster and a master public key K master, the sending peer (3) and the receiving peer (4) comprise an electronic memory and a processing unit, the communication method comprises the following steps: - the external actor (2) assigns (101) an index j to the receiving peer (4) in the deterministic hierarchical portfolio (1), - the external actor (2) determines (102) an identifier Idj of the receiving peer (4) in a deterministic manner from the index j of the receiving peer (4) and the master public key Kmaster, - the external actor (2) generates (103) a decryption IBE key aDKey[Idj,kmaster] from the identifier of the receiving peer Idj and the master private key kmaster, - the external actor (2) configures (104) the receiving peer (4) by recording in the electronic memory of the receiving peer the IBE decryption key aDKey[Idj,kmaster], - the external actor (2) configures (105) the sending peer (3) by recording in the electronic memory of the sending peer the index j of the receiving peer and the master public key Kmaster, - the sending peer (3) determines (106) in a deterministic manner the identifier Idj of the receiving peer from the index j of the receiving peer and the master public key Kmaster, - the sending peer (3) calculates (107) an IBE encryption key aCKey[Idj,Kmaster] from the identifier of the receiving peer Idj and the master public key Kmaster> - the sending peer (3) encrypts (108) a message (60) using the IBE encryption key aCKey[Idj, Kmaster], - the sending peer (3) sends (109) the encrypted message (61) to the receiving peer (4), - the receiving peer (4) decrypts (110) the encrypted message (61) using the IBE decryption key aDKey[Idj, kmaster].
2. Method according to claim 1, in which the steps of determining (102, 106) in a deterministic manner the identifier Idj are performed using a derivation function using an HMAC-SHA512 hash function.
3. Method, according to one of claims 1 to 2, comprising the following additional steps: - the sending peer (3) calculates (111) a public key Kih from a private key kih, - the sending peer (3) discloses (112) to the receiving peer (4) the public key Kih, - the sending peer (3) generates (113) a signature (62) of the message using the encrypted message (61) and the private key kih, - the sending peer (3) sends (114) the signature (62) of the message to the receiving peer (4), - the receiving peer (4) verifies (115) the signature (62) of the message using the public key Kih and the encrypted message (51).
4. The method of claim 3, wherein the sending peer (3) comprises a hardware security component (31) and wherein the private key kih is generated within the hardware security component (31).
5. Method according to one of claims 1 to 2, in which the sending peer (3) and the receiving peer (4) are peers of a network of peers sharing a distributed ledger (5) and in which the following additional steps are carried out: - the sending peer (3) generates (116) a hash (63) of the encrypted message (61), - the sending peer (3) authenticates (117) with the distributed ledger (5) using a private key kih, - the sending peer (3) publishes (118) in the distributed ledger (5) a transaction comprising the identifier of the receiving peer and the hash (63) of the encrypted message (61), - the receiving peer (4) verifies (119) that the hash (63) of the encrypted message published in the distributed ledger (5) corresponds to the encrypted message (61) received.
6. The method of claim 5, wherein the distributed ledger (5) is a blockchain distributed ledger and wherein the blockchain comprises a smart contract issuing a notification to the receiving peer (4), the notification comprising the hash (63) of the encrypted message.
7. Method according to one of claims 3, 5 or 6, in which the external actor (2) generates the private key kih and in which the external actor (2) configures the sending peer by recording the private key kih in the sending peer's electronic memory.
8. The method of claim 7, wherein the private key kih is a strengthened extended child private key generated from the master private key k master using an index ih equal to the sum of an integer index i and 2 31
9. Peer device (3, 4) comprising an electronic memory and a processing unit, the processing unit is configured to, by executing instructions contained in the electronic memory, carry out the following steps: - deterministically determine (106) an identifier Idj of a receiving peer (3, 4) from an index j of the receiving peer (3, 4) and a master public key Kmaster, - calculate (107) an encryption key IBE aCKey[Idj,Kmaster] from the identifier of the receiving peer Idj and the master public key Kmaster, - encrypt (108) a first message (60) using the encryption key IBE aCKey[Idj, Kmaster], - send (109) the first encrypted message (61) to the receiving peer (3, 4), - decrypt (110) a second encrypted message (64) using an IBE key of decryption aDKey[Id;, kmaster].
10. Device according to claim 9, also comprising a hardware security component (31), and in which the hardware security component (31) is configured to carry out the following steps: - determining (106) deterministically an identifier Idj of a receiving peer (3, 4) from an index j of the receiving peer (3, 4) and a master public key Kmaster, - calculating (107) an IBE encryption key aCKey[Idj,Kmaster] from the identifier of the receiving peer Idj and the master public key Kmaster, - decrypting (110) an encrypted message (64) using an IBE decryption key aDKey[Idi, kmaster].