Methods for providing proof of origin for digital key pairs

The method and security module ensure that digital key pairs are generated and used securely within devices, providing a proof of origin to verify their source, preventing unauthorized use and ensuring compliance with brand owner regulations.

CN113424488BActive Publication Date: 2024-12-13SIEMENS AG
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202080013501.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-02-12
Filing Date
2020-02-07
Publication Date
2024-12-13
Estimated Expiration
2040-02-07

AI Technical Summary

Technical Problem

Existing methods fail to ensure that digital key pairs generated by contract manufacturers are used only for their intended devices, allowing unauthorized cloning and unauthorized use of private keys, which undermines brand owner authentication and monitoring.

Method used

A method and security module that generate a digital key pair with the private key stored securely, provide a proof of origin, and issue the public key with a protected proof of origin, ensuring the key pair's generation source is verified, using either asymmetric or symmetric cryptographic methods.

Benefits of technology

Ensures that only genuine key pairs generated at the intended source are used for authentication certificates, protecting the private key from unauthorized use and enabling brand owners to monitor and enforce compliance with their regulations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113424488B_ABST
    Figure CN113424488B_ABST
Patent Text Reader

Abstract

The present invention claims protection for a method for providing an origin certificate (AN) for a digital key pair (P, Q), the method comprising the following steps: - generating a digital key pair (P, Q) at a source (C) predetermined by a device (D), wherein a private key (P) of the digital key pair (P, Q) is stored in the device (D) in an access-protected manner; - providing an origin certificate (AN), which confirms that the digital key pair (P, Q) was generated at the mentioned source (C) and is protected by a secret key (G1) provided by the same device (D); and - issuing a public key (Q) of the generated digital key pair (P, Q) together with the origin certificate (AN).
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention relates to a method for providing a proof of origin for a digital key pair, which method is particularly suitable for use in a request for an authentication certificate, such as a digital certificate, in particular a device certificate, and to a related arrangement. Background Art

[0002] Within the scope of this specification, the term "security" or "security" refers primarily to the security or protection, confidentiality and / or integrity of data and their transmission, as well as the security, confidentiality and / or integrity when accessing the corresponding data. Authentication in data transmission or data access also belongs to the term "security", as this term is used within the scope of this specification. In this case, modules can be hardware units and / or functional units, which can be designed to be suitable for software and / or for firmware. The functions can be implemented, for example, by means of a processor and / or a storage unit for storing program commands.

[0003] In a certificate-based system, each person or object receives a certification certificate, such as a digital certificate, which contains information about his or her identity and the public key of the person or object. Each certificate is authenticated by the issuing authority via a digital signature, which in turn can be authenticated again by a higher-level authority. The trust system of this private key infrastructure PKI is strictly hierarchical. The common trust anchor is formed by the so-called root certificate (also called Root Certificate), which must be authentically configured in all relevant system components.

[0004] The authenticity and integrity of digital certificates are also checked by digital signatures. For this purpose, a value called a digital signature is calculated for the data set with the help of a secret signing key (also called private key). This value enables everyone to check the undeniable authorship and integrity of the data set with the help of an associated public verification key (also called public key). In order to be able to associate a signature created with a signing key with a person, the associated verification key must be associated with this person without a doubt.

[0005] In a device certificate, the identification of the device, for example the serial number or MAC address of the device, is bound to the public key of the device. The manufacturer's device certificate is preferably already used during manufacturing and also serves as an authenticity confirmation for the device. These device certificates usually have a very long validity period, so that the device can use this certificate during its entire use period, for example as a trust anchor for requesting or creating further operating device certificates for operational use. For each certificate, the certificate of the issuing authentication entity and, if necessary, further intermediate certificates up to a trusted root certificate must also be available and must be valid for a correspondingly long period of time.

[0006] Hereinafter, the certification entity is also often referred to as a facility for issuing certificates or a certificate issuing facility.

[0007] Similarly, secret symmetric keys and private asymmetric keys can be stored in a security module with special physical protection, such as a cryptographic processor, a hardware security module (HSM) or a trusted platform module (TPM). The security module can also be adapted to be implemented in software / firmware. Secret keys or private keys can be imported into the security module or generated in the security module. It is usually impossible to read the key from the security module, or it can only be read in a very limited way. The execution of the encryption algorithm using the stored key usually occurs in the security module itself. For the use of the key, authentication is usually required, for example, by transmitting a secret number or password to the security module.

[0008] Today, many products are not produced by the brand owner itself in its own factories, but by contract manufacturers on behalf of the brand owner in their factories. For some products, such as textiles, leather goods, etc., it has been customary for decades to manufacture products abroad (for example, in low-wage countries in the Far East) and then sell them in different countries under their own brand labels.

[0009] Here, the problem for the brand owner is that the contract manufacturer produces the product in larger quantities than agreed and illegally places the excess on the market for his own benefit. Since the products are manufactured in the same plant and by the same employees and machines, there is no longer any technical distinction between the original and the copy. It may therefore be important for the brand owner to be able to monitor his contract manufacturers in an appropriate manner. In particular, the method of "digital certificates" is gaining popularity, because digital certificates can in principle be created simply and cost-effectively even in large quantities and are almost impossible to forge. For this purpose, a new asymmetric key pair is generated for each device. The private key must remain in the device and be reliably protected against unauthorized use, in particular against reading and copying; the public key is transmitted in an authenticated manner to a certification authority (CA for short), which can be designed as an issuing facility, which digitally signs the public key together with other device data (serial number, type, manufacturer name, production date, etc.).

[0010] Regardless of whether the brand owner operates the issuing facility himself or has it operated by a trusted third party, the brand owner can easily determine the exact number of certificates generated. Since the contract manufacturer requests a new certificate for each device, the CA also knows the number of devices produced in accordance with regulations. It is known from EP 3288 215 A1 that the number of generated digital signatures is checked by a security module before generating further digital signatures.

[0011] However, this association only applies accurately if the contract manufacturer actually requests a new certificate for each device. It can certainly be the case that the key pair belonging to the certificate on the device being produced has been generated in hardware (i.e. in the hardware security chip) without the private key being readable; the contract manufacturer would then have to be forced to request a new certificate for each device. It is conversely possible that for a key pair whose private key the contract manufacturer knows, the contract manufacturer obtains a manufacturer certificate from the CA, whereby the contract manufacturer can use the private key and the associated certificate on multiple devices and thus clone devices (with the same serial number).

[0012] DE 10 2010 033231 A1 discloses a method and a server for providing a key certificate for a public device key of a user device installed at a user in a tamper-proof manner through a server of a service provider, the service provider providing services to the user via the user device, wherein if a signature request message received from the user device is successfully verified by the server based on a one-time password, the server provides the key certificate to the user device, and the one-time password is generated by the server for the user device.

[0013] DE 10 2011 004469 A1 discloses a method and a device for protecting location-related messages, which are transmitted by a provider to a large number of recipients and receiving devices varying over time, which are each located in a large number of local areas.

[0014] Further prior art consists of the publications DE 100 17 644 A1 and US 2017 / 353435 A1. Summary of the invention

[0015] Therefore, the technical problem to be solved by the present invention is to improve the method and the facility or the device or the equipment relative to the above-mentioned prior art.

[0016] This object is achieved by the features specified in the dependent claims. Advantageous developments of the invention are set forth in the dependent claims.

[0017] The present invention claims a method for providing proof of origin (AN) for a digital key pair, the method having the following steps:

[0018] - generating a digital key pair from a source predetermined by the device, wherein a private key of the digital key pair is stored in the device in an access-protected manner,

[0019] - provide a proof of origin confirming that the digital key pair was generated at the source mentioned and that the proof of origin is protected by means of a secret key provided by the same device, and

[0020] -Issuing the public key of the generated digital key pair along with the proof of origin.

[0021] Another aspect of the present invention is a security module for providing proof of origin for generating a digital key pair, the security module having:

[0022] - a generation unit designed to generate a digital key pair,

[0023] - a storage unit for private keys and for access protection of secret keys,

[0024] a providing unit designed to provide a proof of origin which confirms that the digital key pair was generated at the mentioned source and which is protected by means of a secret key, and

[0025] An issuing unit designed to issue the public key of the generated digital key pair together with a certificate of origin.

[0026] Another aspect of the invention is a device adapted to request at least one authentication certificate, in particular at least one device certificate, the device comprising:

[0027] a security module, in particular of the type described above, and

[0028] - A processing and issuing unit designed for generating and issuing the mentioned requests.

[0029] The device can be an IOT device or another device, for example, with a security module. The device or also the security module can use the secret key to (group) authenticate a public key from a key pair generated in the device, preferably in the security module, in order to thereby prove the origin or generation location of the key pair.

[0030] This key can be used in the request when launching at least one authentication certificate and thereby ensure that only key pairs generated in the device or security module are (or can be) used for the authentication certificate. Otherwise, the creation of the authentication certificate is rejected.

[0031] This ensures that the private key associated with the authentication certificate is protected from disclosure and that the contract manufacturer cannot use the private key and the associated authentication certificate for multiple devices.

[0032] The invention provides that the issued public key is used together with the proof of origin to request at least one authentication certificate, in particular at least one device certificate. The validity of the request is preferably checked, wherein validity is given if the source of the key pair is ensured and / or proven by means of the proof of origin.

[0033] The expansion of the present invention provides the following additional steps:

[0034] - if the mentioned validity is given, then generate an authentication certificate for the public key, and

[0035] -Issuance of certification certificates.

[0036] According to the invention, it is suitable that the requester of an authentication certificate, in particular a device certificate, can clearly prove the origin of the key pair to the issuing authority. The private key belonging to the requested authentication certificate can be protected according to regulations predefined by the issuing authority; the issuing authority can check (verify) the validity of this (origin) proof and thus monitor and enforce compliance with its regulations. This is also particularly important when creating TLS server certificates and certificates for subordinate certificate authorities.

[0037] A further development of the invention provides that the secret key in the device is only stored and kept at the source of the digital key pair. In one embodiment of the invention, the secret key can only be applied to data present at the source, but not to data located outside the source.

[0038] A refinement of the invention provides that the secret key is a symmetric group key and that a symmetric method, in particular a keyed hashing method for message authentication (HMAC) is used together with the symmetric group key to create an authentication certificate for the digital key pair.

[0039] Alternatively, it is possible that the secret key is a private key of an asymmetric key pair and that an authentication certificate of the digital key pair is created using an asymmetric method, in particular a digital signature, using the private key.

[0040] A further aspect of the invention is a device for checking the validity of a request for at least one authentication certificate, wherein the validity is ensured if the origin of the digital key pair is ensured and / or proven by means of a proof of origin.

[0041] Another aspect of the invention is a device for issuing at least one authentication certificate, in particular at least one device certificate, comprising:

[0042] - a device according to the preceding claim,

[0043] a generating unit designed to generate at least one authentication certificate, and

[0044] An issuing unit designed to issue at least one authentication certificate.

[0045] In addition, a computer program (product) is proposed, which includes a program code that can be implemented by at least one processor, and the program code causes at least one processor to implement the (operation) method according to the present invention and its implementation. The computer program can be run on an installation of the type mentioned above, or can be stored as a computer program product on a computer-readable medium.

[0046] The device, apparatus or device, modules and computer program (product) can be designed corresponding to the above-described embodiments / implementations of the method and their embodiments / implementations, and vice versa. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The characteristics, features and advantages of the present invention described above and the manner in which they are achieved will become clearer and more significantly easier to understand in conjunction with the following description of the embodiments described in more detail in conjunction with the accompanying drawings. Here, in the accompanying drawings:

[0048] Figure 1 An embodiment of a facility for requesting or issuing an authentication certificate according to the invention is shown in a block diagram when an asymmetric cryptographic protection method is used for the authentication proof; and

[0049] Figure 2 An exemplary embodiment of a facility according to the invention for requesting or issuing an authentication certificate is shown in a block diagram when a symmetric cryptographic protection method is used for the authentication proof. DETAILED DESCRIPTION

[0050] Figure 1 A facility CA for issuing a certification certificate Z is shown. If the facility CA issues a certification certificate Z in the form of a signed certificate, the facility is also called a certification authority (English: certification authority). The authority requiring or requesting the certification certificate is represented as a device D, which can be a product of the type mentioned at the beginning. In this case, the device D can include a security module C (e.g. a cryptoprocessor (security chip), an HSM (hardware security module) or a TPM (trusted platform module)) as well as a processing and issuing unit V and a provision unit B, which can also be integrated into the security module C.

[0051] Device D generates a key pair P, Q in security module C for authenticating certificate Z. Security module C stores private key P internally with access protection, and provides public key Q to device D externally.

[0052] The providing unit B is designed to provide the security module C with the secret key G1 in order to generate the authentication certificate AN. The providing unit B is preferably contained in the security module C (however, in Figure 1The key G1 is shown coupled to the security module in FIG. 1 ), so that the key G1 can be particularly well protected against reading and copying. It is particularly advantageous that the key G1 cannot be responded to from outside the security module C and cannot be applied to data originating from outside the security module C, but is only applied inside the security module C to generate an authentication certificate AN for the public key Q generated in the security module.

[0053] The key G1 can be implemented as a private asymmetric key. In this case, the device W for checking the authentication certificate AN must only contain the public key G2 belonging to the private key G1, which public key G2 can also be generally known; the private key G1 does not have to be known outside the security module or a series of similar security modules. In this case, the authentication certificate can be implemented, for example, as a signature on the public key Q: AN=Sig G1 (Q).

[0054] The processing and issuing unit V, which can be integrated into the security module C or can be coupled to the security module inside the device D, can be designed to provide a requirement or request for an authentication certificate ZA (e.g., a certificate request), which contains a key Q and an authentication certificate AN. The processing and issuing unit V generates a certificate request ZA, for example, in accordance with PKCS#10 (Certification Request Syntax Specification [rfc2986], a CMP message (Certificate Management Protocol [rfc4210], etc.). It contains the key Q, the authentication certificate AN, and preferably also other data that should be included in the certificate Z, such as device data (serial number, type, etc.). The certificate request ZA or parts thereof can also be signed using the generated private key P.

[0055] Figure 1 In ZA={Q,Sig G1 The certificate request represented by (Q),…} is transmitted to the issuing facility CA.

[0056] The transmission can take place via a wired communication interface or a radio transmission interface. If a (manufacturer or operating) device certificate is already present in the device D, this certificate is also advantageously used for the secure transmission of the certificate request.

[0057] If you consider Figure 2 , then in principle Figure 1The process in runs similarly to the symmetric encryption method. Here, the key GS (GS is used instead of G1) is a symmetric key, which is not divided into private and public parts. For example, to protect the key Q, HMAC (Keyed-Hashing for Message Authentication) is used, which is described in the document rfc2104 in the IETF organization. The rfc file mentioned above is also published by this organization. Therefore, the security module C is pre-personalized with a symmetric key GS, which is only known to the brand owner of the product or its CA operator. The certificate request is in Figure 2 It is represented by ZA={Q,HMAC(GS,Q),...}.

[0058] According to the two figures, on the side receiving the request, the device W belonging to the issuing facility CA checks the validity of the authentication certificate AN by means of the public key Q: the digital signature Sig is checked with the aid of the public part G2 of the asymmetric group key G1 (Q) or check HMAC HMAC(GS,Q) with the aid of the symmetric key GS. Validity is given if the origin and / or the place of generation of the key Q can be ensured and / or proven with the aid of a secret key (in the example, asymmetric keys G1 / G2 or symmetric key GS).

[0059] In the example, it should be ensured or proven that the key pair P, Q used was generated in the device D, even better in the security module C, and that the private key P cannot be read. Only if the mentioned validity is given, the generation unit E of the issuing facility CA generates a digital signature for the authentication certificate Z. The issuing unit A issues the authentication certificate Z with the generated digital signature, which is transmitted to the device D via the same or another wired communication interface or radio transmission interface. The device D checks the received authentication certificate to determine whether it matches the private key P.

[0060] The method according to the invention is independent of the certificate management protocol used. This protocol does not have to be implemented in the security module, but it is sufficient that the security module protects the public key Q using a symmetrical or asymmetrical method.

[0061] According to a first embodiment of the invention, when a new key pair P, Q is generated in the security module and the public key Q is published in plain text, this public key is automatically protected with a key (G1 or GS); this key is only used for authentication and integrity protection of the public part of the key pair generated internally, and cannot be used for functions that can be called from the outside. For this embodiment, a specific functionality is implemented in the security module, which functionality can be implemented by unit B in the example if it is envisaged to be integrated in the security module C.

[0062] This embodiment is also of particular interest for the creation (issuance) of CA certificates or signed certificates, whose operator wants to prove to a higher-level certification authority (Root CA) or must prove due to the policy of the Root CA operator that the private key is specially protected.

[0063] According to a further embodiment of the invention, a new key pair is also generated in the security module and the public key Q is published in plain text, but initially not protected by the key G1 or GS. It therefore makes sense that in the device D (for example in the firmware) (outside the security module C, in the example in the provision unit B) the public key Q is again transmitted to the security module for protection with an HMAC or a signature. This is already possible for a conventional security module with corresponding keys, but the security provided is lower, since in principle further data (for example a public key generated outside the security module) can also be protected by the key G1 or GS using this method. However, the method can also be fully applicable to this case, since the cost of creating a correspondingly manipulated firmware for an untrusted contract manufacturer is significantly higher than if the contract manufacturer simply sends any certificate request to the issuing facility CA via its infrastructure.

[0064] The check of the validity of the authentication certificate request ZA or the certificate request or the authentication certificate AN of the public key Q in the certificate request does not necessarily have to be carried out directly by the issuing facility CA; instead, a preceding unit not shown in the figure (such as a CA gateway in the CA's trust center, or a registration authority (RA) in the brand owner) can also undertake this task.

[0065] This embodiment is also of particular interest for devices having a manufacturer certificate which have a security module, but whose security module does not have the functionality of the first embodiment described above.

[0066] The security module groups (first embodiment described above) or devices (other embodiments described above) using the same key G1 or GS can have different sizes, for example:

[0067] All security modules or security chips manufactured for devices of the same customer (brand owner)

[0068] All security modules or security chips in a production batch

[0069] All equipment in one series

[0070] All devices with the same firmware version

[0071] All equipment in a production batch

[0072] ·etc.

[0073] It is also possible that each security module or each device uses a different "group" key, ie the "group size" is just one. However, the cost of transmitting the group key from the chip manufacturer or firmware manufacturer to the certification authority increases with the number of groups used.

[0074] If a plurality of different keys G1 or GS are used within the system, it may be necessary to also add an identifier to the authentication certificate AN, by means of which the checking authority can identify which of the keys G1 or GS has been used.

[0075] When using CMP messages, the following structure can be used to implement certificate requests:

[0076]

[0077] Extensions contain extensions that the requester wishes to place in the certificate. These extensions typically handle things like setting the key usage to keyEncipherment.

[0078] For example, the authentication proof AN (HMAC or signature) can be transmitted in the field controls in regToken (see RFC4211 section 6.1).

[0079] The authentication proof AN can also be attached to the CMP message.

[0080] Although the present invention has been illustrated and described in more detail by means of preferred embodiments, the present invention is not limited to the disclosed examples and other variations may be derived therefrom by those skilled in the art without departing from the scope of protection of the present invention.

[0081] The process or method described above can be implemented according to instructions, which are stored on a computer-readable storage medium or in a volatile computer memory (hereinafter collectively referred to as a computer-readable memory). Computer-readable memories are, for example, volatile memories (such as cache, buffer memory or RAM) and non-volatile memories (such as mobile data carriers, hard disks, etc.).

[0082] Here, the functions or steps described above may exist in the form of at least one instruction set in / on a computer-readable memory. Here, the functions or steps are not bound to a specific instruction set or a specific form of instruction set or a specific storage medium or a specific processor or a specific implementation, and may be implemented by software, firmware, microcode, hardware, processors, integrated circuits, etc., running alone or in any combination. Here, different processing strategies may be used, for example, serial processing or multi-processing or multi-tasking or parallel processing by a single processor, etc.

[0083] The instructions may be stored in local memory, but it is also possible to store the instructions on a remote system and access them over a network.

[0084] The device may have one or more processors. The terms "processor", "central signal processing", "control unit" or "data analysis device" include processing devices in the broadest sense, i.e., for example, servers, general-purpose processors, graphics processors, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits (such as FPGAs), discrete analog or digital circuits and any combination thereof, including all other processing devices known to those skilled in the art or developed in the future. Here, the processor may be composed of one or more devices or devices or units. If the processor is composed of multiple devices, these devices can be designed or configured for parallel or sequential processing or execution of instructions.

Claims

1. A method for providing an origin proof (AN) for a digital key pair (P, Q), the method comprising the following steps: - generating the digital key pair (P, Q) at a source (C) predetermined by the device (D), wherein the predetermined source (C) is a security module (C) of the device (D), wherein the private key (P) of the digital key pair (P, Q) is stored in an access-protected manner in the security module (C) of the device (D), and wherein the security module is a cryptoprocessor, a hardware security module and / or a trusted platform module, - providing a certificate of origin (AN), which confirms that the digital key pair (P, Q) was generated at a predetermined source (C) and is protected by means of a secret key (G1; GS) provided by the same device (D), wherein the secret key (G1; GS) provided is provided in the security module (C), and - issuing the public key (Q) of the generated digital key pair (P, Q) together with the said proof of origin (AN).

2. The method according to claim 1, characterized in that The issued public key (Q) is used together with the proof of origin (AN) to request (ZA) at least one authentication certificate (Z).

3. The method according to claim 1, characterized in that The request is checked for validity, wherein validity is indicated if a predefined origin (C) of the digital key pair (P, Q) is ensured and / or proven by means of the proof of origin (AN).

4. The method according to claim 3, characterized in that The method comprises the following steps: - if said validity is given, generating a certification certificate (Z) for said public key (Q), and -Issuance of certification certificate (Z).

5. The method according to any one of claims 1 to 4, characterized in that The secret key (G1; GS) within the device (D) is stored and maintained only at a predetermined source (C) of the digital key pair (P, Q).

6. The method according to any one of claims 1 to 4, characterized in that The secret key (G1; GS) is used only for data present at a predetermined source (C).

7. The method according to any one of claims 1 to 4, characterized in that The secret key is a symmetric group key (GS), and a symmetric method is used with the symmetric group key (GS) to create an origin proof (AN) of a digital key pair (P, Q).

8. The method according to any one of claims 1 to 4, characterized in that The secret key is a private key (G1) of an asymmetric key pair (G1, G2), and using the private key (G1) an asymmetric method is used to create an origin certificate (AN) of a digital key pair (P, Q).

9. A security module (C) for providing an origin proof (AN) for generating a digital key pair (P, Q), the security module comprising: - a generation unit designed to generate said digital key pair (P, Q), - an access-protected storage unit for a private key (P) and for a secret key (G1; GS), a providing unit, which is designed to provide a proof of origin (AN), which confirms that the digital key pair (P, Q) was generated at a predetermined source (C), wherein the predetermined source (C) is a security module (C), and the proof of origin is protected by means of a secret key (G1; GS), and wherein the security module is a cryptoprocessor, a hardware security module and / or a trusted platform module, and - an issuing unit designed to issue the public key (Q) of the generated digital key pair (P, Q) together with the proof of origin (AN).

10. A device (D) adapted to request at least one authentication certificate (Z), said device comprising: - A security module (C) according to claim 9, and - a processing and issuing unit (V) designed to generate and issue the request (ZA).

11. A device (W) for checking the validity of a request (ZA) for at least one authentication certificate (Z), wherein: Validity is given if a predetermined source (C) of the digital key pair (P, Q) is ensured and / or proven by means of a proof of origin (AN), wherein the predetermined source (C) is a security module (C) according to claim 9 of a device (D) according to claim 10 .

12. A facility (CA) for issuing at least one authentication certificate (Z), said facility comprising: - a device (W) according to claim 11, a generation unit (E) designed to generate at least one authentication certificate (Z), and An issuing unit (A) designed to issue at least one authentication certificate (Z).

13. A computer-readable medium having a computer program product stored thereon, the computer program product being directly loadable into a memory of a digital processor, the computer program product comprising program code portions adapted to execute the steps of the method according to any one of method claims 1 to 8.