EP4297332B1 - Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems - Google Patents

Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems Download PDF

Info

Publication number
EP4297332B1
EP4297332B1 EP23209295.7A EP23209295A EP4297332B1 EP 4297332 B1 EP4297332 B1 EP 4297332B1 EP 23209295 A EP23209295 A EP 23209295A EP 4297332 B1 EP4297332 B1 EP 4297332B1
Authority
EP
European Patent Office
Prior art keywords
bed
skid
type
prov
cryptographic material
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP23209295.7A
Other languages
English (en)
French (fr)
Other versions
EP4297332A3 (de
EP4297332A2 (de
EP4297332C0 (de
Inventor
Viktor Friesen
Viktor Pavlovic
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Publication of EP4297332A2 publication Critical patent/EP4297332A2/de
Publication of EP4297332A3 publication Critical patent/EP4297332A3/de
Application granted granted Critical
Publication of EP4297332B1 publication Critical patent/EP4297332B1/de
Publication of EP4297332C0 publication Critical patent/EP4297332C0/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model

Definitions

  • the 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 type defined in more detail in the preamble of claim 1.
  • the procedure for implementing and using cryptographic material essentially deals with the fact that in different life cycle phases of system components of an information technology system that are equipped with cryptographic material, cryptographic material must be used that corresponds to the current security level of the respective system component or a sub-module of the system component. This refers in particular, but not exclusively, to the area of so-called CarlT security for vehicles.
  • Modern vehicles as well as other systems, are characterized by increasing networking.
  • the vehicles are not only connected to generally accessible systems such as the Internet, but also to dedicated systems operated by the vehicle manufacturer or OEM, such as manufacturer-specific applications and a manufacturer-specific server, which is often referred to as a backend server.
  • manufacturer-specific applications and a manufacturer-specific server, which is often referred to as a backend server.
  • backend server which is often referred to as a backend server.
  • These are developed, marketed and operated by the manufacturer exclusively for its own vehicle fleet. All of this together is also referred to as the vehicle ecosystem.
  • test crypto material In order to reliably prevent the protected communication from being interfered with, it is imperative to distinguish between cryptographic material that is used during the development phase and cryptographic material that is used during the production phase, i.e. the actual use of the fully developed product.
  • the cryptographic material for the development phase is also referred to below as test crypto material.
  • test crypto material In the development phase, as long as it is secret crypto material, only test crypto material may be used.
  • the production crypto material, and in particular secret production crypto material must be protected from unauthorized access throughout the entire life cycle of the system component. Ideally, this protection should be ensured by adhering to a special secure process and using special protection mechanisms in the respective development departments and production facilities. However, this is usually only inadequately guaranteed during the development phase, since various components of the information technology system are usually not or not yet implemented during this development phase.
  • the secure generation of the required cryptographic material may not yet be fully implemented or tested.
  • the secure transmission of the cryptographic material from the generation server, the so-called crypto material server, to the system manufacturer, for example a supplier, may not yet be ensured.
  • the secure introduction of the crypto material into the system component has not yet been implemented or has not yet been fully implemented.
  • the secure storage of the cryptographic material in this system component may not yet be implemented because, for example, the target system does not yet have a hardware security module (HSM) installed, although this is to be installed at a later date.
  • HSM hardware security module
  • the secure use of the cryptographic material in the system may not yet be implemented, for example because development interfaces required for testing and debugging are available 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.
  • development interfaces required for testing and debugging are available 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 are necessarily available during development and are usually openly accessible to all persons and/or companies involved in the development process.
  • test crypto material is identical in structure and form to the productive crypto material used later. It is therefore also suitable for use in later operations, i.e. in the productive phase of the respective system component. It is therefore particularly important that the test crypto material, which is relatively poorly secured and therefore highly likely to be corrupted, is not misused in the productive system. It is even more serious if productive crypto material ends up on a system component in the development phase. This material, which requires a very high level of protection, can then also be manipulated or read out in whole or in part. It is therefore no longer secret and cannot be used. If the error goes unnoticed or is deliberately covered up, the system component that later moves into the productive phase loses its security.
  • a method for the secure use of cryptographic material is already known from the DE 10 2020 003 072 B3 known.
  • the cryptographic material has a marking which identifies the cryptographic material as development or production material.
  • the individual system components have a binary status flag which indicates whether the corresponding system component is in the development or production phase of its life cycle.
  • the marking of the cryptographic material is then compared with the binary status flag of the respective system component. If the marking and the flag match, i.e. if the cryptographic material is marked as development material and the system component is in the development phase, for example, the corresponding cryptographic material is used by the system component. If, however, the marking and the binary status flag do not match, security measures are initiated.
  • the match between the marking of the cryptographic material and the binary status flag is checked before the cryptographic material is used or once for all the cryptographic material in the system component.
  • the check for compliance can be carried out, for example, when the system component starts up or when the cryptographic material is made available.
  • a warning message can be issued, the provision of the cryptographic material can be aborted or prevented and/or, if necessary, cryptographic material that has already been introduced into a system component can be deleted.
  • the US 2021/075607 A1 a key management device and a processor chip for encrypting and decrypting data.
  • Cryptographic keys are stored in a key database. With the help of a lookup table, specific keys can be found within the key database using a key number. Metadata can be assigned to a key within the lookup table. The metadata can be used to describe states of boundary conditions under which a particular key can be used.
  • the present invention is based on the object of specifying an improved method for implementing and using cryptographic material in at least one system component of an information technology system, which allows a particularly flexible, secure implementation and use of cryptographic materials that differ in many ways in different system components, and in the process ensures that in the case of a system component which 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 which 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.
  • this object is achieved 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.
  • the cryptographic material has additional data which, according to the invention, is formed by at least one condition, at least one role and/or at least one target component identity.
  • 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, with the creator and the evaluator jointly determining which variables may be used by the creator in the definition.
  • the method according to the invention allows a particularly flexible, secure implementation and use of cryptographic material in a wide variety of system components and/or their sub-modules.
  • 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 a wide variety of cryptographic materials at different times, such as symmetric or asymmetric keys, certificates, random numbers, hash values or the like.
  • a specific target system component that is to use cryptographic material can also 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 large number of different states, thus also having more than two states, such as being in a development phase or a productive phase of a life cycle.
  • Individual sub-modules of a system component can also be in different life cycle phases or states.
  • a network interface can be in a first, insecure state, and a memory element of the System components are in a second, secure state.
  • a corresponding information technology system can be networked or isolated.
  • Cryptographic material is typically generated by a dedicated system, for example a crypto material server, and transmitted as part of a special data packet to a target system, i.e. a target system component.
  • a target system i.e. a target system component.
  • the cryptographic material is supplemented with additional data.
  • a corresponding condition specifies under which circumstances the use of the cryptographic material by the system component is permitted or not permitted.
  • the corresponding conditions can be of a very diverse nature. For example, the condition can require that the respective system component is in a certain stage of a product life cycle, or that the system component has a hardware security module and that this is in a secure state so that the hardware security module can securely receive and store cryptographic material.
  • the cryptographic material can also include several conditions. This makes it possible to control the implementation and use of cryptographic material in different system components in an even larger number of different application scenarios.
  • Cryptographic material intended for a system component fulfils a specific role there. If the same system component uses several 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 in 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 the role. The role differs from the condition in that the role does not impose any condition on the current state of the system component.
  • the cryptographic material can be supplemented with a target component identity.
  • the target component identity includes a unique identification of the system components which the may use corresponding cryptographic material. If the corresponding cryptographic material is applied to a system component that is not included in the target component identity, the use of the cryptographic material on this system component is prevented. This makes it particularly easy and quick to determine which system components may use which cryptographic material and which may not.
  • the target component identity can be directed at an entire class of systems, system components and/or their sub-modules, for example the class "head unit”, “engine control unit”, “flash memory” or the like, as well as at exactly one specific system component, for example the hardware security module with the serial number "GHNS-1934952".
  • At least one condition at least one role and/or at least one target component identity
  • the cryptographic material is typically designed as a crypto material (data) package and is exchanged between systems or system components or introduced there.
  • the crypto material package includes at least the actual cryptographic material, for example an asymmetric key pair, and the respective condition, role and/or target component identity in the form of additional data attached to the cryptographic material.
  • the attached data can be concatenated with the cryptographic material, for example.
  • the crypto material package can also include further data. For the sake of simplicity, only cryptographic material is referred to in this text.
  • 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 value range are then jointly determined by the creator and the evaluator, with the evaluator determining which names and value ranges the creator may use. The However, the creator decides for himself which names and value ranges he ultimately uses.
  • the creator is, for example, the cryptographic material server mentioned above.
  • the evaluator can be implemented using hardware and software or by a human.
  • the evaluator can be included in the system component or can be implemented externally to the system component, but in the same environment as the system component. This enables the evaluator to record the variables underlying the system component and describing the corresponding state of the system component.
  • An evaluator external to the system component enables the condition(s) imposed on the system component using the cryptographic material to be checked when the system component has not yet been booted. For example, checked cryptographic material can be saved in a memory of the system component without the corresponding system component having to be booted up first.
  • the evaluator is in particular able to check at any time whether a possible condition for the respective system component is fulfilled or not. By the creator and the evaluator agreeing on a common set of relevant variables, it can be ensured that the variables required to evaluate a specific condition can actually be recorded by the evaluator. This increases the reliability in the application of the method according to the invention.
  • the cryptographic material comprises at least one target component-specific role. If one and the same cryptographic material is sent to different system components, it can also fulfill different roles on the different system components. Target component-specific roles can thus be introduced into the cryptographic material, which tell the cryptographic material on which system component it should be used and how. This allows even more extensive and flexible control of how cryptographic material is implemented on different system components and used there.
  • 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. By using different value ranges or types, a wide variety of variables can be used to define and subsequently check conditions.
  • a variable of the BOOLEAN type takes on the value TRUE or FALSE.
  • states can be described in even more detail or in more complexity. For example, a certain state can be described using numbers and/or character strings.
  • a value range can be from 1 to 10, for example.
  • the variables used to define a state can be in the form of a vector, for example.
  • the vector can include a first variable of type BOOLEAN and a second variable of type INTEGER. This variable vector is time-dependent. At a certain point in time, for example, the first variable can have the value TRUE and the second variable can have the value 24. This allows a condition for each system component to be evaluated by the evaluator, whose environment is in a unique state described by the current values of the variables at a certain point in time t, i.e. to check whether the variables meet the defined conditions at the point in time t or not.
  • the corresponding variable vector can also include at least one empty element. This is the case, for example, if the evaluator cannot record a certain variable. Instead of an empty element, a placeholder can also be used, such as the number "0", "9999" or a character string such as "NAN”.
  • At least one condition is defined as target component-specific and/or operation-specific.
  • the cryptographic material can thus be used to carry out various operations such as installing software, encrypting or decrypting certain data, creating or checking a signature or the like and/or used by various system components.
  • a condition is defined as operation-specific, i.e. only applicable to a certain 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 them when defining conditions.
  • This set of operations can be general, i.e. valid for all target components, or target component-specific.
  • a further advantageous embodiment of the method according to the invention further 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 for a different operation.
  • a specific variable assume different values to fulfill a condition on different system components and/or to carry out different operations, but different variables can also be required for this.
  • the quantity and/or type as well as a size of a permissible value range of the variables relevant to a condition can differ between different system components and/or operations. For example, to fulfill a condition on a first On a system component, variables 1 and 2 take the values 0 and TRUE and on a second system component, variables 1, 2 and 3 take the values 0, TRUE and FALSE.
  • variables 1, 2, 3, 4, 5 and 6 must take the values TRUE, [0..100], [-100.. 100], 0, "engaged” and FALSE.
  • TRUE [0..100], [-100.. 100], 0, "engaged” and FALSE.
  • at least two BOOLEAN-valued expressions can also be linked with OR, which will be discussed below.
  • an evaluator checks a condition using an evaluation function, wherein at least two evaluators that differ from one another use a different evaluation function, in particular an operation-specific evaluation function.
  • a different evaluation function in particular an operation-specific evaluation function.
  • a generic evaluation function can also be used, whereby all cryptographic material, or the conditions covered by the cryptographic material, can be evaluated by providing just one function.
  • the evaluation function can also be designed specifically for different cryptographic materials, for example depending on the role of the cryptographic material. In particular, a distinction is made between different evaluation functions for different operations.
  • condition in a machine-processable definition language enables the use of existing languages to perform the inventive method.
  • conditions can be formulated using the applicable variables describing a state of the system component, for example as BOOLEAN-valued expressions defined and processable using the definition language.
  • a set of variables relevant to the corresponding condition can also contain different variables. All variables of a corresponding set of variables can be of the same type, i.e. BOOLEAN, INTEGER or STRING, or at least two variables of a set of variables relevant to a respective condition can differ in their type.
  • the same or different machine-processable definition languages can also be used mixed for different conditions included in the cryptographic material.
  • Logical formulas are formed using BOOLEAN constants, BOOLEAN variables, relational terms and well-known propositional logic operators ⁇ , v, ⁇ etc. as well as brackets "(" and ")" to determine the order of evaluation.
  • a finite set of functions is also used, with each function being assigned a fixed number of places, and each function and each position being assigned a fixed range of values.
  • the range of values of the result is defined for each function.
  • a function is then applied to a number of constants, variables and/or functions with the appropriate range of values corresponding to the number of places, and returns a value from the specified result range of values.
  • An example of a two-place function that requires INTEGER as the range of values in both positions and returns an INTEGER value as the result is the addition "+".
  • Logical formulas are formed with relations as in propositional logic, with the difference that relational terms can be formed not only by applying relations to constants and/or variables, but also by functions applied to constants/variables with the corresponding result range of values.
  • 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 can be a scripting language such as Python, for example.
  • At least two conditions are formulated in a different definition language, in particular two target component-specific Conditions are formulated in a different definition language. If a first system component uses a first language and a second system component uses a second language that differs from the first language, providing two conditions formulated in different definition languages ensures that both system components can evaluate the condition that is relevant to them.
  • the variables relevant to the conditions are also formulated in the respective definition language. It is also possible for two conditions that are valid for the same system component to be formulated in a different definition language. It can therefore be advantageous to formulate a certain condition using a certain definition language. This is the case, for example, if the recording and/or processing of certain variables is only possible using a certain definition language or if this is specified due to a wide variety of boundary conditions.
  • a further advantageous embodiment of the method according to the invention further provides that the cryptographic material comprises at least two conditions and all conditions must be fulfilled in order for the cryptographic material to be used by the system component.
  • the conditions used are AND-linked. All conditions must be fulfilled in order for the cryptographic material to be used by the system component. Fulfilling a single condition for the system component to use the cryptographic material is necessary, but not necessarily sufficient, since at least one further condition must be fulfilled.
  • the standard response in the form of TRUE or FALSE can also be appended to the cryptographic material. This reduces the risk that the cryptographic material is used on a system component whose standard response is set to TRUE, even though this should not actually be the case. In this case, the standard response in the form of FALSE is appended to the cryptographic material.
  • a further advantageous embodiment of the method according to the invention further provides that all additional data included in the cryptographic material are cryptographically secured against compromise, in particular using at least one digital signature and/or a symmetrical integrity protection mechanism.
  • a Keyed-Hash Message Authentication Code can be used as a symmetrical integrity protection mechanism. Securing the cryptographic material against compromise increases the protection when carrying out the method according to the invention even further.
  • the additional data attached to the cryptographic material package alongside the cryptographic material are protected against unauthorized manipulation.
  • the cryptographic material together with the associated additional data can be digitally signed by the creator using his asymmetrical private key.
  • secure methods and secure systems are used for signing.
  • the A public key or a certificate containing the public key is then distributed to all affected evaluators.
  • the corresponding public key or certificate is introduced into the corresponding systems in a way that is protected against manipulation.
  • the public key or certificate is stored in a read-only memory (ROM) or in a memory that can only be written to once (WORM).
  • ROM read-only memory
  • WORM write-only memory
  • the cryptographic material package contains such a digital signature. Accordingly, the cryptographic material is only used by the system component if a check of the signature attached to the cryptographic material using the introduced public key or certificate produces a positive result.
  • At least two different actors receive authorization to digitally sign the cryptographic material, whereby all actors authorized to sign receive their own leaf certificate belonging to a common certificate hierarchy with the associated private key. It is therefore particularly useful to give several actors authorization to digitally sign if several actors also create cryptographic material.
  • a system carrying out the signature then signs the corresponding cryptographic material with the private key belonging to its leaf certificate. Not only the generated signature but also the entire certificate chain is then added to the cryptographic material.
  • the certificate chain attached to the cryptographic material is then used by a corresponding evaluator or a system comprising the evaluator to check the correctness of the signature created by the signing system.
  • 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, it is co-signed by the creator of the certificate. The additional data, or 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 the digital signature of the cryptographic material can be dispensed with.
  • additional data i.e. at least one condition, role and/or target component identity
  • the method according to the invention should be used as early as possible in the development of a corresponding system component. Since the checking of the condition by the evaluator depends on variables, these variables must be protected as best as possible against manipulation, since corrupted variables can simulate the existence of a state that does not actually exist. Constants used to evaluate a condition are therefore preferably stored in a write-once memory such as a WORM memory. The values of the variables on which the conditions depend are preferably adapted to the current system state in a systematic manner throughout the entire life cycle of the information technology system or the individual system components.
  • a vehicle ecosystem is preferably used as the information technology system.
  • the method according to the invention can be used for various system components in various networked or non-networked information technology systems. Use is particularly efficient when the information technology system is a vehicle ecosystem, since the corresponding requirements in terms of complex development with many partners involved often make compliance with security guidelines very difficult in practice. By implementing the method according to the invention and thus self-checking by the respective system component, the risk of a potential security gap can be drastically minimized.
  • Figure 1 shows a first embodiment for the use of cryptographic material KM from 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.
  • VAR the set of all variables VAR is referred to as VAR and the individual state variable used here is referred to as "productive".
  • the state variable productive indicates whether the system component SK is in a productive phase of its life cycle, i.e. is a productive system, or not.
  • the cryptographic material KM is a self-signed test root certificate TestRootCert belonging to a test root key pair (TestRootPub, TestRootPriv), which is introduced into the target system as a trust anchor in order to be able to establish test connections with communication partners by checking the trustworthiness of the certificates signed with TestRootPriv received from partners using TestRootCert.
  • FIG. 2 shows a similar example, in which the cryptographic material KM now includes a securely generated certificate ProdRootCert that can be used safely in productive systems.
  • the certificate ProdRootCert can always be used by the target system, i.e. the system component SK, for example in the development and productive phases.
  • ProdRootCert can also be used in the development phase because it does not contain any secret parts.
  • FIG 3 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, namely the two 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 state variable HSMProvisioningSicher indicates whether a hardware security module HSM is already in a state in which it can securely receive and store cryptographic material KM.
  • the state variable HSMVerschlSicher indicates whether the hardware security module HSM is already in a state in which it can securely use secret keys stored in it for encryption.
  • the cryptographic material KM is Figure 3 a 256-bit long, secret symmetric key AESKey, which is to be used for AES encryption in production systems.
  • BED conditions Two operations are to be secured by BED conditions. Firstly, this involves the provision of cryptographic material KM, i.e. the secure introduction and secure storage of a key in the system component SK. Secondly, it involves encryption, i.e. the secure use of a key for encryption in the system component SK.
  • the secure use of the key in the target system is ensured by two conditions BED BED AESKey Provisioning and BED AESKey Encryption .
  • At least one of the specified variables ZKIDENT KM , BED KM *, ROLE KM * can be missing in the crypto material package KM-P.
  • Sign KM is the signature of (KM, ZKIDENT KM , BED KM *, ROLE KM *) created by the creator of the cryptographic material KM and ZK is the certificate chain with which the system component SK can check the correctness of the signature Sign KM .
  • the system component SK has the identity skid and the target system component type Type(skid).
  • the identity skid and the target system component type Type(skid) on a system component SK can be included in the variables VAR.
  • 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. It is also assumed that the evaluator wants to check whether the cryptographic material KM contained in the crypto material package KM-P can 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 carrying out a decryption process. In the example in Figure 4 The operation involves the actual provisioning of the cryptographic material KM.
  • the signature Sign KM is checked. If the signature check is not successful, an exception is handled according to a first link LINK1. If, on the other hand, the signature check is successful, a check is made to see whether the cryptographic material KM, here in the form of the crypto material package KM-P, includes at least one target component identity ZKIDENT KM . If this is the case, a check is made to see 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, on the other hand, this is not the case, i.e. the crypto material package KM-P does not include a target component identity ZKIDENT KM , this step is skipped.
  • condition BED KM * is operation-specific
  • a check is then made to see whether the operation is to provide 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 in the same way as for links LINK1 and LINK2.
  • At least one type-specific condition was detected in the crypto material package KM-P, a check is made to see whether 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 classes referenced by Type(skid) is referred to below as BED KM Type(skid) *. If this is the case, provisioning may take place (see first link LINK1). If this is not the case, a check must be made to see which standard procedure should be used, i.e. whether provisioning may take place or not. For this purpose, a standard response can be included in the crypto material package KM-P, for example.
  • BED KM Type(skid) * is also operation-specific. If this is not the case, the condition BED KM Type(skid) is evaluated and the process continues according to the links LINK1, LINK2. If, however, the conditions BED KM Type(skid) * are operation-specific, it is checked 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 described in Figure 4 not shown). If this is not the case, an exception handling is initiated according to the first link LINK1. If this is the case, however, BED KM Type(skid) * i.e. a condition BED KM Type(skid) , Prov , this is evaluated and the process continues analogously to the links LINK1, LINK2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Stored Programmes (AREA)

Description

  • Die Erfindung betrifft ein Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems nach der im Oberbegriff von Anspruch 1 näher definierten Art.
  • Das Verfahren zur Implementierung und Nutzung von kryptografischem Material beschäftigt sich im Wesentlichen damit, dass in unterschiedlichen Lebenszyklusphasen von Systemkomponenten eines informationstechnischen Systems, welche mit kryptografischem Material ausgestattet sind, dem aktuellen Sicherheitsniveau der jeweiligen Systemkomponente oder eines Untermoduls der Systemkomponente entsprechendes kryptografisches Material Verwendung finden muss. Dies bezieht sich insbesondere, nicht jedoch ausschließlich, auf das Gebiet der sogenannten CarlT-Security für Fahrzeuge.
  • Moderne Fahrzeuge, aber auch andere Systeme, zeichnen sich durch eine zunehmende Vernetzung aus. Die Fahrzeuge sind dabei nicht nur mit allgemein zugänglichen Systemen wie dem Internet verbunden, sondern auch mit dedizierten, vom Fahrzeughersteller bzw. OEM betriebenen Systemen, beispielsweise herstellereigenen Applikationen und einem herstellereigenen Server, welcher häufig auch als Backendserver bezeichnet wird. Diese werden vom Hersteller exklusiv für die eigene Fahrzeugflotte entwickelt, vermarktet und betrieben. All dies zusammen wird auch als Fahrzeug-Ökosystem bezeichnet.
  • In der Praxis ist es nun so, dass durch die vielfältigen Kommunikationsbeziehungen zwischen den einzelnen Systemkomponenten innerhalb eines solchen Fahrzeug-Ökosystems eine Vielzahl neuer Schnittstellen und Anwendungen entsteht, die allesamt durch geeignete kryptografische Verfahren, wie beispielsweise Mechanismen, Protokolle usw., abgesichert werden müssen. Diese kryptografischen Verfahren, welche so prinzipiell aus dem Stand der Technik bekannt sind, benötigen dafür vielfältiges kryptografisches Material wie beispielsweise asymmetrische Schlüsselpaare, symmetrische Schlüssel, Zertifikate, Zufallszahlen, Hashwerte usw. All diese Kryptomateriale sind aufeinander abgestimmt und werden oft vor ihrer Inbetriebnahme, zum Austausch von Kryptomaterial auch während des laufenden Betriebs, in dem Fahrzeug-Ökosystem in alle teilnehmenden Systemkomponenten eingebracht und müssen von diesen genutzt werden. Die Bereitstellung des kryptografischen Materials, das sogenannte Provisioning, erfolgt beispielsweise im Rahmen des Herstellungsprozesses, sie kann aber auch während des Betriebs der Systemkomponenten erfolgen. Die Systemkomponenten umfassen dabei insbesondere in den Fahrzeugen verbaute Steuergeräte, aber auch andere Komponenten wie beispielsweise im Fahrzeug installierte Applikationen, auf einem Smartphone verfügbare Applikationen des OEM, fahrzeugexterne Geräte und dergleichen.
  • Um zuverlässig zu verhindern, dass in die geschützte Kommunikation eingegriffen werden kann, ist es zwingend notwendig, zwischen kryptografischem Material, welches während der Entwicklungsphase verwendet wird, und kryptografischem Material, das während der Produktivphase, also dem realen Einsatz des fertig entwickelten Produkts, zum Einsatz kommt, unterschieden wird. Das kryptografische Material für die Entwicklungsphase, wird nachfolgend auch als Test-Kryptomaterial bezeichnet. In der Entwicklungsphase darf, solange es sich um geheimes Kryptomaterial handelt, nur ausschließlich solches Test-Kryptomaterial verwendet werden. Das Produktiv-Kryptomaterial, und hier insbesondere geheimes Produktiv-Kryptomaterial, muss nämlich während des gesamten Lebenszyklus der Systemkomponente vor unberechtigtem Zugriff geschützt werden. Dieser Schutz sollte dabei im Idealfall durch das Einhalten eines speziellen abgesicherten Prozesses und die Verwendung spezieller Schutzmechanismen in den jeweiligen Entwicklungsabteilungen und Produktionsstätten gewährleistet werden. In der Entwicklungsphase ist dies jedoch meist nur unzureichend gewährleistet, da verschiedene Bausteine des informationstechnischen Systems in dieser Entwicklungsphase meist nicht oder noch nicht umgesetzt bzw. implementiert sind.
  • So kann beispielsweise die sichere Erzeugung des benötigten kryptografischen Materials noch nicht vollständig umgesetzt oder getestet sein. Die sichere Übertragung des kryptografischen Materials vom Erzeugungsserver, dem sogenannten Kryptomaterial-Server, zum Systemhersteller, beispielsweise einem Zulieferer, ist gegebenenfalls noch nicht sichergestellt. Das sichere Einbringen des Kryptomaterials in die Systemkomponente ist noch nicht oder noch nicht endgültig umgesetzt. Das sichere Speichern des kryptografischen Materials in dieser Systemkomponente ist eventuell noch nicht umgesetzt, weil beispielsweise das Zielsystem noch kein Hardwaresicherheitsmodul (Hardware Security Module; HSM) verbaut hat, obwohl dies zu einem späteren Zeitpunkt noch eingebaut werden soll. Die sichere Nutzung des kryptografischen Materials in dem System ist ggf. noch nicht umgesetzt, beispielsweise, weil zum Testen und Debuggen benötigte Entwicklungsschnittstellen vorhanden sind, welche einen lesenden und schreibenden Zugriff auf das gesamte System haben und damit insbesondere auch einen Zugriff auf das installierte kryptografische Material während der Entwicklungsphase erlauben. Diese sind aber notwendigerweise während der Entwicklung vorhanden und meist auch für alle beteiligten Personen und/oder Firmen im Entwicklungsprozess offen zugänglich.
  • Dies führt also dazu, dass nicht sichergestellt werden kann, dass das während der Entwicklungsphase verwendete Kryptomaterial nicht manipuliert oder ausgelesen wird. Dabei ist es jedoch so, dass dieses Test-Kryptomaterial in seiner Struktur und Form identisch zu dem später genutzten Produktiv-Kryptomaterial ist. Es eignet sich somit auch für den Einsatz im späteren Betrieb, also in der Produktivphase der jeweiligen Systemkomponente. Deshalb ist es besonders wichtig, dass das relativ schlecht gesicherte und daher mit einer hohen Wahrscheinlichkeit korrumpierte Test-Kryptomaterial im Produktivsystem nicht missbräuchlich eingesetzt wird. Noch gravierender ist es, wenn Produktiv-Kryptomaterial auf eine Systemkomponente in der Entwicklungsphase gelangt. Dieses einen sehr hohen Schutzbedarf aufweisende Material kann dann ebenfalls manipuliert oder ganz oder teilweise ausgelesen werden. Es ist damit nicht mehr geheim und kann nicht verwendet werden. Falls der Fehler unbemerkt bleibt oder bewusst vertuscht wird, verliert die später in die Produktivphase wechselnde Systemkomponente ihre Absicherung.
  • In der Praxis ist es so, dass die Sicherheitsvorschriften und Richtlinien durch die in den Phasen mit den Systemkomponenten beschäftigten Personen umgesetzt werden. Deshalb sind Fehler, Versehen und auch bewusste Manipulationen nicht auszuschließen. Von daher besteht prinzipiell immer die Gefahr, dass Test-Kryptomaterial in einer bereits in die Produktivphase gewechselten Systemkomponente verbliebt oder das Produktiv-Kryptomaterial auf einer Systemkomponente eingesetzt wird, die noch in der Entwicklungsphase ist. Jegliches bewusst oder versehentlich in der Entwicklungsphase genutztes Kryptomaterial ist, aufgrund der vielen noch offenen Schnittstellen etc. mit hoher Wahrscheinlichkeit korrumpiert. Diese Gefahren führen letztlich zu einem erhöhten Sicherheitsrisiko. Dies stellt einen gravierenden Nachteil der bestehenden Vorgehensweise dar.
  • Ein Verfahren zur sicheren Nutzung von kryptografischem Material ist bereits aus der DE 10 2020 003 072 B3 bekannt. Dabei werden mehrere Systemkomponenten eines vernetzten Systems mit kryptografischem Material ausgestattet. Das kryptografische Material weist eine Markierung auf, welche das kryptografische Material als Entwicklungs- oder Produktivmaterial kennzeichnet. Die einzelnen Systemkomponenten weisen ein binäres Zustandsflag auf, welches angibt, ob sich die entsprechende Systemkomponente in ihrer Lebenszyklusphase in der Entwicklungs- oder in der Produktivphase befindet. Es erfolgt dann ein Vergleich der Markierung des kryptografischen Materials mit dem binären Zustandsflag der jeweiligen Systemkomponente. Stimmen die Markierung und das Flag überein, sprich ist das kryptografische Material beispielsweise als Entwicklungsmaterial markiert und befindet sich die Systemkomponente in der Entwicklungsphase, so wird das entsprechende kryptografische Material von der Systemkomponente verwendet. Stimmen hingegen die Markierung und das binäre Zustandsflag nicht überein, so werden Sicherungsmaßnahmen eingeleitet. Die Überprüfung der Übereinstimmung zwischen der Markierung des kryptografischen Materials und dem binären Zustandsflag erfolgt vor dem jeweiligen Gebrauch des kryptografischen Materials oder einmalig für das gesamte kryptografische Material in der Systemkomponente. Die Überprüfung der Übereinstimmung kann beispielsweise beim Hochfahren der Systemkomponente oder auch beim Bereitstellen des kryptografischen Materials erfolgen. Als Sicherungsmaßnahme kann eine Warnmeldung ausgegeben werden, die Bereitstellung des kryptografischen Materials abgebrochen oder verhindert werden und/oder nach Bedarf bereits in eine Systemkomponente eingebrachtes kryptografisches Material gelöscht werden.
  • Nachteilig ist dabei jedoch, dass zur Unterscheidung, ob kryptografisches Material auf der Systemkomponente eingesetzt werden darf, lediglich zwischen zwei Lebenszyklusphasen der entsprechenden Systemkomponente und zwei verschiedenen Eigenschaften (Test oder Produktiv) für das kryptografische Material unterschieden wird. Im realen Einsatz wird eine Unterscheidung in lediglich zwei Gruppen nicht ausreichen, da die Bedingungen für die sichere Nutzung von kryptografischem Material für verschiedene kryptografische Materiale und Systemkomponenten zu unterschiedlich sind. Wird beispielsweise ein Geheimnis direkt in einem Hardwaresicherheitsmodul erzeugt und aufbewahrt und verlässt dieses nie, so kann das kryptografische Material gegebenenfalls schon während der Entwicklungsphase sicher genutzt werden. Voraussetzung ist dabei jedoch, dass das Hardwaresicherheitsmodul in der Entwicklungsphase keine speziellen Diagnoseschnittstellen, welche das Auslesen des Geheimnisses ermöglichen würden, aufweist bzw. verwendet. Ein in Software inkludiertes Geheimnis hingegen ist Teil eines Programmcodes und kann so über diverse Schnittstellen vergleichsweise einfach ausgelesen beziehungsweise rekonstruiert werden. Ein sicherer Einsatz eines solchen Geheimnisses in einer späteren Produktivphase der Systemkomponente ist dann nicht möglich.
  • Zudem offenbart die US 2021/075607 A1 eine Schlüsselverwaltungsvorrichtung und einen Prozessorchip zur Verschlüsselung und Entschlüsselung von Daten. Kryptografische Schlüssel werden dabei in einer Schlüsseldatenbank gespeichert. Mit Hilfe einer Nachschlagetabelle lassen sich bestimmte Schlüssel innerhalb der Schlüsseldatenbank anhand einer Schlüsselnummer finden. Einem Schlüssel lassen sich dabei innerhalb der Nachschlagetabelle Metadaten zuordnen. Mit Hilfe der Metadaten lassen sich Zustände von Randbedingungen beschreiben, bei denen ein jeweiliger Schlüssel verwendbar ist.
  • Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein verbessertes Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems anzugeben, welches eine besonders flexible sichere Implementierung und Nutzung von sich auf vielfältige Art und Weise unterscheidenden kryptografischen Materialen in verschiedenen Systemkomponenten erlaubt, und dabei gewährleistet, dass bei einer Systemkomponente, die selbst oder bei der wenigstens ein Untermodul in einem unsicheren Modus betrieben wird, für einen unsicheren Betrieb geeignetes kryptografisches Material von der Systemkomponente oder zumindest dem Untermodul verwendet wird und bei einer Systemkomponente, die selbst oder bei der wenigstens ein Untermodul in einem sicheren Modus betrieben wird, für einen sicheren Betrieb geeignetes kryptografisches Material von der Systemkomponente oder zumindest dem Untermodul verwendet wird.
  • Erfindungsgemäß wird diese Aufgabe durch ein Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Ansprüchen.
  • Bei einem Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems der eingangs genannten Art, weist das kryptografische Material Zusatzdaten auf, welche erfindungsgemäß von wenigstens einer Bedingung, wenigstens einer Rolle und/oder wenigstens einer Zielkomponentenidentität ausgebildet werden. Zudem werden sämtliche Bedingungen von einem zur Systemkomponente externen Ersteller definiert und von wenigstens einem in einer Umgebung der Systemkomponente ausgeführten Auswerter ausgewertet, wobei der Ersteller und der Auswerter gemeinsam festlegen, welche Variablen vom Ersteller bei der Definition genutzt werden dürfen.
  • Das erfindungsgemäße Verfahren erlaubt eine besonders flexible sichere Implementierung und Nutzung von kryptografischem Material in den unterschiedlichsten Systemkomponenten und/oder deren Untermodulen. So erfordern verschiedene Systemkomponenten wie ein Steuergerät, ein Cloud-Server, eine auf einem mobilen Endgerät ausgeführte Applikation, ein Fahrzeug oder ein externes Gerät zu verschiedenen Zeitpunkten die Verwendung verschiedenster kryptografischer Materiale, wie symmetrische oder asymmetrische Schlüssel, Zertifikate, Zufallszahlen, Hashwerte oder dergleichen. So kann eine bestimmte Ziel-Systemkomponente, welche kryptografisches Material verwenden soll, in verschiedenen Zuständen auch die Verwendung verschiedener kryptografischer Materiale erfordern. Der Zustand der jeweiligen Systemkomponente wird dabei mit Hilfe wenigstens einer Variablen beschrieben. Die entsprechende Systemkomponente kann eine Vielzahl unterschiedlicher Zustände annehmen, somit also auch mehr als zwei Zustände wie das Befinden in einer Entwicklungsphase oder einer Produktivphase eines Lebenszyklus aufweisen. Auch können sich einzelne Untermodule einer Systemkomponente in verschiedenen Lebenszyklusphasen bzw. Zuständen befinden. Beispielsweise kann sich eine Netzwerkschnittstelle in einem ersten, unsicheren Zustand, und ein Speicherelement der Systemkomponente in einem zweiten, sicheren Zustand befinden. Ein entsprechendes informationstechnisches System kann dabei vernetzt oder isoliert sein.
  • Kryptografisches Material wird typischerweise von einem dedizierten System, beispielsweise einem Kryptomaterial-Server, erzeugt und als Teil eines speziellen Datenpakets an ein Zielsystem, sprich eine Ziel-Systemkomponente, übertragen. Dabei wird erfindungsgemäß das kryptografische Material um Zusatzdaten ergänzt. Eine entsprechende Bedingung legt dabei fest, unter welchen Umständen das Verwenden des kryptografischen Materials von der Systemkomponente zulässig ist bzw. nicht zulässig ist. Die entsprechenden Bedingungen können vielfältigster Natur sein. Beispielsweise kann mit der Bedingung gefordert werden, dass sich die jeweilige Systemkomponente in einem bestimmten Abschnitt eines Produktlebenszyklus befindet, oder dass die Systemkomponente ein Hardwaresicherheitsmodul aufweist, und, dass sich dieses in einem sicheren Zustand befindet, sodass das Hardwaresicherheitsmodul auf sichere Weise kryptografisches Material aufnehmen und ablegen kann. Das kryptografische Material kann dabei auch mehrere Bedingungen umfassen. Hierdurch kann die Implementierung und Nutzung von kryptografischem Material bei verschiedenen Systemkomponenten in einer noch größeren Anzahl unterschiedlicher Einsatzszenarien gesteuert werden.
  • Für eine Systemkomponente vorgesehenes kryptografisches Material erfüllt dort eine bestimmte Rolle. Werden von der gleichen Systemkomponente mehrere kryptografische Materiale der gleichen Art verwendet, beispielsweise mehrere öffentliche 4096-Bit-RSA-Schlüssel, so kann die Systemkomponente selbst nicht unterscheiden, welche Rolle das neue kryptografische Material spielen soll, also beispielsweise wie und wo es in der Systemkomponente zu installieren und wie es zu verwenden ist. Diese, die Rolle des kryptografischen Materials betreffende Information, kann in Form der Rolle an das kryptografische Material angehängt werden. Die Rolle unterscheidet sich dabei von der Bedingung derart, dass die Rolle keine Bedingung an den aktuellen Zustand der Systemkomponente stellt.
  • Zur besonders effizienten Unterscheidung in welcher Systemkomponente kryptografisches Material verwendet werden darf, kann das kryptografische Material mit einer Zielkomponentenidentität ergänzt werden. Die Zielkomponentenidentität umfasst dabei eine eindeutige Kennzeichnung der Systemkomponenten, welche das entsprechende kryptografische Material verwenden dürfen. Wird das entsprechende kryptografische Material auf eine Systemkomponente aufgebracht, welche nicht in der Zielkomponentenidentität umfasst ist, so wird die Verwendung des kryptografischen Materials auf dieser Systemkomponente unterbunden. Hierdurch lässt sich besonders einfach und schnell Vorsehen, welche Systemkomponenten welches kryptografische Material verwenden dürfen und welche nicht.
  • Die Zielkomponentenidentität kann dabei sowohl auf eine gesamte Klasse von Systemen, Systemkomponenten und/oder deren Untermodule gerichtet sein, also beispielsweise auf die Klasse "Head-Unit", "Motorsteuergerät", "Flash-Speicher" oder dergleichen, sowie auf genau eine spezielle Systemkomponente, beispielsweise das Hardwaresicherheitsmodul mit der Seriennummer "GHNS-1934952".
  • Mit Hilfe der wenigstens einen Bedingung, wenigstens einen Rolle und/oder wenigstens einer Zielkomponentenidentität lässt sich somit sehr effizient und flexibel steuern, welches kryptografische Material in welchen Einsatzszenarien, sprich in welchen Zuständen von welcher Systemkomponente und/oder deren Untermodulen, verwendet werden darf und welches nicht.
  • Das kryptografische Material wird typischerweise als Kryptomaterial-(Daten)Paket ausgebildet und zwischen Systemen bzw. Systemkomponenten ausgetauscht bzw. dort eingebracht. Das Kryptomaterial-Paket umfasst dabei wenigstens das eigentliche kryptografische Material, also beispielsweise ein asymmetrisches Schlüsselpaar, und die jeweilige Bedingung, Rolle und/oder Zielkomponentenidentität in Form von an das kryptografische Material angehängter Zusatzdaten. Hierzu können die angehängten Daten beispielsweise mit dem kryptografischen Material konkateniert sein. Auch kann das Kryptomaterial-Paket weitere Daten umfassen. Der Einfachheit halber wird im vorliegenden Text nur vom kryptografischen Material gesprochen.
  • Der Ersteller und der Auswerter können einen festen Satz möglicher Variablen nutzen und bedingungsabhängig passende Variablen auswählen. Der Ersteller wählt dabei für jede Bedingung passende Variablen aus. Ebenso wird die Anzahl und die Art der Bedingungen vom Ersteller bestimmt. Der für die jeweiligen Variablen verwendete Name und zulässige Wertebereich wird dann gemeinsam von Ersteller und Auswerter festgelegt, wobei der Auswerter bestimmt, welche Namen und Wertebereiche der Ersteller verwenden darf. Der Ersteller entscheidet allerdings selbst, welche Namen und Wertebereiche er dann letztendlich verwendet.
  • Bei dem Ersteller handelt es sich beispielsweise um den bereits erwähnten Kryptomaterial-Server. Der Auswerter kann von Hard- und Software ausgebildet sein oder auch von einem Menschen. Der Auswerter kann von der Systemkomponente umfasst sein oder aber auch extern zur Systemkomponente ausgeführt sein, jedoch in einer selben Umgebung wie die Systemkomponente vorgesehen sein. Dies ermöglicht es dem Auswerter, die der Systemkomponente zugrundeliegenden und den entsprechenden Zustand der Systemkomponente beschreibenden Variablen zu erfassen. Ein systemkomponentenexterner Auswerter ermöglicht das Überprüfen der mittels des kryptografischen Materials an die Systemkomponente gestellten Bedingung(en) bei einer noch nicht gebooteten Systemkomponente. So lässt sich beispielsweise ohne ein vorheriges Hochfahren der entsprechenden Systemkomponente in einem Speicher der Systemkomponente entsprechendes überprüftes kryptografisches Material abspeichern.
  • Der Auswerter ist insbesondere dazu in der Lage, zu jedem beliebigen Zeitpunkt zu überprüfen, ob eine etwaige Bedingung für die jeweilige Systemkomponente erfüllt ist oder nicht. Indem sich der Ersteller und der Auswerter auf einen gemeinsamen Satz relevanter Variablen einigen, kann sichergestellt werden, dass die zur Auswertung einer bestimmten Bedingung benötigten Variablen vom Auswerter auch tatsächlich erfasst werden können. Dies erhöht die Zuverlässigkeit in der Anwendung des erfindungsgemäßen Verfahrens.
  • Eine vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht vor, dass das kryptografische Material wenigstens eine zielkomponentenspezifische Rolle umfasst. Wird ein und dasselbe kryptografische Material an verschiedene Systemkomponenten verschickt, so kann es auf den verschiedenen Systemkomponenten auch verschiedene Rollen erfüllen. So lassen sich in das kryptografische Material zielkomponentenspezifische Rollen einbringen, welche dem kryptografischen Material mitteilen, auf welcher Systemkomponente es wie genutzt werden soll. Hierdurch lässt sich noch umfangreicher und flexibler steuern, wie kryptografisches Material auf verschiedene Systemkomponenten implementiert und dort genutzt wird.
  • Eine weitere vorteilhafte Ausgestaltung des Verfahrens sieht ferner vor, dass wenigstens eine Variable einen der folgenden Wertebereiche aufweist:
    • BOOLEAN;
    • INTEGER; oder
    • STRING.
  • Dabei können alle Variablen denselben Wertebereich aufweisen, sprich vom Typ BOOLEAN, INTEGER oder STRING sein, oder aber es können auch einzelne Variablen verschiedene Wertebereiche aufweisen. Durch die Verwendung der unterschiedlichen Wertebereiche bzw. Typen lassen sich die unterschiedlichsten Variablen zur Definition und nachfolgenden Überprüfung von Bedingungen verwenden.
  • Entsprechend nimmt eine Variable vom Typ BOOLEAN den Wert TRUE oder FALSE an. Mit Hilfe der Wertebereiche INTEGER und STRING lassen sich Zustände noch detaillierter beziehungsweise vielschichtiger beschreiben. So kann ein bestimmter Zustand beispielsweise mit Hilfe von Zahlen und/oder auch Zeichenketten beschrieben werden.
  • Ein Wertebereich kann beispielsweise von 1 bis 10 reichen. Die zur Definition eines Zustands verwendeten Variablen können beispielsweise in Form eines Vektors vorliegen. Der Vektor kann beispielsweise eine erste Variable vom Typ BOOLEAN und eine zweite Variable vom Typ INTEGER umfassen. Dieser Variablenvektor ist zeitabhängig. Zu einem bestimmten Zeitpunkt kann beispielsweise die erste Variable den Wert TRUE annehmen und die zweite Variable den Wert 24 aufweisen. Damit kann eine Bedingung für jede Systemkomponente durch den Auswerter, dessen Umgebung sich zu einem bestimmten Zeitpunkt t in einem eindeutigen durch die aktuellen Werte der Variablen beschriebenen Zustand befindet, ausgewertet werden, also darauf überprüft werden, ob die Variablen zu dem Zeitpunkt t die definierten Bedingungen erfüllen oder nicht. Der entsprechende Variablenvektor kann dabei auch wenigstens ein leeres Element umfassen. Dies ist beispielsweise der Fall, wenn der Auswerter eine bestimmte Variable nicht erfassen kann. Anstelle eines leeren Elements kann auch ein Platzhalter verwendet werden, wie beispielsweise die Zahl "0", "9999" oder eine Zeichenkette wie "NAN".
  • Ebenso können Variablen von einem strukturierten Typ sein, beispielsweise können Variablen ein:
    • ARRAY oder ein
    • RECORD sein,
    wobei strukturierte Typen sowohl aus unstrukturierten als auch aus strukturierten Typen gebildet werden können.
  • Entsprechend einer weiteren vorteilhaften Ausgestaltung des Verfahrens ist wenigstens eine Bedingung zielkomponentenspezifisch und/oder operationsspezifisch definiert. So kann das kryptografische Material zur Durchführung verschiedener Operationen wie das Installieren von Software, Ver- oder Entschlüssen von bestimmten Daten, Erstellen oder Prüfen einer Signatur oder dergleichen verwendet und/oder von verschiedenen Systemkomponenten verwendet werden. Damit der Ersteller eine Bedingung als operationsspezifisch, also nur für eine bestimmte Operation geltend, kennzeichnen kann, muss, analog zur Menge der nutzbaren Zustandsvariablen, eine Menge von innerhalb der Systemkomponente bekannten Operationen dem Ersteller mitgeteilt werden, damit dieser diese bei der Definition von Bedingungen nutzen kann. Diese Menge von Operationen kann dabei allgemein, also für alle Zielkomponenten gültig, oder zielkomponentenspezifisch sein.
  • Damit eine bestimmte Bedingung auf unterschiedlichen Systemkomponenten und/oder bei der Durchführung unterschiedlicher Operationen als erfüllt gilt, kann es der Fall sein, dass für wenigstens zwei verschiedene Systemkomponenten und/oder Operationen eine bestimmte Variable einen unterschiedlichen Wert, also einmal TRUE und einmal FALSE, oder einmal 0 und einmal 256 annehmen muss.
  • Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass für eine zielkomponentenspezifische und/oder operationsspezifische Bedingung auf einer unterschiedlichen Ziel-Systemkomponente und/oder bei einer unterschiedlichen Operation wenigstens eine unterschiedliche Variable verwendet wird. So kann nicht nur eine bestimmte Variable zur Erfüllung einer Bedingung auf unterschiedlichen Systemkomponenten und/oder zur Durchführung unterschiedlicher Operationen verschiedene Werte annehmen, sondern es können hierzu auch unterschiedliche Variablen erforderlich sein. Insbesondere kann sich dabei die Menge und/oder Typ sowie eine Größe eines zulässigen Wertebereichs der für eine Bedingung relevanten Variablen zwischen unterschiedlichen Systemkomponenten und/oder Operationen unterscheiden. Beispielsweise müssen zur Erfüllung einer Bedingung auf einer ersten Systemkomponente die Variablen 1 und 2 die Werte 0 und TRUE annehmen und auf einer zweiten Systemkomponente die Variablen 1, 2 und 3 die Werte 0, TRUE und FALSE annehmen. Auf einer dritten Systemkomponente müssen zur Erfüllung der selben Bedingung hingegen die Variablen 1, 2, 3, 4, 5 und 6 die Werte TRUE, [0..100], [-100.. 100], 0, "engaged" und FALSE annehmen. Es können generell auch wenigstens zwei BOOLEAN-wertige Ausdrücke ODER verknüpft sein, worauf im Folgenden noch eingegangen wird.
  • Entsprechend einer weiteren vorteilhaften Ausgestaltung des Verfahrens überprüft ein Auswerter eine Bedingung mittels einer Auswertfunktion, wobei wenigstens zwei zueinander abweichende Auswerter eine zueinander abweichende Auswertfunktion nutzen, insbesondere eine operationsspezifische Auswertfunktion. Generell ist es möglich, dass sämtliche Auswerter dieselbe Auswertfunktion nutzen. Durch das Vorsehen verschiedener Auswertfunktionen wird jedoch eine Flexibilität in der Durchführung des erfindungsgemäßen Verfahrens zur Steuerung, unter welchen Bedingungen kryptografisches Material von Systemkomponenten eingesetzt wird, erhöht.
  • So kann generell auch eine generische Auswertfunktion verwendet werden, wodurch sämtliches kryptografische Material, beziehungsweise die vom kryptografischen Material umfassten Bedingungen, durch das Vorsehen lediglich einer Funktion ausgewertet werden kann. Die Auswertfunktion kann jedoch auch spezifisch für verschiedene kryptografische Materiale, beispielsweise je nach Rolle des kryptografischen Materials, ausgeführt sein. Insbesondere wird dabei noch einmal für verschiedene Auswertfunktionen für verschiedene Operationen unterschieden.
  • Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass wenigstens eine Bedingung in einer maschinell verarbeitbaren Definitionssprache definiert ist, wobei eine durch einen Interpreter interpretierbare ausführbare Sprache oder eine der folgenden formalen Logiken verwendet wird:
    • Aussagenlogik;
    • Aussagenlogik mit Relationen; oder
    • Aussagenlogik mit Relationen und Funktionen.
  • Die Definition der Bedingung in einer maschinell verarbeitbaren Definitionssprache ermöglicht die Verwendung bestehender Sprachen zur Durchführung des erfindungsgemäßen Verfahrens. Unter Verwendung einer auswertbaren Definitionssprache lassen sich Bedingungen über den geltenden, einen Zustand der Systemkomponente beschreibenden Variablen, beispielsweise als mittels der Definitionssprache definierte und verarbeitbare BOOLEAN-wertige Ausdrücke, formulieren. Weist das kryptografische Material mehrere Bedingungen auf, so kann ein für die entsprechende Bedingung relevanter Variablensatz auch unterschiedliche Variablen enthalten. Dabei können alle Variablen eines entsprechenden Variablensatzes vom gleichen Typ sein, sprich BOOLEAN, INTEGER oder STRING, oder sich auch wenigstens zwei Variablen eines für eine jeweilige Bedingung relevanten Variablensatzes in ihrem Typ unterscheiden. Auch können für verschiedene vom kryptografischen Material umfasste Bedingungen dieselben oder verschiedene maschinell verarbeitbare Definitionssprachen gemischt verwendet werden.
  • Bei der bekannten Aussagenlogik haben alle für eine bestimmte Bedingung relevanten Variablen den Wertebereich BOOLEAN. Die einzelnen Variablen können also nur die Werte TRUE oder FALSE annehmen. Logische Formeln werden mit Hilfe von bekannten aussagenlogischen Junktoren, sprich "∧", "∨", "¬" oder dergleichen, sowie Klammern "(" ")" gebildet. Beispiele von aussagenlogischen Formeln sind:
    • Variable1;
    • Variable2 ∧ TRUE;
    • (Variable1 ∧ (Variable2 ∨ Variables)).
  • Bei Aussagenlogik mit Relationen können für eine bestimmte Bedingung relevante Variablen verschiedene Wertebereiche haben. Es existiert eine endliche Menge von Relationen, wobei jeder Relation eine feste Stelligkeit zugeordnet ist, sowie jeder Relation und der Stelle ein fester Wertebereich zugeordnet ist. Ein relationaler Term ergibt sich dann durch die Anwendung einer Relation auf eine der Stelligkeit entsprechende Anzahl von Konstanten und/oder Variablen mit den passenden Wertebereichen. Bei der Auswertung eines relationalen Terms für eine feste vorgegebene Wertebelegung der in diesem Term vorkommenden Variablen ergibt sich immer ein Boolescher Wert, also TRUE oder FALSE. Ein Beispiel für eine zweistellige Relation, die beispielsweise in beiden Stellen INTEGER als Wertebereich erfordert, ist die kleiner-gleich-Relation "≤", auf dieser Relation basierende relationale Terme wären beispielsweise:
    • Variable1 ≤ Variable2;
    • 7 ≤ Variable3.
  • Logische Formeln werden mit Hilfe von BOOLEAN-Konstanten, BOOLEAN-Variablen, relationalen Termen und bekannten aussagenlogischen Junktoren ∧, v, ¬ etc. sowie Klammern "(" und ")" zur Festlegung der Auswertungsreihenfolge gebildet. Ein Beispiel für eine aussagenlogische Formel mit Relationen, das die zweitstelligen Relationen "≤" und "=" verwendet, ist: Variable1 ∧ Variable2 ≤ Variable3 ∨ Variable3 = Variable4 .
    Figure imgb0001
  • Bei Aussagenlogik mit Relationen und Funktionen wird zusätzlich eine endliche Menge von Funktionen verwendet, wobei jeder Funktion eine feste Stelligkeit zugeordnet ist, sowie jeder Funktion und jeder Stelle ein fester Wertebereich zugeordnet ist. Außerdem ist für jede Funktion der Wertebereich des Ergebnisses definiert. Eine Funktion wird dann auf eine der Stelligkeit entsprechende Anzahl von Konstanten, Variablen und/oder Funktionen mit den passenden Wertebereichen angewendet und liefert einen Wert aus dem vorgegebenen Ergebnis-Wertebereich. Ein Beispiel für eine zweistellige Funktion, die beispielsweise in beiden Stellen INTEGER als Wertebereich erfordert und einen INTEGER-Wert als Ergebnis liefert, ist die Addition "+". Logische Formeln werden wie bei der Aussagenlogik mit Relationen gebildet, mit dem Unterschied, dass relationale Terme nicht nur durch Anwendung von Relationen auf Konstanten und/oder Variablen, sondern auch auf Konstanten/Variablen angewendete Funktionen mit entsprechendem Ergebnis-Wertebereich gebildet werden können. Ein Beispiel für eine aussagenlogische Formel mit Relationen und Funktionen ist: (Variable1 ∧ ((Variable2 ≤ (Variable3 + Variable7)) v (((Variable3 - Variables) + Variable2) = Variable4))).
  • Insbesondere die Verwendung einer durch einen Interpreter interpretierbaren ausführbaren Sprache hingegen bietet Vorteile. Solche Sprachen sind aufgrund der Ausführbarkeit sehr "mächtig". So ist vor Ausführung eines entsprechenden Programmcodes keine vorherige Übersetzung/Kompilierung, beziehungsweise Transformation in einen Formelbaum und Einsetzen von Variablenwerten, notwendig. Bei einer interpretierbaren ausführbaren Sprache kann es sich beispielsweise um eine Skriptsprache wie Python handeln.
  • Entsprechend einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens werden wenigstens zwei Bedingungen in einer zueinander abweichenden Definitionssprache formuliert, insbesondere werden zwei zielkomponentenspezifische Bedingungen in einer zueinander abweichenden Definitionssprache formuliert. Verwendet eine erste Systemkomponente eine erste Sprache und eine zweite Systemkomponente eine zweite, zur ersten Sprache abweichende Sprache, so wird durch das Vorsehen zweier mit verschiedenen Definitionssprachen formulierter Bedingungen sichergestellt, dass beide Systemkomponenten die für sie relevante Bedingung auch auswerten können. Entsprechend sind auch die für die Bedingungen relevanten Variablen in der jeweiligen Definitionssprache formuliert. Es ist auch möglich, dass zwei für dieselbe Systemkomponente gültige Bedingungen in einer zueinander abweichenden Definitionssprache formuliert werden. So kann es vorteilhaft sein, eine bestimmte Bedingung mit einer bestimmten Definitionssprache zu formulieren. Dies ist beispielsweise der Fall, wenn das Erfassen und/oder Verarbeiten bestimmter Variablen nur mit einer bestimmten Definitionssprache möglich ist bzw. dies aufgrund verschiedenster Randbedingungen vorgegeben ist.
  • Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass das kryptografische Material wenigstens zwei Bedingungen umfasst und sämtliche Bedingungen erfüllt sein müssen, damit das kryptografische Material von der Systemkomponente verwendet wird. Rückbezogen auf die Verwendung formaler Logiken bedeutet dies, dass die verwendeten Bedingungen UND-verknüpft sind. So müssen alle Bedingungen erfüllt sein, damit das kryptografische Material von der Systemkomponente verwendet wird. So ist das Erfüllen einer einzelnen Bedingung zur Anwendung des kryptografischen Materials von der Systemkomponente notwendig, aber nicht notwendigerweise hinreichend, da wenigstens eine weitere Bedingung erfüllt werden muss.
  • Entsprechend einer weiteren vorteilhaften Ausgestaltung des Verfahrens liefert der Auswerter, wenn von einer Systemkomponente kryptografisches Material verwendet werden soll, dessen zielkomponentenspezifische Bedingung die Klasse der entsprechende Systemkomponente nicht umfasst, wenn durch Nutzung des kryptografischen Materials eine Operation durchzuführen ist, welche nicht von einer operationsspezifischen Bedingung umfasst ist oder wenn ein Auswerter eine zur Überprüfung eines Zustands erforderliche Variable nicht erfassen kann, für die jeweilige Bedingung standardmäßig die folgende Antwort:
    • TRUE;
    • FALSE; oder
    • eine als Standardantwort an das kryptografische Material angehängte Antwort.
  • Hierdurch wird eine noch zuverlässigere Umsetzung des erfindungsgemäßen Verfahrens gewährleistet. So kann generell eine Systemkomponente, beziehungsweise eine Klasse der Systemkomponente, von der bestimmte kryptografische Materiale verwendet werden sollen, nicht in eine zielkomponentenspezifische Bedingung inkludiert sein. Damit trotzdem von der entsprechenden Systemkomponente das kryptografische Material angewendet werden kann, wird standardmäßig nach der Überprüfung der zielkomponentenspezifischen Bedingung der Wert TRUE ausgegeben. Soll stattdessen in einem solchen Fall die Anwendung des kryptografischen Materials unterbunden werden, wird standardmäßig der Wert FALSE ausgegeben. Zur Erhöhung der Flexibilität des erfindungsgemäßen Verfahrens kann auch die Standardantwort in Form von TRUE oder FALSE an das kryptografische Material angehängt werden. Hierdurch lässt sich das Risiko senken, dass auf einer Systemkomponente, deren Standardantwort auf TRUE gesetzt ist, das kryptografische Material angewendet wird, obwohl dies eigentlich nicht der Fall sein sollte. So wird in diesem Falle die Standardantwort in Form von FALSE an das kryptografische Material angehängt.
  • Die im vorigen getätigten Formulierungen gelten entsprechend für eine operationsspezifische Bedingung, sowie für den Fall, dass ein Auswerter eine zur Überprüfung einer bestimmten Bedingung erforderliche Variable nicht erfassen kann.
  • Eine weitere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht ferner vor, dass sämtliche vom kryptografischen Material umfassten Zusatzdaten kryptografisch gegen eine Kompromittierung abgesichert werden, insbesondere unter Verwendung wenigstens einer digitalen Signatur und/oder eines symmetrischen Integritätsschutzmechanismus. Als symmetrischer Integritätsschutzmechanismus kann insbesondere ein Keyed-Hash Message Authentication Code (HMAC) verwendet werden. Das Absichern des kryptografischen Materials gegen Kompromittierung erhöht den Schutz bei der Durchführung des erfindungsgemäßen Verfahrens noch weiter. So werden die neben dem kryptografischen Material an das Kryptomaterial-Paket angehängten Zusatzdaten gegen unbefugte Manipulation geschützt. Beispielsweise kann das kryptografische Material samt den dazugehörigen Zusatzdaten beispielsweise vom Ersteller mit Hilfe seines asymmetrischen privaten Schlüssels digital signiert werden. Insbesondere werden zum Signieren sichere Verfahren und sichere Systeme genutzt. Der öffentliche Schlüssel oder ein den öffentlichen Schlüssel enthaltendes Zertifikat wird dann an alle betroffenen Auswerter verteilt. In den entsprechenden Systemen wird der entsprechende öffentliche Schlüssel bzw. das Zertifikat manipulationsgeschützt eingebracht. Beispielsweise wird der öffentliche Schlüssel bzw. das Zertifikat in einem schreibgeschützten Speicher (ROM) oder in einem nur einmalig beschreibbaren Speicher (WORM) abgespeichert. Entsprechend umfasst das Kryptomaterial-Paket eine solche digitale Signatur. Dementsprechend wird das kryptografische Material von der Systemkomponente nur dann verwendet, wenn eine Prüfung der an das kryptografische Material angehängten Signatur mit Hilfe des eingebrachten öffentlichen Schlüssels bzw. des Zertifikats ein positives Ergebnis liefert.
  • Entsprechend einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens erhalten wenigstens zwei unterschiedliche Akteure eine Berechtigung zum digitalen Signieren des kryptografischen Materials, wobei sämtliche zum Signieren berechtigte Akteure ihr eigenes zu einer gemeinsamen Zertifikatshierarchie gehörendes Blattzertifikat mit dem dazugehörigen privaten Schlüssel erhalten. So ist es insbesondere dann sinnvoll, mehreren Akteuren eine Berechtigung zum digitalen Signieren zu geben, wenn auch mehrere Akteure kryptografisches Material erstellen. Ein die Signatur durchführendes System signiert dann das entsprechende kryptografische Material mit dem zu seinem Blattzertifikat gehörendem privaten Schlüssel. Dem kryptografischen Material wird dann nicht nur die erzeugte Signatur, sondern auch die gesamte Zertifikatskette hinzugefügt. Die an das kryptografische Material angehängte Zertifikatskette wird dann von einem entsprechenden Auswerter bzw. einem den Auswerter umfassenden System genutzt, um die Korrektheit der vom signierenden System erstellen Signatur zu prüfen.
  • Handelt es sich bei dem kryptografischen Material bereits um ein digitales Zertifikat, so ist es von vorneherein signiert. Werden dann Zusatzdaten, sprich wenigstens eine Bedingung, Rolle und/oder Zielkomponentenidentität, in das Zertifikat aufgenommen, so werden diese vom Ersteller des Zertifikats mitsigniert. So lassen sich die Zusatzdaten, oder auch nur Teile davon, als eine oder mehrere Zertifikatserweiterungen in das entsprechende Zertifikat mit aufnehmen und somit mitsignieren. Werden alle Zusatzdaten in das Zertifikat mit aufgenommen, so kann auf die dedizierte Erstellung der digitalen Signatur des kryptografischen Materials verzichtet werden.
  • Zur Gewährung eines bestmöglichen Schutzes sollte das erfindungsgemäße Verfahren frühestmöglich bei der Entwicklung einer entsprechenden Systemkomponente verwendet werden. Da die Überprüfung der Bedingung durch den Auswerter von Variablen abhängig ist, sind diese Variablen bestmöglich vor einer Manipulation zu schützen, da korrumpierte Variablen das Vorliegen eines tatsächlich nicht existierenden Zustands vortäuschen können. Zur Bewertung einer Bedingung verwendete Konstanten werden dementsprechend bevorzugt in einem einmalig beschreibbaren Speicher wie einem WORM-Speicher abgelegt. Die Werte der Variablen, von denen die Bedingungen abhängen, werden bevorzugt während des gesamten Lebenszyklus des informationstechnischen Systems bzw. der einzelnen Systemkomponenten auf systematische Weise an den aktuellen Systemzustand angepasst.
  • Bevorzugt wird als informationstechnisches System ein Fahrzeug-Ökosystem genutzt. Generell kann das erfindungsgemäße Verfahren für verschiedene Systemkomponenten in verschiedenartigen vernetzten oder nicht-vernetzten informationstechnischen Systemen eingesetzt werden. Besonders effizient ist eine Nutzung dann, wenn das informationstechnische System ein Fahrzeug-Ökosystem ist, da hier die entsprechenden Anforderungen hinsichtlich einer aufwändigen Entwicklung mit vielen beteiligten Partnern das Einhalten von Sicherheitsrichtlinien in der Praxis häufig sehr schwierig macht. Durch die Implementierung des erfindungsgemäßen Verfahrens und damit einer Selbstüberprüfung durch die jeweilige Systemkomponente kann die Gefahr einer potenziellen Sicherheitslücke drastisch minimiert werden.
  • Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems ergeben sich auch aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben werden.
  • Dabei zeigen:
    • Fig. 1
    eine Prinzipdarstellung einer ersten Verwendung von kryptografischem Material auf einer Systemkomponente eines informationstechnischen Systems;
    Fig. 2
    eine Prinzipdarstellung einer Verwendung alternativen kryptografischen Materials auf der in Figur 1 gezeigten Systemkomponente;
    Fig. 3
    eine Prinzipdarstellung einer Verwendung alternativen kryptografischen Materials auf einer weiteren Systemkomponente; und
    Fig. 4
    ein Ablaufdiagramm einer beispielhaften Verarbeitung von kryptografischem Material auf einer Systemkomponente bei der Ausführung einer Operation.
  • Figur 1 zeigt ein erstes Ausführungsbeispiel zur Verwendung von kryptografischem Material KM von wenigstens einer Systemkomponente SK eines informationstechnischen Systems IT-S. Ein Zustand der Systemkomponente SK wird mittels wenigstens einer Variable VAR beschrieben. In dem Beispiel in Figur 1 wird die Menge aller Variablen VAR als VAR bezeichnet und die einzelne hier verwendete Zustandsvariable als "produktiv". Die Zustandsvariable produktiv zeigt an, ob sich die Systemkomponente SK in einer Produktivphase ihres Lebenszyklus befindet, also ein Produktivsystem ist, oder nicht. Bei dem kryptografischen Material KM handelt es sich um ein selbstsigniertes, zu einem Test-Root-Schlüsselpaar (TestRootPub, TestRootPriv) gehörendes Test-Root-Zertifikat TestRootCert, das ins Zielsystem als Vertrauensanker eingebracht wird, um damit Test-Verbindungen mit Kommunikationspartnern aufbauen zu können, indem die Vertrauenswürdigkeit der von Partnern empfangenen mit TestRootPriv signierten Zertifikate mit Hilfe von TestRootCert überprüft werden kann.
  • Das Zertifikat TestRootCert ist unter unsicheren Bedingungen erstellt worden, beispielsweise ist der private Schlüssel TestRootPriv nicht sicher abgelegt. Somit darf TestRootCert in Produktivsystemen nicht verwendet werden. Dementsprechend ist eine vom kryptografischen Material KM umfasste Bedingung BED als produktiv= FALSE definiert. Die Bedingung BED besagt, dass das Zertifikat TestRootCert vom Zielsystem, sprich der Systemkomponente SK, nur verwendet werden darf, wenn es sich nicht in der Produktivphase befindet.
  • Figur 2 zeigt ein ähnliches Ausführungsbeispiel, bei dem das kryptografische Material KM nun ein sicher erzeugtes, in Produktivsystemen sicher einsatzbares Zertifikat ProdRootCert umfasst. Entsprechend darf das Zertifikat ProdRootCert vom Zielsystem, sprich der Systemkomponente SK, immer, beispielsweise auch in der Entwicklungs- und in der Produktivphase, verwendet werden. ProdRootCert darf auch in der Entwicklungsphase verwendet werden, weil es keine geheimen Anteile enthält. Entsprechend ist die Bedingung BED auch nicht von der Zustandsvariable produktiv abhängig, sondern gilt immer als erfüllt (TRUE). Da die Bedingung BED von keiner Variablen VAR abhängt, könnte man auch eine leere Menge von Zustandsvariablen wählen, also BEDTestRootCert({}):=(TRUE) anstelle von BEDTestRootCert({produktiv}):=(TRUE).
  • Figur 3 zeigt ein weiteres Ausführungsbeispiel der Implementierung und Nutzung von kryptografischem Material KM in einer Systemkomponente SK. Die Systemkomponente SK weist hier zwei Zustandsvariablen auf, nämlich die beiden Elemente HSMProvisioningSicher: BOOLEAN, und HSMVerschlSicher: BOOLEAN der Menge an Variablen VAR. Die Menge an Variablen VAR entspricht hier einem Vektor mit zwei Elementen. Die Zustandsvariable HSMProvisioningSicher zeigt an, ob ein Hardwaresicherheitsmodul HSM bereits in einem Zustand ist, in dem es auf sichere Weise kryptografisches Material KM aufnehmen und ablegen kann. Die Zustandsvariable HSMVerschlSicher zeigt an, ob das Hardwaresicherheitsmodul HSM bereits in einem Zustand ist, in dem es auf sichere Weise in ihm abgelegte geheime Schlüssel für Verschlüsselung nutzen kann. Bei dem kryptografischen Material KM handelt es in Figur 3 um einen 256-Bit langen, geheimen symmetrischen Schlüssel AESKey, der für AES-Verschlüsselung in Produktivsystemen genutzt werden soll.
  • Zwei Operationen sollen durch Bedingungen BED abgesichert werden. Dabei handelt es sich zum einen um das Bereitstellen kryptografischen Materials KM, sprich das sichere Einbringen und sichere Ablegen eines Schlüssels in die Systemkomponente SK. Ferner handelt es sich um Verschlüsselung, das heißt die sichere Nutzung eines Schlüssels für die Verschlüsselung in der Systemkomponente SK. Die sichere Verwendung des Schlüssels im Zielsystem wird durch zwei Bedingungen BED BEDAESKey Provisioning und BEDAESKey Verschlüsselung sichergestellt. Die Bedingung BED BEDAESKey Provisioning besagt, dass der Schlüssel AESKey nur in das Zielsystem eingebracht werden darf, wenn HSMProvisioningSicher = TRUE gilt. Die Bedingung BED BEDAESKey Verschlüsselung besagt, dass der Schlüssel AESKey im Zielsystem nur dann für die Verschlüsselung genutzt werden darf, wenn HSMVerschlSicher = TRUE gilt.
  • Figur 4 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens. Dabei wird angenommen, dass ein Kryptomaterial-Paket KM-P folgende Form aufweist: KM-P = (KM, ZKIDENT,cnn, BEDKM*, ROLEKM*, Sign,cnn, ZK), wobei ZKIDENT,cnn die Gesamtheit der für das kryptografische Material KM erlaubten Zielkomponentenidentitäten ZKIDENTKM, BEDKM* die Gesamtheit der dem kryptografischen Material KM zugeordneten, gegebenenfalls zielkomponentenspezifischen und/oder operationsspezifischen Bedingungen BED, und ROLEKM* die Gesamtheit der gegebenenfalls zielkomponentenspezifischen Rollen ROLEKM* bezeichnet. Dabei kann auch wenigstens eine der genannten Größen ZKIDENTKM, BEDKM*, ROLEKM* im Kryptomaterial-Paket KM-P fehlen. SignKM ist die vom Ersteller des kryptografischen Materials KM erstellte Signatur von (KM, ZKIDENTKM, BEDKM*, ROLEKM*) und ZK ist die Zertifikatskette, mit deren Hilfe die Systemkomponente SK die Korrektheit der Signatur SignKM überprüfen kann. Zur eindeutigen Adressierung einer Systemkomponente SK wird des Weiteren angenommen, dass die Systemkomponente SK die Identität skid und den Zielsystemkomponenten-Typen Type(skid) aufweist. Beispielsweise können die Identität skid und der Zielsystemkomponenten Typ Type(skid) auf einer Systemkomponente SK in die Variablen VAR inkludiert sein. Ein Systemkomponententyp kann auch als Klasse von Systemkomponenten SK verstanden werden, also beispielsweise alle Systemkomponenten SK der Klasse/des Typs "Head-Unit", "Motorsteuergerät" oder dergleichen. Ferner wird angenommen, dass der Auswerter überprüfen will, ob das im Kryptomaterial-Paket KM-P enthaltene kryptografische Material KM in der Systemkomponente SK für eine Operation Prov in der Systemkomponente SK installiert werden darf. Bei der Operation kann es sich generell um eine beliebige Operation handeln, wie beispielsweise das Durchführen eines Entschlüsselungsvorgangs. In dem Beispiel in Figur 4 handelt es sich bei der Operation um das eigentliche Provisioning des kryptografischen Materials KM.
  • Zuerst erfolgt eine Prüfung der Signatur SignKM. Ist die Signaturprüfung nicht erfolgreich, so folgt gemäß einem ersten Link LINK1 eine Ausnahmebehandlung. Ist die Signaturprüfung hingegen erfolgreich, so wird überprüft, ob das kryptografische Material KM, hier in Form des Kryptomaterial-Pakets KM-P, wenigstens eine Zielkomponentenidentität ZKIDENTKM umfasst. Ist dies der Fall, so wird überprüft, ob die Identität skid der Systemkomponente SK von der Zielkomponentenidentität ZKIDENTKM umfasst ist, und falls nicht, gemäß des ersten Links LINK1 eine Ausnahmebehandlung eingeleitet. Ist dies hingegen nicht der Fall, umfasst das Kryptomaterial-Paket KM-P also keine Zielkomponentenidentität ZKIDENTKM, wird dieser Schritt übersprungen.
  • Anschließend wird überprüft, ob und ggf. welche Bedingungen BEDKM* im kryptografischen Material KM enthalten sind. Umfasst das Kryptomaterial-Paket KM-P keine Bedingung BEDKM*, so wird gemäß eines zweiten Links LINK2, der eine Installation des kryptografischen Materials KM bedeuten könnte, fortgefahren.
  • Anschließend wird untersucht, ob wenigstens eine Bedingung BEDKM* zielkomponentenspezifisch ist.
  • Ist dies nicht der Fall, so wird überprüft, ob wenigstens eine Bedingung BEDKM* operationsspezifisch ist.
  • Ist dies nicht der Fall, so wird die entsprechende Bedingung BEDKM ausgewertet und entsprechend des ersten oder zweiten Links LINK1, LINK2 fortgefahren.
  • Wird hingegen festgestellt, dass die wenigstens eine Bedingung BEDKM* operationsspezifisch ist, so erfolgt anschließend eine Prüfung, ob als Operation eine Bereitstellung des kryptografischen Materials KM vorgesehen ist, also ein Provisioning. Ist dies der Fall, so erfolgt eine Prüfung der operationsspezifischen Bedingung BEDKM Prov. Anschließend wird analog der Links LINK1, LINK2 fortgefahren.
  • Wurde hingegen wenigstes eine typspezifische Bedingung im Kryptomaterial-Paket KM-P erkannt, so wird überprüft, ob wenigstens eine der typspezifischen Bedingungen auch für eine ganze Klasse an Systemkomponenten SK gültig ist, also ob Type(skid) in BEDKM* enthalten ist. Die Menge der für die jeweilige durch Type(skid) referenzierte Klassen gültigen Bedingungen wird im Folgenden als BEDKM Type(skid)* bezeichnet. Ist dies der Fall, so darf ein Provisioning erfolgen (siehe erster Link LINK1). Ist dies nicht der Fall, muss überprüft werden, welches Standardverfahren angewendet werden soll. Also ob ein Provisioning erfolgen darf oder nicht. Hierzu kann beispielsweise eine Standardantwort in das Kryptomaterial-Paket KM-P inkludiert sein.
  • Anschließend wird überprüft, ob die typspezifische Bedingung BEDKM Type(skid)* auch zusätzlich operationsspezifisch ist. Ist das nicht der Fall, wird die Bedingung BEDKM Type(skid) ausgewertet und gemäß der Links LINK1, LINK2 fortgefahren. Sind die Bedingungen BEDKM Type(skid)* hingegen operationsspezifisch, wird überprüft, ob in BEDKM Type(skid)* wenigstens eine operationsspezifische Bedingung, hier als stellvertretendes Beispiel für die Operation Prov ("Provisioning"), also eine Bedingung BEDKM Type(skid), Prov, umfasst ist (dieser Schritt ist in Figur 4 nicht gezeigt). Ist dies nicht der Fall, wird gemäß des ersten Links LINK1 eine Ausnahmebehandlung eingeleitet. Ist dies hingegen der Fall, enthält BEDKM Type(skid)* also eine Bedingung BEDKM Type(skid), Prov, so wird diese ausgewertet und es wird analog der Links LINK1, LINK2 fortgefahren.
  • Nach Auswertung der einzelnen Bedingungen BEDKM, BEDKM Prov, BEDKM Type(skid) oder BEDKM Type(skid), Prov wird geprüft, ob das kryptografische Material KM, hier in Form des Kryptomaterial-Pakets KM-P, wenigstens eine Rolle ROLEKM* umfasst. Ist dies nicht der Fall, erfolgt eine Bereitstellung des kryptografischen Materials KM für die Systemkomponente SK ohne Rolle. Ist dies hingegen der Fall, so wird anschließend überprüft, ob ROLEKM* eine Rolle für den Zielkomponenten-Typen Type(skid) umfasst. Ist dies nicht der Fall, erfolgt erneut eine Ausnahmebehandlung. Ist dies hingegen der Fall, erfolgt die Bereitstellung des kryptografischen Materials KM unter Berücksichtigung der Rolle ROLEKM*.

Claims (13)

  1. Verfahren zur Implementierung und Nutzung von kryptografischem Material (KM) in wenigstens einer Systemkomponente (SK) eines informationstechnischen Systems (IT-S) zur Durchführung wenigstens einer Operation, wobei wenigstens zu einem ersten Zeitpunkt ein durch wenigstens eine Variable (VAR) beschriebener Zustand der Systemkomponente (SK) überprüft wird, das kryptografische Material (KM) um Zusatzdaten ergänzt wird, wobei die Zusatzdaten mögliche Zustände von Systemkomponenten (SK) beschreiben, und das kryptografische Material (KM) von der Systemkomponente (SK) verwendet wird, wenn die Zusatzdaten des kryptografischen Materials (KM) zumindest den Zustand umfassen, den die Systemkomponente (SK) zum ersten Zeitpunkt aufweist,
    dadurch gekennzeichnet, dass
    die Zusatzdaten von wenigstens einer Bedingung (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov), wenigstens einer Rolle (ROLEKM*) und/oder wenigstens einer Zielkomponentenidentität (ZKIDENTKM) ausgebildet werden; und sämtliche Bedingungen (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov) von einem zur Systemkomponente (SK) externen Ersteller definiert und von wenigstens einem in einer Umgebung der Systemkomponente (SK) ausgeführten Auswerter ausgewertet werden, wobei der Ersteller und der Auswerter gemeinsam festlegen, welche Variablen (VAR) vom Ersteller bei der Definition genutzt werden dürfen.
  2. Verfahren nach Anspruch 1,
    dadurch gekennzeichnet, dass
    das kryptografische Material (KM) wenigstens eine zielkomponentenspezifische Rolle (ROLEKM*) umfasst.
  3. Verfahren nach einem der Ansprüche 1 oder 2,
    dadurch gekennzeichnet, dass
    wenigstens eine Variable (VAR) einen der folgenden Wertebereiche aufweist:
    - BOOLEAN;
    - INTEGER; oder
    - STRING.
  4. Verfahren nach einem der Ansprüche 1 bis 3,
    dadurch gekennzeichnet, dass
    wenigstens eine Bedingung (BEDKM Prov , BEDKM Type(skid), BEDKM Type(skid), Prov) zielkomponentenspezifisch und/oder operationsspezifisch definiert ist.
  5. Verfahren nach Anspruch 4,
    dadurch gekennzeichnet, dass
    für eine zielkomponentenspezifische und/oder operationsspezifische Bedingung (BEDKM Prov, BEDKM Type(skid) BEDKM Type(skid), Prov) auf einer unterschiedlichen Zielkomponente und/oder bei einer unterschiedlichen Operation wenigstens eine unterschiedliche Variable (VAR) verwendet wird.
  6. Verfahren nach einem der Ansprüche 1 bis 5,
    dadurch gekennzeichnet, dass
    ein Auswerter eine Bedingung (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid),
    BEDKM Type(skid), Prov) mittels einer Auswertfunktion überprüft, wobei wenigstens zwei zueinander abweichende Auswerter eine zueinander abweichende Auswertfunktion nutzen, insbesondere eine operationsspezifische Auswertfunktion.
  7. Verfahren nach einem der Ansprüche 1 bis 6,
    dadurch gekennzeichnet, dass
    wenigstens eine Bedingung (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov) in einer maschinell verarbeitbaren Definitionssprache definiert ist, wobei eine durch einen Interpreter interpretierbare ausführbare Sprache oder eine der folgenden formalen Logiken verwendet wird:
    - Aussagenlogik;
    - Aussagenlogik mit Relationen; oder
    - Aussagenlogik mit Relationen und Funktionen.
  8. Verfahren nach Anspruch 7,
    dadurch gekennzeichnet, dass
    wenigstens zwei Bedingungen (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid),
    BEDKM Type(skid), Prov) in einer zueinander abweichenden Definitionssprache formuliert werden, insbesondere zwei zielkomponentenspezifische Bedingungen (BEDKM Type(skid), BEDKM Type(skid), Prov).
  9. Verfahren nach einem der Ansprüche 7 oder 8,
    dadurch gekennzeichnet, dass
    das kryptografische Material (KM) wenigstens zwei Bedingungen (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov) umfasst und sämtliche Bedingungen (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov) erfüllt sein müssen, damit das kryptografische Material (KM) von der Systemkomponente (SK) verwendet wird.
  10. Verfahren nach einem der Ansprüche 4 bis 9,
    dadurch gekennzeichnet, dass
    wenn auf einer Systemkomponente (SK) kryptografisches Material (KM) verwendet werden soll dessen zielkomponentenspezifische Bedingung (BEDKM Type(skid), BEDKM Type(skid), Prov) die Klasse der entsprechende Systemkomponente (SK) nicht umfasst, wenn durch Nutzung des kryptografischen Materials (KM) eine Operation durchzuführen ist, welche nicht von einer operationsspezifischen Bedingung (BEDKM Prov, BEDKM Type(skid), Prov) umfasst ist oder wenn ein Auswerter eine zur Überprüfung eines Zustands erforderliche Variable (VAR) nicht erfassen kann, der Auswerter für die jeweilige Bedingung (BED, BEDKM*, BEDKM Prov, BEDKM Type(skid), BEDKM Type(skid), Prov) standardmäßig die folgende Antwort liefert:
    - TRUE;
    - FALSE; oder
    - eine als Standardantwort an das kryptografische Material (KM) angehängte Antwort.
  11. Verfahren nach einem der Ansprüche 1 bis 10,
    dadurch gekennzeichnet, dass
    sämtliche vom kryptografischen Material (KM) umfassten Zusatzdaten kryptografisch gegen eine Kompromittierung abgesichert werden, insbesondere unter Verwendung wenigstens einer digitalen Signatur und/oder eines symmetrischen Integritätsschutzmechanismus.
  12. Verfahren nach Anspruch 11,
    dadurch gekennzeichnet, dass
    wenigstens zwei unterschiedliche Akteure eine Berechtigung zum digitalen Signieren des kryptografischen Materials (KM) erhalten, wobei sämtliche zum Signieren berechtigte Akteure die jeweils ihnen zugeordneten individuellen privaten Schlüssel samt den dazugehörigen individuellen Blattzertifikaten und die dazugehörige Zertifikatskette erhalten.
  13. Verfahren nach einem der Ansprüche 1 bis 12,
    dadurch gekennzeichnet, dass
    als informationstechnisches System (IT-S) ein Fahrzeug-Ökosystem genutzt wird.
EP23209295.7A 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems Active EP4297332B1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102021004427.4A DE102021004427B4 (de) 2021-08-31 2021-08-31 Verfahren zur lmplementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
EP22761462.5A EP4205005A1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
PCT/EP2022/071725 WO2023030811A1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
EP22761462.5A Division EP4205005A1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems

Publications (4)

Publication Number Publication Date
EP4297332A2 EP4297332A2 (de) 2023-12-27
EP4297332A3 EP4297332A3 (de) 2024-03-13
EP4297332B1 true EP4297332B1 (de) 2025-01-15
EP4297332C0 EP4297332C0 (de) 2025-01-15

Family

ID=83149023

Family Applications (5)

Application Number Title Priority Date Filing Date
EP22761462.5A Withdrawn EP4205005A1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209296.5A Active EP4297333B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209298.1A Active EP4297335B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209295.7A Active EP4297332B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209297.3A Active EP4297334B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems

Family Applications Before (3)

Application Number Title Priority Date Filing Date
EP22761462.5A Withdrawn EP4205005A1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209296.5A Active EP4297333B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP23209298.1A Active EP4297335B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP23209297.3A Active EP4297334B1 (de) 2021-08-31 2022-08-02 Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems

Country Status (7)

Country Link
US (1) US12418414B2 (de)
EP (5) EP4205005A1 (de)
JP (4) JP7716580B2 (de)
KR (1) KR20240038749A (de)
CN (1) CN117882072A (de)
DE (1) DE102021004427B4 (de)
WO (1) WO2023030811A1 (de)

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7228420B2 (en) * 2002-06-28 2007-06-05 Temic Automotive Of North America, Inc. Method and system for technician authentication of a vehicle
US7131005B2 (en) * 2002-06-28 2006-10-31 Motorola, Inc. Method and system for component authentication of a vehicle
EP1637954A1 (de) * 2004-09-15 2006-03-22 Ubs Ag Erzeugung anonymisierter Datensätze aus produktiven Anwendungen
US8621654B2 (en) * 2009-09-15 2013-12-31 Symantec Corporation Using metadata in security tokens to prevent coordinated gaming in a reputation system
DE102010011657A1 (de) * 2010-03-17 2011-09-22 Siemens Aktiengesellschaft Verfahren und Vorrichtung zum Bereitstellen mindestens eines sicheren kryptographischen Schlüssels
EP2819057B1 (de) * 2013-06-24 2017-08-09 Nxp B.V. Datenverarbeitungssystem, Verfahren zur Initialisierung eines Datenverarbeitungssystems und Computerprogrammprodukt
CN105117665B (zh) * 2015-07-16 2017-10-31 福建联迪商用设备有限公司 一种终端产品模式与开发模式安全切换的方法及系统
JP6743536B2 (ja) * 2016-07-12 2020-08-19 株式会社リコー 情報処理システム、情報処理装置、情報処理方法、及びプログラム
CN109417480A (zh) * 2016-06-17 2019-03-01 Kddi株式会社 系统、认证站、车载计算机、车辆、公开密钥证书发行方法以及程序
EP3261013A1 (de) * 2016-06-24 2017-12-27 Gemalto Sa Sicheres kryptographische scripting um kryptografisches funktionen anzupassen
US20190068361A1 (en) * 2017-08-30 2019-02-28 Ford Global Technologies, Llc In-vehicle group key distribution
JP7132132B2 (ja) * 2019-01-09 2022-09-06 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、コンピュータプログラム、通信制御方法及び通信方法
DE102019003904A1 (de) 2019-06-03 2020-12-03 Daimler Ag System zur Erzeugung von kryptografischem Material
CN112422595B (zh) * 2019-08-20 2022-10-11 华为技术有限公司 车载系统安全保护方法及设备
DE102019212959B3 (de) 2019-08-28 2021-03-04 Volkswagen Aktiengesellschaft Verfahren zur geschützten Kommunikation eines Fahrzeugs mit einem externen Server, Vorrichtung zur Durchführung der Schlüsselableitung bei dem Verfahren sowie Fahrzeug
TWI705687B (zh) * 2019-09-09 2020-09-21 新唐科技股份有限公司 用於資料加解密的金鑰管理裝置及處理器晶片
CA3166439A1 (en) * 2020-01-03 2021-07-08 Battelle Memorial Institute Blockchain cybersecurity solutions
DE102020003072B3 (de) 2020-05-22 2021-07-15 Daimler Ag Verfahren zur sicheren Nutzung von kryptografischem Material
US11659005B2 (en) * 2020-12-16 2023-05-23 Dell Products, L.P. Systems and methods for self-protecting and self-refreshing workspaces

Also Published As

Publication number Publication date
JP2025143382A (ja) 2025-10-01
JP2024536707A (ja) 2024-10-08
EP4297332A3 (de) 2024-03-13
EP4297333B1 (de) 2025-04-09
EP4297334B1 (de) 2025-04-02
EP4297335C0 (de) 2025-01-15
EP4297333C0 (de) 2025-04-09
EP4297335A2 (de) 2023-12-27
EP4297333A2 (de) 2023-12-27
EP4297334C0 (de) 2025-04-02
US20240356746A1 (en) 2024-10-24
KR20240038749A (ko) 2024-03-25
EP4297333A3 (de) 2024-03-27
EP4297332A2 (de) 2023-12-27
EP4297335B1 (de) 2025-01-15
EP4297334A2 (de) 2023-12-27
JP2025143381A (ja) 2025-10-01
DE102021004427B4 (de) 2024-05-29
CN117882072A (zh) 2024-04-12
EP4297335A3 (de) 2024-03-27
JP2025143380A (ja) 2025-10-01
US12418414B2 (en) 2025-09-16
EP4297334A3 (de) 2024-03-27
WO2023030811A1 (de) 2023-03-09
JP7716580B2 (ja) 2025-07-31
DE102021004427A1 (de) 2023-03-02
EP4297332C0 (de) 2025-01-15
EP4205005A1 (de) 2023-07-05

Similar Documents

Publication Publication Date Title
EP3274825B1 (de) Verfahren und ausführungsumgebung zum gesicherten ausführen von programmbefehlen
EP3012761B1 (de) Schutz von softwaremodellen
EP2940620A1 (de) Ableiten eines gerätespezifischen wertes mit hilfe einer unklonbaren funktion
DE102016210788B4 (de) Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente
EP3811260B1 (de) Kryptografiemodul und betriebsverfahren hierfür
EP3695337B1 (de) Verfahren und bestätigungsvorrichtung zur integritätsbestätigung eines systems
EP3136268B1 (de) Verfahren zur sicherheitsanalyse einer logischen schaltung
DE102020003072B3 (de) Verfahren zur sicheren Nutzung von kryptografischem Material
AT514731A2 (de) Verfahren zur Verifizierung generierter Software sowie Verifizierungseinrichtung zum Durchführen eines solchen Verfahrens
EP4297332B1 (de) Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP4150492B1 (de) Verfahren und secure-element zum nachweis einer vertrauenswürdigen elektronischen baugruppe
DE102021006638A1 (de) Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
DE102021006637A1 (de) Verfahren zur Implementierung und Nutzung von kryptografischem Material in wenigstens einer Systemkomponente eines informationstechnischen Systems
DE102022113104A1 (de) Eindeutige Identitätskennung für Lognachrichtenquellen in Fahrzeugen
DE102012107683B3 (de) Verfahren zur abgesicherten Nutzung von transportablen Datenträgern in geschlossenen Netzwerken
DE102019005545A1 (de) Verfahren zum Betreiben eines Maschinendatenkommunikationsnetzwerks, sowie Maschinendatenkommunikationsnetzwerk
DE102010040115A1 (de) Verfahren zum Bereitstellen von Informationen für ein Steuergerät
DE102023004446A1 (de) Reaktion auf Cyberattacken auf ein elektrisches Fahrzeug
DE102022200544A1 (de) Verfahren zur abgesicherten Bereitstellung eines zu schützenden Computerpro-gramms in einer Recheneinheit
DE102024116338A1 (de) Verfahren zur Integritätsprüfung eines Steuergeräts
DE102022122125A1 (de) Verfahren und Prozessorschaltung zum Betreiben eines Computernetzwerks, um bekannte Sicherheitslücken zu verorten und abzuschirmen, sowie Computernetzwerk, Speichermedium und Kraftfahrzeug
EP4543704A1 (de) Verfahren zum durchführen einer dekomissionierung eines elektrischen energiespeichers eines kraftfahrzeugs, computerprogrammprodukt sowie system
EP3812947A1 (de) Authentifizierung einer teilkonfiguration einer feldprogrammierbaren logikgatter-anordnung
EP3893065A1 (de) Verfahren zur bezahlbasierten ausführung einer durchzuführenden funktion eines feldgerätes, entsprechendes feldgerät und serviceeinheit
DE102020208331A1 (de) Verfahren zum Betreiben eines Hardware-Sicherheits-Moduls

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AC Divisional application: reference to earlier application

Ref document number: 4205005

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04L0009080000

Ipc: G06F0021600000

Ref country code: DE

Ref legal event code: R079

Ref document number: 502022002678

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0009080000

Ipc: G06F0021600000

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/08 20060101ALI20240206BHEP

Ipc: G06F 21/60 20130101AFI20240206BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240517

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20240920

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AC Divisional application: reference to earlier application

Ref document number: 4205005

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502022002678

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

U01 Request for unitary effect filed

Effective date: 20250211

U07 Unitary effect registered

Designated state(s): AT BE BG DE DK EE FI FR IT LT LU LV MT NL PT RO SE SI

Effective date: 20250219

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250415

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250515

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250415

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250416

U20 Renewal fee for the european patent with unitary effect paid

Year of fee payment: 4

Effective date: 20250825

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250115

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20251016