Method for implementing and using cryptographic material in at least one system component of information technology system

Abstract

To provide a method and system for implementing and using cryptographic material (KM) in a system component (SK) of an information technology system.SOLUTION: The method comprises: checking a state of the SK as described by a variable (VAR) at a first time; and supplementing the KM with additional data where possible states of the SK are described. The additional data of the KM is used by the SK when including the state that the SK has at the first time, and comprises conditions (BED, BEDKM*, BEDKMProv, BEDKMType(skid), BEDKMType(skid),Prov), a role (ROLEKM*) and a target component identity (ZKIDENTKM).SELECTED DRAWING: Figure 4

Description

[Technical Field]

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

[0002] The method for implementing and using cryptographic material essentially addresses the problem that at different life cycle stages of system components of an information technology system equipped with cryptographic material, cryptographic material corresponding to the latest security level of the respective system component or of a submodule of a system component must be applied, this particularly but not exclusively concerns so-called CarIT-Security equipment for vehicles.

[0003] Modern vehicles, and other systems in general, are characterized by an increasing degree of networking. This means that vehicles are connected not only to publicly accessible systems such as the Internet, but also to proprietary systems operated by the vehicle manufacturer or OEM, such as proprietary applications and proprietary servers, often called back-end servers. These are developed, marketed, and operated by the manufacturer specifically for its fleet. All of these systems are collectively referred to as the vehicle ecosystem.

[0004] In practice, the diverse communication relationships between the individual system components within such a vehicle ecosystem result in the creation of numerous new interfaces and applications, all of which must be secured together by suitable cryptographic methods, e.g., mechanisms, protocols, etc. Such cryptographic methods, which are known in principle from the prior art, require various cryptographic materials, such as asymmetric key pairs, symmetric keys, certificates, random numbers, hash values, etc. All of this cryptographic material must be adapted to each other and provided to and used by all system components involved in the vehicle ecosystem, often before their use or during ongoing operation to exchange the cryptographic materials. Provisioning of the cryptographic materials, or so-called provisioning, can take place, for example, within the manufacturing process, but can also take place while the system components are in operation. System components in this context include, in particular, control devices integrated into the vehicle, but also other components, such as applications installed in the vehicle, OEM applications available on smartphones, and devices external to the vehicle.

[0005] To ensure that protected communications are not intercepted, it is essential to distinguish between cryptographic material used during the development phase and cryptographic material used in the production phase, i.e., during the actual application of a product after development is complete. Cryptographic material for the development phase is hereinafter also referred to as test cryptographic material. During the development phase, only test cryptographic material is permitted, to the extent that it is confidential. Therefore, production cryptographic material, and here especially confidential production cryptographic material, must be protected against unauthorized access throughout the entire life cycle of a system component. Ideally, such protection should be ensured by the adherence to specific processes maintained in the respective development department or production plant and by the application of specific protection mechanisms. However, this is often only insufficiently ensured during the development phase, since the various components of an information technology system are often not yet realized or implemented.

[0006] For example, the secure generation of the required cryptographic material may not yet be fully specified or tested. The secure transmission of the cryptographic material from a generation server, a so-called cryptographic material server, to the system manufacturer, e.g., to a supplier, may not yet be ensured. The secure attachment of the cryptographic material to system components may not yet be specified or may not yet be finally specified. The secure storage of the cryptographic material in such system components may also not yet be specified. This is because, for example, a Hardware Security Module (HSM) is to be further integrated at a later stage, but has not yet been integrated into the target system. The secure use of the cryptographic material in the system may also not yet be specified. This is because, for example, development interfaces required for testing and debugging exist, which have read and write access to the entire system and, therefore, especially to the installed cryptographic material, which are permitted during the development phase. However, such development interfaces are necessarily available during development and are openly accessible during the development process to all involved personnel and / or companies.

[0007] This means that it is not possible to guarantee that cryptographic material used during the development phase will not be manipulated or read. However, in this case, such test cryptographic material is identical in structure and form to the production cryptographic material used later. This means that such test cryptographic material is also suitable for later application in operation, i.e., during the production phase of the respective system component. It is therefore particularly important that test cryptographic material, which is relatively insecure and therefore highly susceptible to corruption, is not misused in production systems. The situation becomes even more serious if production cryptographic material gets into system components still in the development phase. In that case, this highly protected material can also be manipulated or read in whole or in part. As a result, it is no longer secret and cannot be used. If an error goes unnoticed or is intentionally concealed, system components that later enter the production phase lose their protection.

[0008] In practice, security regulations and guidelines are implemented by personnel working on system components at each stage. Therefore, errors, negligence, and intentional manipulation cannot be ruled out. Therefore, in principle, there is always a risk that test encryption material will be left in a system component that has already been put into production, or that production encryption material will be applied to a system component that is still in development. Any encryption material used in development, whether intentionally or accidentally, is highly likely to be corrupted due to interfaces that are still open. This risk ultimately leads to increased security risks. This is a major drawback of existing approaches.

[0009] A method for securely using cryptographic material is already known from Patent Document 1. In this method, cryptographic material is implemented in multiple system components of a networked system. The cryptographic material has a marking that identifies the cryptographic material as development material or production material. Each system component has a binary additional flag that indicates whether the corresponding system component is in development or production in its life cycle. The binary status flag of each system component is then compared with the marking of the cryptographic material. If the marking and the flag match, i.e., if the cryptographic material is marked as development material and the system component is in development, the corresponding cryptographic material is used by the system component. On the other hand, if the marking and the binary additional flag do not match, a security measure is initiated. A check for a match between the marking of the cryptographic material and the binary additional flag is performed before each use of the cryptographic material or only once for the entire cryptographic material in the system component. The check for a match can be performed, for example, when the system component is started or when the cryptographic material is provided. As a security measure, it may issue a warning message, halt or prevent the provision of cryptographic material, and / or, if necessary, erase cryptographic material already provided to system components.

[0010] However, the drawback of this approach is that only a distinction is made between two life cycle phases of the corresponding system component and between two different characteristics of the cryptographic material (testing or production) to distinguish whether or not it is permissible to apply it in a system component. In practical applications, the distinction between two groups is not sufficient, since the different cryptographic materials and the conditions for their secure use in system components are too diverse. For example, if secrets are generated and stored directly in a hardware security module and never leave it, cryptographic material can possibly be used securely even during the development phase. However, this prerequisite is that the hardware security module in the development phase does not have or use special diagnostic interfaces that would allow the secrets to be read out. In contrast, secrets contained in software are part of the program code and can be read out or reconstructed relatively easily via various interfaces. In that case, it is not possible to securely apply such secrets during the subsequent production phase of the system component. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] German Patent No. 102020003072(B3) Summary of the Invention [Problem to be solved by the invention]

[0012] The object of the present invention is to provide an improved method for implementing and using cryptographic material in at least one system component of an information technology system, which allows for a particularly flexible and secure implementation and use of cryptographic material that differs in many ways in various system components, while ensuring that in the case of a system component operating in an insecure mode, either by itself or at least one of its subordinate modules, cryptographic material suitable for insecure operation is used by the system component or at least one of its subordinate modules, and that in the case of a system component operating in a secure mode, either by itself or at least one of its subordinate modules, cryptographic material suitable for secure operation is used by the system component or at least one of its subordinate modules. [Means for solving the problem]

[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 having the features of claim 1. Advantageous embodiments and developments are evident from the dependent claims.

[0014] In a method of implementing and using cryptographic material in at least one system component of an information technology system of the type mentioned in the introduction, the cryptographic material comprises additional data which, according to the invention, is constituted by at least one condition, at least one role, and / or at least one target component identity.

[0015] The method according to the present invention enables particularly flexible and secure implementation and use of cryptographic material in various system components and / or their submodules. Various system components, such as a control device, a cloud server, an application running on a mobile terminal, a vehicle, or external devices, may require the use of different cryptographic material at different times, such as symmetric or asymmetric keys, certificates, random numbers, hash values, etc. Thus, a specific target system component that should use the cryptographic material may require the use of different cryptographic material in different states. The state of each system component is then described using at least one variable. A corresponding system component may be in many different states, i.e., it may have more than two states, such as a development and a production phase of its life cycle. Individual submodules of a system component may also be in different life cycle stages or states. For example, a network interface may be in a first, insecure state, while a storage element of the system component may be in a second, secure state. The corresponding IT system may be networked or isolated.

[0016] Cryptographic material is typically generated by a dedicated system, such as a cryptographic material server, and transmitted to a target system, i.e., a target system component, as part of a special data package. In this case, the cryptographic material is supplemented with additional data. Corresponding conditions define under what circumstances the use of the cryptographic material by a system component is or is not permitted. Corresponding conditions can be of a very diverse nature. For example, a condition can require that the respective system component be in a specific period of its product lifecycle, or that the system component has a hardware security module that is in a secure state so that the hardware security module can receive and store the cryptographic material in a secure manner. The cryptographic material can also include multiple conditions, thereby enabling the implementation and use of the cryptographic material in different system components to be controlled in an even greater number of different application scenarios.

[0017] Cryptographic material provided to a system component fulfills a specific role. When multiple cryptographic materials of the same type are used by the same system component, for example, when multiple 4096-bit RSA public keys are used, the system component itself cannot determine what role the new cryptographic material should play, i.e., how and where it will be installed or used in the system component. Such information pertaining to the role of the cryptographic material can be attached to the cryptographic material in the form of a role. Roles are distinct from conditions, as they do not impose conditions on the current state of the system component.

[0018] To specifically and efficiently distinguish which system components are allowed to use the encryption material, the encryption material can be supplemented with a target component identity, where the target component identity includes a unique identification of the system components that are allowed to use the corresponding encryption material. If the corresponding encryption material is sent to a system component that is not included in the target component identity, the encryption material is prevented from being used by that system component. This allows for a specific, easy, and fast configuration of which system components are allowed to use which encryption material and which are not allowed to use which encryption material.

[0019] In this case, the target component identity may cover an entire class of systems, system components, and / or their submodules, i.e., classes such as "head unit," "engine control unit," "flash memory," etc., as well as just one particular system component, for example, a hardware safety module with serial number "GHNS-1934952."

[0020] In this way, using at least one condition, at least one role, and / or at least one target component identity, it is possible to very efficiently and flexibly control which cryptographic material is and is not allowed to be used in which application scenario, i.e., in which state, and in which system component and / or its submodules.

[0021] Cryptographic material is typically structured as cryptographic material (data) packages and exchanged between or introduced into systems or system components. A cryptographic material package then includes the actual cryptographic material, i.e., for example, an asymmetric key pair, and the respective conditions, roles, and / or target component identities in the form of additional data attached to the cryptographic material. To this end, the attached data may, for example, be concatenated with the cryptographic material. The cryptographic material package may also include further data. For simplicity, the present text will only use the term cryptographic material.

[0022] A preferred development of the method according to the invention provides for the encryption material to include at least one target component-specific role. If the same encryption material is sent to different system components, it can also play different roles in the different system components. For example, the encryption material can be given a target component-specific role that tells it how it should be used in which system component. This allows for more comprehensive and flexible control over how the encryption material is implemented in different system components and how it is used there.

[0023] In another preferred embodiment of the method according to the invention, all conditions are defined by a generator external to the system component and evaluated by at least one evaluator located in the environment of the system component, and the generator and evaluator jointly determine which variables the generator should use to define the conditions. To this end, the generator and evaluator can use a fixed set of possible variables to select suitable variables condition-dependently. The generator then selects suitable variables for each condition. Similarly, the number and type of conditions are also determined by the generator. The names and permissible value ranges to be used for each variable are jointly defined by the generator and evaluator, and the evaluator decides which names and value ranges of the generator are allowed to use. However, the generator itself decides which names and value ranges are ultimately used.

[0024] The generator is, for example, the cryptographic material server already mentioned. The evaluator may be configured by hardware and software, or may be configured by a human being. The evaluator may be included in the system component, or may be located outside the system component, but in the same environment as the system component. This allows the evaluator to detect variables on which the system component is based and the corresponding state of the system component. An evaluator outside the system component allows checking the conditions imposed on the system component by the cryptographic material when the system component has not yet been booted. For example, the corresponding checked cryptographic material can be saved in a storage device of the system component without the corresponding system component having been started before.

[0025] For this purpose, the evaluation unit can check, in particular, whether the conditions of the respective system components are fulfilled at any given time. By the fact that the creation unit and the evaluation unit agree on a common set of relevant variables, it can be ensured that the variables required for the evaluation of a particular condition can actually be found by the evaluation unit. This increases the reliability of the application of the method according to the invention.

[0026] Furthermore, another preferred embodiment of the method contemplates that at least one variable has one of the following ranges of values: -BOOLEAN; -INTEGER; or -STRING.

[0027] All variables can have the same value range, i.e., be in the form of BOOLEAN, INTEGER, or STRING, or individual variables can have different value ranges, allowing different variables to be used for defining and subsequently checking the condition.

[0028] Accordingly, BOOLEAN variables take on the values ​​TRUE or FALSE. The value ranges INTEGER and STRING can be used to describe more detailed or complex states. For example, a particular state can be described using numbers and / or strings.

[0029] The value range can range, for example, from 1 to 10. The variables used to define the states can be present, for example, in the form of a vector. The vector can contain, for example, a first variable of BOOLEAN format and a second variable of INTEGER format. Such a variable vector is time-dependent. For example, at a certain time point, the first variable can have the value TRUE and the second variable can have the value 24. This makes it possible to evaluate a condition for an environment or system component that is in a unique state described by the current values ​​of the variables at a certain time point t, i.e., to check whether the variable satisfies the condition defined at time point t. The corresponding variable vector can also contain at least one empty element. This is the case, for example, if the evaluation unit cannot find a specific variable. Instead of an empty element, a placeholder, such as the numbers "0", "9999", or the string "NAN", can also be used.

[0030] Similarly, a variable may be of a structure type, for example a variable: -ARRAY or -RECORD, A structure type can be composed of both non-structure types and structure types.

[0031] In another preferred embodiment of the method, at least one condition is defined to be target component-specific and / or operation-specific. For example, the cryptographic material can be used to perform various operations, such as installing software, encrypting or decrypting specific data, creating or verifying signatures, and / or for use by various system components. To enable the creator to characterize the condition in an operation-specific manner, i.e., valid only for a particular operation, the creator must be informed of the set of operations known within the system component according to the set of available state variables, so that the creator can use this to define the condition. Such a set of operations can be generic, i.e., valid for all target components, or it can be target component-specific.

[0032] It may occur that for a particular condition to be considered satisfied when performed by different system components and / or different operations, a particular variable must take on different values, i.e., sometimes TRUE and sometimes FALSE, or sometimes 0 and sometimes 256, for at least two different system components and / or operations.

[0033] Furthermore, in another preferred embodiment of the method according to the present invention, it is contemplated that at least one different variable is used for target component-specific and / or operation-specific conditions at different target system components and / or during different operations. For example, not only can a particular variable take on different values ​​to satisfy a condition and / or perform different operations at different system components, but different variables may also be required for this. In particular, the allowable amount and / or type and size of variables associated with a condition can be differentiated between different system components and / or operations. For example, to satisfy a condition at a first system component, variables 1 and 2 must take the values ​​0 and TRUE, while at a second system component, variables 1, 2, and 3 must take the values ​​0, TRUE, and FALSE. Meanwhile, to satisfy the same condition at a third system component, variables 1, 2, 3, 4, 5, and 6 must take the values ​​TRUE, [0..100], [-100..100], 0, "engaged," and FALSE. In general, at least two BOOLEAN values ​​may be linked by an OR operator, as will be discussed in more detail below.

[0034] In another preferred embodiment of the method, the evaluators check the conditions using evaluation functions, and at least two different evaluators use different evaluation functions, in particular operation-specific evaluation functions. Generally, all evaluators can use the same evaluation function. However, the provision of different evaluation functions allows for greater flexibility in implementing the method of the present invention for controlling the conditions under which cryptographic material is used by system components.

[0035] Usually, a general evaluation function can be used, so that all cryptographic material or conditions configured on the cryptographic material can be evaluated by providing only one function. However, evaluation functions can also be created specific to different cryptographic material, for example depending on the role of the cryptographic material. In particular, a distinction is made here between different evaluation functions for different operations.

[0036] Furthermore, another preferred embodiment of the method provides that at least one condition is defined in a machine-processable definition language, where an executable language that can be interpreted by an interpreter or one of the following formal logics is used: -Propositional logic; -Propositional logic, including relational logic; -Propositional logic, including relational logic and functions.

[0037] Defining conditions in a machine-processable definition language allows the use of existing languages ​​to implement the method according to the present invention. Using an evaluable definition language, conditions can be formulated using valid variables describing the state of a system component, e.g., as expressions of processable Boolean values ​​defined by the definition language. When the cryptographic material has multiple conditions, the variable sets associated with corresponding conditions can also contain different variables. All variables in the corresponding variable sets can be of the same type, i.e., Boolean, integer, or string, or at least two variables in the variable sets associated with each condition can have different types. Different conditions configured in the cryptographic material can use the same or different machine-processable definition languages.

[0038] In well-known propositional logic, all variables associated with a particular condition have the value range BOOLEAN, i.e., each variable can only take on the values ​​TRUE or FALSE. Logical formulas are constructed using the well-known logical connectives of propositional logic, i.e., "Λ", "V", "￢", etc., and parentheses (" "). An example of a propositional logic formula is: - variable 1; -variable 2ΛTRUE; -(variable 1Λ(variable 2V variable 3)).

[0039] In propositional logic, including relational logic, variables associated with a particular condition can have different value ranges. There is a finite set of relational logics, each of which is assigned a fixed arity, and each of which is assigned a fixed value range for each relational logic and term position. A relational term is then obtained by applying the relational logic to one of the corresponding number of constants and / or variables with a matching value range, corresponding to the arity. Evaluating a relational term for a fixed, predetermined value assignment of the variables appearing in such a term always yields a Boolean value, i.e., TRUE or FALSE. For example, an example of a two-digit relational logic requiring integers as the value range in both term positions is the less-than-equal relational logic "≦". A relational term based on this relational logic might look like this: - variable 1 ≤ variable 2; -7≦variable 3.

[0040] A logical formula is constructed using BOOLEAN constants, BOOLEAN variables, relational terms, and well-known propositional logic connectives, i.e., Λ, V, ￢, etc., as well as parentheses (``and'') to specify the order of evaluation. An example of a propositional logic formula containing relational logic, using the binary relational logic ``≦'' and ``='', is as follows: -(Variable 1Λ((Variable 2≦Variable 3)V(Variable 3=Variable 4))).

[0041] Propositional logic, which includes relational logic and functions, additionally uses a finite set of functions, each of which is assigned a fixed arity, and each function and each term position is assigned a fixed value range. Furthermore, a result value range is defined for each function. A function is then applied to a number of constants, variables, and / or functions with matching value ranges corresponding to its arity, returning a value from a given result value range. For example, an example of a binary operation that requires integers as value ranges in both term positions and returns an integer value as a result is the addition "+". Logical formulas are constructed in the same way as in propositional logic, which includes relational logic, except that relational terms can be formed not only by applying relational logic to constants and / or variables, but also by functions with corresponding result value ranges applied to the constants / variables. An example of a propositional logic formula, which includes relational logic and functions, is as follows: -(Variable 1Λ((Variable 2≦(Variable 3 + Variable 7))V(((Variable 3 − Variable 8) + Variable 2) = Variable 4))).

[0042] In contrast, the use of executable languages, especially those that can be interpreted by an interpreter, offers advantages. Such languages ​​are very "powerful" due to their executable nature, i.e., the corresponding program code does not need to be translated / compiled or converted into an expression tree or have variable values ​​assigned before it can be executed. An interpretable executable language can be, for example, a scripting language such as Python.

[0043] In another preferred 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 different from the first language, providing two conditions formulated in different definition languages ​​ensures that both system components can be evaluated with respect to their associated conditions. Accordingly, variables associated with the conditions are also formulated in their respective definition languages. Two conditions valid for the same system component can also be formulated in different definition languages. It may be preferable to formulate certain conditions in a specific definition language. This is the case, for example, if the detection and / or processing of certain variables is only possible in a specific definition language or if this is set based on various boundary conditions.

[0044] Furthermore, another preferred embodiment of the method according to the present invention contemplates that the cryptographic material includes at least two conditions, all of which must be met in order for the cryptographic material to be used by the system component. In terms of the use of formal logic, this means that the conditions used are AND-connected; that is, all of the conditions must be met in order for the cryptographic material to be used by the system component. In this way, the satisfaction of an individual condition is necessary, but not necessarily sufficient, for the cryptographic material to be applied by the system component, since at least one other condition must also be met.

[0045] In another preferred embodiment of the method, the evaluator typically provides the following response for each condition if cryptographic material is to be used by a system component but the target component specific conditions do not include the corresponding system component class, or if an operation is to be performed using cryptographic material but this operation is not included in the operation specific conditions, or if the evaluator is unable to find a variable required for checking the condition: -TRUE; -FALSE; or -Response appended to the encrypted material as a standard response.

[0046] This ensures a more reliable implementation of the method according to the invention. Generally, it may be the case that a system component or a class of system components for which a particular encryption material is to be used is not included in the target component-specific conditions. To ensure that the corresponding system component can still apply the encryption material, the value TRUE is output as standard after the target component-specific conditions have been checked. Alternatively, if application of the encryption material should be prevented in such cases, the value FALSE is output as standard. To increase the flexibility of the method according to the invention, a standard response in the form of TRUE or FALSE can also be attached to the encryption material. This reduces the risk that a system component with the standard response set to TRUE will apply the encryption material even when it should not. In such cases, the standard response FALSE is attached to the encryption material.

[0047] The formulation given above also applies to operation-specific conditions, as well as to cases where the evaluator cannot find the variables needed to check a particular condition.

[0048] Furthermore, another preferred embodiment of the method according to the invention provides that all additional data contained in the encrypted material is cryptographically secured against compromise, in particular by using at least one digital signature and / or a symmetric integrity protection mechanism. Keyed-Hash Message Authentication Code (HMAC) can be used as a symmetric integrity protection mechanism. Securely securing the encrypted material against compromise provides an additional level of protection when implementing the method according to the invention. In this way, the encrypted material as well as additional data added to the encrypted material package are protected against manipulation. For example, the encrypted material, including the additional data to be added, can be digitally signed, for example, by the creator using its asymmetric private key. In particular, a secure method and a secure system are used for signing. The public key or a certificate containing the public key is then distributed to all relevant evaluators. In a corresponding system, the corresponding public key or certificate is embedded in a tamper-protected manner. For example, the public key or certificate is stored in a write-protected memory (ROM) or in a write-once-only memory (WORM). The encrypted material package also includes such a digital signature. Accordingly, cryptographic material is used by a system component only if verification of the signature attached to the cryptographic material using the installed public key or certificate yields a positive result.

[0049] In another preferred embodiment of the method according to the present invention, at least two different entities are authorized to digitally sign encrypted material, and all entities authorized to sign are given their own end-entity certificate and corresponding private key, belonging to a common certificate hierarchy. For example, it is particularly useful to grant permission to multiple entities to digitally sign encrypted material when multiple entities create the encrypted material. A signing system then signs the corresponding encrypted material with the private key belonging to its end-entity certificate. The entire certificate chain, not just the generated signature, is then appended to the encrypted material. The certificate chain appended to the encrypted material is then used by a corresponding validator, or by a system including the validator, to verify the authenticity of the signature created by the signing system.

[0050] If the cryptographic material is already a digital certificate, it is already pre-signed. Then, when the additional data, i.e., at least one condition, role, and / or target component identity, is recorded in the certificate, it is also signed together by the certificate creator. For example, the additional data, or only a part of it, is included in the corresponding certificate as one or more certificate extensions and signed together. If all the additional data is included in the certificate, the dedicated creation of a digital signature for the cryptographic material can be omitted.

[0051] To ensure the best possible protection, the method according to the invention should be applied as early as possible during the development of the corresponding system component. Since the check of the condition by the evaluator depends on variables, these variables should be best protected against manipulation, since a corrupted variable could conceal the existence of a state that does not actually exist. Accordingly, the constants used to evaluate the condition are preferably stored in a write-once memory, such as a WORM memory. The values ​​of the variables on which the condition depends are preferably systematically adapted to the current system state throughout the life cycle of the information technology system or the individual system components.

[0052] Preferably, a vehicle ecosystem is used as the information technology system. In general, the method according to the present invention can be applied to various system components of different types of information technology systems, whether networked or not. The use is particularly efficient when the information technology system is a vehicle ecosystem, since in this case the corresponding requirements for costly development involving many partners often make compliance with safety guidelines very difficult in practice. The method according to the present invention and the associated self-checks performed by each system component can dramatically minimize potential security holes.

[0053] Further preferred embodiments of the inventive method for implementing and utilizing cryptographic material in at least one system component of an information technology system will become apparent from the examples described in detail below with reference to the drawings. [Brief explanation of the drawings]

[0054] [Figure 1] 1 is a schematic diagram illustrating a first use of cryptographic material in a system component of an information engineering system; [Figure 2] FIG. 2 is a schematic diagram illustrating the use of alternative cryptographic materials in the system components shown in FIG. 1; [Figure 3] FIG. 10 is a principle diagram illustrating the use of alternative cryptographic material in another system component. [Figure 4] 10 is a flowchart illustrating an example of processing of cryptographic material in system components when an operation is performed. DETAILED DESCRIPTION OF THE INVENTION

[0055] FIG. 1 illustrates a first example of the use of cryptographic material KM by at least one system component SK of an information technology system IT-S. The state of the system component SK is described by at least one variable VAR. In the example of FIG. 1, the set of all variables VAR is represented as VAR, and each individual state variable used here is represented as "produktiv." The state variable produktiv indicates whether the system component SK is in the production phase of its life cycle, i.e., whether it is a production system. The cryptographic material KM is a self-signed test root certificate TestRootCert belonging to a test root key pair (TestRootPub, TestRootPriv), which is assigned to the target system as a trust anchor, thereby enabling it to establish a test connection with a communication partner by using TestRootCert to check the authenticity of a certificate received from the partner and signed with TestRootPriv.

[0056] The certificate TestRootCert was created under insecure conditions, e.g. the private key TestRootPriv is not stored securely. TestRootCert is therefore not allowed to be used in a production system. Accordingly, the condition BED contained in the cryptographic material KM is defined as produktiv=FALSE. The condition BED states that the certificate TestRootCert is only allowed to be used by the target system, i.e. by the system component SK, if it is not in production.

[0057] 2 shows a similar embodiment in which the cryptographic material KM contains a certificate ProdRootCert that can be securely applied in a production system. Accordingly, the certificate ProdRootCert is always allowed to be used by the target system, i.e., by the system component SK, for example, both in the development and production phases. ProdRootCert is allowed to be used even in the development phase, since it does not contain any secret content. Accordingly, the condition BED does not depend on the state variable produktiv and is always satisfied (TRUE). Since the condition BED does not depend on any variable VAR, an empty set of additional variables can be chosen, i.e., BED TestRootCert ({product}):=(TRUE) instead of BED TestRootCert ({}):=(TRUE).

[0058] 3 shows another example of the implementation and use of cryptographic material KM in a system component SK. The system component SK now has two state variables: both elements HSMProvisioningSicher; BOOLEAN, and HSMVerschlSicher; BOOLEAN of the set of variables VAR. The set of variables VAR corresponds here to a vector with two elements. The additional variable HSMProvisioningSicher indicates whether the hardware security module HSM is already in a state where it can receive and store cryptographic material KM in a secure manner. The state variable HSMVerschlSicher indicates whether the hardware security module HSM is already in a state where it can use the private key stored in it for encryption in a secure manner. The cryptographic material KM in FIG. 3 is a secret symmetric key AESKey of 256 bits in length to be used for AES encryption in the production system.

[0059] Two operations should be protected by the condition BED. On the one hand, this is the provision of cryptographic material KM, i.e. the secure introduction and secure storage of the key in the system component SK. Furthermore, this is encryption, i.e. the secure use of the key for encryption in the system component SK. The secure use of the key in the target system is protected by two conditions BED BED AESKey Provisioning and BED AESKey Verschlusselung Guaranteed by BED BED Conditions AESKey Provisioning indicates that the key AESKey is allowed to be introduced into the target system only if HSMProvisioningSicher=TRUE is true. AESKey Verschlusselung indicates that the key AESKey is allowed to be used for encryption on the target system only if HSMVerschlSicher=TRUE.

[0060] Figure 4 shows a flow chart of the method according to the invention. Here, we assume that the package of cryptographic material KM-P has the following form: KM-P = (KM, ZKIDENT KM ,BED KM * ,ROLE KM * ,Sign KM ,ZK), where ZKIDENT KM represents the totality of permitted target component identities for the cryptographic material KM, and ZKIDENT KM ,BED KM * represents the set of optionally target component-specific and / or operation-specific conditions BED assigned to the cryptographic material KM, and ROLE KM * optionally a target component specific role ROLE KM * In this case, the above variable ZKIDENT KM ,BED KM * ,ROLEKM * At least one of the Sign may be missing from the cryptographic material package KM-P. KM is created by the creator of the encryption material KM, (KM,ZKIDENT KM ,BED KM * ,ROLE KM * ) and ZK is a certificate chain that is used by the system component SK to sign. KM , the validity of the system component SK can be checked. Furthermore, for unique addressing of the system component SK, it is also assumed that the system component SK has an identity skid and a target component type (skid). For example, the identity skid and the target component type (skid) can be contained in the variable VAR of the system component SK. The system component type can also be understood as a class of the system component SK, i.e., all system components SK of the class / type "head unit", "engine control unit", etc. Furthermore, it is assumed that the evaluator wants to check whether the cryptographic material KM contained in the cryptographic material package KM-P is allowed to be installed on the system component SK for the operation Prov on the system component SK. This operation can generally be any operation, such as the execution of a decryption process. In the example of FIG. 4, the operation is the actual provisioning of the cryptographic material KM.

[0061] First, the signature KM If the signature check is unsuccessful, an exception is subsequently handled according to the first link LINK1. If, on the other hand, the signature check is successful, the encryption material KM, here in the form of an encryption material package KM-P, is checked for at least one target component identity ZKIDENT KM If the above is true, it is checked whether the identity skid of the system component SK contains the target component identity ZKIDENTKM If this is not the case, an exception is initiated according to the first link LINK1. KM If it does not contain this step is jumped.

[0062] Continued, Condition BED KM * It is checked whether the encryption material KM contains the condition BED and, if so, what condition it contains. KM * If it does not, the process continues by following the second link LINK2, which results in the installation of the cryptographic material KM.

[0063] Continued, Condition BED KM * is checked to see if it is specific to the target component.

[0064] If that is not the case, at least one condition BED KM * is checked to see if it is operation specific.

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

[0066] In contrast, at least one condition BED KM * If it is determined that the operation is specific, it is then checked whether the operation is intended to provide or provision cryptographic material KM. If so, the operation-specific conditions BED KM Prov The process then proceeds along links LINK1 and LINK2.

[0067] On the other hand, if at least one type-specific condition is found in the cryptographic material package KM-P, then it is determined whether at least one type-specific condition is also valid for the entire class of system components SK, i.e., whether the type (skid) is BED KM * The set of valid conditions for each class referenced by a type (skid) is denoted as BED in the following. KM Type(skid)* If this is the case, provisioning is allowed to take place (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 is allowed to take place or not. For this purpose, a standard response may for example be included in the cryptographic material package KM-P.

[0068] Subsequently, type-specific conditions are added to the operation-specific BED KM Type(skid)* If it is not true, the condition BED KM Type(skid) is evaluated and the process proceeds by following the links LINK1 and LINK2. KM Type(skid)* If is operation-specific, then there is at least one operation-specific condition, here representatively for operation Prov ("provisioning"), namely the condition BED KM Type(skid),Prov But, BED KM Type(skid)* (This step is not shown in Figure 4). If this is not the case, an exception process is initiated according to the first link LINK1. If this is the case, i.e., BED KM Type(skid)* Condition: BED KM Type(skid),Prov If it does, it is evaluated and the process proceeds by following links LINK1 and LINK2.

[0069] Individual conditionsBED KM ,BED KM Prov ,BED KM Type(skid) or BED KM Type(skid),Prov After the evaluation of the cryptographic material KM, here in the form of a cryptographic material package KM-P, the cryptographic material KM is provided with at least one role ROLE KM * If this is not the case, the provision of cryptographic material KM for the system component SK is performed without a role. On the other hand, if this is the case, the ROLE KM * It is checked whether contains a role for the target component type Type(skid). If this is not the case, an exception is thrown again. If this is the case, the role ROLE KM * The encryption material KM is provided taking into consideration the above.

Claims

1. A method of implementing and using cryptographic material (KM) in at least one system component (SK) of an information technology system (IT-S) for performing at least one operation, wherein at at least one first point in time, a state of said system component (SK) described by at least one variable (VAR) is checked, said cryptographic material (KM) is supplemented with additional data, said state data describing possible states of said system component (SK), and said additional data of said cryptographic material (KM) includes at least one state of said system component (SK) at said first point in time, said cryptographic material (KM) being used by said system component (SK), The additional data includes at least one condition (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ), at least one ROLE ＫＭ ＊ ), and / or at least one target component identity (ZKIDENT ＫＭ ) A method comprising:

2. The cryptographic material (KM) contains at least one target component specific role (ROLE). ＫＭ ＊ 10. The method of claim 1, comprising:

3. All the above conditions (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 3. The method according to claim 1, wherein the system component (SK) is defined by a creator external to the system component (SK) and evaluated by at least one evaluator running in the environment of the system component (SK), the creator and the evaluator jointly defining variables (VAR) that the creator can use during the definition.

4. At least one variable (VAR) has the following value range: -BOOLEAN; -INTEGER; or -STRING 4. The method according to claim 1, further comprising:

5. At least one condition (BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 5. The method according to claim 1, wherein the target component and / or operation is defined in a target component-specific and / or operation-specific manner.

6. Target component-specific and / or operation-specific conditions (BEDs) can be set for each target component and / or for each different operation. ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 6. The method of claim 5, wherein at least one different variable (VAR) is used for the variances (VAR).

7. The evaluation part is the condition (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 7. The method according to claim 3, wherein the evaluation functions are checked by at least two different evaluation units, and wherein different evaluation functions are used, in particular operation-specific evaluation functions.

8. At least one of the conditions (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ) is defined in a machine-processable definition language, an executable language that can be interpreted by an interpreter is used, or the following formal logic - propositional logic; - propositional logic, including relational logic; or - Propositional logic including relational logic and functions 8. The method according to claim 1, wherein one of the following is used:

9. At least two of the above conditions (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ) are defined in different definition languages, especially the two goal component specific conditions (BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 9. The method of claim 8, wherein the formula is:

10. The encryption material (KM) is a set of at least two of the conditions (BED, BED) ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ), and in order for the encryption material (KM) to be used by the system component (SK), all of the conditions (BED, BED ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ 10. The method according to claim 8 or 9, characterized in that the following condition must be satisfied:

11. Target component-specific conditions (BED) for cryptographic material (KM) used in system components (SK) ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ) does not contain the class of the corresponding system component (SK), or the operation specific condition (BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ If an operation is performed using cryptographic material (KM) that is not included in the PKM, or if the evaluator cannot find a variable (VAR) required for checking the state, the evaluator checks the respective condition (BED, BED) ＫＭ ＊ , BED ＫＭ Ｐｒｏｖ , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ） , BED ＫＭ Ｔｙｐｅ（ｓｋｉｄ），Ｐｒｏｖ ) the standard response is -TRUE; - FALSE; or - the response attached to said encryption material (KM) as a standard response, 11. The method according to claim 5, wherein the

12. 12. The method according to claim 1, wherein all additional data contained in the cryptographic material (KM) is cryptographically secured against compromise, in particular using at least one digital signature and / or a symmetric integrity protection mechanism.

13. 13. The method of claim 12, wherein at least two different entities are authorized to digitally sign the encrypted material (KM), and all entities authorized to sign are each given an individual private key assigned to them and an associated individual end-entity certificate and associated certificate chain.

14. 14. The method according to any one of claims 1 to 13, characterized in that a vehicle ecosystem is used as the information technology system (IT-S).

Images