This hardware token was tested using Windows XP virtual machine with 32-bit Java version. This token is quite old and supports limited functional- ity. Even though its practical usability nowadays is negligible, its test results show the difference between testing software and hardware tokens.
The greatest difference is speed. While all three software token tests al- ways finished in under a minute,GNTtests took about 27 minutes. As the list below shows, most tests did not run completely. On the other hand,NSS andOpenCryptokiwere subjected to almost complete set of Caetus tests. It is impossible to give a precise estimation of how much time it would take if all the tests were performed. Even this time consumption clearly illus- trates the speed difference. Caetus is designed in such a way that speed is not a problem. Its tests mostly re-initialize every used key so that no key is utilized in more than one test, which leads to big resource consumption. Caetus also does not check against older versions of the PKCS#11 standard, which very likely will be issue with hardware tokens. The best solution to these issues seems to implement a separate set of tests in the tool.
Most tests, as they are written, failed. There were two common thrown exceptions that caused the tests to fail.CKR_FUNCTION_NOT_SUPPORTED
was the first cause. It is quite clear and simply means the token cannot perform the function. The functions affected by this were CopyObject, symmetricGenerateKeyand even symmetricSetAttributeValue.
The other common exception wasCKR_TEMPLATE_INCOMPLETE. It af- fectedCreateObject,UnwrapKey,DeriveKeyandGenerateKey. This most likely is the unfortunate result of the token being old and therefore designed to be compliant to an older version of the standard.
Failed Tests
∙ CreateObject- returnsCKR_TEMPLATE_INCONSISTENTwhen a key is created and the creation template hasCLASS,KEY_TYPEandkey value(=attributes required by standard) specified.
∙ Asymmetric SetAttributeValue- does not permit changing attributes
SENSITIVEtotrueandEXTRACTABLEtofalse.
∙ Key Extraction Attack- even with all the limitations it is still possi- ble to either create a RSA key pair with both WRAPandDECRYPT
=true and bothWRAP andDECRYPTcan be independently set at user’s leisure.
The tests ofGNT USB Security Tokenmust be considered very carefully, because the tests are targeted at the newest PKCS#11 version 2.30, but the token likely is compliant with version 2.10. Still, Caetus managed to detect a vulnerability toKey Extraction Attack. The model checker did not verify this and evaluated the model as safe, but that is due to the fact that Cae- tus determined the token cannot perform symmetric cryptography, which greatly limits the token model capabilities. In reality the token can use sym- metric cryptography and does support wrapping keys, which means the Key Separation Attackis a real threat.
It is also interesting to see thatGNT Tokenshares an implementation mis- take withOpenCryptoki, in which it also is not possible to setSENSITIVEto
trueandEXTRACTABLEtofalse. This seems like a common implemen-
tation error.
9.5 Chapter Conclusion
This chapter showed the results of performing Caetus automated tests on three hardware tokens and one software token. Only Softhsm token was evaluated as safe even againstKey Separation Attack. Still, the tests do not provide absolute guarantee of safety, as it is possible that a similar attack can still be performed outside of PKCS#11 API, because the token does sup- port exporting keys via other mechanics.
This chapter also outlined some common security vulnerabilities among the tokens. The most frequent one was susceptibility to the Key Separation Attack. Moreover there were discovered many cases where the implemen- tation does not adhere to the standard, such as the incorrectly behaving attributeALWAYS_SENSITIVEorEXTRACTABLE.
Conclusion
The thesis dealt with automated testing of PKCS#11 implementations with focus on security of stored cryptographic keys. It first described the stan- dard, then it analysed the functions and designed tests for them. It also listed known attacks regarding key security and outlined tests to determine if some of the attacks present a real threat to the tested implementations. The thesis also analysed possible restrictions to the Cryptoki interface and evaluated their impact. The thesis described model checking, including the limitations of the current implementation. Since the tool implemented in this thesis is written in Java, the thesis deals with both the advantages and drawbacks of using Java for this purpose. Finally the thesis presented Cae- tus, tool written for the purpose of automated testing of PKCS#11 tokens.
The Caetus tool has been published as open-source and it has already been used to analyse PKCS#11 tokens. Unfortunately some parts of the the- sis were less successful. The possible restrictions analysed in chapter 5 were not evaluated as practically viable. The model checking is still experimen- tal and not fully reliable. Still, the author believes that even these negative results must be described in order to help others avoid them.
The primary contribution of the thesis is the Caetus tool, which already discovered some vulnerabilities and non-standard implementations. The author also believes the analysis of Java PKCS#11 wrapper may be very useful to programmers who will use the wrapper in the future, as it may help them avoid the difficulties due to the lack of documentation. Last but not least the author would like to stress theDeriveKeyfunction. While the vulnerabilities to theKey Separation Attackor Downgrade Attackare severe, they are not really surprising and it is reasonable to expect that the forth- coming PKCS#11 implementations will have these vulnerabilities patched. The attacks againstDeriveKey, on the other hand, may be easier to over- look, but are just as dangerous. Therefore it is necessary to pay attention to this function, including theMiscellaneous simple key derivation mechanisms.
The author intends to continue to develop the Caetus tool. The plans for future work include improving the model checking, so that it is reliable and
the models accurately reflect the tokens. There are also plans to expand the tests, so that they can run better and faster with hardware tokens and are capable of working with older versions of the standard. The tests will also be more capable of adjusting themselves over the course of the run in order to better analyse the token functionality and to discover vulnerabilities.
The primary goal of the thesis was to develop a software that could perform automated analysis of PKCS#11 implementations. It was used to discover security vulnerabilities and non-standard function behaviour in some of the tested tokens. Therefore the author believes the thesis fulfilled its goal.
[1] ANTONELLI, C. Localized technological change and the evolution of standards as economic institutions. InInformation Economics and Policy, 1994, p. 195-216.
[2] ARMANDO, A., CARBONE, R., COMPAGNA, L. SATMC: a SAT-based Model Checker for Security-critical Systems. In Tools & Algorithms For The Construction & Analysis Of Systems: 20Th International Conference, TACAS 2014, 2014.
[3] BASIN D, MODERSHEIM S, VIGANO L. OFMC: A symbolic model checker for security protocols. InInternational Journal Of Information Se- curity[serial online]. August 2005;4(3):181-208
[4] BOND, M. Attacks on Cryptoprocessor Transaction Sets. In Crypto- graphic Hardware and Embedded System - CHES 2001 Third International Workshop. 2001, volume 2162, p. 220-234.
[5] BORTOLOZZO M., CENTENARO M., FOCARDI R., STEEL G. Attack- ing and fixing PKCS#11 security tokens. InProceedings of the ACM Con- ference on Computer and Communications Security, 2010, p. 260-269. [6] CHAN A. On optimal cryptographic key derivation. InTheoretical Com-
puter Science[serial online]. 2013. p. 21-36.
[7] CLULOW J. On the security of PKCS#11. InLecture Notes in Computer Science, 2003, 2779:411-425
[8] CORTIER V., DELAUNE S., STEEL G. A formal theory of key conjuring. In Proceedings - IEEE Computer Security Foundations Symposium [serial online]. 2007, p.79-82.
[9] DELAUNE, S., KREMER, S., STEEL, G. Formal analysis of PKCS#11. InProceedings - IEEE Computer Security Foundations Symposium, 2008, p. 331-344.
col Version 1.2.http://tools.ietf.org/. 2008. Available at:http://tools. ietf.org/html/rfc5246#page-25
[11] FROSCHLE, S., SOMMER, N. Concepts and proofs for configuring PKCS#11. InLecture Notes in Computer Science, 2012, p. 131.
[12] GREPCODE. Source code of Java PKCS#11 wrapper. Available at:
http://grepcode.com/file/repository.grepcode.com/ java/root/jdk/openjdk/6-b14/sun/security/pkcs11/
wrapper/PKCS11.java.
[13] JHALA R, MAJUMDAR R. Software Model Checking. ACM Com- puting Surveys [serial online]. October 2009;41(4):21:1-21:54. Available from: Business Source Complete, Ipswich, MA. Accessed May 14, 2014. [14] KAUFFMAN, R. J., TSAI, J. Y. With or without you: The counter- vailing forces and effects of process standardization. InElectronic Com- merce Research and Applications[online], 2010, 9 (2010), p. 305-322. Avail- able at: http://www.sciencedirect.com/science/article/ pii/S1567422309000908
[15] KUMAR, Y., MUNJAL, R., SHARMA, H. Comparison of Symmet- ric and Asymmetric Cryptography with Existing Vulnerabilities and Countermeasures. In IJCSMS International Journal of Computer Science and Management Studies. 2011. Vol. 11, Issue 03.
[16] MCMAHON, S. RSA Security Inc. Public-Key Cryptography Stan- dards - PKCS#11 - v230 [online]. 2009. Available at: http://www. cryptsoft.com/pkcs11doc/v230
[17] OpenDNSSEC. SoftHSM.http://www.opendnssec.org/. 2014. Available at
http://www.opendnssec.org/softhsm/.
[18] ORACLE. Java PKCS#11 Reference Guide. docs.oracle.com. Available
at: http://docs.oracle.com/javase/7/docs/technotes/
guides/security/p11guide.html.
[19] ORACLE. Java Cryptography Architecture Reference Guide. docs.oracle.com. 2011. Available at: http://docs.oracle.com/ javase/6/docs/technotes/guides/security/crypto/
Documentation. docs.oracle.com. 2014. Available at: http: //docs.oracle.com/javase/7/docs/technotes/guides/ security/SunProviders.html
[21] ORACLE. Bug report: The class SunPKCS11 is not available even in JDK/JRE 7 for WIndows 64 bit. bugs.java.com. Available at: http:// bugs.java.com/bugdatabase/view_bug.do?bug_id=7105065
[22] PARK, J. et al. An improved side channel attack using event informa- tion of subtraction. Journal of Network and Computer Applications. 2014, Volume 38, Issue 1, p. 99-105.
[23] SHANNON, C. E. Communication Theory of Secrecy Systems. InBell System Technical Journal. 1949, 28 (4), p. 656-715.
[24] SULLIVAN, N. How the NSA (may have) put a backdoor in RSA’s cryptography: A technical primer.ars technica. 2014. Available at:http: //arstechnica.com/security/2014/01/
[25] The Apache Software Foundation. Apache License, Version 2.0. apache.org. Available at: http://www.apache.org/licenses/ LICENSE-2.0
[26] The AVISPA team. HLPSL Tutorial. www.avispa-project.org [online]. 2006. Available at:www.avispa-project.org
[27] The AVISPA team. AVISPA v1.1 User Manual. www.avispa-project.org [online]. 2006. Available at:www.avispa-project.org
[28] The AVISPA team. The High Level Protocol Specification Language www.avispa-project.org [online]. 2001. Available at:
www.avispa-project.org
[29] VIGANO, L. Automated Security Protocol Analysis With the AVISPA Tool. InElectronic Notes in Theoretical Computer Science 155 (2006) 61-86. 2006.
[30] WANG, Y. Public Key Cryptography Standards: PKCS. InCoRR [on- line], 2012, abs/1207.5446. Available at: http://arxiv.org/abs/ 1207.5446