Methods for encrypting data transmission

Abstract

The present invention relates to a method for encrypting the transmission (10) of data between terminals (14, 16), wherein, before transmitting the data, a verification certificate (Z*) is created and transmitted to a backend (12), and the verification certificate is signed by a root certificate (Z) in the backend (12), the signed verification certificate (Z**) is sent back to a second terminal (16), the public second digital key of the signed verification certificate (Z**) is transmitted to a first terminal (14), and verification is performed using the public second digital key (S2), wherein, during the verification, an encrypted unique symmetric session key (S*) is generated, which is transmitted to the second terminal (16) and decrypted using the private key of the signed verification certificate (Z**), wherein, in the event of verification failure, the first terminal (14) is notified, or in the event of successful verification, the data is decrypted using the session key (S*).

Description

Technical Field

[0001] This invention relates to a method for encrypting data transmission. Background Technology

[0002] With an increasing amount of confidential and personal data being transmitted back and forth between two or more parties (including technical systems and their subsystems) via IP-based communication, it is essential to prevent eavesdropping and manipulation by unauthorized third parties (including hackers). Particularly in embedded systems, highly sensitive data must be protected from unauthorized access during storage and transmission, for example, through SOME / IP, a scalable service-oriented middleware over IP, without requiring a significant CPU load.

[0003] For example, a vulnerability that allows easy access to the keys used to encrypt and decrypt data can jeopardize the security of the entire system. When information is exchanged over a public network, it passes through several exchange nodes, the reliability of which may be questionable. Therefore, data must be fully encrypted by the sender before or during transmission and decrypted by the receiver upon receipt. In this case, these parties or endpoints must always have a protected and temporarily exchanged key that allows them to decrypt the corresponding message from the other party, but this key must also be protected from unauthorized access should the encrypted data be obtained by an unauthorized third party exploiting other security vulnerabilities (e.g., in the cloud).

[0004] DE10355865B4 discloses a method and chip for encrypting data using a key. In this case, the method allows for the encryption and decryption of data using a key-based symmetric encryption algorithm based on procedural principles. Similarly, this example, in the context of existing technology, is based on a novel key-based method implemented in a new chip. The so-called BAPA chip, which implements this method in hardware, is a novel key chip supporting the entire field of electronic data communication. However, a disadvantage is that hardware-related encryption and processing performed by these or other chips cannot be integrated into every embedded system, especially if existing embedded systems no longer allow for any changes to the hardware and its architecture.

[0005] Similarly, US20180063094A1 has disclosed "End-to-End Encryption for Personal Communication Nodes," which, correspondingly, is end-to-end encryption for group communication of personal communication nodes. This is provided by implementing a pairwise encryption process between a pair of end-user devices that are members of a communication group. In this case, the end-user devices share a group key with the pair of end-user devices. The group key is then encrypted using a message key created using the pairwise encryption process. When a transmission member in the group communicates with a member, it generates a stream key and encrypts the stream data with the stream key, encrypts the stream key with the group key, and then transmits the encrypted stream key and encrypted stream data to the group member. The main drawback of this method is that the communication group must register with a server beforehand with its identity and public key. For encrypted communication, a secure connection between a pair of end-user devices must be actively established beforehand. The message key is not encrypted and therefore may be obtained by unauthorized third parties, including hackers.

[0006] In addition, CA 2703 612A1 discloses a secure logical communication link between a secure payment module and a controller for secure communication in a retail environment, which is generated by adopting key authentication for devices that process sensitive information in the retail environment. Summary of the Invention

[0007] The purpose of this invention is to further develop a method for encrypting data transmission, thereby providing particularly strong protection for the data.

[0008] One aspect of the invention relates to a method for encrypted data transmission over a network between a first terminal transmitting data and at least one second terminal receiving data. In this method, the network and terminals have all the components necessary for data transmission, enabling communication between the terminals and the network's backend. The method includes several method steps, wherein, in a first method step, the generation of a private first digital key and a public second digital key, as well as a root certificate, is performed. These two keys are generated corresponding to each other and authenticated using the root certificate. The root certificate is a certificate signed by the certificate authority itself. It is used to verify the validity of all certificates (keys in this example) issued by the certificate authority. Specifically, the generation is performed at the network's backend. In a further method step, the protected storage of the private first digital key is first performed at the network's backend, and respective key copies of the public second digital key are generated and stored for each terminal. Then, two identical public second digital keys are directly generated and transmitted or forwarded to the respective terminals, or these are pre-installed there, wherein one key may be generated first, followed by a key copy of it.

[0009] To achieve the objectives of this invention, and further develop a method for encrypting data transmission to provide particularly strong data protection, according to this invention, before transmitting data between a first terminal as the sender and a second terminal as the receiver, a verification certificate is created by the second terminal, i.e., the receiver terminal, and transmitted to a backend where it is signed by a root certificate. The signed verification certificate is then sent back to the second terminal, and the public second digital key of the signed verification certificate is sent to either the first terminal or the sender terminal, where it is checked against a private key copy of the public second digital key. If verification fails, either the first terminal or the sender terminal rejects the encrypted transmission of the data. Conversely, if verification succeeds, a unique symmetric session key is generated, encrypted with a key copy of the public second digital key of the signed verification certificate, and the data to be transmitted is encrypted using this key. The encrypted session key and the thus encrypted data are then transmitted to the second terminal, i.e., the receiver terminal, where they are decrypted using the private first digital key of the verification certificate. Thus, if verification fails, the first terminal, i.e., the sender terminal, is notified; or if verification succeeds, the data is decrypted using the session key. Therefore, session keys and verification certificates provide particularly protected data transmission against unauthorized third parties, including hackers.

[0010] In other words, an embodiment of a method for hybrid end-to-end (E2E) encryption is provided for authentication and authorization of highly sensitive communications between two or more parties, including technical systems, particularly embedded systems.

[0011] In this scenario, a root certificate with private and public keys is first generated for the system consisting of terminals and a network with a backend, provided by this method. The private first digital key is stored and protected in the public backend. The public key is initially stored in the terminal or pre-installed in, for example, an ECU without a backend connection. If a terminal wants to "push" or is requested to "pull" highly sensitive data to another terminal, it requests a unique verification certificate with a public key from the receiving terminal, which is signed by the backend with the root certificate. Furthermore, the sending terminal checks the signature and validity period of the verification certificate using the public key of the root certificate. If they match, and verification is successful, further steps of the method are initiated; otherwise, the receiving terminal is rejected. Additionally, a unique symmetric session key is generated to encrypt the highly sensitive data to be sent, wherein the session key is encrypted with the public key of the verification certificate. The encrypted highly sensitive data and the encrypted session key are then transmitted to the receiving terminal. Finally, the receiving terminal decrypts the session key with the private first digital key of the verification certificate; if the signature and validity period match, further method steps are initiated, and the highly sensitive data is decrypted with the session key. In the event of a failed match, the sender terminal is notified via a signal.

[0012] In an advantageous embodiment of the invention, the generation of a private first digital key, a public second digital key, and a root certificate is triggered by a command transmitted from one terminal to the backend. This means that the terminal is designed to transmit the command at any time via input, allowing data transmission to be initiated by the terminal's user. Alternatively, generation can also be triggered by commands from other nodes on the server (e.g., from partially autonomous or autonomous terminals).

[0013] Another advantageous design of the invention involves a public second digital key protected in a separate memory outside the network. For example, the public second digital key thus generated and transmitted to the corresponding terminal can be transmitted to a memory coupled to the terminal, resulting in the key not being lost in the event of a terminal defect. In particular, storing the key in a memory outside the network ensures key security and avoids the generation of new keys, thereby, for example, at least partially reducing the working memory requirements of the method.

[0014] In another advantageous embodiment of the invention, a private first digital key is provided to be stored in a protected manner in a memory outside the network. In this case, external storage allows data stored in the backend to also remain protected in another memory. This is particularly advantageous when using a third-party network provider, as the external network storage can be shut down, for example, at the OEM, thus enabling key backup, and can only be provided by the OEM.

[0015] In another advantageous embodiment of the invention, the public second digital key is initially stored in each terminal. This not only avoids generation, but also ensures that the unique key is assigned to only this one terminal. As a result, simplified yet still secure encryption is provided, for example, through an already performed encryption process, without having to allocate working memory for a new key. The public second digital key is initially stored in the terminal, or, for example, pre-installed in an ECU without a backend connection. The root certificate can be activated for a longer period, such as over 20 years, and renewed as needed.

[0016] Also advantageous is the design of the present invention, in which a counter is used to continuously count failed verifications. In this case, the counter should always be triggered when it fails verification for various reasons. The reasons can be categorized, and data on the failures can be stored for statistical evaluation and improvement. Similarly, different counters can be combined in this method to collect different data and information.

[0017] Another advantageous design of the invention involves triggering at least one warning signal when the counter count exceeds a predetermined value. Specifically, third-party login attempts and hacking attacks should be immediately identified and forwarded to the network. Therefore, potential unauthorized interference can be immediately prevented, thus preventing transmission.

[0018] In other advantageous embodiments of the invention, a validity period for the verification certificate or signature is provided, and encrypted transmission is time-limited. Specifically, if a connection to a backend is successful and communication is conducted over a public network, the validity period of the verification certificate is significantly shortened, potentially to as little as one day or even two hours, depending on the application, to prevent unauthorized data interception by hackers or others. This time limitation also allows data transmission to proceed for a period before being interrupted after a predetermined time has elapsed. This prevents unauthorized interference with the transmission.

[0019] A particularly advantageous aspect is:

[0020] - By using root certificates and verification certificates (which are certified and authorized), ensure that the sending terminal only sends data that has been successfully verified with the root certificate in terms of signature and validity period (i.e., from an authorized terminal).

[0021] Highly sensitive data is only transmitted at specific times.

[0022] - By using a verified certificate generated for the current communication session (which is certified), highly sensitive data is ensured to be encrypted and decrypted using a session key protected by the verified certificate.

[0023] - Symmetric session keys that are encrypted or decrypted using asymmetric authentication keys can encrypt or decrypt highly sensitive data in embedded systems without requiring a large CPU load.

[0024] - If a terminal or component (e.g., an ECU without a back-end connection in an embedded system) needs to send highly sensitive data to another terminal or component in a protected manner, this can also be done without a back-end connection, but a previously verified certificate that is still valid must be used, which is possible in protected embedded systems with a longer validity period.

[0025] - If the backend connection is successful and communication is conducted over a public network, the validity period of the verification certificate will be significantly shortened, up to one day or even two hours, depending on the application, to prevent unauthorized replay attacks by hackers.

[0026] Other terminals or components can more easily use their dedicated verification certificates and public root certificates.

[0027] Insert into a protected system. Detailed Implementation

[0028] Further advantages, features, and details of the invention are set forth in the following description of preferred embodiments and with reference to the accompanying drawings. Without departing from the scope of the invention, the features and combinations thereof mentioned in the specification, and the features and combinations thereof mentioned and / or shown individually in the accompanying drawings, may be used not only in their respective combinations, but also in other combinations or individually.

[0029] In this case, a single Figure 1 Possible examples of methods for encrypting data transmission 10 according to the present invention are shown, particularly by means of hybrid E2E encryption and authentication.

[0030] This example illustrates a network with a backend 12, a first terminal 14, and a second terminal 16. The backend 12 is accessible to registered terminals, namely the first and second terminals 14 and 16. In this example, the first terminal 14 is shown as the sender, and the second terminal 16 is shown as the receiver.

[0031] Figure 1A loop for a request method is illustrated, which begins with initialization 20 to generate a root certificate Z (not shown), a private first digital key S1 (not shown), and a public second digital key S2 (not shown). The public second digital key S2 is copied in such a way that a first key copy K1 and a second key copy K2 are generated for forwarding to all terminals 14 and 16, and for encrypting and protecting authorized transmissions of highly sensitive data. Therefore, in initialization 22, the public root certificate Z is generated, and the protected private first digital key S1 is generated. Subsequently, key copy K1 is sent to the first terminal 14 at 24, and key copy K2 is sent to the second terminal 16 at 26.

[0032] Next is sequence 28, which involves a substitution request between the first terminal 14 and the second terminal 16, where request 30 for sending highly sensitive data (pull data) is triggered by the second terminal 16. This is followed by request 32 for the public second digital key S2 or key copy K1, for sending the verification certificate Z* of the highly sensitive data (push) via the first terminal 14. In cases where the backend connection is unavailable, such as for embedded components without a backend connection, a valid verification certificate Z* needs to be reused (33) for initialization in such situations.

[0033] Subsequently, on the second terminal 16, the generation of verification certificate Z* is performed (34), and then a request (36) is initiated on the backend 12 to sign verification certificate Z* with the root certificate, i.e., root certificate Z. Afterwards, the signed verification certificate Z** is sent back from the backend 12 to the second terminal 16 (38). Transmission (40) occurs. In this case, the second terminal 14 sends back either the public second digital key S2 used for signing highly sensitive data or a copy of the key K1 of the signed verification certificate Z**.

[0034] The steps for the first terminal 14 are as follows:

[0035] - In the first step 42, the validity of the signature and the verification certificate Z** are checked using the public second digital key S2 and the key copy K1 of the root certificate Z, respectively. If the verification fails, a stop occurs at step 46, where the process stops and the receiver, i.e., the second terminal 16, is notified.

[0036] - In the second step 44, a random session key is generated, namely a unique symmetric session key S*.

[0037] - In step 3, 48, all highly sensitive data is encrypted using the session key S*.

[0038] - In step 50, the session key S* is encrypted using either the public second digital key S2 or the key copy K1 of the signed verification certificate Z**.

[0039] Finally, in the fifth step, the first terminal 14 transmits 52 encrypted data and the session key S* to the second terminal 16, and performs corresponding decryption 54. In this case, the second terminal 16 decrypts the session key S* using the private first digital key S1 of the verification certificate Z*. If decryption fails, a stop occurs 58, where the process stops and the sending first terminal 14 is notified. Otherwise, decryption occurs 56, where the second terminal 16 decrypts the highly sensitive data using the session key S*. This completes the method for encrypting transmitted data.

[0040] In other words, in Figure 1 The present invention provides a method for encrypting and transmitting data between terminals 14 and 16 over a network, the method comprising the following steps:

[0041] - Generate a private first digital key S1 and a public second digital key S2, as well as a root certificate Z;

[0042] - The private first digital key S1 is stored securely in the backend 12 of the network; and

[0043] - Generate and store corresponding key copies K1 and K2 of the public second digital key S2 in the corresponding terminals 14 and 16;

[0044] In this scenario, a verification certificate Z* is created and transmitted to the backend 12 before data transmission via the second terminal 16 (receiving terminal), and is signed by the root certificate Z in the backend 12. Subsequently, the signed verification certificate Z** is transmitted to the first terminal 14 and verified by the first terminal 14 (sender terminal) using a private key copy K1 of the public second digital key S2. Thus, in the event of verification failure, encrypted data transmission is rejected; or in the event of successful verification, a unique symmetric session key S* is generated, encrypted with the key copy K1 of the public second digital key of the signed verification certificate Z**. Furthermore, the session key S* is transmitted to the second terminal 16 and decrypted using the private first digital key S1 of the signed verification certificate Z**. This notifies the first terminal 14 in the event of verification failure, or decrypts the data using the session key S* in the event of successful verification.

[0045] The generation of the private first digital key S1, the public second digital key S2, and the root certificate Z can also be initiated by a command transmitted from one of terminals 14 and 16 to the backend 12. Similarly, the public second digital key S2 is stored encrypted in external memory. Furthermore, the private first digital key S1 can also be stored encrypted in external memory. Additionally, the public second digital keys K1 and K2 are initially stored in terminals 14 and 16, respectively.

[0046] In the event of a series of failed verifications, these verifications can be counted using a counter, and if the counter count exceeds a predetermined value, at least one warning signal can be triggered.

[0047] Similarly, the validity period of the verification certificate Z* can be specified relative to the signature verification certificate Z**, and encrypted transmissions are time-limited.

[0048] List of reference numerals

[0049] 10. Encrypted transmission

[0050] 12 Backend

[0051] 14 First Terminal

[0052] 16 Second Terminal

[0053] 20 Initialization

[0054] 22 Initialization

[0055] 24 Send

[0056] 26 Send

[0057] 28-sequence

[0058] 30 Requests

[0059] 32 Requirements

[0060] 33 Reuse

[0061] 34 generated

[0062] 36 Request

[0063] 38. Send back

[0064] 40 Transmission

[0065] 42. Step 1

[0066] 44 Step Two

[0067] 46 Stop

[0068] 48 Step 3

[0069] 50 Step Four

[0070] 52 Transmission

[0071] 54 Decryption

[0072] 56 Decryption

[0073] 58 Stop

[0074] K1 First Key Copy

[0075] K2 Second Key Copy

[0076] S1 First Key

[0077] S2 Second Key

[0078] S* Session Key

Claims

1. A method for encrypting the transmission (10) of data between a first terminal (14) transmitting data and at least one second terminal (16) receiving data via a network, comprising the following steps: - generating a private first digital key and a public second digital key and a root certificate; - storing the private first digital key securely in a backend (12) of the network; and - generating and storing a respective key copy of the public second digital key for the respective terminals and transmitting the respective key copy to the respective terminals; characterized in that - prior to the transmission of data, a verification certificate is created by means of the second terminal (16) and transmitted to the backend (12), and the verification certificate is signed in the backend (12) by the root certificate; - the signed verification certificate is sent back to the second terminal (16), the public second digital key of the signed verification certificate is transmitted to the first terminal (14) and verified with a private key copy of the public second digital key, wherein in the event of a failed verification, the first terminal (14) rejects the encrypted transmission of data, or in the event of a successful verification, a unique symmetric session key is generated which is encrypted with the key copy of the public second digital key of the signed verification certificate, by means of which the data to be transmitted is encrypted; - the encrypted session key and the data encrypted thereby are transmitted to the second terminal (16) and decrypted by means of the private first digital key of the signed verification certificate, wherein in the event of a failed verification, the first terminal (14) is notified, or in the event of a successful verification, the data is decrypted with the session key.

2. The method according to claim 1, characterized in that the private first digital key and the public second digital key and the root certificate are generated by means of a command transmitted from one of the terminals to the backend (12).

3. The method according to claim 1 or 2, characterized in that the public second digital key is stored in an encrypted manner in a memory external to the network.

4. The method according to claim 1 or 2, characterized in that the private first digital key is stored in an encrypted manner in a memory external to the network.

5. The method according to claim 1 or 2, characterized in that the public second digital key is initially stored in the terminals.

6. The method according to claim 1 or 2, characterized in that the failed verifications are continuously counted with a counter.

7. The method according to claim 6, characterized in that in the event that the count of the counter is higher than a predetermined value, at least one warning signal is triggered.

8. The method according to claim 1 or 2, characterized in that a validity period of the verification certificate is predetermined.

9. The method according to claim 1 or 2, characterized in that a validity period of the signed verification certificate is predetermined.

10. The method according to claim 1 or 2, characterized in that the encrypted transmission is limited in time.

Images