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 <dula...@wso2.com> 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 <me...@wso2.com> > 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- >> modules-d54734834d7e >> >> [2]Blog on PKCS #11 >> >> https://medium.com/@mevan.karu/standard-api-for-connecting- >> hsms-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 : me...@wso2.com >> Mobile : +94 71 202 8954 >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Dulanja Liyanage > Lead, Platform Security Team > WSO2 Inc. > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Mevan Karunanayake - Trainee Software Engineer | WSO2 Email : me...@wso2.com Mobile : +94 71 202 8954
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
