PROCEDURES FOR THE SECURE EXCHANGE OF ENCRYPTED MESSAGES

Description

[0001] The present invention relates to a method for the secure exchange of encrypted messages between a sender and a receiver using an encryption authority (VA).

[0002] US 2006 / 0143453 A1 describes a method for authenticating clients, but does not involve the encryption of information between clients. In a time when data attacks are becoming increasingly common, a particular concern of the invention is to make access-sensitive data exchange between a sender and a receiver more secure.

[0003] According to the invention, this is achieved by a method having the features of claim 1. Advantageous developments of the method are the subject of the dependent claims.

[0004] In this process, the sender and receiver exchange a shared genesis hash before the first data exchange, which forms the basis for subsequent encryption. For subsequent data transactions, the last confirmed hash between sender and receiver is then used.

[0005] The process uses blockchain technology, familiar from cryptocurrencies, to ensure the chronological authenticity of the data exchanged between sender and receiver. This means that any subsequent modification of the blockchain data would immediately result in a breach of integrity, effectively preventing such attacks.

[0006] The inventive method for the secure exchange of encrypted messages between a sender and a receiver using an encryption authority (VA) is specified as follows.

[0007] The transmitter and receiver can, for example, be transmitters and receivers in a communications network. This means that the method according to the invention is particularly suitable for the secure, encrypted transmission of data in a communications network, be it text data, image or video data, and / or audio data. The method is also suitable for the transmission of streaming data. The transmitter and receiver can also be hardware components that communicate with each other to achieve something, such as access to an area, a motor vehicle, or a device, e.g., a smartphone.

[0008] For example, when securing access to a motor vehicle, the electronic key is the transmitter, the electronic door lock is the receiver and the VA is usually located in the vehicle control system.

[0009] In the case of access security for a smartphone, the sender is the access app with input device that enables access to the smartphone. The receiver is the smartphone's operating system and the VA is stored in a part of the smartphone's operating system or, in the case of a wireless connection, in a server connected to the smartphone. Either data has already been exchanged between sender and receiver, in which case the data exchange is based on data from the last data exchange, e.g. the last confirmed hash. If no data exchange has yet taken place, start data, e.g. a shared genesis hash, is exchanged between the sender and receiver before the first data exchange. This forms the basis for subsequent encryption.

[0010] Furthermore, the method comprises the following steps, preferably the sequence of the following steps: a) The sender requests a token from the VA, which is required to encrypt the messages to be transmitted. b) The VA creates the token and writes it into a new block created by the VA, which is appended to a blockchain of the VA, hereinafter main chain. c) The VA returns the created token to the sender. d) The sender creates a key, which is derived from the token and the data or the seed data, in particular the last confirmed hash or the genesis hash. e) The sender uses the key to encrypt a message for transmission to the recipient. f) The sender saves the hash of the unencrypted message in a new block of its private blockchain. g) The sender transmits the encrypted message to the recipient.h) the sender creates the hash of the encrypted message and transmits it to the VA, i) the receiver transmits the hash of the encrypted message to the VA and requests an integrity confirmation from the VA, n) the VA compares the hashes of the receiver and sender and transmits the comparison result and the token to the receiver, o) if the VA confirms the integrity, the receiver calculates the key for the subsequent decryption of the message from the token and the last confirmed hash of the unencrypted message or the genesis hash, p) the receiver decrypts the message using the key, q) the receiver saves the hash of the unencrypted message in a block of its private blockchain, r) the receiver transmits an acknowledgment of receipt for the hash of the unencrypted message to the sender and an acknowledgment of receipt of the hash of the encrypted message to the VA for further data transmissions.

[0011] This process ensures, on the one hand, that the data sent by the sender is identical to the data received by the receiver. The process also ensures that the data is encrypted differently with each data transfer. The token, which forms the basis of the encryption, is stored only by the VA. It is preferably stored neither by the sender nor by the receiver. On the other hand, the VA only receives the hash of the encrypted message. Thus, neither hacking the sender, the receiver, nor the VA can provide access to the transmitted data. The use of blockchains for the VA (main chain) and the sender and receiver (private chains) ensures that no changes can be made to the transaction history and that changes to the data can be immediately detected even afterward. This data transfer process can therefore be described as a milestone in data security.

[0012] The method according to the invention is an application add-on that ensures and monitors the protection goals of data protection, in particular confidentiality, as well as key management. The method according to the invention offers interfaces for integrating these into existing applications, such as access security, vehicle keys, data transmission in communication networks such as WhatsApp ®< , Skype ®< , email, and messengers. The method can work with any encryption method, such as the Advanced Encryption Standard (AES). Thus, the method according to the invention can be integrated into any tool to make it even more secure without the user having to confront it with new applications.For example, the information security of an order management system can be significantly increased by integrating the method according to the invention using true end-to-end encryption and enhanced integrity monitoring. The method according to the invention therefore primarily serves as an IT security add-on to existing applications.

[0013] The method according to the invention offers particular advantages with regard to the protection goal of confidentiality: For each transaction between sender and receiver, a new private key is generated, which is never stored on either entity. Rather, these parameters secure the parameters necessary for key generation. Should data thus become known to one of the entities (sender, receiver, or encryption authority), this information is not sufficient to generate the cipher.

[0014] In an advantageous development of the method according to the invention, the following steps are carried out between steps i) and n): k) the receiver bases the integrity request to the VA on transaction tree (Merkle) technology, l) the VA checks the transaction tree using the main chain, m) the VA transmits the result of the integrity check to the receiver.

[0015] This transaction tree verification offers an extended check for integrity violations. Using the Merkle Tree Hashing method, it is possible to check the entire chain—that is, the main chain as well as the sender's and receiver's private chains—for violations. This not only checks the currently received message for changes using a hash value, but also the entire chain sequence. Integrity monitoring is thus improved, and the inventive method offers a variety of difficult-to-tamper with protection functions to maintain the integrity of a third-party system. Merkle Tree Hashing is a very efficient verification method, eliminating the need for performance-intensive verification of the blockchain and keeping the amount of data to be transferred to a minimum.The invention offers end-to-end encryption with constantly changing keys and thus the highest security standard for data transmission.

[0016] In an advantageous development of the invention, the transaction tree calculated using the hashes is used to verify the order of the blocks. This enables efficient and data-minimized integrity checking using the transaction tree.

[0017] In an advantageous development of the invention, the tokens are deleted from the main chain after a predetermined period of time. This makes it optionally possible to destroy keys after a certain period of time. It is then no longer possible to access the keys already assigned. This development thus makes the entire system significantly more secure.

[0018] Preferably, the VA creates the token randomly, making it impossible to predetermine the value of the token, which would be entirely possible, for example, if it were created based on a defined algorithm.

[0019] Preferably, in step b), the VA also determines the GUID of the hash or genesis hash last confirmed by the sender. The VA returns the created token and the GUID to the sender, and in step d), the sender uses the GUID to determine the hash of the last unencrypted message between sender and receiver and creates a key derived from the token and the last confirmed hash or genesis hash. This makes the process simpler and less computationally intensive.

[0020] The VA naturally communicates with a multitude of senders and receivers. As a result, the VA's main chain is significantly longer than the sender's and receiver's private chains. Therefore, the main chain blocks that do not concern the sender or receiver are preferably transmitted to the sender and receiver as empty space blocks. This has the advantage that the sender and receiver are not burdened with data that does not concern their own data transmission. Furthermore, it makes it impossible to access data concerning third parties via the sender and receiver.

[0021] In an advantageous development of the invention, a transaction tree is calculated based on the successive blocks and this is used to check the integrity.

[0022] Each block of the main chain preferably contains the following data: Sender ID, Receiver ID, Token, Hash GUID, Hash of the previous block, Hash of the encrypted message, and Confirmation Flag. This data also contains all important IDs for the data exchange, as well as confirmation of the transfer process in the form of a confirmation flag. If no confirmation flag is received for the transfer process, the transfer is either repeated, aborted, or an error routine is triggered, which, for example, asks the user to verify the technical requirements for the transfer.

[0023] Preferably, each block of the private chain contains the following data: sender ID, hash of the previous block, hash of the unencrypted message, and confirmation flag. Here, too, the data contains all the important IDs for the data exchange, as well as confirmation of the transmission process in the form of the confirmation flag.

[0024] Preferably, the VA combines blocks from the main chain in transactions with third parties into a combined block, which is transmitted to the sender and receiver along with the token. This reduces the number of blocks and significantly reduces the computational effort.

[0025] In one embodiment of the invention, the transmitter is formed by an access key to a building or a vehicle, which contains a controller and a wireless radio connection to the VA and the receiver. The receiver is usually formed by a vehicle or an access device of a building.

[0026] The method can also be an access method for a device, such as a smartphone. The sender is the access app, and the receiver is the smartphone's operating system. The AB can be either in the operating system or by a server with which the smartphone communicates via the wireless network; in this case, a wireless connection would be required for access.

[0027] Preferably, the hash in the method contains information about the blockchain or the transaction tree so that the blockchain can be used to verify integrity.

[0028] Furthermore, using a client's (receiver or sender's) own private blockchain, it is possible to perform an integrity check at any time. The hash values ​​of the unencrypted messages in the chain are used for this purpose. This allows the host system to be checked for subsequent integrity violations, even some time after the messages have been received.

[0029] In addition to this method, it is also possible to check one's own database for integrity violations using the blockchain of the other client (sender or receiver). This provides additional security. If this method is used in a third-party system, such as a messenger, an attacker would first have to manipulate the blockchain data and then the third-party system itself, which makes attacks significantly more difficult.

[0030] Furthermore, the two methods above can be combined, whereby the integrity of the database is checked for breaches using two instances. This means that attackers would have to manipulate two instances. This further enhances security.

[0031] In summary, the method according to the invention ensures all aspects of data protection in one process. confidentiality

[0032] The unique concept of the inventive method allows for end-to-end encryption with constantly regenerated keys for each transaction. Furthermore, private keys are preferably destroyed after an individually specified time.

[0033] The method according to the invention allows integrity monitoring over an indefinite period of time. Potential integrity conflicts are detected immediately, making unwanted changes to the data by third parties or cyberattacks visible at any time. Access control

[0034] Private keys can only be calculated by the sender and recipient of the transaction. Other clients (third-party senders and recipients) do not have access to the parameters necessary to determine private keys. Availability

[0035] The "distributed ledger" principle familiar from blockchain, which can only be applied to the main chain, makes it possible to provide a redundant encryption authority system. This protects key data from loss. Independence of the encryption algorithm used

[0036] A major advantage of the inventive method is that it is compatible with every currently known and future symmetric encryption algorithm. This means that if more secure methods than AES are invented in the future, they can also be integrated into the inventive method. Thus, the inventive method is always state-of-the-art in terms of encryption. Self-destruction of the keys

[0037] Certain parameters necessary for key generation are preferably destroyed after a specified time. This makes it impossible to recalculate the key. authenticity

[0038] The authenticity of an instance known in the method according to the invention can also be determined without great effort. This is described in more detail in Example 8.2 using a car and mobile phone as keys. Aim of the method according to the invention

[0039] The primary goal of the method is to improve data protection in existing IT systems and application areas. The method according to the invention can therefore be integrated into a wide variety of systems.

[0040] Structure of the system for applying the method according to the invention: Encryption Authority (VA): This is the system that operates the central authority for assigning parameters for key generation. Main Chain: Based on blockchain technology, this is the chaining of blocks that secures the hash value of the encrypted message and the token for generation (see key generation) for each block in the VA. Private Chain (per device): Each device (sender and receiver) stores its own blockchain. Thus, each device only receives information intended for its own use and no information about other keys. The device secures the hash value of the unencrypted message for each block. Short description of the main process:

[0041] Information about key creation is requested here. The sender therefore first requests a token from the Encryption Authority. This token is needed to create a private key. The hash value of the last unencrypted message is also required. This is located in the sender's private chain. To ensure that a hash is used that is known to the recipient, the VA returns a GUID (Global Unique Identifier) ​​that the sender can use to determine the hash value in the private chain. The private key can now be generated by combining the token and hash value, and the message can be sent encrypted using this. The hash value of the unencrypted message is saved in the next block in the private chain and can thus be used for the next encryption after an acknowledgement of receipt. The VA then also saves a block for this transaction in the main chain.Here it secures the hash value of the encrypted message, as well as other basic data. Receiving the message and decrypting it

[0042] After receiving an encrypted message, it is first saved in the recipient's private chain using the hash value of the encrypted message. The data integrity is then checked, i.e. a search is carried out for any changes to the data during communication. To do this, the Encryption Authority checks the hash value of the encrypted message with the hash value of the received message. If any discrepancies are found, this is an indication of a breach of integrity (see Integrity Violation). If there is no breach of integrity, the Encryption Authority loads the token, combines this with the hash value of the last decrypted message of the last transaction, and this calculates the key. The message can now be decrypted. Structure of the chains

[0043] The inventive method (Private Self-Destructing Encryption Chain, or PSDE chain for short) is based on blockchain technology. A distinction is made between the private and the main chain. While the main chain is managed by the VA, the data in the private chain is different on each device (sender and receiver). The structure of the respective blocks is explained in more detail below. Space Chain Block

[0044] A space block is a space filler in the private chain. Since only blocks containing information relevant to the respective sender and receiver are secured in the private chain, any intervening blocks are automatically combined by the VA. Self-destruction of private keys

[0045] Another advantage of the PSDE chain is the self-destruction of private keys after a specified time interval. This means that the encryption authority checks expired blocks after a specified time and then deletes the tokens. Since the tokens are essential for calculating the keys, it is no longer possible to calculate the key. Examples - Transmission of digital information in text or media form (chat)

[0046] Encryption and protection against unauthorized changes play a crucial role, especially when digitally transmitting sensitive data (credit card information, company documents). Thanks to the PSDE Chain, comprehensive protection can be provided. Furthermore, it can be easily integrated into existing applications. - Communication between objects (Internet of Things)

[0047] Since the communication of data between objects is becoming increasingly important in the 21st century, it is all the more important to protect communication in order to prevent theft and misuse of objects. For example, the method can be used between a car and a mobile phone (as a key) without having to accept long waiting times. The vehicle generates a random text, encrypts it, and transmits it using the inventive method. Once the correctly decrypted text is returned, the car can be unlocked. From the hash values ​​of the last messages in the private chain, new private keys are then created for the next communication using the VA token. This ensures that communication between the vehicle and mobile phone is always secured to the highest standard, and in this case, the authenticity of the key is also guaranteed. Another possible variant: - Virtual Private Network (VPN) connection

[0048] Even with VPN connections, serious security vulnerabilities often occur, and keys are sometimes changed far too infrequently. The PSDE chain makes it possible to secure VPNs with constantly changing private keys. The following example describes this using a site-to-site VPN, but it also applies to all other VPN types (point-to-point, point-to-site). Possible variants - Two-stage integrity check

[0049] One possible variant of the PSDE chain is to perform the initial integrity check with the recipient instead of just the server. This provides double security, as both the hash value of the encrypted message can be compared with the encryption authority, and the hash value of the unencrypted message can be compared with the sender's hash value. - Use on a normal database basis without blockchain technology

[0050] Furthermore, it would also be possible to use the PSDE chain on a standard database basis, without using blockchain technology. However, this would result in several disadvantages, such as slow integrity determination. Use of other arbitrary values ​​instead of the hash value of the last message to generate the key.

[0051] In an advantageous development of the invention, authenticity can also be determined using an integrity check via a transaction tree between the sender and receiver. If a violation occurs, the data transmission is aborted and an error message is issued. The advantage of this method is that the authenticity can be performed without a connection to the VA. This is important, for example, if the sender and receiver are a vehicle key and an electronic access system for the vehicle, and the VA can only be accessed via public wireless networks.

[0052] Another possible design of the PSDE chain would be to use other values ​​for key generation instead of the hash value of the last unencrypted message. For example, the unencrypted message could be used directly, or other values ​​known to both devices could be combined (user ID, size of the last message, etc.). It's not necessarily necessary to use the last message; this also applies to other data in the communication between sender and receiver. Using the PSDE Chain without an Integrity Check The integrity check is an optional step, but in some situations it is not required. Therefore, the PSDE Chain can also be operated without an integrity check. Integrity Check Without Transaction Tree Verification The integrity check itself can also be expanded to different levels. For example, a transaction tree check is only necessary if the order of the messages needs to be verified. Often, however, comparing the hash values ​​is sufficient, and thus, in some cases, the transaction tree verification can be omitted. The following terms are used synonymously: hash - hash value; client - sender - receiver; For example, vehicle access:

[0053] Using the example of a car and a key to unlock it, the key sends encrypted random data to the vehicle using the method according to the invention. The vehicle then checks for any violations, preferably using a two-stage integrity check (with both the encryption authority and the key) using a transaction tree. If any violations are found, the key is not the original, and the vehicle cannot be unlocked.

[0054] It is obvious to the person skilled in the art that the above-described embodiments of the invention can be combined with one another in any desired manner.

[0055] The invention is described below, for example, with reference to the schematic drawing, which shows: Fig. 1 is a flowchart of the present method, and Fig. 2 is a flowchart of an integrity check for implementation in the method according to Fig. 1 .

[0056] The method according to the invention as described in Fig. 1 The method shown enables a secure exchange of encrypted messages between a sender S and a receiver E using an encryption authority VA. Such a method is preferably used in a third-party application in which data is transferred between senders and receivers. Such a third-party system can be Messenger, WhatsApp ®< , Skype ®< , Twitter ®< , or another similar system. However, the method can also be used in connection with access security to vehicles, machines, devices of all kinds, smartphones, or desktops.

[0057] Before the first data exchange, the sender and receiver exchange a shared genesis hash, which forms the basis for subsequent encryption. Otherwise, the confirmed hash from the last data exchange is used.

[0058] On the one hand, the process uses blockchain technology to generate new encryption base data for each data transfer and to enable integrity verification via the blockchain's hash at any time, or at least with each data transfer process.

[0059] First, in step a), the sender requests the VA to assign a token, which is to be used as the basis for the encryption of the data to be transmitted.

[0060] In step b), the VA creates the token and writes it into a new block created by the VA, which is then attached to its blockchain, hereinafter the main chain.

[0061] In step c), the VA returns the created token to the sender. The sender then creates a key in step d) derived from the token and the last confirmed hash or genesis hash. In step e), the sender S encrypts a message for transmission to the recipient E using the created key. Subsequently, in step f), the sender S saves the hash of the unencrypted message in a new block of its private blockchain and, in step g), transmits the encrypted message to the recipient E. In step h), the sender creates the hash of the encrypted message and transmits it to the VA. Subsequently, in step i), the recipient transmits the hash of the encrypted message to the VA and requests an integrity confirmation from the VA.

[0062] The VA then compares the hashes of receiver E and sender S in step n) and transmits the comparison result and the token to the receiver.

[0063] If the VA confirms the integrity, the receiver E calculates the key for subsequent decryption of the message using any encryption method from the token and the last confirmed hash of the unencrypted message or the genesis hash in step o). If the integrity is not confirmed, the process is aborted at this point because the data between sender and receiver is inconsistent.

[0064] The receiver decrypts the message using the key in step p) and saves the hash of the unencrypted message in a block of its private chain in step q). Finally, in step r), the receiver E transmits an acknowledgment of the hash of the unencrypted message to the sender S and an acknowledgment of the hash of the encrypted message to the VA for further data transmissions as described here.

[0065] Fig. 2 shows an alternative embodiment of the method according to the invention. In particular, the following additional steps are carried out between steps i) and n): k) the receiver bases the integrity request to the VA on transaction tree (Merkle) technology, l) the VA checks the transaction tree using the main chain, m) the VA transmits the result of the integrity check to the receiver.

[0066] This transaction tree verification offers an extended check for integrity violations. Using the Merkle tree hashing method, it is possible to check the entire chain—that is, the main chain as well as the private chains of the sender and receiver—for violations. This not only checks the currently received message for changes using a hash value, but also the entire chain sequence. Integrity monitoring is thus improved, and the inventive method offers a variety of difficult-to-tamper with protection functions to maintain the integrity of a third-party system.

[0067] The secure transmission method of the invention is described, for example, based on the interaction between an electronic radio-based vehicle key, the locking mechanism on the vehicle and the VA arranged in the vehicle or on a server: a) The vehicle key requests a token from the VA. The VA is hosted, for example, by the vehicle manufacturer. b) The VA creates the token and writes it into a new block created by the VA, which is appended to a blockchain of the VA, hereinafter referred to as the main chain. c) The VA returns the created token to the key. d) The key creates a cipher derived from the token and the data or seed data, in particular the last confirmed hash or genesis hash. e) The sender (vehicle key) uses the key to encrypt a randomly selected message for transmission to the vehicle. f) The vehicle key saves the hash of the unencrypted message in a new block of its private blockchain. g) The vehicle key transmits the encrypted message to the vehicle. h) The vehicle key creates the hash of the encrypted message and transmits it to the VA.i) The vehicle sends the VA the hash of the encrypted message and requests an integrity confirmation from the VA, which can be done, for example, using the transaction tree. n) The VA checks the integrity using the transaction tree and sends the token to the vehicle. o) If the VA confirms the integrity, the vehicle calculates the key for subsequently decrypting the message from the token and the last confirmed hash of the unencrypted message or genesis hash. If there is an integrity violation, the vehicle will not be unlocked. p) The vehicle decrypts the message using the key. q) The vehicle saves the hash of the unencrypted message in a block of the private chain.

[0068] This ensures secure decryption of the vehicle. The key system is secure against radio signal recording, which is currently a major vulnerability with keyless-go systems.

[0069] Preferably, a further integrity check can be performed with the key, either between the sender or receiver and the VA and / or between sender and receiver. If an access attempt is made by an attacker who, for example, has only recorded the key's radio signal, this cannot be confirmed due to the missing chain blocks, and the vehicle cannot be decrypted. r) Finally, the vehicle transmits an acknowledgment of the hash of the unencrypted message to the vehicle key and an acknowledgment of the hash of the encrypted message to the VA for further transactions.

[0070] Another example of the method according to the invention will now be described using a chat app. This involves the secure exchange of data between sender and receiver, i.e., usually two chat clients, in the chat system, which is usually operated by a third-party provider, such as Messenger ®< , Skype ®< , Discord ®< , Twitter ®< , etc.: a) The chat sender requests a token from the VA. The VA is hosted by a server. b) The VA creates the token and writes it into a new block created by the VA, which is appended to a blockchain of the VA, hereinafter referred to as the main chain. c) The VA returns the created token to the chat app. d) The chat sender creates a key derived from the token and the data or seed data, in particular the last confirmed hash or genesis hash. e) The chat sender uses the key to encrypt a message to be transmitted within the chat app for transmission to the operating system. f) The chat sender saves the hash of the unencrypted message in a new block of its private blockchain. g) The chat sender transmits the encrypted message to the recipient. h) The chat sender creates the hash of the encrypted message and transmits it to the VA.i) The chat recipient sends the hash of the encrypted message to the VA and requests an integrity confirmation from the VA. n) The VA checks the integrity using the transaction tree and sends the token to the recipient. o) If the VA confirms the integrity, the chat recipient calculates the key for decrypting the message from the token and the last confirmed hash of the unencrypted message or genesis hash. p) The recipient decrypts the message using the key. q) The recipient saves the hash of the unencrypted message in a block of the private chain. r) The recipient sends an acknowledgment of receipt for the hash of the unencrypted message to the sender and an acknowledgment of receipt of the hash of the encrypted message to the VA for further transactions.

Claims

1. Method for securely exchanging encrypted messages between a sender and a recipient using an encryption authority (VA), in which method, prior to a first data exchange, the sender and recipient exchange shared initial data comprising a genesis hash, said initial data forming the basis for subsequent encryptions, which method comprises the following steps: a) the sender requests the issuing of a token from the VA, b) the VA generates the token and writes it into a new block created by the VA, which is appended to a blockchain of the VA, hereinafter referred to as the main chain, c) the VA returns the generated token to the sender, d) the sender generates a key derived from the token and from data of a previous data transmission or from the initial data, e) the sender encrypts a message for transmission to the recipient using the key, f) the sender stores the hash of the unencrypted message in a new block of his private blockchain, g) the sender transmits the encrypted message to the recipient, h) the sender generates the hash of the encrypted message and transmits it to the VA, i) the recipient transmits the hash of the encrypted message to the VA and requests an integrity confirmation from the VA, n) the VA compares the hashes from the sender and the recipient and transmits the comparison result and the token to the recipient, o) in the event of confirmation of integrity by the VA, the recipient calculates the key for subsequently decrypting the message from the token and the data of the previous data transmission or the shared initial data comprising the genesis hash, in particular from the most recently confirmed hash of the unencrypted message within the genesis hash, p) the recipient decrypts the message using the key, q) the recipient stores the hash of the unencrypted message in a block of his private blockchain, r) the recipient transmits a receipt confirmation for the hash of the unencrypted message to the sender and a receipt confirmation of the hash of the encrypted message to the VA for further data transmissions.

2. Method according to claim 1, characterized in that the VA generates the token on a random basis.

3. Method according to one of the preceding claims, characterized in that blocks of the main chain that do not relate to the sender or recipient are transmitted as empty space blocks.

4. Method according to one of the preceding claims, characterized in that the encryption is carried out using the Advanced Encryption System.

5. Method according to one of the preceding claims, characterized in that each block of the main chain contains the following data: sender ID, recipient ID, token, hash GUID, hash of the previous block, hash of the encrypted message, confirmation flag.

6. Method according to one of the preceding claims, characterized in that each block of the private blockchains of the sender and / or recipient contains the following data: sender ID, hash of the previous block, hash of the unencrypted message, confirmation flag.

7. Method according to one of the preceding claims, characterized in that the tokens are deleted from the main chain after a predetermined period of time.

8. Method according to one of the preceding claims, characterized in that the sender is formed by an access key to a building or a vehicle, which contains a control unit and a wireless radio connection to the VA and to the recipient, which is formed by a vehicle or an access arrangement of a building.

9. Method according to one of the preceding claims, characterized in that the private blockchain of a client (sender or recipient) and / or the opposite client (recipient or sender) is used for performing an integrity check, for which purpose the hashes of the unencrypted messages from the respective private chain are used.

10. Method according to one of the preceding claims, characterized in that the keys are destroyed after a predetermined period of time.