SYSTEM FOR GENERATING CRYPTOGRAPHIC MATERIAL

Abstract

A system for generating cryptographic material includes a cryptomaterial server and developer module. The cryptomaterial server has at least one cryptomaterial generator and a cryptomaterial distributor. The cryptomaterial generator is set up to generate cryptographic material by using specifications that can be predetermined via the developer module. The cryptomaterial server has a receiving part of a specification interface and the developer module has a corresponding sending part of the specification interface, which can be coupled directly or indirectly for the secure transmission of data. The developer module has a user interface or can be coupled directly or indirectly to one that is set up for an input of the specifications in abstract form. A transformation module automatically transforms the input specifications into a syntax of the cryptomaterial generator.

Claims

1-15. (canceled)

16. A system for generating cryptographic material, the system comprising: a developer module; and a cryptomaterial server comprising a cryptomaterial generator configured to generate cryptographic material using specifications that are predetermined via the developer module; and a cryptomaterial distributor, wherein the cryptomaterial server has a receiving part of a specification interface and the developer module has a corresponding sending part of the specification interface, wherein the receiving and sending parts of the specification interface are couplable directly or indirectly for the secure transmission of data, wherein the developer module has a user interface or is coupled directly or indirectly to the user interface, wherein the user interface is configured to accept an input of the specifications in abstract form, and wherein the system includes a transformation module configured to automatically transform the input specifications into a syntax of the cryptomaterial generator.

17. The system of claim 16, wherein the transformation module is part of the cryptomaterial generator.

18. The system of claim 16, wherein the cryptomaterial generator has a hardware security module configured to generate the cryptographic material.

19. The system of claim 18, wherein the syntax of the cryptomaterial generator is predetermined by a syntax of the hardware security module.

20. The system of claim 16, wherein the cryptomaterial server further comprises a cryptomaterial database storing the cryptographic material generated by the cryptomaterial generator.

21. The system of claim 20, wherein the cryptomaterial distributor is connected to the cryptomaterial generator directly or indirectly via the cryptomaterial database.

22. The system of claim 21, wherein the cryptomaterial database is directly connected to a hardware security module of the cryptomaterial generator and in parallel to the transformation module in the cryptomaterial generator.

23. The system of claim 16, wherein the cryptomaterial generator further comprises a specification database.

24. The system of claim 16, wherein the transformation module comprises an interpreter configured to generate the syntax of the cryptomaterial generator.

25. The system of claim 16, wherein the transformation module comprises a translator configured to generate a program code that generates generate the syntax for the cryptomaterial generator.

26. The system of claim 16, wherein the user interface comprises a text-oriented or graphic-oriented syntax-controlled editor configured to input the specifications in abstract form.

27. The system of claim 16, wherein the user interface comprises checking modules configured to check the syntax of the cryptomaterial generator or to check a type of the input of the specifications.

28. The system of claim 16, wherein the user interface is configured to process the input of the specifications in a declarative, non-operational form.

29. The system of claim 16, wherein the cryptomaterial server further comprises a distributing interface, wherein the cryptomaterial distributor is connected directly or indirectly to at least one receiver or user of the cryptographic material via the distributing interface.

30. A method, comprising: predetermining, by a developer module, specifications for a specific application of a vehicle-specific information technology system; and generating, by a cryptomaterial server based on the specifications, the cryptographic material; and distributing the generated cryptographic material to a receiver or user of the specific application.

Description

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0032] Here are shown:

[0033] FIG. 1 a schematic depiction of a translator-based approach of a transformation module;

[0034] FIG. 2 a schematic depiction of an interpreter-based approach of a transformation module;

[0035] FIG. 3 an alternative interpreter based approach, in which the input and the use of the specifications by the interpreter are separated from one another; and

[0036] FIG. 4 an overview of a whole system having the system according to the invention for generating and distributing cryptographic material.

DETAILED DESCRIPTION

[0037] The system according to the invention proposes a transformation module 1 as an essential component, which is designed and used to provide an abstract, formal, and practicable language for unambiguous description of the specifications of cryptographic material. The transformation into the syntax of a cryptomaterial generator 2 depicted and described later in more detail can here be substantially achieved in two different ways. One way is indicated in the depiction of FIG. 1 and relies on a translator 4. Specifications SPEC are input via a user interface 3 not depicted in FIGS. 1 and 2, namely for a specific application n for which cryptographic material is to be generated. The specifications SPEC then reach the translator 4 and are converted by this into source code QC for the respective application n. This source code QC.sub.n is then installed as a program in a corresponding high-level language, in which the translator 4 has generated the source code QC, for example in Java, on a cryptomaterial server 5. Here, part of this cryptomaterial server 5 is the cryptomaterial generator 2 and, in particular, a hardware security module 6 not necessarily yet extensively present in the cryptomaterial generator 2, the hardware security module also being referred to as HSM.

[0038] An interpreter-based approach of the transformation module 1 constitutes an alternative to this approach with the translator 4. FIG. 2 depicts such an approach by way of example. Here, various specifications SPEC.sub.n to SPEC.sub.m for different applications n, m are supplied directly to an interpreter 7, which uses a higher-level programming language as a common interpreter 7 for the specifications SPEC.sub.n to SPEC.sub.m of all applications n, m. The interpreter 7 unites the logic of all conceivable programming and can thus generate the desired cryptographic material for each conceivable valid specification SPEC, in particular by means of the HSM 6 via the cryptomaterial generator 2, which comprises this HSM 6. This means, in particular, that the specifications can be implemented by the interpreter 7 directly, so without interposed translation and, in particular, without interposed installation of the source code QC.

[0039] Since an individual specification must be compiled for each of the applications n, m and in order to prevent these having to be input anew every time, the individual specifications can be filed in a specification database 8 and reloaded and implemented by the interpreter 7 as needed. This is correspondingly indicated in the depiction of FIG. 3. A specification interface 9 connects the individual specifications SPEC.sub.n to SPEC.sub.m to this specification database 8, which is then in turn connected to the interpreter 7 and, via this, to the cryptomaterial generator 2 or its HSM 6.

[0040] In the depiction of FIG. 4, a whole system is now shown. This serves to generate cryptographic material or cryptomaterial CM, which is preferably to be used in a vehicle ecosystem. The cryptomaterial server 5 used here comprises the cryptomaterial generator 2 in an inherently known manner in an exemplary embodiment characteristic of the system present here, the embodiment being depicted by way of example on the basis of an interpreter 7 as an essential component of the transformation module 1. The inherently known part of the cryptomaterial server 5 comprises, along with the cryptomaterial generator 2 that is also fundamentally known, though not in this embodiment, a cryptomaterial distributor 10, via which the cryptomaterial CM is distributed to various receivers R.sub.1, R.sub.2, R.sub.3. Here, for example when the whole system is seen from the perspective of a vehicle manufacturer, the receivers can be the email account of a supplier, the server of a supplier, which then further distributes the cryptomaterial CM, or even the server of the manufacturer, for example at the end of the manufacturing process or the belt end of the vehicle manufacturing. The cryptomaterial is then forwarded to users, which are here assigned numerals N.sub.1, N.sub.2, N.sub.3, by the receivers R.sub.1, R.sub.2, R.sub.3, and the receivers R.sub.2, R.sub.3 are separated from one another, when the data are forwarded to a vehicle as user N.sub.2, for example via a server as receiver R.sub.2, such that eventually the cryptographic material CM is available to the user N.sub.2, i.e., for example in the control unit of a vehicle. Of course, it is also conceivable that receiver R.sub.1 and user N.sub.1 are one and the same unit, for example a server, which communicates with the vehicle. Further examples for users N are, for example, applications on mobile terminals, which achieve a driving authorization, an access authorization for the vehicle or other communications to be encoded for security reasons.

[0041] The cryptomaterial CM is thus correspondingly generated on the cryptomaterial server 5 and further distributed by the cryptomaterial distributor 10. To generate the cryptomaterial CM suitable for the respective application n, m, a developer module 11 is now provided. This developer module 11 comprises, for example, a suitable editor, in order to input the corresponding specifications SPEC for the cryptographic material CM of the respective application n, m in a text-based and/or graphic-based manner. As already mentioned above, for this, a syntax check and similar can already be carried out in the editor itself. The input language or the graphical input is here abstractly formal and thus unambiguously understandable, both for various human users of the developer module 11 or its user interface 3 and for the system. Substantially analogously to the depiction in the design according to FIG. 3, the specifications are transmitted via an interface 9 in the cryptomaterial generator 2. Here, the specification database 8 can preferably be present, in order to use the advantages already described in the context of FIG. 3. Then the transformation module 1 follows, which is here formed as interpreter-based, yet fundamentally could be implemented just as well as a translator-based transformation module 1. The cryptomaterial generator 2 in the depiction according to FIG. 4 shall, in any case, comprise an HSM 6. Now it is possible to provide corresponding cryptomaterial CM on the one hand by the transformation module 1 or interpreter 7 and, on the other hand, by the HSM 6. This is then stored in an optional cryptomaterial database 12 and forwarded from here and, optionally, without intermediary storage, as is indicated in the depiction of FIG. 4, for distribution to the cryptomaterial distributor 10. From this, the distribution of the cryptomaterial described above to the receivers R.sub.1, R.sub.2, R.sub.3 or users N.sub.1, N.sub.2, N.sub.3 is then carried out. The specification database 8 here offers the advantage that, with increasing use of the cryptomaterial generator 2, this database is filled again and again, corresponding to the specification SPEC, if this is already known to it, to obtain the corresponding specifications SPEC for the corresponding task directly from the specification database 8 and, from this, to completely automatically generate the necessary cryptomaterial CM, in order to thus be able to save the input of repeating processes via the developer module 11.

[0042] Here, the considerations explained below underlie the development of a formal abstract language for use in the transformation module 11.

[0043] As an input parameter for a method for generating the suitable cryptomaterial CM, names or identifiers of the combinations of receivers R.sub.1, R.sub.2, R.sub.3 and user N.sub.1, N.sub.2, N.sub.3, which require the cryptomaterial CM, are used. Moreover, abstract specifications SPEC for the respective combinations are necessary, which require the cryptomaterial required by this, i.e., for example symmetrical or asymmetrical keys, certificates, random numbers, hash values and similar.

[0044] The output parameters for the transformation module 1 then substantially consist of a list of cryptomaterial datasets with a dataset for each system identifier, which corresponds to the specification of the cryptographic material CM according to the input parameters. In order to correspondingly convert these, the following steps are necessary: firstly, the necessary base types must be correspondingly identified, for example, the definition of the system identifier, such as a device ID, for example, a chassis number or similar in the form of a STRING can be carried out. Furthermore, version types can be defined, for example also in a STRING. Further necessary base data are also conceivable.

[0045] Subsequently, the type of the necessary structure must then be identified, for example an ARRAY or RECORD, in order to achieve as compact a description of the structures as possible, for example a list of the chassis numbers of a fleet in a field (ARRAY) or the systems of a vehicle as hierarchy of system and subsystems in a RECORD. Then, all of the cryptographic functions supported by the hardware security module 6 must be identified, for example hash methods, MAC methods, symmetrical encryption and decryption methods, asymmetrical methods (RSA, ECC etc.), X-509 certificates, together with all supported parameters and variants. For this, corresponding forms of spelling and preferably meaningful and easily understandable names are to be defined. Furthermore, all data types and formats required by the identified cryptofunctions must be identified and set for the input and output. For this too, appropriate meaningful names, such as OctetString, for example, should be chosen. Then, an extension of the cryptofunctions of base types must be defined on structured types. A speech construct can now be correspondingly defined for the composition and the encoding of the cryptomaterial CM to be output.

[0046] It is now crucial to establish a grammar that allows the description of the cryptomaterial CM by means of the identified base types, structured types and cryptofunctions and the dataset to be output. Here, this grammar describes a declarative language that can be easily interpreted, since the cryptomaterial can be described statically and thus declaratively. In particular, a non-operation language is necessary, such that the grammar remains correspondingly simple. Here, FOR loops, for example for initializing and processing ARRAYs, are sufficient. In particular, WHILE loops that are otherwise common in programming are not necessary. This has the crucial advantage that the programs run through to the end more and more reliably, regardless of possible parameters, which cannot guarantee such a consistent run-through of the program when querying a WHILE loop. Furthermore, no recursions are necessary. No dynamic data structures are also required. User-defined functions, procedures and methods are also not necessary, since the pre-defined functions here suffice for using the cryptofunctions.

[0047] The interpreter can now use this grammar in order to translate a specification SPEC corresponding to the grammar into a series of commands of a higher-level programming language such as Java or even C++, for example, which is then in turn used by the HSM 6. Because the target language itself is a Turing power programming language and because the cryptofunctions supported by the HSM are used exclusively in the specification language, the target language is complete. It thus covers all conceivable specifications. The language to be developed is here correspondingly simple since, due to the limitation described above such as its declarative, non-operational character, a correspondingly simple development is depicted and thus enables a simple interpreter 7 as an example of the transformation module 1.

[0048] The abstract language to be defined is respectively closely linked to the power of the HSM 6 installed in the underlying cryptomaterial generator 2, since the HSM 6 eventually defines the syntax for the cryptomaterial generator 2 and, above all, also forms the anchor for the security of the generated cryptomaterial CM. In order to achieve a high degree of security, all the generated cryptomaterial CM should be generated inside the HSM 6. Mechanisms that the HSM 6 does not support are nevertheless conceivable and indicated in FIG. 4. However, they should never be used in a maximum secure system with the specification SPEC.

[0049] The attachment of the abstractly formal language to the syntax of the HSM 6, however, now optionally results in a slightly deviating language generally having to be generated for each HSM 6. In order to avoid this effort, two solution approaches are substantially offered.

[0050] Thus, the language can be constructed modularly in a first approach. Here, further language elements can be added, depending on the HSM 6 used, to an obligatory core, which each relevant HSM 6 should support. The interpreter 7 is inherently “maximally powerful” and supports “all” HSMs, so does not have to be changed from system to system. Yet the number of accepted specifications would vary from HSM 6 to HSM 6.

[0051] The second solution approach provides that the language is the same for all systems, regardless of the HSM 6 used. All functions/mechanisms that are necessary or could be necessary for the creation of the cryptographic material CM are implemented in the software completely by the interpreter 7. Thus, the interpreter 7 could also manage completely without the HSM 6, which, however, would be rather precarious in terms of security in at least a few cases.

[0052] Here, it is the case that an input language is predetermined for the specifications SPEC in the user interface 3 or in the developer module 11 by the transformation module 1, the input language in any case not being the same as the language that is used as syntax of the cryptomaterial generator 2 or the HSM 6.

[0053] The interpreter 7 knows the HSM 6 underlying the respective system or cryptomaterial server 5 or cryptomaterial generator 2 and the functional scope supported by it. All functionalities supported by the respective HSM 6 are then also treated by this. This means that, instead of the individual software function classified as insecure, the interpreter 7, when at all possible, involves the functions of the HSM to be classified as secure. Only if specifications SPEC that the HSM 6 does not support have been used in the input are the available software functions of the interpreter 7 invoked or used.

[0054] This means that different cryptographic material CM would be generated/stored/sent with different levels of security. The user of the cryptomaterial server 5 can thus bypass it in a different manner. Thus, the user can only see how securely the respective cryptomaterial CM was generated/stored/sent. Here, different grades of security are conceivable, wherein the security or the degree of security can respectively be based on different aspects (generating, storing, sending). A very secure possibility for the user would be e.g., to set the cryptomaterial server 5 in such a way that this only generates secure cryptomaterial CM. If the input contains specifications SPEC which the cryptomaterial server 6 cannot securely implement, it refuses to generate the cryptomaterial CM.

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