METHOD FOR IMPLEMENTING AND USE OF CRYPTOGRAMIC MATERIAL IN AT LEAST ONE SYSTEM COMPONENT OF AN INFORMATION TECHNOLOGY SYSTEM

Description

[0001] The invention relates to a method for implementing and using cryptographic material in at least one system component of an information technology system of the type defined in more detail in the preamble of claim 1.

[0002] The procedure for implementing and using cryptographic material essentially deals with the fact that, in different lifecycle phases of system components of an information technology system equipped with cryptographic material, cryptographic material corresponding to the current security level of the respective system component or a submodule of the system component must be used. This relates in particular, but not exclusively, to the field of so-called CarlT security for vehicles.

[0003] Modern vehicles, and other systems as well, are characterized by increasing connectivity. These vehicles are not only connected to publicly accessible systems like the internet, but also to dedicated systems operated by the vehicle manufacturer or OEM, such as proprietary applications and a manufacturer-owned server, often referred to as a backend server. These systems are developed, marketed, and operated by the manufacturer exclusively for its own vehicle fleet. All of this together is also known as the vehicle ecosystem.

[0004] In practice, the diverse communication relationships between the individual system components within such a vehicle ecosystem create a multitude of new interfaces and applications, all of which must be secured by suitable cryptographic methods, such as mechanisms, protocols, etc. These cryptographic methods, which are generally known from the state of the art, require a variety of cryptographic material, such as asymmetric key pairs, symmetric keys, certificates, random numbers, hash values, etc. All this cryptographic material is coordinated and is often introduced into all participating system components in the vehicle ecosystem before commissioning, and for the exchange of cryptographic material even during operation. These components must then be used by the system.The provisioning of cryptographic material takes place, for example, during the manufacturing process, but it can also occur during the operation of the system components. These system components include, in particular, control units installed in the vehicles, but also other components such as in-vehicle applications, OEM applications available on a smartphone, external devices, and the like.

[0005] To reliably prevent interference with protected communication, it is essential to distinguish between cryptographic material used during the development phase and cryptographic material used during the production phase, i.e., the actual deployment of the fully developed product. The cryptographic material for the development phase is subsequently referred to as test cryptographic material. During the development phase, only test cryptographic material may be used, as long as it is classified. Production cryptographic material, and in particular classified production cryptographic material, must be protected from unauthorized access throughout the entire lifecycle of the system component.Ideally, this protection should be ensured by adhering to a specific, secure process and using special security mechanisms in the respective development departments and production facilities. However, this is usually only inadequately guaranteed during the development phase, as various components of the information technology system are typically not yet implemented or have not yet been fully developed.

[0006] For example, the secure generation of the required cryptographic material may not yet be fully implemented or tested. The secure transfer of the cryptographic material from the generation server, the so-called cryptomaterial server, to the system manufacturer, such as a supplier, may not yet be guaranteed. The secure integration of the cryptomaterial into the system component may not yet be implemented, or not yet finalized. The secure storage of the cryptographic material in this system component may not yet be implemented, for example, because the target system does not yet have a hardware security module (HSM) installed, even though this is planned for later. The secure use of the cryptographic material within the system may also be affected.Not yet implemented, for example, because development interfaces required for testing and debugging exist, which have read and write access to the entire system and thus, in particular, also allow access to the installed cryptographic material during the development phase. These interfaces are, however, necessarily present during development and are usually openly accessible to all persons and / or companies involved in the development process.

[0007] This means that it cannot be guaranteed that the cryptographic material used during the development phase will not be manipulated or read. However, this test cryptographic material is identical in structure and form to the production cryptographic material used later. It is therefore also suitable for use in later operation, i.e., in the production phase of the respective system component. For this reason, it is particularly important that the relatively poorly secured and therefore highly likely to be corrupted test cryptographic material is not misused in the production system. The situation is even more serious if production cryptographic material gets onto a system component during the development phase. This material, which has a very high protection requirement, can then also be manipulated or read, in whole or in part. It is then no longer confidential and cannot be used.If the error goes unnoticed or is deliberately covered up, the system component, which later moves into the production phase, loses its protection.

[0008] In practice, security regulations and guidelines are implemented by the individuals working with the system components during the various phases. Therefore, errors, oversights, and even deliberate manipulation cannot be ruled out. Consequently, there is always a risk that test cryptographic material remains in a system component that has already transitioned to the production phase, or that production cryptographic material is used on a system component that is still under development. Any cryptographic material used intentionally or unintentionally during the development phase is highly likely to be corrupted due to the numerous open interfaces and other issues. These risks ultimately lead to an increased security vulnerability, representing a significant drawback of the current approach.

[0009] A method for the secure use of cryptographic material is already known from DE 10 2020 003 072 B3. In this method, several system components of a networked system are equipped with cryptographic material. The cryptographic material has a marker that identifies it as development or production material. The individual system components have a binary state flag that indicates whether the corresponding system component is in the development or production phase of its life cycle. A comparison is then made between the marker of the cryptographic material and the binary state flag of the respective system component.If the marker and the flag match—for example, if the cryptographic material is marked as development material and the system component is in the development phase—then the corresponding cryptographic material is used by the system component. If, however, the marker and the binary state flag do not match, security measures are initiated. The verification of the match between the cryptographic material's marker and the binary state flag is performed either before each use of the cryptographic material or once for all cryptographic material in the system component. This verification can occur, for example, when the system component is started up or when the cryptographic material is deployed.As a security measure, a warning message can be issued, the provision of cryptographic material can be aborted or prevented, and / or cryptographic material already introduced into a system component can be deleted as needed.

[0010] A disadvantage of this approach, however, is that the only way to determine whether cryptographic material may be used on a system component is to distinguish between two lifecycle phases of the respective system component and two different properties (test or production) for the cryptographic material. In real-world applications, a distinction between only two groups will not suffice, as the conditions for the secure use of cryptographic material vary too much for different cryptographic materials and system components. For example, if a secret is generated and stored directly within a hardware security module and never leaves it, the cryptographic material may be used securely even during the development phase.However, this requires that the hardware security module, during the development phase, does not have or use any special diagnostic interfaces that would allow the secret to be read. A secret included in software, on the other hand, is part of the program code and can therefore be read or reconstructed relatively easily via various interfaces. Secure use of such a secret in a later production phase of the system component is then not possible.

[0011] Furthermore, US patent 2021 / 075607 A1 discloses a key management device and a processor chip for encrypting and decrypting data. Cryptographic keys are stored in a key database. A lookup table allows specific keys to be found within the key database using a key number. Metadata can be assigned to each key within the lookup table. This metadata can be used to describe the conditions under which a particular key can be used.

[0012] The present invention is based on the objective of providing an improved method for the implementation and use of cryptographic material in at least one system component of an information technology system, which allows a particularly flexible and secure implementation and use of cryptographic materials that differ in many ways in various system components, and ensures that, in the case of a system component that is itself or in which at least one sub-module is operated in an insecure mode, cryptographic material suitable for insecure operation is used by the system component or at least the sub-module, and in the case of a system component that is itself or in which at least one sub-module is operated in a secure mode, cryptographic material suitable for secure operation is used by the system component or at least the sub-module.

[0013] According to the invention, this problem is solved by a method for implementing and using cryptographic material in at least one system component of an information technology system with the features of claim 1. Advantageous embodiments and further developments are described in the dependent claims.

[0014] In a method for implementing and using cryptographic material in at least one system component of an information technology system of the type mentioned above, the cryptographic material includes additional data which, according to the invention, are formed by at least one condition, at least one role, and / or at least one target component identity. Furthermore, the cryptographic material comprises at least one target component-specific role.

[0015] The method according to the invention allows for a particularly flexible and secure implementation and use of cryptographic material in a wide variety of system components and / or their submodules. Various system components, such as a control unit, a cloud server, an application running on a mobile device, a vehicle, or an external device, require the use of various cryptographic materials at different times, such as symmetric or asymmetric keys, certificates, random numbers, hash values, or the like. Thus, a specific target system component that is to use cryptographic material may require the use of different cryptographic materials in different states. The state of the respective system component is described using at least one variable.The corresponding system component can assume a multitude of different states, thus exhibiting more than two states, such as being in a development phase or a production phase of a life cycle. Individual submodules of a system component can also be in different life cycle phases or states. For example, a network interface might be in a first, unsafe state, while a storage element of the system component is in a second, safe state. Such an information technology system can be networked or isolated.

[0016] Cryptographic material is typically generated by a dedicated system, such as a cryptographic server, and transmitted as part of a special data packet to a target system, i.e., a target system component. According to the invention, the cryptographic material is supplemented with additional data. A corresponding condition defines the circumstances under which the use of the cryptographic material by the system component is permitted or prohibited. These conditions can be of a wide variety of nature. For example, the condition can require that the respective system component is in a specific phase of a product lifecycle, or that the system component has a hardware security module and that this module is in a secure state so that it can securely receive and store cryptographic material.The cryptographic material can also include multiple conditions. This allows the implementation and use of cryptographic material in various system components to be controlled across an even greater number of different use cases.

[0017] Cryptographic material intended for a system component fulfills a specific role within that component. If the same system component uses multiple cryptographic materials of the same type, for example, several public 4096-bit RSA keys, the system component itself cannot distinguish which role the new cryptographic material should play—for example, how and where it should be installed within the system component and how it should be used. This information concerning the role of the cryptographic material can be attached to the cryptographic material in the form of a role. The role differs from a condition in that the role does not impose any condition on the current state of the system component.

[0018] To efficiently distinguish which system component is authorized to use cryptographic material, the cryptographic material can be supplemented with a target component identity. This target component identity uniquely identifies the system components that are permitted to use the corresponding cryptographic material. If the cryptographic material is applied to a system component that is not included in the target component identity, its use on that component is blocked. This allows for a particularly simple and quick way to define which system components are authorized to use which cryptographic material and which are not.

[0019] The target component identity can be directed to an entire class of systems, system components and / or their submodules, such as the class "Head Unit", "Engine Control Unit", "Flash Memory" or the like, as well as to exactly one specific system component, such as the hardware security module with the serial number "GHNS-1934952".

[0020] With the help of at least one condition, at least one role and / or at least one target component identity, it is thus possible to control very efficiently and flexibly which cryptographic material may be used in which application scenarios, i.e., in which states of which system component and / or its submodules, and which may not.

[0021] Cryptographic material is typically structured as a cryptographic material (data) package and exchanged between or introduced into systems or system components. The cryptographic material package comprises at least the actual cryptographic material, such as an asymmetric key pair, and the respective condition, role, and / or target component identity in the form of additional data appended to the cryptographic material. This appended data can, for example, be concatenated with the cryptographic material. The cryptographic material package can also include other data. For the sake of simplicity, this text will only refer to the cryptographic material.

[0022] If the same cryptographic material is sent to different system components, it can fulfill different roles on those components. Target-component-specific roles can be embedded in the cryptographic material, instructing it how and on which system component it should be used. This allows for more comprehensive and flexible control over how cryptographic material is implemented and used on different system components.

[0023] According to an advantageous embodiment of the method according to the invention, all conditions are defined by a creator external to the system component and evaluated by at least one evaluator running in an environment of the system component. The creator and the evaluator jointly determine which variables are to be used by the creator when defining conditions. For this purpose, the creator and the evaluator can use a fixed set of possible variables and select suitable variables depending on the condition. The creator selects suitable variables for each condition. The number and type of conditions are also determined by the creator. The name used for the respective variables and the permissible range of values ​​are then jointly defined by the creator and the evaluator, with the evaluator determining which names and value ranges the creator is permitted to use.However, the creator decides which names and value ranges he ultimately uses.

[0024] The creator is, for example, the aforementioned cryptographic material server. The evaluator can be hardware and software or a human. The evaluator can be integrated into the system component or run externally, but in the same environment as the system component. This allows the evaluator to capture the variables underlying the system component and describing its corresponding state. An external evaluator allows the verification of the condition(s) imposed on the system component by the cryptographic material, even before the system component has booted. For example, verified cryptographic material can be stored in the system component's memory without first starting the corresponding system component.

[0025] The evaluator is particularly capable of verifying at any given time whether a given condition for the respective system component is met or not. By agreeing on a common set of relevant variables, the creator and the evaluator can ensure that the variables required for evaluating a specific condition can actually be captured by the evaluator. This increases the reliability in the application of the method according to the invention.

[0026] A further advantageous embodiment of the procedure provides that at least one variable has one of the following value ranges: BOOLEAN; INTEGER; or STRING.

[0027] All variables can have the same value range, i.e., be of type BOOLEAN, INTEGER, or STRING, or individual variables can have different value ranges. Using different value ranges or types allows for the use of a wide variety of variables to define and subsequently check conditions.

[0028] Accordingly, a variable of type BOOLEAN takes the value TRUE or FALSE. Using the value ranges INTEGER and STRING, states can be described in even greater detail or with more complexity. For example, a specific state can be described using numbers and / or strings.

[0029] A value range can, for example, extend from 1 to 10. The variables used to define a state can, for example, be in the form of a vector. The vector can, for instance, include a first variable of type BOOLEAN and a second variable of type INTEGER. This variable vector is time-dependent. At a specific time, for example, the first variable might have the value TRUE and the second variable the value 24. This allows a condition for each system component to be evaluated by the evaluator, whose environment at a specific time t is in a state uniquely described by the current values ​​of the variables. This means it can be checked whether the variables satisfy the defined conditions at time t or not. The corresponding variable vector can also include at least one empty element.This is the case, for example, when the evaluator cannot capture a specific variable. Instead of an empty element, a placeholder can also be used, such as the number "0", "9999", or a string like "NAN".

[0030] Similarly, variables can be of a structured type; for example, variables can be: ARRAY or a RECORD where structured types can be formed from both unstructured and structured types.

[0031] According to a further advantageous embodiment of the method, at least one condition is defined as target-component specific and / or operation-specific. This allows the cryptographic material to be used for various operations, such as installing software, encrypting or decrypting specific data, creating or verifying a signature, or the like, and / or to be used by different system components. In order for the creator to mark a condition as operation-specific, i.e., valid only for a particular operation, a set of operations known within the system component must be communicated to the creator, analogous to the set of usable state variables, so that the creator can use these operations when defining conditions. This set of operations can be general, i.e., valid for all target components, or target-component specific.

[0032] In order for a certain condition to be considered fulfilled on different system components and / or when performing different operations, it may be the case that for at least two different system components and / or operations a certain variable must take on a different value, i.e. once TRUE and once FALSE, or once 0 and once 256.

[0033] A further advantageous embodiment of the method according to the invention provides that at least one different variable is used for a target-component-specific and / or operation-specific condition on a different target system component and / or during a different operation. Thus, not only can a specific variable assume different values ​​to fulfill a condition on different system components and / or to perform different operations, but different variables may also be required for this purpose. In particular, the quantity and / or type as well as the size of a permissible range of values ​​of the variables relevant for a condition can differ between different system components and / or operations.For example, to satisfy a condition, variables 1 and 2 on a first system component must take the values ​​0 and TRUE, respectively, and variables 1, 2, and 3 on a second system component must take the values ​​0, TRUE, and FALSE. On a third system component, however, to satisfy the same condition, variables 1, 2, 3, 4, 5, and 6 must take the values ​​TRUE, [0..100], [-100..100], 0, "engaged," and FALSE. Generally, at least two Boolean OR expressions can also be combined, which will be discussed later.

[0034] According to a further advantageous embodiment of the method, an evaluator checks a condition using an evaluation function, wherein at least two differing evaluators use a differing evaluation function, in particular an operation-specific evaluation function. Generally, it is possible for all evaluators to use the same evaluation function. However, providing different evaluation functions increases the flexibility in implementing the inventive method for controlling the conditions under which cryptographic material is used by system components.

[0035] A generic evaluation function can generally be used, allowing all cryptographic material, or rather the conditions encompassed by the cryptographic material, to be evaluated by providing only one function. However, the evaluation function can also be implemented specifically for different cryptographic materials, for example, depending on the role of the cryptographic material. In particular, a further distinction is made between different evaluation functions for different operations.

[0036] A further advantageous embodiment of the method according to the invention further provides that at least one condition is defined in a machine-processable definition language, wherein an executable language that can be interpreted by an interpreter or one of the following formal logics is used: Propositional logic; propositional logic with relations; or propositional logic with relations and functions.

[0037] Defining the condition in a machine-processable definition language enables the use of existing languages ​​to carry out the method according to the invention. Using an evaluable definition language, conditions can be formulated about the current variable describing a state of the system component, for example, as BOOLEAN-valued expressions defined and processable by the definition language. If the cryptographic material has multiple conditions, a variable set relevant to the corresponding condition can also contain different variables. All variables in a corresponding variable set can be of the same type, i.e., BOOLEAN, INTEGER, or STRING, or at least two variables in a variable set relevant to a particular condition can differ in their type.It is also possible to use the same or different machine-processable definition languages ​​in combination for different conditions encompassed by the cryptographic material.

[0038] In standard propositional logic, all variables relevant to a given condition have the value domain BOOLEAN. Individual variables can therefore only take the values ​​TRUE or FALSE. Logical formulas are formed using familiar propositional connectives, such as "∧", "∨", "¬", and the like, as well as parentheses "(" ")". Examples of propositional formulas are: Variable1; Variable2 ∧ TRUE; (Variable1 ∧ (Variable2 v Variable3)).

[0039] In propositional logic with relations, variables relevant to a given condition can have different ranges of values. There exists a finite set of relations, where each relation is assigned a fixed arity, and each relation and its position are assigned a fixed range of values. A relational term is then obtained by applying a relation to a number of constants and / or variables corresponding to the arity, with the appropriate ranges of values. When evaluating a relational term for a fixed, predefined set of values ​​for the variables appearing in that term, the result is always a Boolean value, i.e., TRUE or FALSE. An example of a binary relation that requires INTEGER as the range of values ​​in both positions is the less-than-or-equal-to relation "≤". Relational terms based on this relation would be, for example: Variable1 ≤ Variable2; 7 ≤ variable3.

[0040] Logical formulas are constructed using BOOLEAN constants, BOOLEAN variables, relational terms, and familiar propositional connectives ∧, v, ¬, etc., as well as parentheses "(" and ")" to define the order of evaluation. An example of a propositional formula with relations, using the binary relations "≤" and "=", is: Variable1 ∧ Variable2 ≤ Variable3 ∨ Variable3 = Variable4 . (Variable1 ∧ ((Variable2 ≤ Variable3) v (Variable3 = Variable4))).

[0041] In propositional logic with relations and functions, a finite set of functions is used, where each function is assigned a fixed arity, and each function and each place value is assigned a fixed range of values. Furthermore, the range of the result is defined for each function. A function is then applied to a number of constants, variables, and / or functions corresponding to its arity, with the appropriate ranges of values, and returns a value from the specified result range. An example of a binary function that requires INTEGER as the range in both places and returns an INTEGER value is the addition "+".Logical formulas, like those in propositional logic, are formed using relations, with the difference that relational terms can be formed not only by applying relations to constants and / or variables, but also by applying functions to constants / variables with a corresponding result range. An example of a propositional logic formula with relations and functions is: . In particular, the use of an executable language that can be interpreted by an interpreter offers advantages. Such languages ​​are very "powerful" due to their executability. For example, no prior translation / compilation, or transformation into a formula tree and insertion of variable values, is necessary before executing the corresponding program code. An interpretable executable language could be, for example, a scripting language like Python.

[0042] According to a further advantageous embodiment of the method according to the invention, at least two conditions are formulated in different definition languages; in particular, two target-component-specific conditions are formulated in different definition languages. If a first system component uses a first language and a second system component uses a second language that differs from the first, providing two conditions formulated in different definition languages ​​ensures that both system components can evaluate the condition relevant to them. The variables relevant to the conditions are also formulated in the respective definition languages. It is also possible for two conditions valid for the same system component to be formulated in different definition languages.It can therefore be advantageous to formulate a specific condition using a specific definition language. This is the case, for example, when capturing and / or processing certain variables is only possible with a specific definition language, or when this is dictated by various constraints.

[0043] A further advantageous embodiment of the method according to the invention provides that the cryptographic material comprises at least two conditions, and all conditions must be met for the cryptographic material to be used by the system component. Referring back to the use of formal logic, this means that the conditions used are AND-connected. Thus, all conditions must be met for the cryptographic material to be used by the system component. While fulfilling a single condition is necessary for the system component to use the cryptographic material, it is not necessarily sufficient, since at least one further condition must also be met.

[0044] According to a further advantageous embodiment of the method, if cryptographic material is to be used by a system component whose target-component-specific condition does not include the class of the corresponding system component, if an operation is to be performed by using the cryptographic material which is not covered by an operation-specific condition, or if an evaluator cannot detect a variable required to check a state, the evaluator provides the following answer by default for the respective condition: TRUE; FALSE; or a response appended to the cryptographic material as a standard response.

[0045] This ensures an even more reliable implementation of the method according to the invention. For example, a system component, or a class of system components, from which certain cryptographic materials are to be used, can generally not be included in a target-component-specific condition. To allow the cryptographic material to be applied by the corresponding system component nonetheless, the value TRUE is output by default after checking the target-component-specific condition. If, instead, the application of the cryptographic material is to be prevented in such a case, the value FALSE is output by default. To increase the flexibility of the method according to the invention, the standard response in the form of TRUE or FALSE can also be appended to the cryptographic material.This reduces the risk of cryptographic material being applied to a system component whose default response is set to TRUE, even though this should not be the case. In such instances, the default response is appended to the cryptographic material in the form of FALSE.

[0046] The formulations given above apply accordingly to an operation-specific condition, as well as to the case where an evaluator cannot capture a variable required to check a specific condition.

[0047] A further advantageous embodiment of the method according to the invention provides that all additional data included in the cryptographic material are cryptographically protected against compromise, in particular by using at least one digital signature and / or a symmetric integrity protection mechanism. A keyed-hash message authentication code (HMAC) can be used as a symmetric integrity protection mechanism. Protecting the cryptographic material against compromise further increases the security when carrying out the method according to the invention. This protects the additional data appended to the cryptographic material package against unauthorized manipulation. For example, the cryptographic material, including the associated additional data, can be digitally signed by the creator using their asymmetric private key.In particular, secure procedures and systems are used for signing. The public key, or a certificate containing the public key, is then distributed to all relevant evaluators. The corresponding public key or certificate is implemented in the respective systems in a tamper-proof manner. For example, the public key or certificate is stored in read-only memory (ROM) or in write-once memory (WORM). Accordingly, the cryptographic material package includes such a digital signature. Consequently, the system component only uses the cryptographic material if a verification of the signature attached to the cryptographic material using the implemented public key or certificate yields a positive result.

[0048] According to a further advantageous embodiment of the method according to the invention, at least two different actors are authorized to digitally sign the cryptographic material, with each authorized actor receiving its own sheet certificate belonging to a common certificate hierarchy, along with the corresponding private key. This is particularly advantageous when granting multiple actors authorization to digitally sign is also useful if multiple actors are creating cryptographic material. A system performing the signing then signs the corresponding cryptographic material with the private key belonging to its sheet certificate. The cryptographic material is then not only given the generated signature but also the entire certificate chain. The certificate chain appended to the cryptographic material is then evaluated by a corresponding evaluator or...a system encompassing the evaluator was used to verify the correctness of the signature created by the signing system.

[0049] If the cryptographic material is already a digital certificate, it is signed from the outset. If additional data, i.e., at least one condition, role, and / or target component identity, is then included in the certificate, this data is also signed by the certificate issuer. In this way, the additional data, or even just parts of it, can be included as one or more certificate extensions in the corresponding certificate and thus co-signed. If all additional data is included in the certificate, the dedicated creation of a digital signature for the cryptographic material can be omitted.

[0050] To ensure the best possible protection, the method according to the invention should be used as early as possible in the development of a corresponding system component. Since the condition verification by the evaluator depends on variables, these variables must be protected against manipulation as effectively as possible, as corrupted variables can simulate the existence of a state that does not actually exist. Accordingly, constants used to evaluate a condition are preferably stored in a write-once memory such as a WORM (Write Once Read Many) memory. The values ​​of the variables on which the conditions depend are preferably systematically adapted to the current system state throughout the entire lifecycle of the information technology system or the individual system components.

[0051] Preferably, a vehicle ecosystem is used as the information technology system. In general, the method according to the invention can be used for various system components in different types of networked or non-networked information technology systems. Its use is particularly efficient when the information technology system is a vehicle ecosystem, since the corresponding requirements regarding complex development with many partners often make compliance with safety guidelines very difficult in practice. By implementing the method according to the invention and thus enabling self-verification by the respective system component, the risk of a potential security vulnerability can be drastically minimized.

[0052] Further advantageous embodiments of the inventive method for implementing and using cryptographic material in at least one system component of an information technology system also result from the exemplary embodiments which are described in more detail below with reference to the figures.

[0053] This shows: Fig. 1 shows a schematic representation of a first use of cryptographic material on a system component of an information technology system; Fig. 2 shows a schematic representation of a use of alternative cryptographic material on the Figure 1 system component shown; Fig. 3 a schematic representation of a use of alternative cryptographic material on another system component; and Fig. 4 a flowchart of an exemplary processing of cryptographic material on a system component during the execution of an operation.

[0054] Figure 1Figure 1 shows a first embodiment of the use of cryptographic material KM of at least one system component SK of an information technology system IT-S. A state of the system component SK is described by means of at least one variable VAR. In the example in Figure 1 The set of all variables VAR is referred to as VAR, and the individual state variable used here is called "productive". The state variable productiveThis indicates whether the system component SK is in a production phase of its lifecycle, i.e., whether it is a production system or not. The cryptographic material KM is a self-signed test root certificate, TestRootCert, belonging to a test root key pair (TestRootPub, TestRootPriv). This certificate is introduced into the target system as a trust anchor to establish test connections with communication partners. The trustworthiness of certificates signed with TestRootPriv received from partners can then be verified using TestRootCert.

[0055] The certificate TestRootCert was created under insecure conditions; for example, the private key TestRootPriv is not securely stored. Therefore, TestRootCert must not be used in production systems. Accordingly, a condition BED encompassed by the cryptographic material KM is considered invalid. productive =FALSE is defined. The condition BED states that the certificate TestRootCert may only be used by the target system, i.e., the system component SK, if it is not in the production phase.

[0056] Figure 2 Figure 1 shows a similar embodiment where the cryptographic material KM now includes a securely generated certificate, ProdRootCert, which can be used securely in production systems. Accordingly, the ProdRootCert certificate may always be used by the target system, i.e., the system component SK, for example, also in the development and production phases. ProdRootCert may also be used in the development phase because it contains no secret elements. Accordingly, the condition BED is also not dependent on the state variable. productiveThe condition BED is not dependent on any variable VAR, but is always considered true (TRUE). Since the condition BED does not depend on any variable VAR, one could also choose an empty set of state variables, i.e., BED TestRootCert ({}):=(TRUE) instead of BED TestRootCert ({productive}):=(TRUE).

[0057] Figure 3Figure 1 shows another embodiment of the implementation and use of cryptographic material KM in a system component SK. The system component SK has two state variables: the two elements HSMProvisioningSecure: BOOLEAN and HSMEncryptedSecure: BOOLEAN of the set of variables VAR. The set of variables VAR corresponds to a vector with two elements. The state variable HSMProvisioningSecure indicates whether a hardware security module (HSM) is already in a state where it can securely receive and store cryptographic material KM. The state variable HSMEncryptedSecure indicates whether the hardware security module (HSM) is already in a state where it can securely use the secret keys stored within it for encryption. The cryptographic material KM is... Figure 3about a 256-bit long, secret symmetric key AESKey, which is to be used for AES encryption in production systems.

[0058] Two operations are to be secured by conditions BED. The first is the provisioning of cryptographic material KM, i.e., the secure insertion and storage of a key in the system component SK. The second is encryption, meaning the secure use of a key for encryption within the system component SK. The secure use of the key in the target system is ensured by two conditions: BED AESKey Provisioning< and BED AESKey Encryption<. The condition BED AESKey Provisioning< stipulates that the key AESKey may only be inserted into the target system if HSMProvisioningSecure = TRUE. The condition BED AESKey Encryption< stipulates that the key AESKey may only be used for encryption in the target system if HSMEncryptionSecure = TRUE.

[0059] Figure 4Figure 1 shows a flowchart of a method according to the invention. It is assumed that a cryptographic material package KM-P has the following form: KM-P = (KM, ZKIDENT KM , BED KM *, ROLE KM *, Sign KM , ZK), where ZKIDENT KM denotes the entirety of the target component identities allowed for the cryptographic material KM, BED KM * denotes the entirety of the conditions BED assigned to the cryptographic material KM, which may be target component-specific and / or operation-specific, and ROLE KM * denotes the entirety of the roles ROLE KM *, which may be target component-specific. At least one of the aforementioned quantities ZKIDENT KM , BED KM *, ROLE KM * may also be missing from the cryptographic material package KM-P. Sign KM is the signature created by the creator of the cryptographic material KM of (KM, ZKIDENT KM , BED KM *, ROLE KM *) and ZK is the certificate chain with which the system component SK can verify the correctness of the signature Sign KM.For the unambiguous addressing of a system component SK, it is further assumed that the system component SK has the identity skid and the target system component type Type(skid). For example, the identity skid and the target system component type Type(skid) can be included in the variables VAR on a system component SK. A system component type can also be understood as a class of system components SK, for example, all system components SK of the class / type "Head-Unit", "Engine Control Unit", or the like. Furthermore, it is assumed that the evaluator wants to check whether the cryptographic material KM contained in the cryptomaterial package KM-P may be installed in the system component SK for an operation Prov in the system component SK. The operation can generally be any operation, such as performing a decryption process. In the example in . Figure 4The operation involves the actual provisioning of the cryptographic material KM.

[0060] First, the signature Sign KM is checked. If the signature check fails, an exception is handled according to the first link LINK1. If the signature check is successful, it is then checked whether the cryptographic material KM, here in the form of the cryptomaterial package KM-P, includes at least one target component identity ZKIDENT KM. If this is the case, it is checked whether the identity skid of the system component SK is included in the target component identity ZKIDENT KM, and if not, an exception is handled according to the first link LINK1. If this is not the case, i.e., the cryptomaterial package KM-P does not include a target component identity ZKIDENT KM, this step is skipped.

[0061] The process then checks whether and, if so, which conditions BED KM * are contained in the cryptographic material KM. If the cryptographic material package KM-P does not contain a condition BED KM *, the process proceeds according to a second link LINK2, which could lead to the installation of the cryptographic material KM.

[0062] Next, it is examined whether at least one condition BED KM * is target component specific.

[0063] If this is not the case, it is checked whether at least one condition BED KM * is operation-specific.

[0064] If this is not the case, the corresponding condition BED KM is evaluated and the process continues according to the first or second link LINK1, LINK2.

[0065] If, however, it is determined that at least one condition BED KM * is operation-specific, a check is then performed to see if the operation involves providing the cryptographic material KM, i.e., provisioning. If this is the case, the operation-specific condition BED KM Prov< is checked. The process then continues analogously to links LINK1 and LINK2.

[0066] If, however, at least one type-specific condition is detected in the cryptomaterial package KM-P, a check is performed to see if at least one of the type-specific conditions is also valid for an entire class of system components SK, i.e., whether Type(skid) is contained in BED KM *. The set of conditions valid for the respective class referenced by Type(skid) is referred to below as BED KM Type(skid)< *. If this is the case, provisioning may occur (see the first link LINK1). If this is not the case, it must be checked which standard procedure should be applied, i.e., whether provisioning may occur or not. For this purpose, a standard response may, for example, be included in the cryptomaterial package KM-P.

[0067] The process then checks whether the type-specific condition BED KM Type(skid)< * is also operation-specific. If not, the condition BED KM Type(skid)< is evaluated, and the process continues according to links LINK1 and LINK2. If, however, the conditions BED KM Type(skid)< * are operation-specific, the process checks whether BED KM Type(skid)< * contains at least one operation-specific condition, here as a representative example for the operation Prov ("Provisioning"), i.e., a condition BED KM Type(skid)< , Prov< , (this step is in Figure 4 (not shown). If this is not the case, exception handling is initiated according to the first link LINK1. If, however, this is the case, i.e., if BED KM Type(skid)< * contains a condition BED KM TyPe(skid), Prov< , then this condition is evaluated and the process continues analogously to links LINK1 and LINK2.

[0068] After evaluating the individual conditions BED KM, BED KM Prov<, BED KM Type(skid)<, or BED KM Type(skid), Prov<, it is checked whether the cryptographic material KM, here in the form of the cryptographic material package KM-P, includes at least one role ROLE KM *. If this is not the case, the cryptographic material KM is provided to the system component SK without a role. If, however, this is the case, it is then checked whether ROLE KM * includes a role for the target component type Type(skid). If this is not the case, exception handling is performed again. If, however, this is the case, the cryptographic material KM is provided taking the role ROLE KM * into account.

Claims

1. Method for the implementation and use of cryptographic material (KM) in at least one system component (SK) of an information technology system (IT-S) for carrying out at least one operation, wherein a state of the system component (SK) described by at least one variable (VAR) is checked at least at a first point in time, the cryptographic material (KM) is supplemented with additional data, the additional data describing possible states of system components (SK), and the cryptographic material (KM) is used by the system component (SK) if the additional data of the cryptographic material (KM) comprise at least the state that the system component (SK) has at the first point in time, characterized in that the additional data are formed by at least one condition (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Pov), at least one role (ROLEKM*) and / or at least one target component identity (ZKIDENTKM), and the cryptographic material (KM) has at least one target component-specific role (ROLEKM*).

2. Method according to claim 1, characterized in that all conditions (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) are defined by a creator, which is external to the system component (SK), and evaluated by at least one evaluator, which is executed in an environment of the system component (SK), wherein the creator and the evaluator jointly determine which variables (VAR) may be used by the creator in the definition.

3. Method according to either of claims 1 or 2, characterized in that at least one variable (VAR) has one of the following value ranges: - BOOLEAN; - INTEGER; or - STRING.

4. Method according to any of claims 1 to 3, characterized in that at least one condition (BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) is defined in a target component-specific and / or operation-specific manner.

5. Method according to claim 4, characterized in that for a target component-specific and / or operation-specific condition (BEDKMPrav, BEDKMType(skid), BEDKMType(skid), Prov), at least one different variable (VAR) is used on a different target component and / or in a different operation.

6. Method according to any of claims 2 to 5, characterized in that an evaluator checks a condition (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) by means of an evaluation function, wherein at least two differing evaluators use a differing evaluation function, in particular an operation-specific evaluation function.

7. Method according to any of claims 1 to 6, characterized in that at least one condition (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) is defined in a machine-processable definition language, wherein an executable language, which can be interpreted by an interpreter, or one of the following formal logics is used: - propositional logic; - propositional logic with relations; or - propositional logic with relations and functions.

8. Method according to claim 7, characterized in that at least two conditions (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) are formulated in a differing definition language, in particular two target component-specific conditions (BEDKMType(skid), BEDKMType(skid), Prov).

9. Method according to either of claims 7 or 8, characterized in that the cryptographic material (KM) comprises at least two conditions (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) and all conditions (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov) must be fulfilled in order for the cryptographic material (KM) to be used by the system component (SK).

10. Method according to any of claims 4 to 9, characterized in that if cryptographic material (KM) is to be used on a system component (SK), the target component-specific condition (BEDKMType(skid), BEDKMType(skid), Prov) of the cryptographic material not comprising the class of the corresponding system component (SK), if an operation is to be carried out by using the cryptographic material (KM), the operation not being subject to an operation-specific condition (BEDKMProv, BEDKMType(skid), Prov), or if an evaluator cannot detect a variable (VAR) required to check a condition, the evaluator provides the following response by default for each condition (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid), Prov). - TRUE; - FALSE; or - a response attached as a standard response to the cryptographic material (KM).

11. Method according to any of claims 1 to 10, characterized in that all additional data contained in the cryptographic material (KM) are cryptographically secured against compromise, in particular using at least one digital signature and / or a symmetric integrity protection mechanism.

12. Method according to claim 11, characterized in that at least two different participants are authorized to digitally sign the cryptographic material (KM), wherein all participants authorized to sign receive the individual private keys assigned to them together with the associated individual leaf certificates and the associated certificate chain.

13. Method according to any of claims 1 to 12, characterized in that a vehicle ecosystem is used as an information technology system (IT-S).