Computer-implemented method for creating signed certificates

Abstract

The invention relates to a computer-implemented method for creating signed certificates (Zert2), the method comprising the steps of: - generating a first private key (Priv1), a first public key (Pub1) and a first certificate (Zert1), wherein the first certificate (Zert1) comprises the first public key (Pub1), information regarding the certificate owner (Inh) and a first validity period (T1, T2), - generating a second private key (Priv2), a second public key (Pub2) and a second certificate (Zert2), wherein the second certificate (Zert2) comprises the second public key (Pub2), the information regarding said certificate holder (Inh) and a second validity period (T3, T4), wherein the second validity period (T3, T4) starts after the first validity period (T1, T2) has started, wherein the validity periods of the first certificate (Zert1) and of the second certificate (Zert2) preferably overlap, - signing the second certificate (Zert2) with the first private key (Zert1).

Description

[0001] Computer-implemented method for creating signed certificates

[0002] The invention relates to a computer-implemented method for creating signed certificates, in which certificates are generally created as follows: generating a first private key, a first public key and a first certificate, wherein the first certificate comprises the first public key, information about the certificate holder and a first validity period.

[0003] Certificates play a central role in ensuring the security and trustworthiness of communication connections in the context of internet encryption. These certificates can be issued or signed by Certificate Authorities (CAs) and are an essential component of the Public Key Infrastructure (PKI). By using certificates, users can be sure that they are communicating with a legitimate partner (and not a fraudulent third party) and that the data they send and receive is encrypted and protected from unauthorized access. A certificate contains a public key used to encrypt messages, as well as information about the certificate holder that has been verified by the Certificate Authority.

[0004] For example, US 2004 / 148505 A1 states that certificates are signed by a higher-level authority. However, reaching the validity period of the certificates is problematic, so certificates for devices should preferably have a validity period that is longer than the lifespan of the devices.

[0005] The validity period of a certificate is a crucial aspect that influences its security and trustworthiness. It determines how long a certificate is considered valid and trustworthy. Within this period, the associated private key is assumed to be secure and uncompromised. The validity period is defined by the certificate's issue date and expiration date. It is important that this period is carefully chosen to ensure an appropriate balance between security and user-friendliness.

[0006] Once a certificate's validity period expires, it is no longer considered trusted. This means that any connection attempting to use the expired certificate is considered insecure. Users and systems that rely on the integrity and authenticity of certificates must be able to detect expired certificates and take appropriate action. In practice, this often means replacing the expired certificate with a new, valid one. Certificate holders are therefore strongly encouraged to request renewal before the expiration date.

[0007] The certificate renewal process typically involves generating a new key pair (private and public key) and issuing a new certificate by the certificate authority. This helps maintain a high level of security, as new keys are regularly generated and used, minimizing the risk of compromise. Certificate authorities play a crucial role in this process by ensuring that the applicant's identity is verified and the new certificate is issued correctly.

[0008] However, problems arise if the certification authority itself is compromised. In this case, an unauthorized third party could impersonate another institution and have a certificate issued or signed by the compromised certification authority. The aim of the present invention is to eliminate such uncertainties.

[0009] This goal is achieved through a computer-implemented procedure for creating signed certificates, comprising the following steps:

[0010] - Generating an initial private key, an initial public key, and an initial certificate, wherein the initial certificate includes the initial public key, information about the certificate holder (i.e., the entity that owns the initial private key associated with the initial public key), and an initial validity period.

[0011] - Generating a second private key, a second public key and a second certificate, wherein the second certificate includes the second public key, the information of the said certificate holder and a second validity period, the second validity period beginning after the beginning of the first validity period, the validity periods of the first certificate and the second certificate preferably overlapping, and signing the second certificate with the first private key.

[0012] The solution according to the invention provides a chain of certificates that can be traced back temporally to at least one previously expired certificate. The new signature, also referred to herein as a chain signature, can be generated by hashing the content of the second certificate (and optionally one or more further signatures such as a root signature) and then encrypting it with the first private key.

[0013] It should be emphasized that the first private key, the first public key, the second private key, and the second public key are created by the same user. It can also be said that the first certificate and the second certificate are assigned to the same user.

[0014] The solution according to the invention solves the following problem: If a certification authority has been compromised in the period between the issuance of the first certificate and the second certificate, and a third party attempts to have a new second certificate issued or signed by the compromised certification authority on behalf of the certificate holder of the first certificate, this third party will still not be in possession of the first private key and therefore cannot sign the new second certificate, even if they could have it signed by the compromised certification authority.

[0015] The solution according to the invention thus provides protection against the forgery of certificates if a certification authority is compromised, since a newly issued certificate is not signed using the private key of the certification authority, or not only using the private key of the certification authority, but also using the private first key.

[0016] The authenticity of the second certificate, signed using the first private key, can be verified by the first certificate, which was in turn signed by the certification authority, but at an earlier point in time when it can be assumed that the certification authority had not yet been compromised.

[0017] In the method according to the invention, it is typically provided that the method further comprises the following steps:

[0018] Signing the first certificate by a certificate authority using a private root key that corresponds to a public root key, and

[0019] - Preferably, the second certificate is signed by the certificate authority using the private root key associated with the public root key. If the first certificate was signed by the certificate authority, a temporal signature trace back to the certificate authority can be established simply by signing the second certificate with the private key of the first certificate, without the certificate authority having to sign the second certificate itself.

[0020] To increase the security level, the certificate authority is required to also sign the second certificate. Typically, the certificate holder creates the second certificate and signs it with the first private key. It is then sent to the certificate authority and signed there using the private root key. Preferably, when signing with the private root key, a hash value is generated from the content of the second certificate and the signature with the first private key. This provides a particularly high level of security, as the chain signature with the first private key cannot be added subsequently.

[0021] Verification of the second certificate by a third party's computing unit can be carried out as follows:

[0022] - Verifying the signed second certificate using the first public key contained in the first certificate, and

[0023] - preferably, verification of the signed first and / or second certificate using the public root key, preferably taken from a root certificate.

[0024] Verification of the second certificate can occur, for example, when the third or additional computing unit receives a message signed with the second private key. The following steps are used for this purpose:

[0025] Signing a message with the second private key by the certificate holder,

[0026] Sending the signed message from the certificate holder to the next computing unit (generally to a recipient),

[0027] - Through the further computing unit or the receiver, receiving the first and the second certificate,

[0028] Verifying the second certificate according to the above procedural steps and

[0029] - Verification of the signed message using the second public key contained in the second certificate.

[0030] The order of the steps mentioned is not mandatory, so the two verification steps can also be performed in reverse and / or the first and second certificates can be received before the message. Furthermore, a third party or another processing unit can encrypt a message with the second public key and send it to the first processing unit. The following steps are used for this:

[0031] - Through the further processing unit, receiving the first and second certificates, verifying the second certificate according to the above procedure steps, encrypting a message with the second public key,

[0032] Sending the encrypted message to the certificate holder, and

[0033] - Decrypting the encrypted message using the second private key.

[0034] Signing the second certificate with the first private key is typically done by hashing the second certificate (optionally along with the root signature) and signing it with the first private key. In other words, the entire contents of the certificate are first converted into a hash value using a cryptographic hash function, such as SHA-256. A hash value is a unique, fixed-length representation of the certificate's contents. The hash value is then encrypted with the first private key. This encrypted hash value is the certificate's digital signature. If the second certificate is also to be signed with the private root key, it is again hashed (optionally along with the chain signature) and encrypted with the private root key. In this case, there will be two signatures.

[0035] In a preferred scenario, the first and second validity periods can overlap, ensuring a continuous chain of certificates. Alternatively, the second validity period could immediately follow the first, or there could be a time gap between the first and second validity periods.

[0036] The foregoing explanations were made considering a first certificate and a second certificate. However, the procedure is extendable to many more certificates, so that a chain of certificates from a single certificate holder can be defined. In general, there can be at least one further certificate from said certificate holder whose validity period begins before the start of the first validity period or after the start of the second validity period, so that a temporal chain of certificates from said certificate holder exists, in which a root certificate defines the beginning of the chain. Preferably, the validity periods of any two consecutive certificates overlap, and / or preferably, no three of the validity periods overlap at any time.

[0037] In the aforementioned variant of the chain with at least three certificates, the following three variants in particular may be provided.

[0038] In the first scenario, each certificate in the chain, except for the root certificate, is signed with the private key belonging to the preceding certificate. Here, a third party, who wants to verify the last certificate in the chain, retrieves all certificates of the certificate holder. Starting with the last certificate in the chain, the third party can then check whether a certificate was signed with a private key belonging to the preceding certificate. In other words, each certificate in the chain is verified. Furthermore, each certificate in the chain can be signed by the certificate authority, and this root signature can also be verified.

[0039] In a second variant, each certificate in the chain, except for the root certificate, can be signed with all the private keys belonging to all the preceding certificates. To verify the last certificate in the chain, all certificates of the certificate holder are retrieved. The last certificate in the chain will have a number of (n-1) chain signatures, where n is the length of the chain. All chain signatures of the last certificate in the chain are checked, but the preceding certificates do not need to be checked. Furthermore, each certificate in the chain (i.e., also the last certificate in the chain) can be signed by the certificate authority, and this root signature can also be verified. Thus, n signatures of the last certificate can be verified.

[0040] In a third variant, each certificate in the chain, with the exception of the root certificate, can be signed only with the private key belonging to the root certificate. In other words, each certificate in the chain is encrypted only with a chain signature and, optionally, with a root certificate. This can offer a fast verification method while still providing a high level of security against compromised certificate authorities.

[0041] Preferably, all certificates in the chain, or at least the first and second certificates, have a strictly monotonically increasing serial number. In other words, all certificates have a serial number, with a certificate having an earlier validity period than another certificate having a lower serial number. The strictly monotonically increasing serial numbers may, but do not have to, increase linearly. If the function for determining the serial numbers is known, it is also possible to determine whether a certificate immediately precedes another, or whether all certificates in the chain are present. The purpose of the serial numbers is to verify whether a certificate is indeed before, immediately before, after, or immediately following another certificate.

[0042] In another aspect, the invention provides a computing unit or system for creating signed certificates, wherein the computing unit is configured to carry out the aforementioned procedure.

[0043] In a further aspect, the invention creates a computer-implemented data structure formed by the signed second certificate described above. In this data structure, it can be provided, in particular, that the second certificate is signed with the private keys of all previous certificates.

[0044] To better illustrate the present invention and explain its operation in detail, reference is made below to the accompanying figure. This figure serves to clarify the technical features of the invention. The following description of the figure is intended to contribute to a thorough understanding of the structural and functional properties of the invention and to explain its advantages and technical advances compared to the prior art. It shows:

[0045] Figure 1 shows the method according to the invention in a temporal sequence.

[0046] Figure 1 depicts two timelines. The first, left-hand timeline represents the actions performed by a so-called certificate holder (Inh). The certificate holder (Inh) can be implemented as a computing unit and represents a communication participant who wants to communicate cryptographically securely with other communication participants using a public / private key scheme. "Communicating cryptographically securely" in this context means that messages can be encrypted using a recipient's public key and signed using the sender's own private key.

[0047] The right-hand timeline in Figure 1 illustrates the actions performed by a Certificate Authority (CA). It is evident that, in a first step (S1), the CA generates a private root key (PrivCA) and a public root key (PubCA). From these, a root certificate (ZertCA) can be created in a second step (S2). This root certificate contains information about the CA, the public root key (PubCA), a start date (TO) for the validity period of the root certificate (ZertCA), and an end date (TO) for the validity period of the root certificate (ZertCA). This is known from the prior art.

[0048] In order for the certificate holder (Inh) to communicate cryptographically securely, they generate a first private key (Privl) and a first public key (Publ) in a third step (S3). This can be done according to common algorithms, e.g., using RSA, DSA, ECDSA, or EdDSA.

[0049] Furthermore, in a fourth step, the certificate holder Inh generates a first certificate Zertl, which includes the first public key Privl, information about the certificate holder Inh, and a first validity period, which can be defined by the start TI of the validity period of the first certificate Zertl and the end T2 of the validity period of the first certificate Zertl.

[0050] Now, in a fifth step (S5), the certificate holder (Inh) sends the first certificate (Zertl) to the certificate authority (CA), which signs this first certificate (Zertl) in a sixth step (S6) with the private root key (PrivCA). For this, the first certificate (Zertl) is hashed using a predefined algorithm and then signed with the root key (PrivCA).

[0051] The steps described above create the digital signature sig(PrivCA), which is stored together with the certificate content Zertl. The resulting document Zertl+sig(PrivCA) is the certificate signed by the Certificate Authority (CA). The signature sig(PrivCA) allows anyone who receives the signed certificate Zertl to verify the certificate's authenticity and integrity (i.e., to validate the signature or the signed certificate) by retrieving the root certificate ZertCA, extracting the public root key PubCA from it, and obtaining the hash value by decrypting the signature sig(PrivCA). This hash value can be compared with a hash value obtained by hashing the content of the first certificate Zertl using the same cryptographic hash function used to create the signature (e.g., SHA-256). If the hash values ​​match, this confirms the integrity and authenticity of the first certificate Zertl.If the hash values ​​do not match, this means that the certificate's content has been altered or the signature is invalid. In this case, the certificate should be considered untrusted.

[0052] It should be noted that the creation of the first certificate (Zertl) can also take place at the Certificate Authority (CA) if the certificate holder (Inh) sends the first public key (Publ) and their information (i.e., information about the certificate holder (Inh) of the first public key (Publ)) to the CA. The CA can then generate the first certificate (Zertl) and sign it immediately afterward.

[0053] It should be noted that signing by the Certificate Authority (CA) is by no means mandatory and could be omitted, for example if the certificate holder is the Certificate Authority (CA) itself.

[0054] The signed first certificate (Zertl) can be returned to the certificate holder (Inh) in a seventh step (S7) and / or stored in the certification authority (CA) and made available to third parties there.

[0055] As the end T2 of the validity period of the first certificate Zertl approaches, or if it has already expired, the creation of a second certificate Zert2 can begin. This second certificate should have a start date T3 after the start date TI of the validity period of the first certificate Zertl. Preferably, the validity periods of the two certificates Zertl and Zert2 can overlap, i.e., T3 <T2, oder der Beginn T3 des Gültigkeitszeitraums des zweiten Zertifikats Zert2 kann mit dem Ende T2 des Gültigkeitszeitraums des ersten Zertifikats Zertl übereinstimmen, d.h. T3=T2.

[0056] The second certificate, Zert2, is created analogously to the first certificate, Zertl, either by the certificate holder, Inh, or by the certification authority, CA. In other words, in an eighth step, S8, the second private key, Priv2, and the second public key, Pub2, are generated, analogous to the first private key, Privl, and the first public key, Publ. Then, in a ninth step, S9, the second certificate, Zert2, is generated, containing the second public key, Pub2, the certificate holder's information, Inh, and the second validity period, T3 and T4.

[0057] As per the invention, the second certificate, Zert2, is now signed in a tenth step, S10, using the first private key, Privl. This can only be done by the certificate holder, Inh, since only they possess the first private key, Privl. Thus, this signature, sig(Privl), is a sign that the issuer of the signature, sig(Privl), is the same person who was the certificate holder, Inh, of the now expired first certificate, Zertl.

[0058] If a third party receives the second certificate, Zert2+sig(Privl), signed in this way, it can be validated. The third party can use the second certificate, Zert2, to, for example, verify the authenticity and integrity of a message received from the certificate holder, Inh, or to encrypt a message to be sent to the certificate holder, Inh. Validating the second certificate, Zert2, can be done as follows: First, the already expired first certificate, Zertl, is retrieved. This certificate, signed by the Certificate Authority (CA) as described above, is Zertl+sig(PrivCA). It can be retrieved from the third party's internal storage, from the Certificate Authority (CA), from the certificate holder, Zertl, or from another source.The second certificate, Zert2+sig(Privl), signed with the first private key, is then verified using the first public key, Publ, contained in the first certificate, Zertl. This verification process is analogous to the method described above for verifying the first certificate, Zertl+sig(PrivCA). That is, the signature, sig(Privl), is decrypted using the first public key, Publ, to obtain a hash value. Similarly, the second certificate, Zert2, is hashed using the same hash algorithm that was used to generate the signature. The hash values ​​are then compared to see if they match. If they do, it can be concluded that the second certificate, Zert2, was signed by the same certificate holder, Inh, who also created the (outdated) first certificate, Zertl, since only this certificate holder, Inh, possesses the first private key, Privl.

[0059] Furthermore, the signed first certificate Zertl+sig(PrivCA) can be validated as described above. This verifies that the first certificate Zertl was signed by the certification authority CA at time TO. Ideally, the certificate ZertCA of the certification authority CA is still valid at the time of validation.

[0060] The described method thus allows a chronological chain of certificates Zertl, Zert2 to be created, so that it can be traced that all certificates Zertl, Zert2 actually originate from the same certificate holder Inh, regardless of whether the certificate authority (CA) was compromised during the period T0-T3. To maintain high security standards, however, the second certificate Zert2 is usually signed by the certificate authority (CA), i.e., sent to the CA in step SI 1 with or without the signature sig(Privl), hashed there (where only the content of the second certificate Zert2, or both the second certificate Zert2 and the signature sig(Privl) can be hashed), and then encrypted with the private root key PrivCA, i.e., signed by the certificate authority (CA) in step S12.The second certificate signed in this way, Zert2+sig(Privl)+sig(PrivCA), can then optionally be returned to the certificate holder Inh in step S13 or made available to third parties in another way.

[0061] Alternatively, the second certificate, Zert2, can first be signed by the Certificate Authority (CA) before being signed with the first private key, Privl. In this case, when signing with the first private key, Privl, either only the content of the second certificate, Zert2, or both the second certificate, Zert2, and the signature, sig(CA), can be hashed and then signed or encrypted.

[0062] As the end of the validity period T4 of the second certificate Zert2 approaches, or if it has already expired, the creation of a third certificate Zert3 can begin. This third certificate should have a start date T5 after the start date T3 of the validity period of the second certificate Zert2. Again, the second certificate Zert2 and the third certificate Zert3 can overlap or follow each other directly.

[0063] The third certificate, Zert3, can essentially be created using the same process as the second certificate. In step S14, the third private key, Priv3, and the third public key, Pub3, are generated. Then, in step S15, the third certificate, Zert3, is generated. In steps S16 and S17, this certificate can be signed with at least one private key, Privl or Priv2, from one of the previous certificates, Zert3. Furthermore, the third certificate, Zert3, could be signed by the Certificate Authority (CA) as described above.

[0064] In one variant, the third certificate, Zert3, is signed only with the second private key, Priv2, which belongs to the second certificate, Zert2, and is located immediately before the third certificate, Zert3. The "only" here refers to signatures using other private keys of the certificate holder, Inh. In addition to the aforementioned chain signature, the third certificate, Zert3, can be root-signed by the certificate authority, as described above for the second certificate.

[0065] In a second option, the third certificate, Zert3, could be signed using all private keys, Priv2 (generating one signature per private key), belonging to all certificates, Zertl and Zert2, that precede the third certificate, Zert3. During signing, only the certificate content can be hashed, or, for at least one signature, it can be specified that the certificate content and at least one chain signature are hashed. In addition to the aforementioned signature, the third certificate, Zert3, can be signed by the Certificate Authority (CA), as described above for the second certificate, Zert2.

[0066] In a third scenario, the third certificate, Zert3, could be signed only with the private key Privl belonging to the first certificate, Zertl, in the chain of certificates Zertl, Zert2, Zert3, which is located at the beginning of the chain. This certificate, Zertl, at the beginning of the chain, is called the root certificate. The "only" here refers to signatures using other private keys of the certificate holder, Inh. In addition to the aforementioned chain signature, the third certificate, Zert3, can be signed by the certification authority, as described above for the second certificate, Zert2.

[0067] If a fourth, fifth, sixth, etc. certificate is to be created at a later date, the procedure described above for the second and third certificates (Cert2, Cert3) can be followed. Specifically, these certificates can only be signed with the private key belonging to the immediately preceding certificate or the root certificate, or with all private keys belonging to all preceding certificates.

[0068] What is not shown is that, to simplify validation, a strictly monotonically increasing serial number of the certificates can be inserted into each certificate as a fixed component.

Claims

Claims:

1. Computer-implemented procedure for creating signed certificates (Cert2), comprising the steps: - Generating a first private key (Privl), a first public key (Publ) and a first certificate (Zertl), where the first certificate (Zertl) includes the first public key (Publ), information about the certificate holder (Inh) and a first validity period (TI, T2), - Generating a second private key (Priv2), a second public key (Pub2) and a second certificate (Zert2), wherein the second certificate (Zert2) comprises the second public key (Pub2), the information of the said certificate holder (Inh) and a second validity period (T3, T4), wherein the second validity period (T3, T4) begins after the start of the first validity period (TI, T2), wherein the validity periods of the first certificate (Zertl) and the second certificate (Zert2) preferably overlap, characterized in that the method comprises the following step: Signing the second certificate (Zert2) with the first private key (Zertl).

2. The method of claim 1, comprising the step of: Signing the first certificate (Zertl) by a certificate authority (CA) using a private root key (PrivCA) that is associated with a public root key (PubCA), and - preferably signing the second certificate (Cert2) by a certification authority (CA) using the private root key (PrivCA) that belongs to the public root key (PubCA).

3. Method according to claim 2, wherein the second certificate (Cert2) is created by the certificate holder (Inh) and signed with the first private key (Publ), then sent to the certification authority (CA) and signed there using the private root key (PrivCA), wherein, when signing using the private root key (PrivCA), a hash value of the content of the second certificate and the signature with the first private key (Certl) is preferably formed.

4. Method according to any one of claims 1 to 3, comprising the following steps for verifying the second certificate (Cert2): - Verification of the signed second certificate (Cert2) using the first public key (Publ) contained in the first certificate (Certl) and - preferably, verification of the signed first and / or second certificate (Zertl, Zert2) using the public root key (PubCA), which was preferably taken from a root certificate (ZertCA).

5. The method of claim 4 for verifying a message, comprising the steps of: Signing a message with the second private key (Priv2), sending the signed message to a recipient, - By the recipient, receiving the first and second certificates (Zertl, Zert2), Verifying the second certificate (Cert2), and - Verification of the signed message using the second public key (Pub2) contained in the second certificate (Cert2).

6. A method according to claim 4 or 5 for decrypting a message, comprising the steps of: - Receiving the first and second certificates (Cert2), Verifying the second certificate (Cert2), Encrypting a message with the second public key (Pub2), sending the encrypted message to the certificate holder (Inh), and - Decrypting the encrypted message using the second private key (Priv2).

7. Method according to one of the preceding claims, wherein the signing of the second certificate (Cert2) with the first private key (Privl) is carried out by hashing the second certificate (Cert2) and signing it with the first private key (Privl).

8. Method according to one of the preceding claims, wherein the first validity period (TI, T2) and the second validity period (T3, T4) overlap.

9. Method according to one of the preceding claims, wherein there is at least one further certificate (Cert3) of the said certificate holder (Owner), the validity period of which begins before the start of the first validity period or begins after the start of the second validity period, such that a temporal chain of certificates (Cert, Cert2, Cert3) of the said certificate holder (Owner) exists, in which a root certificate defines the start of the chain.

10. Method according to claim 9, wherein each certificate of the chain (Cert2, Cert3), with the exception of the root certificate (Certl), is signed with the private key (Privl, Priv2) belonging to the respective preceding certificate (Certl, Cert2).

11. Method according to claim 9, wherein each certificate (Cert2, Cert3) of the chain, with the exception of the root certificate (Certl), is signed with all the private keys (Privl, Priv2) belonging to the respective preceding certificates (Certl, Cert2).

12. Method according to claim 9, wherein each certificate (Cert2, Cert3) of the chain, with the exception of the root certificate (Certl), is signed only with the private key (Privl) belonging to the root certificate (Certl).

13. Method according to any one of claims 1 to 12, wherein all certificates (Zertl, Zert2, Zert3) comprise a strictly monotonically increasing serial number.

14. Computing unit for creating signed certificates (Zertl, Zert2, Zert3), wherein the computing unit is configured to perform the method according to any one of claims 1 to 12.

15. Computer-implemented data structure formed by the signed second certificate (Cert2) generated according to claim 1, wherein the second certificate (Cert2) is preferably signed with the private keys of all previous certificates.

Images