COMMUNICATION DEVICE AND METHOD FOR CRYPTOGRAPHICALLY SECURING COMMUNICATION

Abstract

A communication device for a vehicle has a communication unit set up to establish a communication link between the vehicle and an external vehicle server and to exchange data in a cryptographically secured manner between the vehicle and the external vehicle server. The communication unit is further set up to be operated in a first or second mode. The modes differ in the type of cryptographic securing of the data. The communication unit has a secure hardware memory in which a binary value corresponding to the respective mode is stored.

Claims

1-15. (canceled)

16. A communication device for a vehicle, the communication device comprising: a communication unit comprising a secure hardware memory and configured to establish a communication link between the vehicle and an external vehicle server; exchange data in a cryptographically secured manner between the vehicle and the external vehicle server; and be operated in a first or second mode, wherein the first and second modes differ in a type of cryptographic securing of the data, wherein a binary value corresponding to one of the first and second modes in which the communication unit is currently being operated is stored in the secure hardware memory, and wherein the binary value in the secured hardware memory is only changeable once.

17. The communication device of claim 16, wherein the first mode comprises asymmetric cryptographic protection of the data, and the second mode comprises symmetric cryptographic protection or protection by post-quantum cryptography.

18. The communication device of claim 16, wherein the secured hardware memory is a write-once memory.

19. The communication device of claim 16, wherein the communication unit comprises at least one secure interface configured for communication with the external vehicle server, wherein the at least one secure interface is secured via symmetric encryption or a process of post-quantum cryptography.

20. The communication device of claim 16, wherein the binary value is changeable from the external vehicle server by a cryptographically secured command, wherein protection of the command is configured via a symmetric cryptographic process.

21. The communication device of claim 20, wherein the protection and encryption of the cryptographically secured command employs at least one secret stored in the communication unit.

22. The communication device of claim 21, wherein different secrets are stored in the communication unit for different functions of the cryptographic protection.

23. The communication device of claim 22, wherein the communication unit is configured to assign the different secrets to different functions only as part of a software update during or after a switch from the first mode to the second mode.

24. A method for securing communication between a vehicle and an external vehicle server, the method comprising: establishing, by a communication unit of the vehicle, a communication link between the vehicle and the external vehicle server; operating the communication unit in a first one of two modes during communications over the communication link; and switching the communication unit from operating in the first one of the two modes to operating in a second one of the two modes based on a binary value stored in a secured memory of the communication unit, wherein the binary value is only changeable once.

25. The method of claim 24, wherein the first mode comprises asymmetric cryptographic protection and the second mode comprises symmetric cryptographic protection or protection by post-quantum cryptography.

26. The method of claim 24, wherein changing of the binary value and the switching from the first one of the two modes to the second one of the two modes is triggered via a symmetrically secured message of the external vehicle server.

27. The method of claim 24, wherein when switching from the first one of the two modes to the second one of the two modes, functions and protocols used in the first one of the two modes are deactivated or replaced by functions and protocols for the second one of the two modes.

28. The method of claim 24, further comprising: switching off services and applications that cannot be sufficiently secured in the second one of the two modes.

29. The method of claim 24, further comprising: generating, when switching from the first one of the two modes to the second one of the two modes, post-quantum cryptographic keys from secrets stored in the communication unit during manufacture of the communication unit and a master key securely stored in the external vehicle server.

30. The method of claim 24, wherein new functions, protocols, or mechanisms for cryptographic protection are imported via a software update at least when switching to the second one of the two modes, wherein transmission of the software update is protected via symmetric cryptographic protection or protected by post-quantum cryptography.

Description

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0030] Here are shown:

[0031] FIG. 1 a schematic scenario explaining the invention;

[0032] FIG. 2 a communication device in a possible configuration according to the invention; and

[0033] FIG. 3 a fleet of vehicles with such communication devices and an external vehicle server.

DETAILED DESCRIPTION

[0034] In the illustration of FIG. 1, a vehicle 1 can be seen communicating via a secure communication link 2 with an external vehicle server 3, which is shown here as a cloud. This external vehicle server can, in particular, be a back-end of the vehicle manufacturer. For this purpose, the vehicle has a communication device 4 which, for example, communicates with control units 5 of the vehicle 1, such as a telematics control unit and/or a head unit, or is also integrated into their design. In any case, the configuration comprises a communication unit 6, via which the secure communication between the vehicle 1 and the external vehicle server 3 takes place. Each control unit can individually use its own communication device, or several control units together can use a central communication device 4.

[0035] The communication device 4 or its communication unit 6 allows operation in two different operating modes, each of which works with different cryptographic protection. The first mode, which will still be set when the vehicle 1 is supplied at the current time, allows communication via conventional standardized processes, which are typically asymmetric, in particular via TLS or possibly also IPSec using RSA or ECC. This first mode can also be referred to as pre-quantum mode because the protection it offers can be classified as secure at the current time. However, if quantum computers become generally accessible and, in particular, market-ready, then such protection mechanisms, which are based on RSA or ECC, for example, can be cracked very easily and do not offer sufficient protection for security-related data transmitted between the server 2 and the vehicle 1. The communication device 4 provides a second mode for this purpose, which can also be referred to as the post-quantum mode. This is activated in particular when quantum computers are correspondingly available and thus the situation commonly referred to as the post-quantum threat has occurred.

[0036] In this situation of the existing post-quantum threat, i.e., when quantum computers are more or less freely available to break conventional asymmetric cryptographic processes, alternative cryptographic processes are required that can withstand this threat. It is then possible to switch from the previously used conventional asymmetric cryptography, for example, to a previously known conventional symmetric cryptography. According to current knowledge, this switch to AES, SHA-512, or HMAC, for example, is secure insofar as the security of the key is only halved by the quantum computer. However, this can easily be compensated for by longer keys, for example keys with 256 or, in particular, 512 bits, which then still offer a security of 128 or 256 bits respectively. Alternatively, it is also possible to switch from conventional asymmetric cryptography in the first mode to post-quantum cryptography (PQC) when switching to the second mode. Such post-quantum cryptographic processes are currently under development, but have not yet been standardized and their security cannot yet be definitively assessed. However, such processes can also be used because the connection of the communication device 4 to the external vehicle server 3 means that it can also be provided with corresponding software updates in order to correspondingly implement cryptographic processes arising in the future that work in accordance with the PQC process via software updates.

[0037] In order to be able to now implement the switch as simply and efficiently as possible, in particular without being able to implement the replacement of control units 5 or the communication device 4, a binary value, which is indicated here by the box 8, is stored in the communication unit 6 in a secure hardware memory 7, as can be seen in the schematic representation of the communication unit 6 in FIG. 2. This binary value 8, which can also be referred to as the post-quantum flag, indicates whether the communication unit 4 is in the first pre-quantum mode, which is the current supplied state of the communication device 4, or whether it has changed its value and the communication unit 6 is in post-quantum mode, i.e., in the mode which is to be activated after the post-quantum threat has occurred. It is preferably the case here that this binary value can only change its value once, from the first mode to the second mode. This can be implemented in terms of hardware, for example, with the aid of a write-once memory (WOM) module, so that the protected hardware memory 7 is intended in particular to be such a WOM module.

[0038] The communication unit 6 has various interfaces, for example an interface 9 to the control units 5 or the communication interface 10 for the secured data transmission 2. This interface 10 or, in particular, a part of this interface 10 functions via post-quantum-resistant processes as a secure interface 10.1, which can be used by the external vehicle server 3 if required, e.g., to switch the binary value 8 from the first to the second mode, i.e., to switch the communication unit 6 to post-quantum mode. This secured interface 10.1 can be protected here with the aid of symmetric cryptographic processes already known today and considered relatively secure against a post-quantum threat. Examples of this could be AES-256, SHA-512, HMAC-256. This or a further post-quantum-resistant secured interface 10.1 can also be used by the external vehicle server 3, if necessary, to correspondingly switch off services or applications in the communication unit 6 or in the control units 5 connected to it or to replace them with more suitable functions, services and applications as part of a remote software update which runs via the correspondingly secured interface 10.1, which functions, services and applications are optimized, if necessary, with respect to the protection mechanisms used in the second operating mode for cryptographic protection.

[0039] Accordingly, in order to achieve a secure exchange of data in the event of the switch, it can be correspondingly provided that individual secrets A, B, C ... N were securely imported and stored in the devices when the communication unit 6 was made. This can be implemented, for example, by using so-called hardware security modules 11, i.e., a specially secured memory or memory area. It should now be possible to use these secrets A, B, C ... N exclusively in the second mode, i.e., in post-quantum mode. Separate keys of sufficient length are to be imported for each cryptomechanism to be used in post-quantum mode. The individual secrets A, B, C ... N are therefore assigned to different functions or are assigned to such as part of a software update during or after the switch to the second mode. For example, a 512-bit secret can be provided to protect the secured interface 10.1 for mode switching. A further 512-bit secret can be provided to protect a further secured remote interface or a further interface provided in the interface module in parallel with the interface 10.1 just mentioned for shutting down applications that are not sufficiently secured in post-quantum mode, i.e., applications that can no longer be secured or protected with sufficient security in the second mode, for example due to the available resources. Further secrets can also be provided, for example in the form of 512-bit secrets, for encryption, authentication, key exchange, and for securing a software update, in particular via a corresponding remote interface.

[0040] Thus, after switching the communication unit 6 to post-quantum mode by changing the binary value 8, the communication unit 6 is now operated in post-quantum mode in such a way that the data of the communication link 2 is secured via a new or different type of cryptography.

[0041] A first alternative of the configuration of the communication unit 6 and the associated method could provide for the individual data to be stored twice. This means a prophylactic implementation and provision of a complete set of post-quantum-resistant functions and protocols in addition to the pre-quantum functions and protocols. The post-quantum-resistant functions and protocols can then be used immediately in the event of a switch from the first to the second mode. The advantage of this alternative is that, in the event of switching to post-quantum mode, secure communication between the vehicle 1 and the external vehicle server 3 is immediately possible. However, since there is no generally standardized PQC procedure available at the time of application, the only option currently available for this alternative is the use of symmetric cryptography, which, according to current knowledge, guarantees sufficient protection even in post-quantum mode after the post-quantum threat has occurred, particularly if the selected key length is correspondingly large.

[0042] The second alternative is that the cryptographic processes are only updated by a software update, for example in the course of switching the communication unit 6 from the first to the second mode. The exact type and use of the key material stored in the communication unit 6 or the secrets A, B, C ... N on which it is based is therefore only defined by a software update, in particular a remote software update by the external vehicle server 6 and the software to be imported in the course of this. This alternative has the advantage that memory space can be saved, since only one type of communication protection needs to be present in each of the two modes. Furthermore, it is the case that today it is not yet necessary to determine which process is to be used at all using the pre-stored secrets A, B, C ... N in the event of switching to post-quantum mode. In this way, knowledge gained between the delivery of the communication unit 6 or the vehicle 1 equipped with it and the occurrence of the post-quantum threat can be incorporated into the decision as to how the encryption is to be implemented in the second mode. In particular, it may be possible in this way to switch from the conventional asymmetric process to a correspondingly asymmetric PQC process if both the computing and storage capacities in the communication unit 6 are sufficient for this and the previously stored secrets A, B, C ... N are of a sufficient length to derive PQC keys from them, if shared secrets are required at all to derive or negotiate asymmetric PQC keys, which is not yet known.

[0043] In addition to keeping the secrets A, B, C ... N in the hardware security module 11 of the communication unit 6, these individual secrets must also be stored securely in the external vehicle server and must be able to be assigned to the corresponding devices or vehicles, for example via a unique device ID for the respective communication unit 6 or communication device 4, or the vehicle 1 equipped with it. Alternatively, the individual secrets could also be derived, among other things, from the device ID with the aid of post-quantum secure processes, such as symmetric processes and a master key. Suitable key derivation functions (KDF) can be used for this purpose. The illustration in FIG. 3 shows this situation schematically. In the area of the external vehicle server 3 there is a database 12 in which a master key of sufficient length is securely stored. By communicating with individual vehicles 1.1, 1.2, ... 1.n or the communication devices 4 located therein, it is now possible to use a device ID of the respective communication device 4 for the respective vehicle 1.1, 1.2, ... 1.n in order to be able to carry out the corresponding key derivations via the master key.

[0044] As already mentioned, after switching to the second mode, all services and applications as well as functions that cannot or cannot sufficiently be protected by the new cryptographic protection, for example due to a lack of resources, are switched off accordingly by the external vehicle server via the secured interface 10.1, or are switched off or deactivated in the control units 5 connected to the communication unit 6 via the interface 9.

[0045] Although the invention has been illustrated and described in detail by way of preferred embodiments, the invention is not limited by the examples disclosed, and other variations can be derived from these by the person skilled in the art without leaving the scope of the invention. It is therefore clear that there is a plurality of possible variations. It is also clear that embodiments stated by way of example are only really examples that are not to be seen as limiting the scope, application possibilities or configuration of the invention in any way. In fact, the preceding description and the description of the figures enable the person skilled in the art to implement the exemplary embodiments in concrete manner, wherein, with the knowledge of the disclosed inventive concept, the person skilled in the art is able to undertake various changes, for example, with regard to the functioning or arrangement of individual elements stated in an exemplary embodiment without leaving the scope of the invention, which is defined by the claims and their legal equivalents, such as further explanations in the description.