安全策略建立RSA协商加密的安全信道

基本概念

CA(Certificate Authority)被称为证书授权中心，是数字证书发放和管理的机构。根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。
数字证书颁发过程一般为：用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息。
认证流程
https认证流程：

1、服务器生成一对密钥，私钥自己留着，公钥交给数字证书认证机构（CA）
2、CA进行审核，并用CA自己的私钥对服务器提供的公钥进行签名生成数字证书
3、在https建立连接时，客户端从服务器获取数字证书，用CA的公钥（根证书）对数字证书进行验证，比对一致，说明该数字证书确实是CA颁发的（得此结论有一个前提就是：客户端的CA公钥确实是CA的公钥，即该CA的公钥与CA对服务器提供的公钥进行签名的私钥确实是一对。），而CA又作为权威机构保证该公钥的确是服务器端提供的，从而可以确认该证书中的公钥确实是合法服务器端提供的。
注：为保证第3步中提到的前提条件，CA的公钥必须要安全地转交给客户端（CA根证书必须先安装在客户端），因此，CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是，该前提条件在各种信任机制上，基本保证成立。

制作自己的根证书及数字证书
通过CA生成数字证书比较很麻烦，而且要收费贵，在公司设备与公司的服务器通信时可以采用自己生成的数字证书，但是需要将数字证书导入到设备中。

以上原文链接：https://blog.csdn.net/lwwl12/java/article/details/80691746

建立RSA协商加密的安全信道

RSA算法简介

加密算法是计算机通信安全的基石，加密算法分为2个大类，即”对称加密算法“和”非对称加密算法“。”对称加密算法“的缺点比较明显，即甲方必须把加密规则告诉乙方，否则无法解密。因此保存和传递密钥，就成了最头疼的问题。本文所依赖的加密算法RSA算法是一种”非对称加密算法“，其具有以下特点：

乙方生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。
甲方获取乙方的公钥，然后用它对信息加密。
乙方得到加密后的信息，用私钥解密。

其实关键知识点就是：用公钥加密，用私钥解密，私钥要做好保密。

安全信道协商流程

我们选择使用RSA加密算法建立安全信道，在介绍具体方法之前，我们先约定几个术语：

C表示客户端（Client）
S表示服务端（Server）
priKey表示私钥（PrivateKey）
pubKey表示公钥（PublicKey）

下面分步骤对流程进行详细描述。

前提说明

在安全信道建立之前，客户端和服务端已经拥有一套公私钥对，公钥由客户端持有，私钥由服务端持有。这里的公私钥分别表示为：pubKey0和priKey0.

Client->Server传递pubKey

客户端生成一对公私钥，分别表示为pubKeyC和priKeyC，其中priKeyC客户端自己持有，pubKeyC需要传递给服务端；
客户端使用pubKey0对pubKeyC进行加密，然后通过TCP链路将加密后的数据传输给服务端；（这个过程我们称为Stage1）
服务端收到客户端加密的信息后，使用priKey0对信息进行解密，得到pubKeyC.

Server->Client传递pubKey

服务端生成一对公私钥，分别表示为pubKeyS和priKeyS，其中priKeyS服务端自己持有，pubKeyS需要传递给客户端；
服务端使用pubKeyC对pubKeyS进行加密，然后通过TCP链路将加密后的数据传输给客户端；(这个过程我们称为Stage3)
客户端收到服务端加密的信息后，使用priKeyC对信息进行解密，得到pubKeyS.

加密通信

经过上述全双工的加密协商过程，客户端和服务端之间就建立了使用RSA算法进行加密的通信信道，后续的数据传输就是在上述安全信道下进行的。具体如下：

Client-->Server的数据，在Clietn端加密，在Server端解密，使用的是由服务端初始化生成的公私钥对（pubKeyS和priKeyS）；
Server-->Client的数据，在Server端加密，在Client端解密，使用的是由客户端初始化生成的公私钥对（pubKeyC和priKeyC）.

工程实践中的一些优化点

尽量降低初始化私钥priKey0泄漏风险

上述公私钥协商过程的安全性是建立在初始化私钥，即服务端所持有的priKey0未泄漏的基础上的。如果priKey0泄漏了，那么理论上这个”安全“信道就不安全了。一般工程实践中，会通过2中方式去尽量降低私钥泄漏风险：

将初始化公私钥对从一对扩展到多对，在Stage1的过程中，选择某一个公钥对数据进行加密，同时将公钥索引追加到传递给服务端的信息中去。服务端在收到信息后先解析出索引，然后取出对应的私钥进行解密；
不定期的更新公私钥对，这种方案会有一定的弊端，服务端需要同时维护针对不同客户端版本的私钥信息，并且还要额外增加一个字段标识服务端使用那对私钥进行解密，不过可以通过控制客户端版本数量的方式，将维护成本降低，如维护2个版本客户端，其他版本强制退出。

服务端Stage3初始化公私钥性能

对于客户端来说，每次建立安全通道，单个客户端只需要进行一次公私钥对的初始化计算，性能不是瓶颈。但是，对于服务端来说，尤其是接入层，服务了众多TCP长连接，如果频繁的进行公私钥对的初始化计算，CPU性能的消耗成本是巨大的。所以一般工程实践中，会选择一种更为理性的方案。
具体做法可以是：

在服务端启动的时候，预先初始化多对公私钥对，如可以初始化128对或者更多，然后将这些公私钥对保存在内存中。
在Stage3阶段，服务端不即时生成公私钥对，只需要随机选择一个内存中的一对公私钥，并进行加密操作，将对应的公钥传递给客户端即可。

以上文章出处： http://www.cnblogs.com/berlin-sun/

一般Linux系统项目功能实现

利用Openssl第三方库加解密相关功能函数

1、预存服务器端根证书（单个或者多个，客户端去遍历）

2、利用第三方库函数生产自身设备秘钥对