^{1}

^{2}

^{3}

^{4}

^{1}

^{2}

^{3}

^{4}

In 2007, a real faked X.509 certificate based on the chosen-prefix collision of MD5 was presented by Marc Stevens. In the method, attackers needed to predict the serial number of X.509 certificates generated by CAs besides constructing the collision pairs of MD5. After that, the randomness of the serial number is required. Then, in this case, how do we predict the random serial number? Thus, the way of generating serial number in OpenSSL was reviewed. The vulnerability was found that the value of the field “not before” of X.509 certificates generated by OpenSSL leaked the generating time of the certificates. Since the time is the seed of generating serial number in OpenSSL, we can limit the seed in a narrow range and get a series of candidate serial numbers and use these candidate serial numbers to construct faked X.509 certificates through Stevens’s method. Although MD5 algorithm has been replaced by CAs, the kind of attack will be feasible if the chosen-prefix collision of current hash functions is found in the future. Furthermore, we investigate the way of generating serial numbers of certificates in other open source libraries, such as EJBCA, CFSSL, NSS, Botan, and Fortify.

Digital certificates are adopted widely in Internet, which is a basic security measurement. Many principals, such as clients and servers, depend on digital certificates to authenticate each other. If an attacker can forge other’s digital certificate, he/she may impersonate other’s identity and access sensitive information. This is one of serious threats for the public.

The security of digital certificates is based on the digital signature algorithms and hash algorithms. If an attack against these algorithms occurs, the digital certificates based on these algorithms cannot be trusted any more. Among attacks, collision of hash algorithms is one of the most serious threats. Since the first real MD5 collision attack was presented by Wang [

At Eurocrypt 2007, the different certificates with the same signature were created firstly by Stevens based on the chosen-prefix collision attack of MD5 [

The method of Stevens cannot forge a certificate from an existing certificate because the second preimage attack of MD5 is hard so far. The method needs to construct two certificates based on chosen-prefix collision attack of MD5 before submitting one of them to apply for a certificate to a CA. The implementation of the process has two key issues, one related to the collision pair construction of MD5 and the other to some fields controlled by CAs, such as serial number, in certificates, which attackers need to predict before submitting the application. Against the threat, Stevens gave two suggestions for CAs: one is to replace MD5 algorithm with other secure hash algorithms (such as SHA-256) because chosen-prefix collision of other hash algorithms does not occur at present; the other is to add a sufficient amount of fresh randomness at the appropriate fields (such as serial number) in order to prevent attackers from predicting if MD5 cannot be replaced at once [

In this paper, we will focus on whether the randomness of some fields in certificates is enough to prevent attackers from predicting. Since the detailed codes of business CAs are not public, we review the way of generating certificates by open source software OpenSSL to find how to predict the values of some fields in certificates. OpenSSL uses a pseudo random number generator (PRNG) to output random numbers. Some literatures related to the security of the PRNG have been proposed [

In this paper, we have three contributions as follows:

We find a vulnerability of OpenSSL that the field “not before” in certificates leaks the time of generating certificates, which is the seed of generating the field “serial number,” so that it is possible to predict the value of “serial number.”

We give the predicting method for the field “serial number” and forge certificates based on the proposed method and Stevens’s method.

We investigate five other open source libraries and find similar vulnerability in two libraries, EJBCA and NSS.

The paper is organized as follows. In Section

In X.509 certificates, the signature of CA is the most important part to prevent from forging. Any modification of contents in certificates would make the change of CA’s signature, in other words the change of Hash value. If a user A’s certificate has existed, we cannot forge the certificate directly because it needs to construct the second preimage of hash value of the certificate. However, we can use other user B’s identity to apply a certificate for CA, and generate a chosen-prefix collision pair, which can forge A’s certificate.

According to the chosen-prefix collision, the prefixes p and

Before that, identical-prefix collision had been studied, which is easier to be constructed than chosen-prefix collision. Although identical-prefix collision can be used to forge certificates, the kind of forgery is meaningless in practical attacks because the user’s identity is in the prefix and cannot be changed.

The overview of collision complexities is in Table

The overview of collision complexities.

MD5 | |

| |

identical-prefix | chosen-prefix |

| |

| |

| |

SHA-1 | |

| |

identical-prefix | chosen-prefix |

| |

| |

To forge a certificate, we need to know which part of certificate is as the prefix and which part of certificate the collision pair is placed on. The data structure of X.509 certificate is in Table

The data structure of X.509 certificates.

field | comments | example |
---|---|---|

X.509 version number | Standard X.509 | Version 3 |

| ||

Serial number | Chosen by CA | 0x01000001 |

| ||

Signature algorithm identifier | Standard X.509 | MD5withRSAEncryption |

| ||

Issuer distinguished name | Identity of CA | CN=“xxx CA” |

L=“xxxxx” | ||

C=“xx” | ||

| ||

Not valid before | Controlled by CA | Jan.1,2017,00h00m01s |

| ||

Not valid after | Controlled by CA | Dec.31,2017,23h59m59s |

| ||

Subject distinguished name | Identity of users | CN=“xxxxx” |

O=“xxxx” | ||

L=“xxx” | ||

C=“xx” | ||

| ||

Public key algorithm | Standard X.509 | RSAEncryption |

| ||

Subject public key info | Controlled by users | 0x98765432… |

| ||

Version 3 extensions | Standard X.509 | … |

According to the chosen-prefix collision attack, the generating collision pair is like random number, while only the field “subject public key info” is the analogy with random number. Thus, the collision pair constructed by chosen-prefix collision attack is placed in the field “subject public key info” (Table

To forge A’s certificate, we need to generate a chosen-prefix collision pair to construct two certificates, one of which is in the name of A and the other is in the name of B. Then, we submit B’s identity and public key to the CA and get its signature. The signature of A’s certificate is replaced, which can be verified successfully.

The flow of the forging a certificate is in Figure

The flow of forging a certificate.

In [

Thus, in this paper, we try to answer the two questions:

How do we predict the value of the field “serial number” if the CA chooses a random number as the serial number?

How do we predict the value of the field “not valid before” that is in the unit of second?

To answer the two questions, we need to know how CAs generate the value of the two fields. However, the different CAs may adopt different ways to filling the fields. Since the open source software OpenSSL [

We use OpenSSL 1.1.0e to review how a certificate is generated. Before 0.9.8 of OpenSSL, MD5 was a default configuration for creating message digests [

The authors in [

Input: n, b, where b is divided into 20-byte-length block bi

//entropy is 0 by default

//md is 20-byte states; s is 1023 bytes PRNG states

for i=1 to n do

t=size(

s[p:p+t mod 1023]=s[p:p+t mod 1023]

p=p+t+1 mod 1023

end for

q=min(q+size(b), 1023)

return

Input: r, where r is divided into 10-byte-length blocks

// r is defined and evaluated in the function

Output: b

for i=1 to n do

s[p:p+9 mod q]=s[p:p+9 mod q]

p=p+10 mod q

end for

return

The input parameter md_{0} of

When we use OpenSSL to generate a X.509 certificate, there are two ways to generate the serial number. In the configure file of OpenSSL “openssl.conf” (Figure

“openssl.conf”: the configure file of OpenSSL.

On the other hand, if the file “serial” does not exist, OpenSSL would use random number as the serial number of X.509 certificates. An example is in Figure

An example of X.509 certificate.

Reviewing the source code of OpenSSL, we can find it calls the function “

Part of x509.c.

After a serial of function calling, the functions “

RAND_add() and RAND_bytes() are called in bn_rand.c.

In the case, the parameter b of_{0} of

The source code of RAND_bytes().

In summary, the serial number depends on two time variables “tim” and “tv,” where “tim” is a 32-bit integer which records the number of seconds since 00:00:00 Jan. 1, 1970, and “tv” is a 64-bit integer which records the number of 100 nanoseconds since 00:00:00 Jan. 1, 1601, in Windows, while “tv” records the number of microseconds since 00:00:00 Jan. 1, 1970, in Linux. The two times are the current system time.

The valid time of X.509 certificate depends on two times: “not before” and “not after.” The different time between “not before” and “not after” is the valid time.

In the source codes of OpenSSL, x509.c generates the content of a X.509 certificate (Figure

Input: x, startdate, enddate, days

Output: x

If(startdate==NULL)

X509_gmtime_adj(s,0)

else

…

If (enddate==NULL)

X509_time_adj_ex(s,days,0,0)

else

...

Since the parameter “startdate” is set as NULL when the function is called, the data field “not before” of certificates is set as the current time of system. The detail code is in X509_vfy.c by a serial of functions calling (Figure

The default value of “not before” is the current time of system.

In Figure

From above analysis, the serial number and “not before” depend on the system time when the certificate is generated in OpenSSL. In addition, the value of “not before” is the time when generating the certificate. Thus, we know some information of the seeds of the serial number.

In [

The above serial number generator of X.509 certificates in OpenSSL is an example of LESL. The current time of the day in microseconds provides about 36 bits of entropy. However, since “not before” of certificates leaks the time in seconds, as the part of seeds of serial number, we can try every 100 nanoseconds (in Windows) or microseconds (in Linux) to find which seed is used. Thus, the entropy is lost, and only 20 bits (10^{6}). In the next subsection, we will make the entropy reduce to 10 bits (10^{3}).

In [

Obviously, according to the difference of the two times, attackers can control the time when a CA generates a certificate because the value of "not before" directly shows the time. Furthermore, the serial number depends on the time in seconds and in nanoseconds in OpenSSL (Figures

The testing result for timing precision.

Operation system | Timing Precision | Computation Complexity |
---|---|---|

Windows XP | 10ms | |

| ||

Windows 7 | 1ms | |

| ||

Ubuntu 14.04 | 1ms | |

From Table

According to the above discussion, attackers can predict the serial number and “not before” of a certificate. To verify the conclusion, we use Algorithm

Step

Step

and computes

Step

microsecond (for Linux) in

Step

Step

(for Windows XP)

(for Ubuntu)

Step

with the seed of

Step

to generate forged certificates according to the Stevens’s method [

Step

In Windows XP, the time precision is 0x18730 100nanoseconds (=100144). So in Step 5, we select randomly a value of m; the success probability is 0.01; in other words, we submit the application more than 69 times; the success probability is more than 50%. In Ubuntu, the time precision is 0x3f0 microseconds (=1008). So the success probability is 0.001.

The testing result shows that the real serial number of the certificate is one of the candidate serial numbers that we predict (in Table

Forged certificate.

Field | Submitted Certificate | Forged Certificate |
---|---|---|

Serial number | cd e9 6e da bc a0 04 f4 | cd e9 6e da bc a0 04 f4 |

| ||

Signature algorithm identifier | MD5withRSAEncryption | MD5withRSAEncryption |

| ||

Issuer distinguished name | My Test CA | My Test CA |

| ||

Not valid before | 0x59c5905d | 0x59c5905d |

| ||

Not valid after | 0x5f692add | 0x5f692add |

| ||

Subject distinguished name | My Tes1, tes1@cer1.com | My Tes2, tes2@cer1.com |

| ||

Public key algorithm | RSAEncryption | RSAEncryption |

| ||

Subject public key info (2048bit) | BE 4F C4 66 2B AB 69 FB B9 50 78 55 12 33 9C E3 | 00 48 C7 2A F7 D3 19 0C C9 24 1D 43 D5 CB B4 6C |

25 7B B3 9A A4 2F D9 F6 C7 56 C9 9A 38 D8 08 5A | E4 AD 87 60 4E 74 F1 C6 41 23 D8 17 7C 85 20 DB | |

00 00 00 00 C8 4C B9 00 6F E2 2B E0 91 09 8F F6 | 00 00 00 00 B3 73 81 B5 62 8C BD 7A 91 09 8F F6 | |

9C EB 64 14 35 B3 01 47 DC FC C1 81 DD 96 93 9E | 9C EB 64 14 35 B3 01 47 DC FC C1 81 DD 96 93 9E | |

61 07 07 0E 3B 5F F7 C3 B8 FF AE AB 40 32 56 2B | 61 07 07 0E 3B 5F F7 C3 B8 FF AE AB 40 32 56 2B | |

21 21 CC B7 CB 4D DD C4 78 5D C1 02 02 83 09 88 | 21 21 CC B7 CB 4D DD C4 78 55 C1 02 02 83 09 88 | |

26 DD 3D 51 7A 5D 4A E7 7D 53 4E B3 B4 D5 D0 72 | 26 DD 3D 51 7A 5D 4A E7 7D 53 4E B3 B4 D5 D0 72 | |

FD 20 B5 58 F2 3B AE 06 D7 17 B5 FD DB 02 22 DC | FD 20 B5 58 F2 3B AE 06 D7 17 B5 FD DB 02 22 DC | |

2A BD B8 D8 9B ED B7 D1 B0 83 F6 8F 98 69 BD 8E | 2A BD B8 D8 9B ED B7 D1 B0 83 F6 8F 98 69 BD 8E | |

9B 0D 44 71 ED 86 A6 80 1A A6 39 5D E7 88 E0 CE | 9B 0D 44 71 ED 86 A6 80 1A A6 39 5D E7 88 E0 CE | |

0B F5 C5 F9 D6 5C 27 35 A0 F0 65 93 FE CA D3 DA | 0B F5 C5 F9 D6 5C 27 35 A0 F0 65 93 FE CA D3 DA | |

42 AC 0A 98 AB B9 49 70 28 85 8C 46 31 B7 3F 9D | 42 AC 0A 98 AB B9 49 70 28 85 8C 46 31 B7 3F 9D | |

28 32 19 5E 45 7C 79 36 81 D6 04 9C 40 3E AA FA | 28 32 19 5E 45 7C 79 36 81 D6 04 9C 40 3E AA FA | |

AA AD 19 1A 78 82 4C D2 52 06 0B E4 05 CF 4A 39 | AA AD 19 1A 78 82 4C D2 52 06 0B E4 05 CF 4A 39 | |

97 41 FD 43 AB 90 A3 0C 20 59 C7 EF DD 5B 70 0E | 97 41 FD 43 AB 90 A3 0C 20 59 C7 EF DD 5B 70 0E | |

82 79 54 AD 5E 2D 30 95 54 97 C6 10 4F CA 20 59 | 82 79 54 AD 5E 2D 30 95 54 97 C6 10 4F CA 20 59 |

Since the value of “not before” leaks the time of certificates’ generation, attackers can limit a narrow range of the seeds for generating serial numbers in OpenSSL. The problem shows that the entropy of the seed is too low, which cannot guarantee the randomness of serial numbers. Thus a natural idea is to add entropy of the seed. In Figure

The other idea is that the value of "not before" should be set a future time instead of the current system time. For example, the value can be set as 00:00:00 of the second day after the day of application. Thus, attackers cannot know the exact time when the certificate is generated.

We have investigated other open source libraries generating certificates, EJBCA [

EJBCA is an open source PKI Certificate Authority software based on Java technology. We reviewed the source codes of EJBCA Community 6.10.1.2. In EJBCA, a tool called CertTool is provided to generate certificates, where is in

From Figures

The valid time of certificates in EJBCA.

The serial number of certificates in EJBCA.

Obviously, the problem of EJBCA is similar to OpenSSL. We can get “not before” of certificates easily, then know the seed of “SHA1PRNG,” and predict the serial number.

CFSSL is an open source PKI/TLS toolkit developed by CloudFlare. We reviewed the source codes of CFSSL 1.2 in order to find how the valid time and serial number of certificates are generated.

From Figure

The valid time and the serial number of certificates in CFSSL.

NSS is a set of libraries supporting cross-platform network security services and developed by Mozilla. We reviewed the source codes of NSS 3.38 to find the way that the valid time and serial number of certificated are generated. The tool creating certificates is in

From Figure

The valid time of certificates in NSS.

The serial number of certificates in NSS.

Botan is an open source cryptography library written in C++. We reviewed the source codes of Botan 2.6 to find the way that the valid time and serial number of certificated are generated.

Form Figure

The valid time and the serial number of certificates in Botan.

The definition of rng() in Botan.

There are 5 kinds of random number generators in Botan, which is dependent on the command parameters “rng –system –rdrand –auto –entropy –drbg –drbg-seed=

Fortify is an open source application supported by the CA Security Council. We reviewed the source codes of Fortify 1.0.17 to find the way that the valid time and serial number of certificated are generated.

Form Figure

The valid time and the serial number of certificates in Fortify.

Concluding the above analysis on OpenSSL, EJBCA, CFSSL, NSS, Botan, and Fortify, we can compare the way generating valid time and serial number of certificates in Table

The comparison of 6 open source libraies.

Programming Language | Not Before | Serial Number | ||
---|---|---|---|---|

Is random? | Is predictable? | |||

OpenSSL | C | current time | | |

| ||||

EJBCA | Java | current time - 10minutes | | |

| ||||

CFSSL | go | current time | | |

| ||||

NSS | C | current time | | |

| ||||

Botan | C++ | current time | | |

| ||||

Fortify | Typescript | current time | | |

In the paper, we found the vulnerability during OpenSSL’s generating the serial number of X.509 certificates. It is possible to forge certificates based on the method presented by Stevens. Similarly, EJBCA and NSS have the same vulnerability among other 5 open source libraries.

Although MD5 has been replaced by CAs now, with the development of technology, new attacks for current hash algorithm adopted by CAs, such as SHA-256, will probably occur in the future. If the chosen-prefix collision of some hash algorithm occurs, the threat will work again probably. In that case, attackers still need to predict the value of fields controlled by CAs in order to construct forged certificates. Thus, the randomness of the serial number is important for CAs too.

The data used to support the findings of this study are included within the article.

The author declares that they have no conflicts of interest.

The project is supported by Key Research and Development Plan of Shandong Province, China (NO.2017CXGC0704), and Fundamental Research Fund of Shandong Academy of Sciences, China (NO.2018:12-16).