Method for checking the equivalence of encryption secrets

Abstract

The present invention relates to a method for checking the equality of cryptographic secrets, at least one of which is stored in a read-protected state in a secure system. The method according to the invention is characterized in that at least one secure system comprises an interface (2, 4) for cryptographic hash values, via which a hash value of a secret given a salt or a hash value of the salt is output for comparison with a corresponding hash value of another secret given the salt or a hash value of the salt, for checking.

Description

Technical Field

[0001] The present invention relates to a method for checking the equivalence of encrypted secrets, at least one of the secrets being stored in a read-protected state in a secure system.

Background Art

[0002] Modern vehicles are today part of a large-scale vehicle ecosystem of information technology. At this time, the so-called vehicle backend, abbreviated as the backend, is at the center of this vehicle ecosystem. This is usually a server operated by an automobile manufacturer, to which the vehicle is connected and through which it is connected to, for example, the Internet or a network between vehicles. At this time, the communication connection between the backend and the vehicle is protected using well-known standard methods of information security. Many of them are TLS, but sometimes IPSec is also used. In this case, all of these standard methods are based on so-called asymmetric encryption, such as ECC or RAS. At this time, the vehicle ecosystem can also include other components, such as individual control devices or smartphones attached to the vehicle, and applications operating on the smartphone are provided, for example, by an automobile manufacturer and communicate with both the vehicle or the control device of the vehicle and the backend. Communication inside the vehicle is performed, for example, via WLAN or Bluetooth, and communication outside the vehicle is usually performed via a general mobile radio network. Further components of the vehicle ecosystem may be, for example, manufacturer-specific external devices such as so-called OBD dongles, which usually communicate only with the vehicle via a hardware interface. These communication relationships are also usually protected by an asymmetric encryption method, such as TLS or IPSec.

[0003] However, there are also cases where it is more efficient or necessary for reasons of security requirements to provide shared secrets to two or more participants in the vehicle ecosystem in a more secure manner, and the shared secrets can continue to be used to protect communications between these participants by means of an encryption method based on the shared secrets, generally a so-called symmetric encryption. Examples of shared secrets and the encryption methods based thereon may be, for example, a 128-bit shared key by AES for encryption, a 256-bit shared key by HMAC for authentication or integrity, or an individual password for password authentication.

[0004] Also, such types of shared secrets are protected as much as possible against unauthorized access, here especially against unauthorized read access, in the systems using these secrets. This can be achieved by providing only an interface for local calls of the encryption operations using these secrets and no interface for reading the secrets themselves. Furthermore, such secrets are maximally protected against reverse engineering, for example by software-based obfuscation techniques or by using Hardware Security Modules (HSMs) as a system for storing the secrets more securely. After being stored, those secrets do not leave this system.

[0005] The advantage of this procedure is that when using a hardware security module, no one, especially an attacker with full access to the system, can access the secret value and obtain this secret in plain text with reasonable effort. All encryption operations using the key are similarly executed within a secure system, for example, within an HSM. However, the drawback of this procedure is that it is difficult to troubleshoot when an encryption operation fails. Such errors may occur when, for example, performing message authentication code (MAC), password decryption, or check on the receiving side. On the receiving side, if, for example, decryption, integrity check, or authentication fails, naturally, there is a suspicion that the secret used on the sending side, that is, the key used to encrypt and / or authenticate the message, and the key used to decrypt the message and / or check the integrity of the message on the receiving side may be different from each other. Especially when it is very important for security reasons to update the secret regularly, that is, to exchange or newly agree on the secret, such a suspicion naturally arises. If the operation with the recently updated secret has never been successful until this point, the suspicion of the error is immediately directed at the secret. However, when at least one corresponding secret of the participating communication partners is held in a secure system such as the above-mentioned HSM, it is not easy to check whether all the corresponding communication partners are using the same secret. This secret value securely stored within the system cannot be easily read and is designed to be so. Therefore, even in a debugging situation, even if one has full access to the system or device, it is usually impossible to read.

[0006] As a possible approach for such equivalence checking, the use of a cryptographic hash function can be considered. In this way, it will be possible to read not the secret itself, but the hash of this secret. In this manner, the hash values of different instances of the same secret can be read from different secure systems, or at least from different systems where at least one is secure, and subsequently the hash values can be compared to check for equivalence. This has the advantage that it is impossible to read the key or the secret itself, and usually it is also impossible to infer the secret from the cryptographic hash value.

[0007] Patent Document 1 enables the creation of a security indicator that utilizes the formation of hash values and the comparison of hash values for protecting secrets during provisioning, and activates a "security flag" when an external specified value is equivalent to the hash value generated from a key.

Patent Document 1

[0008] However, this procedure becomes particularly problematic when the corresponding secret, such as a password, does not have sufficient entropy, for example, if it is too short or has a certain well-known pattern. In this case, common attack techniques well-known in the IT field, such as brute-force attacks, dictionary attacks, or attacks using rainbow tables that can infer the secret from the hash value, are possible.

Summary of the Invention

Problems to be Solved by the Invention

[0009] Therefore, an object of the present invention is to provide an appropriate method for checking the equivalence of encrypted secrets, where the secret itself remains secret, and the comparison of the secrets is possible even with high security against external attacks.

Means for Solving the Problems

[0010] Based on the present invention, this problem is solved by the method having the features of claim 1, and in particular here, the features described in the characterizing part of claim 1. Advantageous embodiments and developments become apparent from the dependent claims which depend thereon.

[0011] The method according to the present invention for checking the equivalence of the encryption secret uses, at this time, at least one secret stored in a read-protected state in a secure system which can be formed as a hardware security module (HSM) according to a highly preferred development of the method according to the present invention. At least one secure system, i.e., for example, an HSM, has an interface for hash values. The cryptographic hash value of the secret stored in the secure system can be read via this interface. Furthermore, this secure system can secretly give a so-called salt or the hash value of such a salt to the secret before creating the hash value. Next, the cryptographic hash value is created from the secret and the added salt or its hash value, and accordingly, an attack on this secret, for example, by means of a rainbow table, etc. also becomes difficult. Because creating a rainbow table is extremely complicated and costly, and thus not rewarded even if labor is expended.

[0012] In a general definition, a salt that is not a secret value and is not defined externally, preferably not fixed for all queries, is particularly efficient. Therefore, the salt should be created in a secure system as much as possible, and at that time, it must be freely selected. In this way, in a secure system where secrets are stored in a protected state for reading, it can always be guaranteed that only a secure salt is used. At this time, it is important that the salt always has a sufficient length and is sufficiently distinguishable. However, the problem is that something is added to the secret stored by the salt, and this is not necessarily the same in different systems, and usually, when each system defines its own salt, they will not be the same. Therefore, this enhanced security will cast doubt on the equality check.

[0013] Therefore, according to a highly preferred development form of the present invention, the salt is provided to be configured as a salt composed of a plurality of parts, one salt part is determined by at least one secure system, and the other salt part is transmitted to this secure system.

[0014] Thereby, on the one hand, it becomes possible to generate a very secure salt for well-known attacks by a secure system. According to a highly preferred development form of the method according to the present invention, this salt is always newly generated as a self-determined salt part, and in particular, it can always be generated by a secure random number generator. The other salt part is transmitted to the secure system.

[0015] In another highly preferred embodiment according to the present invention, furthermore, the self-determined salt part by the secure system can be provided to be made public before the formation of the secret hash value. Thereby, preferably for each situation, the salt part generated by the secure system is well-known as an instance to be compared, for example, and this instance can transmit the externally determined part to the secure system.

[0016] In another highly preferred embodiment, the order in which the salt part and the secret are concatenated is determined within the secure system or provided to be externally defined to this secure system. This order of the secret and the salt part has a decisive influence on the hash value of the combination of the salt and the secret. In this case, the order can be externally defined, for example, and theoretically the same order can always be used. For example, in one system, the order of self-determined salt, externally determined salt, and secret is used, and in another system, a structure is used in which the salt part has the reverse order correspondingly, so that from both systems, the same cryptographic hash value for the combination of the secret and the salt part is generated, enabling comparison with high reliability.

[0017] Here, in a highly preferred embodiment, the salt itself is provided to be formed as a two-part salt having a self-determined salt part and an externally determined salt part. In this case, comparison of two secrets is possible, and this process can be arbitrarily repeated any number of times, whereby, for example, the secrets of a plurality of participating instances can be collated with each other, particularly in the debugging process.

[0018] When checking the equivalence of a plurality of secrets stored in different secure systems, according to a highly preferred development of the method according to the present invention, a query of its self-determined salt part is made in the first system, and then this salt part is transmitted to another system, and this other system transmits its self-determined salt part together with the hash value of its secret and both salt parts. The self-determined salt part of the other system is fed back to the first system as an externally determined salt part, and the first system can proceed to calculate the hash value from its secret and both salt parts, and then compare the hash values transmitted from both systems. Thereby, it is possible to reliably and efficiently check the equivalence of the secrets, particularly in the debugging process which has been mentioned many times already.

[0019] In particular, according to a very advantageous development of the solution method according to the invention, here, instead of the salt, the hash value of the concatenated salt parts can be used. Next, the secret is given this hash value of the already concatenated and hashed salt parts and is hashed again. The comparison is made based on this second hash value. This can enhance the security against chosen-plaintext attacks.

[0020] According to one development of the invention, in the concatenation order of the first system, the salt parts are swapped with respect to the concatenation order of another system, so that at least the first system can be provided to receive the order as an external specification. That is, the order is always the order "seen" from each secure system. If a fixed order of concatenation is determined, this can be carried out as such without taking other measures. Preferably, according to a very advantageous development of this idea, another system determines the order itself, discloses it each time, and can transmit, for example, its self-determined salt part, and the hash value of both the secret and both salt parts together. Next, this order self-determined by another system is used as the transmission order to the externally specified first system. At this time, when the order of the salt parts is swapped with respect to each other from the perspective of each secure system, if the secrets of both secure systems do the same thing, in the highest possible security considered, the cryptographic hash values of the secret and both salt parts are guaranteed to match in all cases. At this time, self-determined salt parts of sufficient length and / or entropy are always preferably generated and used, and the externally specified salt part for one system is, so to speak, the self-generated salt part of the other system, so fixed values and completely externally derived specified values for the salt are not permitted, thereby further enhancing the security of the method.

[0021] Such use of the self-determined salt portion makes it possible to prevent the so-called category of chosen-plaintext attacks. This is because the possibility of such chosen-plaintext attacks is made difficult by using the self-determined salt portion. Other attack possibilities, such as attacks using rainbow tables, are also significantly restricted. This is because such attacks require individual rainbow tables for all salts, and it is impossible to implement them for economic reasons alone, especially when the salt or its portion used has sufficient length and entropy.

[0022] Instead of the conventional cryptographic hash function for detecting the hash value of the secret and the salt portion, here, according to a highly preferred development form of the method according to the present invention, a composite cryptographic one-way function based on a hash function, such as HMAC or the so-called key derivation function (KDF), can be used. Since the hash value is calculated by this function, additional security advantages are brought compared to the calculation of conventional hash values such as SHA-256.

[0023] Here, two secrets can be compared with each other by the hash values of their respective secrets and salts. If there are more secrets, this can be repeated iteratively. However, it would also be possible to directly compare three or more secrets using this method. As the number of secrets increases, it becomes increasingly important to preferably implement the determined concatenation order and this order in the respective secure systems, because the possibility of concatenating the secrets and the salt or salt portion increases.

[0024] Furthermore, in another highly preferred embodiment of the method according to the present invention, secure configuration options are provided in a secure system such as an HSM for the individual sub-functions of the cryptographic hash interface, which makes it possible to configure at least the following settings so that they cannot be tampered with. These settings include the following questions, - Use a self-determined salt part? - Before creating the hash value, disclose the surrounding self-determined salt part? - Use an externally determined salt part? - How much to use the externally determined salt part? - Is the concatenation order determined in a secure system or can it be specified externally? - In the concatenation order, is the secret always in a specified location, especially coming first? - Is the salt resulting from the concatenated salt parts hashed in advance? - Is the secret hashed in advance? At least one, preferably all, of them should be included.

[0025] Due to these various decisions, the system can be adapted accordingly, for example, mutually or to a specified inspection strategy, for use in the method according to the present invention. Depending on the configuration of the corresponding interface, even a system configured identically to itself can be further differently formed by this configuration, so the security is further enhanced. At this time, especially the last question can be omitted if hashing the secret in advance is determined in advance as a normal procedure.

[0026] A further advantageous embodiment of the method according to the present invention is also apparent from the examples shown in more detail below with the aid of figures.

Brief Description of the Drawings

[0027]

Figure 1

Figure 2

Figure 3

Modes for Carrying Out the Invention

[0028] Figure 1 shows the vehicle ecosystem 1 or a part thereof. The part shown includes, by way of example, two vehicles V1 and V2, each of which is equipped with two control devices ECU1 and ECU2. In addition, a vehicle backend B, often abbreviated as the backend, is shown. The backend B can communicate with the vehicles V1, V2 or their control devices ECU1, ECU2. For this purpose, the backend B is equipped with a security system in the form of a hardware security module HSM. In this embodiment, two secrets SEC3 and SEC4 are stored in this security system. In both vehicles V1, V2, corresponding secrets SEC5 and SEC6 are stored, for example, in hardware security modules HSM3 and HSM4 in the second control device, respectively. In the embodiment illustrated here of the part of the vehicle ecosystem 1, both vehicles V1, V2 must be able to communicate with each other. For this purpose, by way of example only, both first control devices ECU1 perform their role using the hardware security module HSM1 of the first vehicle 1 and the HSM2 of the second vehicle 2. The corresponding secrets are called SEC1 and SEC2.

[0029] If there is a problem in any communication and it is due to the cryptographic process, there must be a possibility that there is also a problem with each of the secrets SEC1, SEC2. Therefore, the following embodiments will explain how to easily, surely, and more efficiently check the equivalence of both cryptographs SEC1 and SEC2 in the hardware security modules HSM1 and HSM2 of each control device ECU1 of both vehicles V1, V2. At this time, it is not necessary to read the secrets SEC1, SEC2 themselves, and this reading is usually impossible even when full access is available during the debug process in the security system.

[0030] Therefore, instead of reading the secrets SEC1 and SEC2 themselves, the hash values HASH1 and HASH2 of these secrets SEC1 and SEC2 are read. For generating the hash values HASH1 and HASH2, a general function for generating hash values, such as SHA-256, can be used. However, instead of such a conventional cryptographic hash function used in the description of the embodiments below, a composite cryptographic one-way function based on a cryptographic hash function can also be used. For example, HMAC or a key derivation function KDF, etc. In this case, for example, instead of calculating the hash HASH(SEC||SALT) from the secret and the salt, the function HMAC(SEC, SALT) or KDF(SEC, SALT, iteration) will be involved. At this time, the iteration can be understood as a freely selected natural number that determines the number of times of applying the key derivation function.

[0031] Next, in the embodiment described with reference to FIG. 2, it is necessary to check the secrets SEC1 and SEC2 of two different hardware security modules HSM1 and HSM2. For this purpose, an inspection unit labeled 3 in FIG. 2 is used. Both hardware security modules HSM1 and HSM2 are each provided with one hash value interface 2 that implements all the above-described characteristics or can be configured according to those characteristics. That is, through this interface 2, both a pre-query of the self-determined salt part and the possibility of determining the concatenation order of the salt parts become possible. The inspection unit 3 is a system designed to check the equivalence of the secrets SEC1 and SEC2 stored in both hardware security modules HSM1 and HSM2.

[0032] Here, the detailed process is shown below. Also in FIG. 2, the process is shown by the corresponding communication arrows between the inspection unit 3 and the interface 2, or between the hardware security modules HSM1 and HSM2 on which they are mounted.

[0033] 1. To check the equivalence of secrets SEC1 and SEC2, the inspection unit 3 that wants to obtain the hash values of secrets SEC1 and SEC2 transmits the identifiers sec of the respective secrets SEC1 and SEC2 to the hardware security module HSM1 and the hardware security module HSM2 simultaneously. Furthermore, a request to disclose the self - part of the salt to be used respectively is also transmitted.

[0034] 2. Both hardware security modules HSM1 and HSM2 generate new random self - parts of the salt, each having a sufficient length of, for example, 256 bits respectively. Next, the self - part SALT1 of the hardware security module HSM1 and the self - part SALT2 of the hardware security module HSM2 are transmitted to the inspection unit 3 as shown in Figure 2.

[0035] 3. The inspection unit 3 determines in which order R the salt parts need to be concatenated. At this time, F is the externally determined salt part, and E is the self - determined salt part.

[0036] 4. The inspection unit 3 transmits the externally determined salt parts SALT2 and SALT1 to the respective hardware security modules HSM1 and HSM2. That is, the hardware security module HSM1 receives the self - determined salt part SALT2 by the hardware security module HSM2 as the externally determined salt part. The order of concatenation for this is R(F, E) here. The other hardware security module HSM2, correspondingly, receives the salt self - part SALT1 of the first hardware security module HSM1 as the salt external part F, and accordingly, the order of the salt parts is reversed. Because for the second hardware security module HSM2, SALT2 becomes the salt self - part E.

[0037] 5. The first hardware security module HSM1 forms a hash value with a concatenation corresponding to a specified order R, i.e., HASH1 := HASH(SEC1 || SALT2 || SALT1). The second hardware security module HSM2 calculates its hash value HASH2 := HASH(SEC2 || SALT2 || SALT1). Next, both of these hash values HASH1 and HASH2 are transmitted to the inspection unit 3.

[0038] 6. The inspection unit 3 checks the equivalence of both received hash values HASH1 and HASH2. Both secrets SEC1 and SEC2 are exactly the same if the received hash values HASH1 and HASH2 are the same. Here, if there is a difference, the secrets SEC1 and SEC2 are clearly not the same, and the error being searched for can be found in the areas of these secrets SEC1 and SEC2.

[0039] The following second embodiment is configured substantially in the same way. Each of the two secrets SEC1 and SEC2 with the identifier sec is stored in one of the two hardware security modules HSM1 and HSM2, respectively. At this time, the first hardware security module HSM1 is equipped with an interface 2 that implements all of the above-described characteristics, i.e., this interface 2 enables, in particular, both a pre-query of a self-determined sort part and the possibility of determining the concatenation order of both sort parts. In contrast, the other hardware security module HSM2 can receive an externally determined sort part via a simpler interface 4 and process it immediately only when the concatenation order R, such as a sort self-part and a sort external part R(E, F) with the secret prefixed from the perspective of the second hardware security module HSM2, is determined in advance. FIG. 3 shows the same process as the schematic diagram of FIG. 2 in detail.

[0040] 1. The inspection unit 3 that wants to obtain the hash value HASH1 of the secret SEC1 transmits the identifier sec of the secret SEC1 to the first hardware security module HSM1 together with a request to disclose its own part SALT1 of the salt to be used.

[0041] 2. The first hardware security module HSM1 generates a new random salt self-part SALT1 of sufficient length and transmits it to the inspection unit 3.

[0042] 3. The inspection unit 3 that wants to obtain the hash value HASH1 of the secret SEC2 transmits the identifier sec of the secret SEC2 to the second hardware security module HSM2 together with the salt self-part SALT1 received from the first hardware security module HSM1, and further transmits a request for calculating the hash value and a transmission request including the hash value and the salt self-part SALT2 used for the calculation.

[0043] 4. The second hardware security module HSM2 generates a new random salt self-part SALT2 of sufficient length, calculates the requested hash value as HASH2 := HASH(SEC2 || SALT2 || SALT1), and transmits the hash value HASH2 to the inspection unit 3 together with the salt self-part SALT2 used for the calculation.

[0044] 5. The inspection unit 3 transmits the external part SALT2 of the salt to be used and the order R of the concatenation R(F, E) to be used to the first hardware security module HSM1. This time, from the perspective of the first hardware security module HSM1, that is, by swapping the external part of the salt and the self-part of the salt.

[0045] 6. The first hardware security module HSM1 calculates its hash value HASH1 := HASH(SEC1 || SALT2 || SALT1) and transmits the hash value HASH1 to the inspection unit 3.

[0046] 7. The inspection unit 3 checks the equivalence of both received hash values HASH1 and HASH2. The secrets SEC1 and SEC2 are exactly equivalent if the received hash values HASH1 and HASH2 are the same as above.

Claims

1. A method for checking the equivalence of encrypted secrets, wherein at least one of said secrets is stored in a read-protected state in a secure system, in said method, at least one of said secure systems comprises an interface (2, 4) for cryptographic hash values, and for checking, the hash value of said secret given a salt or a hash value of a salt is output via said interface (2, 4) for comparison with the corresponding hash value of another secret given a salt or a hash value of a salt, said salt is configured as a salt consisting of a plurality of parts, one salt part is self-determined by at least one of said secure systems, and the other salt part is transmitted to said secure system, When checking the equivalence of a plurality of secrets stored in different secure systems, the salt part self-determined in the first secure system is transmitted as an externally determined salt part to another secure system, and the salt part self-determined in said another secure system is transmitted as an externally determined salt part to said first secure system, and said another secure system transmits the hash value of its secret and the self-determined and externally determined salt parts to an inspection unit, and said first secure system transmits the hash value of its secret and the self-determined and externally determined salt parts to said inspection unit, and then, the respective hash values of said secret and both of said salt parts transmitted from both of said secure systems for checking are compared, characterized by said method.

2. The method according to claim 1, characterized in that the salt part self-determined in said secure system is made public before the formation of the hash value of said secret given the salt part.

3. The method according to claim 1 or 2, characterized in that the order of concatenating said salt part and said secret in said secure system is determined within said secure system itself or specified externally.

4. The order (R) of concatenation of the self-determined salt part and the externally-determined salt part of the first secure system is reversed with respect to the order (R) of concatenation of the self-determined salt part and the externally-determined salt part of the other secure system, and at least the first secure system receives the order (R) of its concatenation as an external specification and transmits it. The method according to any one of claims 1 to 3.

5. The method according to claim 4, wherein the other secure system determines the order (R) of its concatenation and publishes it.

6. The method according to any one of claims 1 to 5, wherein the self-determined salt part is always newly generated, particularly by a secure random number generator.

7. The method according to any one of claims 1 to 6, wherein at least one self-determined salt part is always used.

8. The method according to any one of claims 1 to 7, wherein a composite cryptographic one-way function based on a hash function is used as the cryptographic hash function.

9. The method according to any one of claims 1 to 8, wherein a hardware security module is used as the secure system.

10. At least one of the secure systems is provided with a communication interface, and via the communication interface, the cryptographic hash interface (2, 4) can be configured to be tamper-proof with respect to at least one of the following sub-functions: - Whether to use a self-determined salt part? - Whether to publish the self-determined salt part of the periphery before creating the hash value? - Whether to use an externally-determined salt part? - How much to use the externally-determined salt part? - Whether the secret is hashed in advance? The method according to any one of claims 1 to 9.

Images