tiny ca助力互联网金融移动支付应用

1、应用场景
移动终端设备T通过互联网接入商业银行B，在T和B之间完成安全的帐务交易和交易结果反馈。
（qq：22066821，[email protected]）
2、业务需求
（1）识别在网络上终端（客户）的真实身份；
（2）保证网络上传送的交易信息不被篡改；
（3）保证网络上传送的交易信息不泄露；
（4）网络上的用户行为不可否认；
（5）建立安全的通信链路。

3、安全架构

采用数字证书的方式实现以上业务场景的业务需求，考虑到业务规模只是区域性质、在业务量上仅仅布署几万台移动终端设备、系统需求要求高度灵活，另外在项目上的投入比较小，计划自建简单CA数字证书签发验签系统，完成证书的生成、签发、验签等功能。为了严格的数据安全，在移动终端T上使用sdkey作为密钥对的生成、存储和保护设备；在CA端采用hsm（硬件加密模块、密码机、加密机）作为CA根密钥对的生成、存储和保护设备。
    图示：T(sdkey) -> https 双向认证 ->B前置 -> CA系统  -> hsm
CA采用JAVA EE系统架构，在JCA/JCE框架下，实现了X509 V3证书的根证自签名、证书请求生成、证书签发、签名验签、https双向认证等功能。

4、系统特点
通常情况下，用bouncycastal的安全组件或者keytool来搭建根证以及https双向认证都是比较简单的事情，他们都需要原始的公钥和私钥。但是本系统有一点不同就是双方的私钥是绝对安全的，分别在两端的sdkey和hsm中生成、存储，应用拿不到私钥明文，因此根私钥相关的证书签名不可能用软算法来实现；而且CA通过tcp协议链接hsm，hsm因为不同的型号、不同的厂商而指令协议不同。
考虑上上述情况，需要有专门的签名算法支撑服务。
4.1.实现基于hsm的安全provider
实现符合JCA/JCE要求的security.Provider,在jvm中，把签名任务接收过来，发送给hsm来完成后，把结果反馈给应用，从而避开sun和bouncycastle的安全组件。
4.2.构造签名算法
一般情况下，hsm提供的都是原始算法，比如sha1、rsa、sm2、sm3等等，证书签名算法却没有提供（这里说的证书签名算法包括：sha1withrsa、sm3withsm2等等），这里我们需要用软算法补充hsm的原子算法，实现证书签名所需要的签名算法实现，比如：先调用hsm的md5算法，获得签名数据的摘要，然后根据不同算法的格式要求，进行填充补位，然后送给rsa进行签名，完成最后的md5withrsa签名。
4.3.在线证书签发
由于本系统的在线证书签发都是在后台完成，所以没有考虑更多的安全审批（RA）措施。在移动终端设备T端，主要是Android系统调用sdkey厂商提供的pkcs11接口，产生密钥对后生成证书签名请求（pkcs10数据包），CA对数据解包后进行签名，本地留存cert文件后，把证书封装成pkcs7格式，返回移动终端设备T。
4.4.离线证书签发
离线证书签发主要是针对服务器证书，由于服务器和CA系统在统一网段，是可信区域，采用ca系统产生密钥对后签名形成证书，并把私钥和证书打包成pkcs12或者jks格式。