Hi all, Now I have almost completed the researching on usages and design of Crypto API[1]. Currently I am at the stage of designing the connector to carbon-kernel conforming to API specification. We already have an implementation of the Crypto API based on JCE providers. So, I extended my research on PKCS #11 JCE providers which are compatible with any PKCS #11 supported device where I can integrate HSM support directly through the JCE provider using current Crypto API implementation.
Following are the PKCS #11 JCE providers that I researched on and issues that I found related to them. PKCS #11 JCE Provider Related issues SunPKCS11 provider[2] - Limited set of functionalities. (Most of PKCS #11 mechanisms are not implemented.) OpenSC PKCS11 provider[3] - Limited set of functionalities. (Less functionalities than SunPKCS11) - Seems to be project is closed. (Site is also not accessible) - Lack of proper documentation. IAIK JCE provider[4] - Proprietary provider. IMB JCE provider[5] - Proprietary provider. So I have following two options; 1. Develop a universal JCE PKCS #11 provider which supports any HSM that supports PKCS #11. (This will be based on SunPKCS11/IAIK PKCS11 wrapper.) 2. Develop another implementation of Crypto API to provide HSM support. Major issues related to option 1 are, - It'll be an overhead, because Crypto-API implementation only requires encryption/decryption, sign/verification and, key and certificate retrieval functionalities of the provider. - Implementing a JCE provider is complex and time consuming task. (Doesn't get along with my current project plan) Even though option 1 has the advantage of not being application specific, considering the time limitations from above two options I am planning on taking option 2 where I can provide a Crypto API implementation with only required functionalities. *References* [1] Carbon Crypto service - https://github.com/wso2/carbon-crypto-service/ [2] SunPKCS11 JCE Provider Documentation - https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html [3] OpenSC PKCS #11 provider - https://github.com/OpenSC/OpenSC-Java/tree/master/pkcs11 [4] IAIK PKCS #11 provider - https://jce.iaik.tugraz.at/sic/Products/Core_Crypto_Toolkits/PKCS_11_Provider [5] IBM PKCS #11 provider - https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/pkcs11implDocs/ibmpkcs11.html Regards, On Wed, Aug 15, 2018 at 12:05 PM, Mevan Karunanayake <[email protected]> wrote: > Hi Dulanja, > > 1. I researched on both JCE providers and PKCS #11, but most of the HSM > vendors only provide the PKCS #11 implementation (In our case we are going > to use YubiHSM2 for testing and they only provide PKCS #11 implementation). > Also most of the vendors who provide the JCE implementation provide their > JCE implementation on top of their PKCS #11 implementation. So in my point > of view it is better to write a connector to directly talk to PKCS #11 > module without using HSM vendor provided JCE. > > 2. Currently we have an extension point developed for carbon kernel to use > external cryptographic providers and external key stores. I am planning on > using that endpoint and develop the connector conforming to that extension > point API specification. So as you asked HSM support can be used by any > wso2 product. > PR of adding extension point to carbon kernel - > https://github.com/wso2/carbon-kernel/pull/1818 > Repository of the carbon-crypto-service - https://github.com/wso2/carbon > -crypto-service/ > > On Tue, Aug 14, 2018 at 5:28 PM, Dulanja Liyanage <[email protected]> > wrote: > >> Hi Mevan, >> >> 1. Usually HSM vendors provide JCE providers that has the capability to >> communicate with the HSM. Did we research on that? If yes, what are the >> gaps in those that require us to develop a new connector for this? >> >> 2. Currently, in most of the usecases, IS uses the cryptographic >> capabilities provided by the carbon kernel. And the need to integrate with >> an HSM is not IS specific. Did we consider the platform level requirements >> and how to do this at the platform level? >> >> Thanks, >> Dulanja >> >> >> >> On Tue, Aug 14, 2018 at 3:30 PM, Mevan Karunanayake <[email protected]> >> wrote: >> >>> Hi all, >>> >>> >>> Hardware Security Module(HSM)[1 >>> <https://www.cryptomathic.com/news-events/blog/understanding-hardware-security-modules-hsms> >>> ] is a trusted, tamper resistant hardware device designed to perform >>> cryptographic operations. HSMs are mainly designed to overcome the major >>> issue with software cryptographic providers, which is the key management >>> process provided by them depends on the hardware and OS level security of >>> the host. >>> >>> Primary objective of the project is to integrate HSM support to IS to >>> provide cryptographic operations such as key management, encryption, >>> decryption, hashing etc. Right now IS supports only for software >>> cryptographic providers, by adding this feature provides capability of >>> supporting hardware cryptographic providers also. >>> >>> First goal is to decouple our connector from the details of underlying >>> HSM and provide a common logical view of the HSM to the connector. Public >>> Key Cryptography Standard (PKCS) #11 >>> <http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html> >>> [2 >>> <https://medium.com/@mevan.karu/standard-api-for-connecting-hsms-with-client-applications-6296eb187d89>] >>> is a common standard, which specifies an API for devices that hold >>> cryptographic information and perform cryptographic operations to >>> communicate with client applications. HSM vendor is responsible for >>> providing the API implementation and most of the HSM vendors provide >>> library implementation as a dynamic library(.so / .dll) file. >>> >>> Next task is to develop the connector using JAVA, a wrapper is required >>> to map JAVA calls to corresponding C calls and vice versa. IAIK PKCS#11 [ >>> 3 <http://javadoc.iaik.tugraz.at/pkcs11_wrapper/current/index.html>] >>> wrapper API is a library to access PKCS#11 modules from the Java >>> programming language. Wrapper works on top of PKCS#11 library >>> implementation provided by HSM vendor by mapping Java data structures and >>> function calls to C data structures and vice versa. >>> >>> Initial step of the project is to implement a product independent simple >>> Java command line client application to provide cryptographic operations >>> such as encrypting, decrypting, signing, sign verification etc. Following >>> diagram depicts the high level view of how application works with the HSM. >>> >>> >>> Here application talks to the IAIK wrapper through Java calls and >>> wrapper maps the Java calls to C. PKCS #11 module(.so / .dll file) is >>> responsible for mapping C request to native and mapping native response >>> from HSM to C. Then IAIK converts the response from PKCS #11 module to Java >>> and sends the response back to the application. >>> >>> Second step will be to develop a connector and integrate HSM to IS >>> product for cryptographic functionalities after evaluating the >>> possibilities and existing extension points. >>> >>> References >>> >>> [1] Blog on HSMs - https://medium.com/@mevan.karu >>> /secure-cryptographic-operations-with-hardware-security-modu >>> les-d54734834d7e >>> >>> [2]Blog on PKCS #11 >>> >>> https://medium.com/@mevan.karu/standard-api-for-connecting-h >>> sms-with-client-applications-6296eb187d89 >>> >>> [3] IAIK PKCS#11 Java Wrapper >>> >>> http://javadoc.iaik.tugraz.at/pkcs11_wrapper/current/index.html >>> >>> -- >>> Mevan Karunanayake - Trainee Software Engineer | WSO2 >>> Email : [email protected] >>> Mobile : +94 71 202 8954 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks & Regards, >> Dulanja Liyanage >> Lead, Platform Security Team >> WSO2 Inc. >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Mevan Karunanayake - Trainee Software Engineer | WSO2 > Email : [email protected] > Mobile : +94 71 202 8954 > -- Mevan Karunanayake - Trainee Software Engineer | WSO2 Email : [email protected] Mobile : +94 71 202 8954
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
