Random Data and Key Generation Evaluation of ...

Random Data and Key Generation Evaluation of Some Commercial Tokens and Smart Cards Ahmad Boorghany, Siavash Bayat Sarmadi, Parnian Yousefi,

Pouneh Gorji, Rasool Jalili

Data & Network Security Lab., Computer Engineering Department, Sharif University of Technology Tehran, Iran {boorghany, pyousefi, pounehg}@ce.sharif.edu, {sbayat, jalili}@sharif.edu

Abstract—In this paper, we report our evaluation of the strength of random number generator and RSA key-pair generator of some commercially available 1 constrained hardware modules, i.e., tokens and smart cards. That was motivated after recent related attacks to RSA public keys, which are generated by constrained network devices and smart cards, and turned out to be insecure due to low-quality randomness. Those attacks are mostly computing pair-wise GCD between the moduli in public keys, and resulted in breaking several thousands of these keys. Our results show that most of the tested hardware modules behave well. However, some have abnormal or weak random generators which seem to be unsuitable for cryptographic purposes. Moreover, another hardware module, in some rare circumstances, unexpectedly generates moduli which are divisible by very small prime factors. Keywords-Random Generator Evaluation; RSA Common Prime; GCD Attack; Hardware Security Module; Cryptography.

I.

INTRODUCTION

Modern cryptography has an essential dependency on random data. The bits in high-quality random data should be unpredictable to a great extent. Even a theoretically-strong cryptosystem may fail if its corresponding random number generator does not succeed to produce good random numbers. An example for this is the bug in Debian’s OpenSSL package, which caused by an improper random generation, and remained unpatched for two years between 2006 and 2008 [1]. The bug made the source of entropy for random number generator to become just a process id, which accepts only 32768 different values in most systems. Such low-entropy output was used to generate RSA private keys, hence it was reproducible by any attacker. Thousands of these weak keys are still being used in the Internet [2]. Another example is a recent major flaw in the random number generator of Android devices [3], resulted in considerable insecurities such as a private-key disclosure vulnerability in Bitcoin clients [4]. Due to an extensive scan of the Internet done by Heninger et al. [5], almost all weak keys which are detected in HTTPS or 1

Respecting the privacy of the providers and manufacturers of the evaluated tokens and smart cards, we do not disclose their names and brands.

SSH servers belongs to embedded or headless devices, including routers, firewall, and modems. This is because these devices do not have access to enough entropy sources, and/or the programmer simplified key generation algorithm to reduce the computational complexity, in order to satisfy the device constraints. In [5], authors also analyzed the behavior of Linux random number generator when most of its entropy sources are removed. This is similar to the situation of a constrained headless device. Another consequence of using low-quality random numbers is the generation of weak RSA keys. RSA public key is often consisting of a fixed public exponent (usually, 65537) and a modulus N, that is a product of two secret large primes. If a low-entropy random number generator is being used, it is possible to have the same prime in two different generated keys. In other words, we would have two moduli N1 and N2 which have a common factor p. Note that using true randomness, this probability is extremely low. For example, for generating 1024-bit moduli, this probability is less than 2-500. If we have two moduli N1 and N2 with a common prime factor p, we could compute the greatest common divisor (GCD) of these moduli to obtain p, considering that the GCD algorithm runs in a short time using Euclidean algorithm. Upon obtaining a non-obvious divisor of moduli, one can easily divide both by p to reach other primes q1 and q2, and completely factor the moduli. This is a well-known technique to attack a bulk of RSA public keys, which is applied in [5, 6]. One can compute all pair-wise GCDs between moduli in order to find probable weak keys, sharing a common prime factor. Lenstra et al. [6] ran a crawl on the Internet to collect all reachable RSA public keys, and then applied this attack along with other analyses on the security of gathered keys. Following the results of [5, 6], Bernstein et al. [7] obtained a collection of over 3,000,000 RSA public keys which are published by Taiwanese government. These public keys are signed by government certificate authority (CA) and were made public by a directory server. In fact, they are generated for people in Taiwan in order to equip citizens with a personal smart card, which can be used in government-to-person and person-to-person communications/negotiations. The provided

Proc. of 11th International ISC Conference on Information Security and Cryptology (ISCISC'14) © 2014 IEEE

smart cards have FIPS 140-2 Level 2 certification, and an RSA key-pair is generated inside the hardware. Bernstein et al. performed simple GCD attack on this database and immediately factored 103 of public moduli. Some of these moduli had obvious periodic patterns, which are far from being random. This shows that the random generator of primes can misbehave in some cases. Authors then attempted to extract probable patterns for other primes, and utilized latticebased methods to factor more moduli. This approach led to factorization of 81 more moduli. The results of [7] show that very constrained embedded systems such as smart cards have a potential of generating bad randomness. In this paper, we have evaluated the random number generator and RSA key generator of security hardware modules, which are commercially available in the market. These modules include security tokens and smart cards, both suffer from limited sources of entropy. We have collected various types of tokens and smart cards from different brands. A relatively-long random stream has been generated by each, and its strength has been evaluated using statistical tests. Moreover, many RSA keys have been generated by those modules to perform GCD attack. GCDs have been computed between all pairs of generated moduli, in addition to computing GCDs with more collected RSA keys from other databases (see Section III-A for a list). Our results show that some of these modules generate output streams with weak randomness quality. In a case, this deviation from uniform random output can be easily seen by a simple visual representation of frequency of repeated bytes. Furthermore, the output of randomness evaluation software shows failure of different tests on those output streams. On the RSA key evaluation side, we have encountered a token which under some circumstances generates moduli with surprisingly small prime factors. The organization of the paper is as follows. Section II covers theoretical and practical preliminaries, as well as an introduction of the used random evaluation software. Section III describes our methodology. It is divided into the method of evaluation of the results, and the method of generating random data and RSA keys. Section IV is devoted to the evaluation results and corresponding discussion. Finally, the conclusion is provided in Section V. II.

PRELIMINARIES AND TOOLS

A. Randomness Evaluation Tool NIST’s Statistical Test Suite (STS) [8] is a tool to evaluate the strength of random data for different purposes, including cryptography. It consists of several statistical tests such as frequency tests, template matching tests, and runs test. To evaluate the randomness of an input bit stream, it should be divided into k sequences of n bits. All tests are independently done to each sequence and output a success or failure per sequence. The proportion of successes for each test is a measure for evaluating randomness of the bit stream. There are an expected proportion of successes for a true random

stream, and an acceptance threshold below this. If the proportion of successes for a test becomes lower than this acceptance threshold, it is a sign of bad randomness. Parameters of STS, set up in our experiments, are explained in Section III-A. B. GCD Attack on RSA Public Keys RSA cryptosystem is based on the hypothesis that, until the factorization of an integer N is unknown, exponentiation modulo N is one-way. Therefore, to generate an RSA key, two large prime numbers p and q are chosen in a random manner (e.g., with a size of 512 bits each), and multiplied together to form N=p×q. Integers, p and q, are kept secret by the receiver to invert above exponentiation and to decrypt the message. Exploiting a high-entropy source of random data, if a typically-large N is generated, there will be no chance in practice that any two key generations share a common prime factor. On the other hand, if the random data source misbehaves, it will be probable that moduli generated in the process of two RSA key generations have a common prime factor. Consider N1 is generated by p×q1, and N2 is generated by p×q2, which means they have common factor p. Then, the attacker who does not know the factorization of N1 and N2 may compute their greatest common divisor (GCD) and obtain p. Finally, a simple division by p results in finding q1 and q2, and both composites are factored. Note that the GCD of two large numbers can be efficiently computed in polynomial time using Euclidean algorithm (actually within a few milliseconds for a typical computer). This technique is used in this paper to evaluate generated RSA keys. C. Tokens and Smart Cards A token is a USB stick which contains a microcontroller inside. This hardware is mainly used for security purposes, and its electronic circuit is usually designed to be tamperproof. A token may store (small) confidential data, or it may keep encryption/decryption keys. Access to the stored data is protected by user-defined PIN codes. It is common to store a cryptographic key inside a token in such a way that the key can never leave the token. Hence, the corresponding encryption and decryption have to be performed inside the token. A smart card is very similar to a token. It is a card containing a chip which is connected through contact or contactless interface. The main difference between a smart card and a token is that the latter can be directly connected to a computer using its USB interface, but the former requires a card reader. Both have a full-fledged microcontroller inside, which can be programmed at manufacturing phase. Their microprocessors are often 8-bit and runs in very low-speed, say 3 to 16 MHz. They have different types of memory such as RAM, ROM, EEPROM, and Flash memory. Except RAM, all other types are non-volatile, which means that their data persist after removing the token or smart card. Non-volatile memory is used to store programs and persistent data.

Tokens and smart cards can be programmed with arbitrary functionality. In order to use different types of tokens and smart cards in conjunction with third-party applications on PC, various standards are developed. In our experiments, we have used PKCS#11 standard to interact with most tokens and smart cards. PKCS#11 is a standard interface to talk to any cryptographic hardware module. It is included in the PKCS series of standards, published by RSA Laboratories, for the usage of cryptography in practice. A hardware module which supports PKCS#11, should provide a dynamic library (a .dll file in Windows or a .so file in Linux) along with a driver in its installation package. Applications on the PC directly use the PKCS#11 dynamic library and do not care about the actual protocol to communicate with the hardware. PKCS#11 defines a set of functions, which should be implemented in the dynamic library, such as C_GenerateKey, C_Encrypt, and C_GenerateRandom. Eliminating their prefix C_, their names are self-describing. Each hardware module may implement a subset of cryptographic algorithms. Hence, it provides a list of supported mechanisms, like RSA_PKCS_KEY_PAIR_GEN, SHA256_HMAC, and AES_CBC. Java Card is a specification developed by Oracle Corporation, which addresses the need to change the functionality of a hardware module after manufacturing. Card issuers, or even the end user, may need a custom logic to be executed inside the hardware. Using a smart card (or even a token) which supports Java Card, one can write a program in a simplified Java language, called applet, and loads it into the smart card. Then, a Java Card virtual machine inside the card will interpret its byte-codes and run desired program. Java Card specification provides many cryptographic functions, such as key generation for different encryption algorithms or generation of random data, which are available for the loaded applet. Two of our tested smart cards support Java Card specification. The PKCS#11 and Java Card APIs which are used in our experiments are detailed in Section III-B. III.

METHODOLOGY

A. Evaluation of Random Data and Keys Each test in STS [8] recommends a set of parameters in order to achieve a meaningful result. According to these recommendations, we have collected a bit stream of 10 million bits from each hardware module, and divided it into k=100 sequences of n=100000 bits. This way, we can leave all other parameters as their default values, except M, which is the substring size of non-overlapping template set of tests. We set M=1024 to obey recommended equation of M > 0.01×n. Note that we did not change the level of significance α. This is an acceptable average portion of failures, which is fixed in the source code of STS as α=0.01. That is the NIST’s recommendation of α for cryptographic usage. We have configured STS to run 161 tests which are instantiations of 15 distinct tests with different parameters. After running these tests on the generated bit stream of each hardware module, the output will be a set of successes and

failures for each test. The proportion of successes for all tests is computed for further analysis. Expected proportion of successes is 1-α=0.99. According to STS recommendation, acceptance threshold is 0.99 - 3×√α×(1-α)/k ≈ 0.96, where k=100 is the number of sequences. If any proportion becomes less than 0.96, which is equivalent to more than four failures, then the corresponding test will decide that the bit stream is not random. In addition to running above experiments on tokens and smart cards, we have generated a similar bit stream using Blum-Blum-Shub (BBS) random generation algorithm [9]. BBS is a secure but inefficient random generator whose security is provable, assuming integer factorization is hard. We ran a 1024-bit modulus BBS algorithm on a conventional PC in order to apply STS on its output, and use the results as the reference strong randomness. According to our results in Section IV, for most bit streams, at least one test from “Non-overlapping Template” set had a success proportion less than the acceptable threshold. This is the case even for BBS random generator, which is considered to be strong. It seems that one or two marginal failures from “Non-overlapping Template” set are acceptable. Therefore, we have separated the number of such failures in the reports of Section IV. The evaluation of generated RSA keys is based on computing pair-wise GCD between the public moduli, i.e., Ns. For any N, its GCD is computed with other generated Ns by the same hardware module and all other tokens or smart cards. In addition, GCDs on the generated Ns are computed with a database of collected RSA public keys, obtained from different sources. The main part of this database consists of more than 3.8 million TLS certificates and SSH keys, gathered by Heninger et al. [5] via crawling HTTPS websites and scanning SSH servers on the Internet. In fact, they have not published their database, however, provided an interface to their test engine on https://factorable.net/keycheck.html. We have uploaded each public key, generated by tokens or smart cards, to this interface in order to find any common prime factor. Moreover, we have downloaded the set of public keys, which are signed by the certificate authority of “Iranian Ministry of Industry, Mine, and Trade” (MOCCA). About 25000 1024-bit RSA public keys are fetched from MOCCA’s LDAP directory, accessible at ldap://ldap.gica.ir. However, the best choice for our experiments was the collection of generated public keys on Taiwanese personal smart cards, as explained in Section I. Unfortunately, after Bernstein et al. [7] found weak keys in this collection, the LDAP directory is inaccessible from ldap://moica.nat.gov.tw. B. Generation of Random Data and Keys On PKCS#11 tokens and smart cards, we have developed a Java application using IAIK PKCS#11 Wrapper. For generating random data, there is often no need to enter the module pin code. A working session is established via calling C_OpenSession, which is implemented in PKCS#11 DLL,

and then, calling C_GenerateRandom generates and returns the random buffer. The size of required random string is passed to C_GenerateData as an argument. Most tokens and smart cards do not generate more than 5000 bytes in a single run. Hence, we have called this function for many times to obtain 10 million bits. Although there is a function named C_SeedRandom to optionally seed the random generator inside the token, we did not use it in order not to hide the vulnerability of a module by injecting external random bits. The net duration of calling C_GenerateData is reported in Section IV as the random generation time. RSA keys are generated in a similar way on PKCS#11 modules. After opening a session, it is required to call C_Login and enter the module pin code, because generated RSA key-pair is stored on the module. Regarding the fact that CKM_RSA_PKCS_KEY_PAIR_GEN mechanism is supported by all tested hardware modules, we have called C_GenerateKey and passed the modulus size as parameters. This generates public key and private key, and both are stored in the module. Finally, the public key is returned by the function and its modulus N, is saved for GCD experiments. Note that it is required to use C_DestroyObject to remove both public and private keys from the internal storage of the module. Otherwise, its memory may become full during the process. The average time of calling C_GenerateKey is reported in Section IV. For testing Java smart cards, a Java Card applet is developed, which accepts two commands. Command 1 generates a block of random data, and command 2 is used to retrieve it. In Java Card specification, RandomData class is provided in the package javacard.security in order to generate random buffers. To instantiate an object from this class, parameter ALG_SECURE_RANDOM is passed to note that we need a cryptographically secure random buffer. Then, method generateData gets the buffer size and generates the random data. In Java Card, similar to PKCS#11, there is an optional method setSeed to seed the random number generator, but we did not use it. Traditional protocol of smart card communication is standardized in ISO/IEC 7816. It suffers from a maximum size of 254 bytes for payload in the response. As a result, command 2 should be repeated several times to retrieve the whole generated random data. The reports on the generation time in Section IV only include command 1. On the RSA key generation side, another applet is developed to instantiate an object from the class KeyPair. Passing ALG_RSA_CRT to KeyPair constructor indicates that we desire an RSA key generation. Moreover, the size of RSA modulus is passed in this step. Then, method genKeyPair do the actual job. All these tasks are done in command 1. Commands 2 and 3 are used to retrieve the generated N. Note that for the case of 2048-bit moduli, two responses are needed to retrieve whole bits of N.

To summarize, a total of 10 million bits of random data, and two sets of 1024-bit and 2048-bit RSA moduli, each one containing 100 keys, have collected from every smart card and token. The average time of random generation per bit, and the average time of RSA key generations are measured and reported in Section IV. These measurements on time are done in order to show probable relation/trade-off between the output quality and the generation time. IV.

EVALUATION RESULTS

We have evaluated five tokens and three smart cards. All tokens and one of the smart cards support PKCS#11. Two other smart cards are Java Cards, which means that developed applets, explained in Section III-B, are loaded into them in order to do the desired experiments. As a visual and intuitive representation of bit streams generated by the hardware modules, Fig. 1 shows the number of repetitions for each byte (i.e., the byte frequencies). For all modules, a 16-by-16 chart is shown where each cell represents one value between 0 and 255, and the number of occurrences of a value determines the color of corresponding cell. The color spectrum is designed such that the expected number becomes blue, and numbers getting far from this expectation turn to red. Fig. 1 shows an anomaly in the output of Smart Card 3. Comparing to the results of Blum-BlumShub and other random generators, the frequencies of bytes in the output of Smart Card 3 are far from their expected value.

TABLE I. Results of evaluating random data generation by the tested modules. NOTs are “Non-overlapping Template” tests. Hardware Module

Type

# of Unacceptable Proportions (+ NOTs)

Generation Time (μs/bit)

Eval.

Token 1

PKCS#11

0 (+ 1)

0.08

Good

Token 2

PKCS#11

0 (+ 0)

18

Good

Token 3

PKCS#11

0 (+ 1)

754

Good

Token 4

PKCS#11

0 (+ 0)

112

Good

Token 5

PKCS#11

0 (+ 0)

18

Good

Smart Card 1

PKCS#11

1 (+ 0)

0.08

Warn

Smart Card 2

Java Card

0 (+ 3)

18

Warn

Smart Card 3

Java Card

4 (+ 1)

4.6

Bad

Blum-BlumShub Algo.

-

0 (+ 1)

-

-

Token 1

Token 2

Token 3

Token 5

Token 4

5010

4882

Smart Card 1

Smart Card 2

Smart Card 3

4754

Blum-Blum-Shub

Figure 1. Shows the frequency of each byte in the generated bit streams. 16-by-16 matrix represents the frequency of each byte from 0 to 255. The expected value (i.e., 4882) is colored blue and the spectrum turns to red while getting far from this expectation. Blum-BlumShub analysis is included as a reference strong randomness.

A summery of results on the output of STS is provided in Table I. Output of STS for each bit stream is a set of success proportions. For each proportion, there is an acceptable threshold which is 0.96 in our setting (see Section III-A for more details). Table I shows the number of proportions below 0.96, where each one is a sign of bad randomness. As mentioned earlier, and can be seen in Table I, there is at least one test from “Non-overlapping Template” set, which fails even for the output of Blum-Blum-Shub generator (i.e., our reference random stream). Therefore, we have separated unacceptable proportions for “Non-overlapping Template” set of tests (NOTs) to allow better interpretation. Fig. 2 also shows the diagram of proportions on all modules. Dashed line is the acceptance threshold 0.96, and all proportions below that are unacceptable. The value of unacceptable proportions and the name of corresponding (failed) tests are written beside each point. There is one failure of NOTs in Blum-Blum-Shub output, and others have none or a few such failures. Smart Card 2 has three failures on NOTs and Smart Card 1 has one failure on Serial test. This is a warning on the randomness strength of the output for both hardware modules. The generated data by Smart Card 3 is exceptionally below desired strength and seems to be unsuitable for cryptographic purposes. It has five proportions below acceptance threshold, three of which are very low. Note that the random generation speed of Smart Card 3 is relatively fast in comparison to other smart cards or tokens. Moreover, all randomness generation issues are on smart cards rather than tokens. Evaluation of generated RSA keys has been done by computing pair-wise GCDs between each public key and other generated public keys, in addition to computing GCDs with a

set of collected public keys from other sources. Furthermore, we have downloaded about 25000 certificates from the certificate authority of “Iranian Ministry of Industry, Mine, and Trade” (MOCCA). These certificates are signed by MOCCA and made available for public in an LDAP server. Before starting our main experiments, we have tested GCD attack on this database itself. As expected, no common prime factors were detected between MOCCA signed keys. The results of GCD experiments on the generated RSA keys are summarized in Table II. We have generated 100 1024-bit keys and 100 2048-bit keys on each hardware module. The average generation time is also reported in order that one may find a relation between weaknesses and the generation time. TABLE II. Results of applying GCD attack on the generated RSA keys by each hardware module. Hardware Module

Type

1024-bit Generation Time (s)

2048-bit Generation Time (s)

# of Factored Moduli

Token 1

PKCS#11

9.7

42.0

0

Token 2

PKCS#11

19.3

153

0

Token 3

PKCS#11

3.9

15.2

0

Token 4

PKCS#11

14.8

148

0

Token 5

PKCS#11

19.0

103

11

Smart Card 1

PKCS#11

18.1

57.7

0

Smart Card 2

Java Card

1.98

12.7

0

Smart Card 3

Java Card

2.0

13.4

0

Figure 2. The success proportions of STS tests are shown for each hardware module. The acceptance margin is 0.96, which is determined by the dashed line. Proportions below this are signs of bad randomness. Blum-Blum-Shub results are provided as the reference strong randomness.

We have encountered a very unusual result during our GCD experiments. For the Token 5, 11 2048-bit keys out of 100 were factored. The GCD between these 100 keys and themselves resulted in finding very small common prime factors, e.g., three, five, and seven. That was very strange to us and most probably, it is an implementation bug in primality testing. We discussed this issue with the manufacturer. Fortunately, they have told us that this version of their token has been produced recently and in a very small number, meaning that it is easy to recall and replace all tokens after the investigation. V.

CONCLUSION

We have performed two types of evaluation on various tokens and smart cards available in the market. The random generators of these modules are evaluated using NIST’s Statistical Test Suite. Moreover, the GCD attack has been applied to the generated 1024-bit and 2048-bit RSA keys by these modules. Our results showed that one of the smart cards generates weak random data, and a token produces factorable modulus in its 2048-bit keys under some situations.

REFERENCES [1]

[2]

[3]

[4]

[5]

[6] [7]

[8]

[9]

S. Yilek, E. Rescorla, H. Shacham, B. Enright, and S. Savage, “When private keys are public: results from the 2008 Debian OpenSSL vulnerability," In Proc. 9th ACM SIGCOMM Conf., 2009, pp. 15-27. Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap: Fast Internetwide scanning and its security applications," In Proc. 22nd USENIX Security Symp., 2013, pp. 605-620. K. Michaelis, C. Meyer, and J. Schwenk, “Randomly failed! The state of randomness in current Java implementations.” In Proc. Topics in Cryptology–CT-RSA, 2013, pp. 129-144. V. Buterin. (2013, August 11). Critical Vulnerability Found In Android Wallets [Online]. Available: http://bitcoinmagazine.com/6251/criticalvulnerability-found-in-android-wallets/ N. Heninger, Z. Durumeric., E. Wustrow, and J. A. Halderman, “Mining your Ps and Qs: Detection of widespread weak keys in network devices,” In Proc. 21st USENIX Security Symp., 2012, pp. 205-220. A. K. Lenstra et al., “Public keys,” In Proc. 32nd Advances in Cryptology–CRYPTO, 2012, pp. 626-642. D. J. Bernstein et al., “Factoring RSA keys from certified smart cards: Coppersmith in the wild,” In Proc. 19th Advances in CryptologyASIACRYPT, 2013, pp. 341-360. National Institute of Standards and Technology (2010), STS: Statistical Test Suite (Version 2.1.1) [Software]. Available: http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html L. Blum, M. Blum, and M. Shub, “A simple unpredictable pseudorandom number generator,” SIAM J. Computing, vol. 15, no. 2, pp. 364383, 1986.