We performed some experiments on the low-level APDU protocols of several smartcards and authentication tokens. Results include sensitive cryptographic keys in the clear, PINs in the clear or easily reversible, stateless protocols that allow easy injection of commands and restrictions on key use enforced at the PKCS#11 (driver) level that are trivially bypassed at the APDU level.
Cryptographic hardware allows cryptographic operations to be performed inside a protected, tamper-resistant environment, so that sensitive keys are never leaked as plaintexts out of the device.
In this work we focus on devices that offer a PKCS#11 API for cryptographic operations (the most widely used standard). However, in contrast to previous research, we investigate what can be achieved by attackers that interact at the low-level (called APDU-level) communication protocol, and we show new attacks that we found on real devices.
Our findings will be presented in September at the 19th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2016). A preprint of the paper is available here.
Known attacks on PKCS#11
In the last 15 years, several API-level attacks to cryptographic keys have appeared in literature [1,2,3,4,5,6,7]. PKCS#11 defines a number of attributes for keys that regulate the way keys
should be used. As pioneered by Clulow [5], the attributes of a PKCS#11 key might be set so to give the key conflicting roles, contradicting the standard key separation principle in cryptography.
In the following picture we illustrate the simplest attack found by Clulow:
The attacker creates the orange key with can be used to wrap other keys (attribute wrap) and to decrypt ciphertexts (attribute decrypt). The key wrapping operation should allow for exporting sensitive keys in a secure way, but if the wrapping key can be used to decrypt arbitrary ciphertexts, we enable an easy attack: it is enough for the attacker to wrap the sensitive green key under the orange key and then ask for the decryption of the obtained ciphertext.
This kind of attack has been shown to be possible on real devices (see also our web page).
As a result of the attacks we found, at least one manufacturer released an update to their PKCS#11 driver, but not to the device firmware. This inspired us to investigate new attacks that bypass the PKCS#11 layer and interact directly at the low-level (i.e., the APDU-level) communication protocol, described below.
The PKCS#11 Middleware
The PKCS#11 API is typically implemented in the form of a middleware which translates the high-level PKCS#11 commands into low-level ISO 7816 Application Protocol Data Units (APDUs) and exposes results of commands in the expected PKCS#11 format.
All of the devices we have analyzed are based on the PC/SC specification for what concerns the low-level device API. It is important to notice that, even if PC/SC provides a standard layer for low-level communication, different devices implement the PKCS#11 API in various, substantially different ways. As a consequence, each device requires its specific PKCS#11 library on top of the PC/SC one.
The above picture gives an overview of a typical PKCS#11 middleware architecture with two cards requiring two different PKCS#11 libraries which communicates with the cards using the same PC/SC library.
APDU-level vulnerabilities
We have analyzed the following 5 devices:
- Aladdin eToken PRO (USB)
- Athena ASEKey (USB)
- RSA SecurID 800 (USB)
- Safesite Classic TPC IS V1 (smartcard)
- Siemens CardOS V4.3b (smartcard)
Our findings have been reported to manufacturers following a responsible disclosure process. Official responses from manufacturers, if any, will be made available in this web page. For readability, in the following we will refer to the above tokens and smartcards as eToken PRO, ASEKey, SecurID, Safesite Classic and Siemens CardOS, respectively.
We have focused on the security of:
- PIN enabling cryptographic operations with the device;
- Cryptographic operations independently of the knowledge of the PIN;
- Cryptographic keys leaked in the clear out of the device.
By analysing the low-level communication between the middleware and the token we found various problematic behaviours that we summarize below.
PIN insecurity
In Siemens CardOS and Safesite Classic the PIN is sent in the clear. An attacker can easily sniff the PIN even without having control of the computer, for example using a hardware USB sniffer. We report an APDU trace for Safesite Classic in which we can see, in red, the 4 digits PIN going through in the clear:
# Standard ISO-7816 Select file:
APDU: 00 a4 04 00 0c a0 00 00 00 18 0a 00 00 01 63 42 00
SW: 90 00
# Standard ISO-7816 Verify:
APDU: 00 20 00 01 08 31 32 33 34 00 00 00 00
SW: 90 00
The other three devices performs a challenge-response authentication. We report an APDU trace for eToken PRO in which we can see, in red, the challenge and the response:
# Custom Get challenge:
APDU: 80 17 00 00 08
SW: df 89 61 34 62 05 13 36 90 00
# Custom External authenticate:
APDU: 80 11 00 11 0a 10 08 64 d5 97 15 4a 44 eb 23
SW: 90 00
For eToken PRO and ASEKey we have reverse-engineered the middleware protocol. Once the algorithm to compute the response is known, an attacker can try all possible PINs and check whether or not the response computed from the challenge and the PIN matches the one in the trace. For numeric PINs this is particularly effective.
Interestingly, the PIN can be always sniffed if the attacker can attach to the application which gets the PIN from the user. This can be mitigated by running authentication at a different privilege (as discussed in the threat model section in the paper).
Cryptographic operations performed out of the device
We discovered that in Siemens CardOS, eToken PRO and SecurID encryption and decryption under a sensitive symmetric key is performed entirely by the middleware. For eToken PRO we discovered a similar behaviour for encryption and decryption under RSA session keys.
We report an example APDU trace for eToken PRO that retrieves a DES cryptographic key from the token in order to perform a key wrapping operation in software. Notice that key wrapping should be used to securely export keys as ciphertexts.
# Fetch the key for key wrapping: plain key value in red color
APDU: 80 18 00 00 04 0e 02 00 00 18
SW: 17 3f ff ff ff ff 01 08 3f 44 5f c4 eb 76 f1 86
06 64 65 73 6b 65 79 00 90 00
In Siemens CardOS encryption under a symmetric sensitive key sends no APDUs to the device, giving evidence that the device is not even involved in performing the operation and that the key is directly stored in the middleware.
Cryptographic keys leaked in the clear
This is an APDU trace we recorded during a 3DES symmetric key generation on the SecurID token. The key (in red) is transmitted in the clear from the middleware to the token:
# 3DES Secret key generation
APDU: 80 16 00 00 1a 72 35 be 4e aa de 2d 47 72 b2 8b
47 5f de 63 4d 7e 30 a5 f0 ac 5f c0 56 c6 90
SW: 90 00
The key is generated by the library and then transferred to the token: it can be leaked by either attaching to process memory or sniffing the communication channel.
The most surprising behaviour is shown by the Athena ASEKey token that reuses the authentication challenge (sent in the clear) as the value of freshly generated DES keys. Even more surprisingly, the challenge value is sent back to the token encrypted under an RSA public key, apparently to protect its confidentiality.
Security analysis and threat model
We classify threat scenarios depending on the attacker capabilities:
- Administrator privileges, can sniff the PIN, use it to perform cryptographic operations and any PKCS#11 or APDU attack.
- Physical access to the host: can install physical key-loggers and USB sniffers.
- User privileges:
- Monolithic: the application is run by the same user as the attacker, who can easily sniff and alter data by attaching to the application process;
- Separate authentication mechanism: the application is run by the same user as the attacker, but the authentication is managed by a separate software with higher privileges or hardware (e.g. biometric);
- Separate privileges: the middleware layer is run at a different privilege level and the attacker cannot attach to it and observe or alter APDUs.
In the paper we give, for each device, a detailed analysis of what attacks are enabled under each threat scenarios.
We summarize the APDU-level attacks we found on the five devices we tested.
1. PKCS#11-level attacks for comparison.
2. Requires reverse engineering of the authentication algorithm and bruteforcing.
3. Leakage occurs only during generation.
4. Requires access to middleware memory.
5. Possible for RSA Authentication Client version < 3.5.3.
Fixes and mitigations
Compliant PKCS#11 devices should implement all the cryptographic operations inside the hardware. This would prevent all of the attacks we have discussed so far, except for the ones on authentication. However, fixing this at the hardware level requires to redesign the device and is probably just not affordable, in general.
In our analysis we show that having separate authentication and privileges is a highly secure setting that fixes the problem of cryptographic operations implemented at the library level and, at the same time, protects PIN authentication. It is worth noticing that running the middleware with separate privileges can be done transparently to the application while having separate authentication requires to modify the application so that the login step is managed by separate software or hardware.
Contacts
This research has been developed by:
- Claudio Bozzato (Ca’ Foscari University)
- Riccardo Focardi (Ca’ Foscari University and Cryptosense)
- Francesco Palmarini (Ca’ Foscari University)
- Graham Steel (Cryptosense)
You can contact us at ‘focardi at unive dot it’ or ‘graham at cryptosense dot com’.
References
[1] R. Anderson. The correctness of crypto transaction sets. In Revised Papers from the 8th International Workshop on Security Protocols, London, 2001. Springer LNCS 2133.
[2] M. Bond. Attacks on cryptoprocessor transaction sets. In Proceedings of the 3rd International Workshop on Cryptographic Hardware and Embedded Systems (CHES’01), Paris, 2001. Springer LNCS 2162.
[3] M. Bond and R. Anderson. API level attacks on embedded systems. IEEE Computer Magazine, 34(10):67–75, October 2001.
[4] M. Bortolozzo, M. Centenaro, R. Focardi, and G. Steel. Attacking and fixing PKCS#11 security tokens. In Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS’10), ACM, 2010.
[5] J. Clulow. On the security of PKCS#11. In 5th International Workshop on Cryptographic Hardware and Embedded Systems (CHES’03), Springer, 2003.
[6] S. Delaune, S. Kremer, and G. Steel. Formal analysis of PKCS#11 and proprietary extensions. Journal of Computer Security, 18(6):1211–1245, November 2010.
[7] D. Longley and S. Rigby. An automatic search for security flaws in key management schemes. Computers and Security, 11(1):75–89, March 1992.