DE102023134816A1 - Method for encrypted communication of electronic terminals with an access device as well as communication device, terminal management unit and terminal therefor - Google Patents

Abstract

The invention discloses a method for encrypted communication between electronic terminal devices (D) using a network key (NetKey). A shared secret key (K) is agreed upon for exchanging the network key (NetKey). For this purpose, device-specific data of a unique certificate (ZertD) for the terminal device (D) is transmitted to a terminal device management unit (S). The unique certificate (ZertD) for the terminal device (D) is determined by the terminal device management unit (S) using a certificate generation routine based on the transmitted device-specific data and known static data. After verifying the validity of the specific certificate (ZertD) and authenticating the terminal device (D), a shared secret key (K) for the authorized terminal device (D) and the terminal device management unit (S) is calculated using data from the specific certificate (ZertD) recognized as valid. The network key (NetKey) is transmitted to the terminal device (D) encrypted with the calculated shared secret key (K). The terminal device (D) can then calculate the shared secret key (K) using a device-specific secret key (PrivKeyD) known to it and data (PubKeyS) received from the terminal device management unit (S) and decrypt the received encrypted network key (NetKey) with the calculated shared secret key (K).

Description

The invention relates to a method for encrypted communication between electronic terminals and an access device. The terminals have a communication unit for data communication and are configured to communicate with the access device. The terminal and the access device are configured to encrypt and decrypt encrypted transmitted data using a network key. The terminal and the access device agree on a common secret key for the encrypted communication.

The invention further relates to a communication device having an access device and a plurality of terminals configured for encrypted communication with the access device, wherein a terminal registration unit is coupled to the access device and configured for registering terminals and for encrypted transmission of a secret network key to the registered terminals.

A communication key is required for encrypted communication between components of a communications system with distributed end devices and an access device. This key must be communicated to new components securely when training them. This can be done, for example, using a central key management unit, i.e., a key server, or by user input of a device-specific, previously assigned key.

WO 2021/141685 A1 Describes a method for improving the security of communication between client and server instances, while simultaneously enabling the rotation of server certificates (e.g., X509 certificates). A client list of server certificates (e.g., a certificate fingerprint) is updated without reconfiguring or reinstalling a client and/or server application, without starting a new session (e.g., a Hypertext Transfer Protocol Secure (HTTPS) session), or without deploying new code. A client certificate list can thus be passively or actively updated to enable a client to non-invasively verify the identity of a server instance, thus increasing security against man-in-the-middle attacks.

US 10,992,656 B2 discloses examples of distributed profile and key management. For example, a management service may generate a partially populated device profile and provide the partially populated device profile to a client application executable on a client device. The client application may generate a credential and insert the credential into the partially populated device profile to generate a fully populated device profile. The credentials may be shared with at least one other client application on the client device. The management service may use the fully populated device profile to generate multiple profiles based on a single credential, such as a single X.509 security certificate. This allows configurations to be exchanged, compiled, and transmitted as a whole.

EP 3 451 218 B1 discloses a method for the subsequent generation of a device certificate for verifying an electronic device according to a public key infrastructure without transmitting a public key. The method comprises obtaining a first key, which is a symmetric key and is assigned to the device, at a certificate generation device. A second key for the electronic device is derived from the first key. The device certificate for the public key infrastructure is generated, wherein the second key acts as a public key assigned to the device certificate. Similarly, a private key for the public key infrastructure can be generated by the electronic device based on a common first, symmetric key. This approach makes it possible to reduce the manufacturing costs for producing an electronic device while simultaneously enabling the use of a public key infrastructure to certify the properties of the device.

EP 3 451 222 A1 describes a method for post-manufacturing certificate generation for an electronic device, in which a public key is obtained from the electronic device and the device is enrolled in a trust chain provided by a public key infrastructure in which a subordinate certificate is validated by an attestor associated with a parent certificate in the chain. Enrollment comprises generating a certificate of the electronic device for the trust chain using the public key obtained from the electronic device. Enrollment takes place on a registration device separate from the electronic device. The electronic Device certificate is a derived certificate of the enrollment device certificate associated with the enrollment device.

If communication with a key server is not desired or not possible (e.g., because the system is not connected to the Internet) and user input is impractical (e.g., because the system is large), it is still possible to encrypt the communication key using an asymmetric encryption method. For this purpose, the Diffie-Hellman with elliptic curves (ECDH) method can be used.

For key exchange via ECDH, X.509 certificates are used and exchanged between the components. These include, among other things, a public key and a signature (also called a certificate).

The certificates are more than 300 bytes in size. Transmitting such large data volumes poses problems, especially when considering the potential size of distributed systems, especially for radio communication in the sub-GHz frequency range.

Since data must be transmitted encrypted, the communication key required for encryption must be securely transmitted from the management software to the components. A connection to a key server is not desirable and often technically impossible, as there is often no internet connection when setting up a communication system, such as a warehouse management system or a building automation system. Furthermore, it is undesirable, or rather impractical, especially for larger systems, for the user to enter individual device keys for the end devices into key management software for all components.

The object of the present invention is to provide an improved method for encrypted communication between electronic terminals and an access device and a related communication device, in which the registration of the device key in the access device and the secure transmission of a network key from the access device to the terminals takes place with a reduced number of data to be transmitted and without the need to handle registration data which is provided to the terminals to be registered, for example with QR codes, and is entered directly into the access device using a method other than the encrypted communication path.

The object is achieved by the method having the features of claim 1, the communication device having the features of claim 10, the access unit having the features of claim 15, and the terminal having the features of claim 16. Advantageous embodiments are described in the subclaims.

• - Übertragen von geräteindividuellen Daten eines eineindeutigen Zertifikates für das Endgerät an das Zugriffsgerät, wobei die geräteindividuellen Daten das Endgerät eineindeutig charakterisieren;
• - Bestimmen des eineindeutigen Zertifikates für das Endgerät anhand der übertragenen geräteindividuellen Daten und anhand von dem Endgerät und einer Endgeräte-Verwaltungseinheit bekannten statischen Daten mit einer Zertifikat-Generierung Routine durch die mit dem Zugriffsgerät gekoppelten Endgeräte-Verwaltungseinheit;
• - Überprüfen der Gültigkeit des bestimmten Zertifikates für das Endgerät durch die Endgeräte-Verwaltungseinheit und Authentifizieren des Endgerätes als ein für die Kommunikation mit dem Zugriffsgerät zugelassenes Endgerät, sofern das Zertifikat als gültig erkannt wurde;
• - Berechnen eines gemeinsamen geheimen Schlüssels für das zugelassene Endgerät und die Endgeräte-Verwaltungseinheit mit Daten des bestimmten und als gültig erkannten Zertifikats durch die Endgeräte-Verwaltungseinheit;
• - Verschlüsseln des Netzwerkschlüssels mit dem berechneten gemeinsamen geheimen Schlüssel durch die Endgeräte-Verwaltungseinheit; und
• - Übertragen des verschlüsselten Netzwerkschlüssels von dem Zugriffsgerät an das Endgerät, wobei das Endgerät mit einem ihm bekannten geräteindividuellen geheimen Geräteschlüssel und mit von der Endgeräte-Verwaltungseinheit empfangenen Daten den gemeinsamen geheimen Schlüssel berechnet und den empfangenen verschlüsselten Netzwerkschlüssel mit dem berechneten gemeinsamen geheimen Schlüssel entschlüsselt.

The following steps are proposed for a generic procedure:

• - Transferring device-specific data of a unique certificate for the terminal device to the access device, whereby the device-specific data uniquely characterises the terminal device;
• - Determining the unique certificate for the terminal device based on the transmitted device-specific data and on static data known to the terminal device and a terminal device management unit using a certificate generation routine by the terminal device management unit coupled to the access device;
• - Verification of the validity of the specific certificate for the terminal device by the terminal device management unit and authentication of the terminal device as a terminal device authorized for communication with the access device if the certificate is recognized as valid;
• - Calculating a common secret key for the authorized terminal device and the terminal device management unit using data from the specific certificate recognized as valid by the terminal device management unit;
• - Encryption of the network key with the calculated shared secret key by the terminal management unit; and
• - Transferring the encrypted network key from the access device to the terminal device, whereby the terminal device calculates the common secret key using a device-specific secret key known to it and data received from the terminal device management unit and decrypts the received encrypted network key with the calculated shared secret key.

This exploits the fact that during the production of the end devices, the required device-specific secret device keys (private keys) and the associated certificates are created, signed, and programmed into the end devices by software. Since these certificates are always created in the same way, they differ only in a few device-specific parts, i.e., device-specific (variable) data. These include the serial number, the public key, and the signature. The rest of the certificate is static for a certificate issuer or at least for a production series and can therefore be transmitted once to an access device responsible for registering a production series of end devices, or to a linked end device management unit, without the static certificate data having to be transmitted again to the access device or end device management unit for each end device.

After receiving the device-specific data of the certificate from the device, the terminal device management unit is able to determine the complete device-specific certificate of the terminal device together with the known static data of the certificate by combining the device-specific data with the known static data according to the structure scheme for the certificate known to the terminal device management unit.

The certificate required for authentication and use of a public asymmetric key thus does not need to be transmitted in its entirety. Furthermore, the end device does not need to be registered manually or via another communication channel, such as QR codes, with the end device management unit. Registration and the associated release and transmission of the secret network key take place after the certificate verification using the device-specific data contained therein.

For example, unique device information and unique device identification can be transmitted as device-specific data of the end device.

The unique device information can be a public device key and/or a device signature.

The unique device identification can be a serial number of the end device.

Static data for generating the unique certificate can be, for example, a manufacturer identifier, a version identifier, a country identifier, a place of manufacture identifier and/or validity periods.

It is advantageous to generate the device key for encrypted communication in the form of an asymmetric key, in particular a private secret key of a pair of private and public keys.

The asymmetric key can be generated using elliptic curves with the Elliptic Curve Diffie-Hellman Key Agreement (ECDH) protocol.

Encryption of the network key can be performed with a symmetric block cipher algorithm (AES) by encrypting blocks of the network key with the device key.

A communications device configured to carry out the above-mentioned method comprises an access device and a plurality of terminals configured for encrypted communication with the access device. The access device is coupled to a terminal management unit configured to register terminals and to transmit a secret network key to the registered terminals in encrypted form. This terminal management unit can be configured as an electronic device, e.g., as a computer or key server equipped with key management software. The terminal management unit coupled to the access device can also be implemented as a computer program that runs on a data processing unit directly or indirectly connected to a data communication unit and thereby executes, or at least triggers and controls, the above-mentioned method steps.

It is proposed that the terminal devices be configured to transmit device-specific data that uniquely characterize the terminal device to the terminal device management unit, to calculate the shared secret key using a device-specific secret device key known to the terminal device and other data, and to decrypt the received encrypted network key using the calculated shared secret key. The additional data can be data from the terminal device management unit, such as, in particular, a public device key of the terminal device management unit and/or other or additional data from the certificate of the terminal device management unit and/or data from the certificate of the terminal device.

1. a) zur Bestimmung eines eineindeutigen Zertifikates für das zu registrierende Endgerät anhand der übertragenen geräteindividuellen Daten und anhand von dem Endgerät und der Endgeräte-Verwaltungseinheit bekannten statischen Daten mit einer Zertifikat-Generierung Routine,
2. b) zur Überprüfung der Gültigkeit des berechneten Zertifikates für das Endgerät und zur Registrierung des Endgerätes als für die Kommunikation mit dem Zugriffsgerät zugelassenes Endgerät, sofern das Zertifikat als gültig erkannt wurde,
3. c) zum Berechnen eines gemeinsamen geheimen Schlüssels für das zugelassene Endgerät und die Endgeräte-Verwaltungseinheit mit Daten des bestimmten und als gültig erkannten Zertifikats durch die Endgeräte-Verwaltungseinheit,
4. d) zum Verschlüsseln des Netzwerkschlüssels mit dem berechneten gemeinsamen geheimen Schlüssel und
5. e) zur Steuerung einer Übertragung des verschlüsselten Netzwerkschlüssels über das Zugriffsgerät an das Endgerät eingerichtet ist.

The terminal device management unit is set up:

1. a) to determine a unique certificate for the terminal device to be registered based on the transmitted device-specific data and on the basis of static data known to the terminal device and the terminal device management unit using a certificate generation routine,
2. b) to verify the validity of the calculated certificate for the terminal device and to register the terminal device as a terminal device authorized for communication with the access device, provided that the certificate has been recognized as valid,
3. c) to calculate a common secret key for the authorized terminal device and the terminal device management unit using data from the specific certificate recognized as valid by the terminal device management unit,
4. d) to encrypt the network key with the calculated shared secret key and
5. e) is set up to control the transmission of the encrypted network key via the access device to the terminal device.

This interaction enables a data-reduced certificate exchange, secure and simple authentication and registration of end devices with the end device management unit, and secure transmission of the encrypted network key to the authenticated end devices.

The communication device may have at least one access device, i.e. an access point, which has the secret network key and is configured for encrypted communication with the terminal device management unit and for communication with the terminal devices and forwarding data between the distribution device and the terminal devices.

The terminal devices and the access device can each have transceivers and be configured for wired or wireless communication.

The access device can be, for example, a base station, an access point or a repeater of a communication system, e.g. a storage facility or a building automation device.

The access device can optionally also be a terminal device registered with the terminal device management unit, via which the communication between the terminal device to be registered and the terminal device management unit is handled. This terminal device serving as an access device can, for example, act as a router.

After the initial key exchange, multiple registered devices can also communicate directly with each other. This applies even if an additional access device is present, such as an access point, a repeater, or a system control center. Communication between the participants in the communication device is made possible by exchanging the shared secret network key with the registered participants.

The terminal management unit can be implemented as a computer program functionality in a computer that is wired or wirelessly coupled to the at least one access device. However, the terminal management unit can also be integrated into an access device, such as a base station.

1. a) zur Bestimmung des eineindeutigen Zertifikates für das zu registrierende Endgerät anhand der übertragenen geräteindividuellen Daten und anhand von dem Endgerät und dem Zugriffsgerät bekannten statischen Daten mit einer Zertifikat-Generierung Routine,
2. b) zur Überprüfung der Gültigkeit des berechneten Zertifikates für das Endgerät und zur Registrierung des Endgerätes als für die Kommunikation mit dem Zugriffsgerät zugelassenes Endgerät, sofern das Zertifikat als gültig erkannt wurde,
3. c) zur Berechnung eines gemeinsamen geheimen Schlüssels für das zugelassene Endgerät und die Endgeräte-Verwaltungseinheit mit Daten des bestimmten und als gültig erkannten Zertifikats durch die Endgeräte-Verwaltungseinheit,
4. d) zum Verschlüsseln des Netzwerkschlüssels mit dem berechneten gemeinsamen geheimen Schlüssel und
5. e) zur Steuerung einer Übertragung des verschlüsselten Netzwerkschlüssels über das Zugriffsgerät an das Endgerät.

The terminal device management unit is configured to authenticate terminal devices and transmit a secret network key to the registered terminal devices in encrypted form. The terminal device management unit is configured to:

1. a) to determine the unique certificate for the terminal device to be registered based on the transmitted device-specific data and on the basis of static data known from the terminal device and the access device using a certificate generation routine,
2. b) to verify the validity of the calculated certificate for the terminal device and to register the terminal device as a terminal device authorized for communication with the access device, provided that the certificate has been recognized as valid,
3. c) to calculate a common secret key for the authorized terminal device and the terminal device management unit using data from the specific certificate recognized as valid by the terminal device management unit,
4. d) to encrypt the network key with the calculated shared secret key and
5. e) to control the transmission of the encrypted network key via the access device to the terminal device.

The terminal device is configured to transmit device-specific data of a unique certificate for the terminal device to the terminal device management unit, whereby the device-specific data uniquely characterizes the terminal device. The terminal device can be configured to calculate the shared secret key using a device-specific secret device key known to the terminal device and data from the terminal device management unit, and to decrypt the received encrypted network key using the calculated shared secret key.

The terminal device is thus configured to receive an encrypted network key from the terminal device management unit and to decrypt the received encrypted network key using the calculated shared secret key. Individual secret device keys of the terminal device and the terminal device management unit can be used to encrypt and decrypt the network key, which are known only to the terminal device and the terminal device management unit, respectively.

For this purpose, a key exchange can be carried out using the Diffie-Hellman method, preferably using elliptic curves according to the ECDH method (Elliptic Curve Diffie-Hellman). Through the bidirectional exchange of the respective public keys between the end device and the end device management unit, the same common key for encrypting and decrypting the network key can be calculated using the respective secret (not exchanged) private keys and parameters known to both communication partners, e.g., parameters of an agreed-upon elliptic curve, as well as the exchanged public keys. Since the secret device keys are unknown and are not communicated, an attacker eavesdropping on the communication cannot derive the common key based on the exchanged data.

• 1 - Blockdiagramm einer Kommunikationseinrichtung mit einer Zugriffseinheit, Verteilergeräten und einer Anzahl von Endgeräten;
• 2 - Kommunikationsdiagramm des Ablaufs für den Schlüsseltausch zwischen Zugriffseinheit und zu registrierenden Endgerät.

The invention is explained in more detail below with reference to the accompanying drawings. They show:

• 1 - Block diagram of a communication device with an access unit, distribution devices and a number of terminal devices;
• 2 - Communication diagram of the key exchange process between the access unit and the terminal to be registered.

1 shows a block diagram of a communication device 1 with at least one access device A, a terminal management unit S coupled to the access device A and a number of terminals D.

The terminal devices D comprise a data processing unit 2, such as a microprocessor or microcontroller, a data memory 3 and a transceiver 4 for data communication.

The access devices A also have transceivers 5a, 5b and a signal processing unit 6, which is designed to forward at least data received from one of the transceivers 5a, 5b to a terminal D coupled via a communication channel K1 or to the terminal management unit S.

The terminal device management unit S can be integrated into an access device A or can be coupled to the access devices A either wired or wirelessly via a communication channel K2. For this purpose, the access devices A each have a transceiver 5b, whose functionality can alternatively be implemented by a single transceiver 5a for both communication channels K1, K2.

The terminal management unit S has a transmitter 7 for wired or wireless communication with the access devices A. The transmitter 7 is connected to a data processing unit 8. The data processing unit 8 is coupled to a data storage unit 9.

The data processing units 2, 6, 8 preferably interact with a computer program having program code means which, when the computer program is executed, cause the respective data processing unit and the data memories 3, 9 or transmitters 4, 5a, 5b, 7 connected thereto to carry out the method according to the invention.

In particular, the logic of the terminal devices D and the terminal device management unit S, which is designed for authentication, registration and the protected exchange of a secret network key, is explained below.

In production, for example, the required device-specific data, specifically the secret device key (PrivKeyD), as well as the associated certificates in combination with standardized static data for the communication device, are created, signed, and programmed into the devices by software. Since the certificates are always created in the same way, they differ only in a few parts, namely the device-specific data. These include, for example, a serial number, a public device key (PubKey), and a signature for the entire certificate (CertificateD).

Certificate:
   Data:
      Version: 1 (0x0)
      Serial Number: 1 (0x1)
   Signature Algorithm: ecdsa-with-SHA256
      Issuer: C=DE, ST=Germany, L=Leer, O=eQ-3, CN=SP-CA
      Validity
      Not Before: Sep 4 00:00:00 2022 GMT
      Not After : Aug 22 00:00:00 2122 GMT
      A Subject: CN=EEE1234567
      Subject Public Key Info:
         Public Key Algorithm: id-ecPublicKey
            Public-Key: (256 bit)
            pub:
            B 04:51:52:be:a7:95:d7:19:a1:11:01:2f:c7:db:bd:
            B 6a:f4:b5:da:57:12:b8:13:87:da:aa:75:80:e8:f6:
            B f1:3f:4d:1e:15:67:ee:b7:c6:73:7e:6a:16:2c:25:
            B eb:a2:47:1d:b7:e6:56:b2:54:ac:08:6d:c4:87:54:
            B 99:b6:d9:99:99
         ASN1 OID: prime256v1
         NIST CURVE: P-256
   Signature Algorithm: ecdsa-with-SHA256
   C 30:46:02:21:00:85:c7:78:8e:1f:39:42:3e:d7:e4:70:f4:51:
   C dc:6c:2f:46:22:b3:51:61:dd:36:0c:a4:58:91:ed:10:5b:87:
   C 41:02:21:00:ff:1b:9a:02:96:7d:62:3b:59:d2:6a:0e:1d:75:
   C 20:2c:e0:fa:22:ab:70:ac:62:36:7f:86:c5:d1:67:09:4c:f1 

Certificates can be structured as follows, for example:

 Certificate:
   Data:
      Version: 1 (0x0)
      Serial Number: 1 (0x1)
   Signature Algorithm: ecdsa-with-SHA256
      Issuer: C=DE, ST=Germany, L=Leer, O=eQ-3, CN=SP-CA
      Validity
      Not Before: Sep 4 00:00:00 2022 GMT
      Not After : Aug 22 00:00:00 2122 GMT
      A Subject: CN=EEE1234567
      Subject Public Key Info:
         Public Key Algorithm: id-ecPublicKey
            Public key: (256 bit)
            pub:
            B 04:51:52:be:a7:95:d7:19:a1:11:01:2f:c7:db:bd:
            B 6a:f4:b5:da:57:12:b8:13:87:da:aa:75:80:e8:f6:
            B f1:3f:4d:1e:15:67:ee:b7:c6:73:7e:6a:16:2c:25:
            B eb:a2:47:1d:b7:e6:56:b2:54:ac:08:6d:c4:87:54:
            B99:b6:d9:99:99
         ASN1 OID: prime256v1
         NIST CURVE: P-256
   Signature Algorithm: ecdsa-with-SHA256
   C 30:46:02:21:00:85:c7:78:8e:1f:39:42:3e:d7:e4:70:f4:51:
   C dc:6c:2f:46:22:b3:51:61:dd:36:0c:a4:58:91:ed:10:5b:87:
   C 41:02:21:00:ff:1b:9a:02:96:7d:62:3b:59:d2:6a:0e:1d:75:
   C 20:2c:e0:fa:22:ab:70:ac:62:36:7f:86:c5:d1:67:09:4c:f1 

The underlined elements, labeled A, B, and C in the first column, are unique to each certificate. These are device-specific data.

The device-specific data labeled A is a serial number for the device D. The device-specific data labeled B is the device's public key PubKeyD. The device-specific data of the device D labeled C is the signature SigD for the certificate ZertD of the device D, which is composed of device-specific (dynamic) data and static data.

Furthermore, the ZertD certificate includes static data, such as a version number, a serial number, the specification of the signature algorithm, data about the issuer of the certificate, a country code (C=DE = Germany; ST=Germany), a location code (L=city), a manufacturer company (O=company abbreviation) and a common name that identifies the domain on which a certificate is installed (CA = certification authority).

As static data, information about the public device key, in particular the bit length of the block coding, an object identifier of an object, e.g. according to the ASN.1 standard, and the selected elliptic curve NIST CURVE as a predefined parameter for calculating the shared secret key K can also be included in the certificate.

As static data, a validity period VALIDITY can be defined for all components of communication unit 1. This period can extend over a very long period and be set so that no certificate renewal is necessary over the expected lifetime of the communication device. However, a limited validity period can also be defined, so that all participants must renew their certificates before expiration.

The structure of the ZertD certificate, composed of device-specific data and static data, is used to transmit only the device-specific data, such as the serial number, the respective public device key PubKeyD, PubKeyS, and the signature SigD, when registering a terminal device D, rather than the entire ZertD certificate. This allows the ZertD certificate to be verified to authenticate the terminal device D, and a shared secret key K can be generated by the terminal device management unit S and the terminal device D to be registered. This key can be used to encrypt a network key NetKey and securely transmit it from the terminal device management unit S to the terminal device D to be registered.

The component that receives the device-specific data can then create the certificate itself from the variable and the static data known to it and, for example, using the ECDH method, calculate an asymmetric key that is used as a shared secret key by the terminal device D and the terminal device management unit S for encrypted communication.

Since the certificates in the end devices D were signed by the software in production, the authenticity of the end devices D can also be verified by checking the signature.

Connecting the end devices D to a key server or requiring a user to enter device-specific keys is not required. Key servers and the entry of local keys are not required.

2 shows a communication diagram of the key exchange process between the terminal management unit S and the terminal D to be registered via the intermediate access device A.

The end devices D each have a device-specific certificate ZertD, which contains device-specific data including a public device key PubKeyD, a signature for the certificate ZertD, and possibly other device-specific data, such as a unique device identification (e.g., serial number). The device-specific certificate also contains static data, such as a manufacturer identification, a validity period, a country code, and the like, which is uniform for all end devices D or an approved group of end devices D of the communication unit 1.

Furthermore, the terminal devices D each have a device-specific secret device key PrivKeyD, which is not communicated to the outside world and is stored in the terminal device D and is inaccessible to subscribers connected to the terminal device D.

The terminal devices are communicatively connected to at least one access device A1, A2, which in turn are coupled to a terminal device management unit S. The terminal device management unit S and the registered access devices A1, A2, which are authorized for communication, have a secret network key NetKey, which is used to encrypt the data exchanged in the communication unit 1.

The terminal device management unit S has a certificate ZertS, a secret device key PrivKeyS and a public device key PubKeyS.

To start the connection of a terminal device D to the communication unit 1, a check is first carried out in step REG to determine whether the terminal device D is already registered and has the public key PubKeyS of the terminal device management unit S and the system address. If registration has not yet taken place, a multicast or broadcast query with a general system address (e.g. @0x000000) is sent. The receipt of this query in the access devices A1, A2 leads to an event signal to the terminal device management unit S. The terminal device management unit S transmits in singlecast a piece of system information SysInfo comprising the public key PubKeyS of the terminal device management unit S to the access device A1, which has the best connection quality (score) to the terminal device D. This system information SysInfo is transmitted to the terminal device D in a single data packet, or as shown split into several data packets, in singlecast, multicast, or broadcast.

With the transmission status, the access device A1 signals to the terminal management unit S that the system information SysInfo has been completely transmitted. In the event of data loss of one or more data packets, these can be retransmitted.

The terminal device then sends a query with the received system address @SysAdr. The query includes information about the terminal device and a request to be registered with the terminal device management unit S (AssoRequest). This results in an event that is transmitted to the terminal device management unit S along with the device information.

The terminal device management unit S then sends a certificate request via the access device A1 to the terminal device D to be registered. This device then transmits the device-specific data of its certificate ZertD, which includes at least the public device key PubKeyD and the signature SignaturD of the terminal device D. This device-specific data is transmitted in data packets (REP) until all device-specific data of the terminal device D has arrived at the terminal device management unit S.

The terminal device management unit S then checks the certificate ZertD of the terminal device D in order to authenticate the terminal device D and to register it as a terminal device D authorized for integration into the communication unit 1.

From this system state, the terminal device D is known to the communication unit 1 and further communication is encrypted if a common secret key has already been defined.

Otherwise, a query is sent in multicast or broadcast from terminal D to access devices A1, A2 with the system address @SysAdr and the request to be trained (AssoRequest). This results in an event forwarded to the terminal management unit S with the command to add the terminal to the access device A1 with the best reception. This command is confirmed by access device A1 with an ACK. An AssoCMD command with the encrypted network key CrypNetKey is then transmitted from the terminal management unit S via access device A1 to terminal D. This can again be done in one or more data packets.

Optionally, the access devices A2 with poorer transmission quality can be disconnected by a command from the terminal management unit S (event = remove device), which is then confirmed (ACK) by the disconnected access device A2 to the terminal management unit S.

Complete receipt of the encrypted network key CrypNetKey is confirmed by the terminal device D via the access device A1 to the terminal device management unit S (AssoCMD). Furthermore, the terminal device D sends a response AssoRESP to the registration via the access device A1 to the terminal device management unit S as an event. This results in an activation AssoCONF of the completed registration, including the generation of a shared key, which is used for the encrypted transmission of the network key NetKey.

The generation of the common secret key K is achieved by exchanging the public keys PubKeyD of the terminal device D and PubKeyS of the terminal device management unit S as well as the secret device keys PrivKeyD and PrivKeyS present in the terminal device D and the terminal device management unit S, as well as parameters that are either known to all participants of the communication device 1 or are part of the static data of the certificates ZertD of the terminal devices D and, if applicable, also of the certificate ZertS of the terminal device management unit S.

This allows the ZertD certificate of the terminal device D to be registered to be transmitted to the terminal device management unit S with a reduced data volume by transmitting only the device-specific data of the ZertD certificate. The entire ZertD certificate is reassembled from the device-specific data and the static data, which are known to the terminal device management unit S for all approved terminal devices D and which are the same for all approved terminal devices D in a group, according to a known scheme and verified using the received SigD signature. The SigD signature is only valid for the correctly assembled ZertD certificate, whereby the validity of the SigD signature for the ZertD certificate can be verified using standard procedures.

Likewise, together with the public device key PubKeyS transmitted to the terminal device D, the other device-specific data of the certificate ZertS of the terminal device management unit S can also be transmitted to the terminal device D. This also allows the terminal device D to optionally check the validity of the public key PubKeyS of the terminal device management unit S.

The shared secret key K, which is agreed between the terminal device management unit S and the terminal device D for the encrypted transmission of the network key NetKey, can be calculated from the respective secret device keys PrivKeyD and PrivKeyS and the mutually exchanged public device keys PubKeyD and PubKeyS and known parameters, for example using an asymmetric key exchange method.

The two communication partners, terminal device D and terminal management unit S, wish to communicate encrypted over an insecure medium, such as a cable or wireless connection, using a symmetric encryption method with the help of a shared secret network key, NetKey. However, for the secure exchange of the network key, NetKey, a shared secret key K is first required. The Diffie-Hellman method enables the calculation of a secret key K in the terminal management unit S and the terminal device D without third parties being able to learn this secret key K.

To do this, parameters such as a large prime number p and a natural number g that is smaller than the prime number p are first defined publicly.

The terminal device management unit S and the terminal device D each generate a random number to be kept secret, i.e., the private device key PrivKeyD, PrivKeyS, which can alternatively be defined and implemented secretly during installation. These secret device keys PrivKeyD, PrivKeyS are not transmitted and thus remain unknown to third parties.

The terminal device management unit S calculates the public device key PubKeyS using its secret device key PrivKeyS and sends it to the terminal device D. This can be done, for example, using the formula PubKeyS = g ^PrivKeyS mod p.

The end device D calculates the public device key PubKeyD using its secret device key PrivKeyD and sends it to the end device management unit S. This can be done, for example, using the formula PubKeyD = g ^PrivKeyD mod p.

The terminal device management unit S receives the public device key PubKeyD of the terminal device D and calculates a number K ₁ using its private device key PrivKeyS and the public device key PubKeyD of the terminal device D. This can be done, for example, using the formula K ₁ = PubKeyD ^PrivKeyS mod p.

The terminal device D receives the public device key PubKeyS of the terminal device management unit S and calculates with its private device key PrivKeyD and the public device key Pub KeyS of the terminal management unit S is a number K ₂ . This can be done, for example, with the formula K ₂ = PubKeyS ^PrivKeyD mod p.

These numbers K1 and K2 are equal due to a commutative relationship in the calculation rule and correspond to the common secret key K.

Instead of the simple parameters p and g, more complex parameters can also be agreed upon, such as elliptic curves. This is achieved using the Elliptic Curve Diffie-Hellmann (ECDH) algorithm, based on the same basic principle outlined above of exchanging only the public device keys PubKeyD, PubKeyS, and the parameters for the agreed elliptic curves.

Thus, an asymmetric key exchange procedure with public device keys PubKeyD and PubKeyS is initially used to negotiate a symmetric key K, which is used for the encrypted transmission of the network key NetKey, which is known only to the registered communication participants of communication unit 1. Subsequently, further communication can only be carried out in encrypted form using the symmetric network key NetKey. For this purpose, the AES-CCM procedure can be used, for example, which extends the Advanced Encryption Standard AES with an operating mode for block ciphers that guarantees both confidentiality and integrity.

The authentication of the end devices to be registered, or the end devices D and the end device management unit S to be linked, is carried out using signed certificates, which are not transmitted to the communication partner in their entirety, but only with their device-specific (dynamic) data. The recipient of the device-specific data can then combine the certificate with the static data known to them and verify the validity of the combined certificate using the received signature.

QUOTES CONTAINED IN THE DESCRIPTION

This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• WO 2021/141685 A1 [0004]
• US 10,992,656 B2 [0005]
• EP 3 451 218 B1 [0006]
• EP 3 451 222 A1 [0007]

Claims (16)

Method for encrypted communication between electronic terminals (D) and an access device (A), wherein the terminals (D) have a communication unit (1) for data communication and are configured to communicate with the access device (A), wherein the terminal (D) and the access device (A) are configured to encrypt and decrypt encrypted transmitted data using a network key (NetKey), and wherein the terminal (D) and the access device (A) agree on a common secret key (K) for the encrypted communication, characterized by - transmitting device-specific data of a unique certificate (ZertD) for the terminal (D) to the access device (A), wherein the device-specific data uniquely characterize the terminal (D); - Determining the unique certificate (ZertD) for the terminal device (D) based on the transmitted device-specific data and based on static data known to the terminal device (D) and a terminal device management unit (S) using a certificate generation routine by the terminal device management unit (S) coupled to the access device (A); - Checking the validity of the determined certificate (ZertD) for the terminal device (D) by the terminal device management unit (S) and authenticating the terminal device (D) as a terminal device (D) authorized for communication with the access device (A), provided that the certificate (ZertD) has been recognized as valid; - Calculating a common secret key (K) for the authorized terminal device (D) and the terminal device management unit (S) using data from the determined certificate (ZertD) recognized as valid by the terminal device management unit (S); - Encrypting the network key (NetKey) with the calculated shared secret key (K) by the terminal device management unit (S); and - Transmitting the encrypted network key (NetKey) from the access device (A) to the terminal device (D), wherein the terminal device (D) calculates the shared secret key (K) using a device-specific secret device key (PrivKeyD) known to it and data (PubKeyS) received from the terminal device management unit (S) and decrypts the received encrypted network key (NetKey) with the calculated shared secret key (K). Procedure according to Claim 1 , characterized in that unique device information and unique device identification are transmitted as device-specific data of the certificate (ZertD) of the terminal device (D). Procedure according to Claim 2 , characterized in that the unique device information is a public device key (PubKeyD) and/or a device signature (SigD). Procedure according to Claim 2 or 3 , characterized in that the unique device identification is a serial number of the terminal device (D). Method according to one of the preceding claims, characterized in that static data for generating the unique certificate (ZertD) are a manufacturer identifier, a version identifier, a country identifier, a place of manufacture identifier and/or validity periods. Method according to one of the preceding claims, characterized by generating the common secret key (K) for encrypted communication by means of asymmetric encryption, in particular with pairs of private and public device keys (PrivKeyD, PubKeyS; PrivKeyS, PubKeyD). Procedure according to Claim 6 , characterized by generating the shared secret key (K) using elliptic curves with the Elliptic Curve Diffie-Hellman Key Agreement Protocol (ECDH). Procedure according to Claim 6 or 7 , characterized by generating the common secret key (K) by the terminal device management unit (S) with the private secret key (PrivKeyS) of the terminal device management unit (S) and the public key (PubKeyD) of the registered terminal device (D) and calculating the common secret key (K) by the registered terminal device (D) with the private secret key (PrivKeyD) of the terminal device (D) and the public key (PubKeyS) of the terminal device management unit (S). Method according to one of the preceding claims, characterized by encrypting the network key (NetKey) with a symmetric block encryption algorithm (AES) by encrypting blocks of the network key (NetKey) with the device key. Communication device with an access device (A) and a plurality of terminals (D) which are designed for encrypted communication with the access device (A), wherein a terminal management unit (S) is coupled to the access device (A), which is designed for the registration of terminals (D) and for the encrypted transmission of a secret network key (NetKey) to the registered terminals (D), characterized in that - the terminals (D) are designed for the transmission of device-specific data of a unique certificate (ZertD) for the terminal (D) to the terminal management unit (S), wherein the device-specific data uniquely characterize the terminal (D), - that the terminal management unit (S) a) for determining the unique certificate (ZertD) for the terminal (D) to be registered on the basis of the transmitted device-specific data and on the basis of data known to the terminal (D) and the terminal management unit (S) static data with a certificate generation routine, b) to check the validity of the calculated certificate (ZertD) for the terminal device (D) and to register the terminal device (D) as a terminal device (D) authorized for communication with the access device (A), provided that the certificate (ZertD) has been recognized as valid, c) to calculate a common secret key (K) for the authorized terminal device (D) and the terminal device management unit (S) with data of the specific certificate (ZertD) recognized as valid by the terminal device management unit (S), d) to encrypt the network key (NetKey) with the calculated common secret key (K) and e) to control a transmission of the encrypted network key (NetKey) via the access device (A) to the terminal device (D), and - that the terminal devices (D) are configured to calculate the common secret key (K) with a device-specific secret device key (PrivKeyD) known to the terminal device (D) and with terminal device management unit (S) received data (PubKeyS) and for decrypting the respectively received encrypted network key (NetKey) with the calculated common secret key (K). Communication device according to Claim 10 , characterized in that the communication device has at least one access device (A) which has the secret network key (NetKey) and is set up for encrypted communication with the terminal devices (D) and with the terminal device management unit (S) and for forwarding data between the terminal device management unit (S) and the terminal devices (D). Communication device according to Claim 10 , characterized in that the terminal management unit (S) is implemented in an access device (A), wherein the access device (A) has the secret network key (NetKey) and is set up for encrypted communication with the terminals (D). Communication device according to one of the Claims 10 until 12 , characterized in that the terminals (D) and the access device (A) each have transceivers (4, 5a, 5b) and are set up for wired communication or for wireless radio communication. Communication device according to one of the Claims 10 until 13 , characterized in that the access device (A) is a terminal (D) registered with the terminal management unit (S). Terminal management unit (S) for a communication device according to one of the Claims 10 until 14 , wherein the terminal device management unit (S) is set up for the authentication of terminal devices (D) and encrypted transmission of a secret network key (NetKey) to the registered terminal devices (D), characterized in that the terminal device management unit (S) a) for determining the unique certificate (ZertD) for the terminal device to be registered (D) on the basis of the transmitted device-specific data and on the basis of static data known to the terminal device (D) and the access device (A) using a certificate generation routine, b) for checking the validity of the calculated certificate (ZertD) for the terminal device (D) and for registering the terminal device (D) as a terminal device (D) approved for communication with the access device (A), provided that the certificate (ZertD) has been recognized as valid, c) to calculate a common secret key (K) for the authorized terminal device (D) and the terminal device management unit (S) with data of the specific certificate (ZertD) recognized as valid by the terminal device management unit (S), d) to encrypt the network key (NetKey) with the calculated common secret key (K) and e) to control a transmission of the encrypted network key (NetKey) via the access device (A) to the terminal device (D). Terminal (D) for a communication device according to one of the Claims 10 until 14 , wherein the terminal (D) is configured to transmit device-specific data of a unique certificate (ZertD) for the terminal (D) to the terminal management unit (S), wherein the device-specific data uniquely characterize the terminal (D), and to calculate the common secret key (K) with a device-specific secret device key (PrivKeyD) known to the terminal (D) and with data (PubKeyS) received from the terminal management unit (S), and to decrypt the respectively received encrypted network key (NetKey) with the calculated common secret key (K).

Images