非对称加密原理探索

今天阅读https原理的时候,发现它采用了非对称加密的知识,于是去探索了一下非对称加密的基本原理。

非对称加密

在非对称加密算法中,有公钥和私钥两种密钥,其中,公钥是公开的,不需要保密,私钥由个人持有,必须妥善保管和注意保密。加密和解密使用两种不同的密钥,是它得名的原因。

每一个公钥都对应一个私钥。
密钥对中,让大家都知道的是公钥,不告诉大家,只有自己知道的,是私钥。

如果用其中一个密钥加密数据,则只有对应的那个密钥才可以解密。
如果用其中一个密钥可以进行解密数据,则该数据必然是对应的那个密钥进行的加密。

A与B之间进行通信,如果他们不想通信的内容被他人知道,就可以对通信的内容进行非对称的加密。

比如BC架构中,浏览器与服务器之间进行数据通信,服务器可以将自己的公钥发送给浏览器,浏览器就可以将自己想要发送给服务器的信息利用公钥进行加密,当服务器收到该信息时,利用自己的私钥对信息进行解密就可以获取加密之前的内容,同时保证了其他任何人获取到该信息都无法破解。

同时服务器也可以利用自己的私钥对返回的信息进行加密,浏览器就可以利用服务器发送给自己的公钥进行解密。

公钥认证

数字签名

在公钥加密、解密里面描述的通讯过程看似简单,但想想这个问题:在上述过程中,A怎么知道B在给他的回信在传递过程中,有没有被人修改?这就涉及到数字签名的概念。

要达到这个目的,一般是对信息做一个hash计算得到一个hash值,注意,这个过程是不可逆的,也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时,把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后,会重新计算信息的hash值,并和信息所附带的hash值(解密后)进行对比,如果一致,就说明信息的内容没有被修改过,因为这里hash计算可以保证不同的内容一定会得到不同的hash值,所以只要内容一被修改,根据信息内容计算的hash值就会变化。当然,不怀好意的人也可以修改信息内容的同时也修改hash值,从而让它们可以相匹配,为了防止这种情况,hash值一般都会加密后(也就是签名)再和信息一起发送。

下面通过例子来说明这个过程:
B给A回信时,采用了数字签名的方式
1、B先用hash函数,生成信件的摘要(digest)
2、B使用自己的私钥,对这个摘要加密,这样就生成了数字签名(signature)
3、B将这个签名附在要回复的信息后面,一起发给A
4、A收到B的信息后,取下数字签名,并通过B的公钥解密,得到信件的摘要信息
5、A在对B发送的信息本身使用B指定的hash函数,将得到的结果同上一步解密得到的摘要进行对比,如果两者一致,就说明B发过来的信息未被修改过。

问题就这样结束了吗?远没有,试想,虽然A确定了B回给他的信息是未修改过的,但是怎么确定给他回信息的就是B?如果有不怀好意的C把A保存的B的公钥偷偷换成自己的,并冒用B的名义给A发信息呢?
要解决这个问题,A只要能确定自己持有的公钥到底是不是B的就行了,这就需要用到数字证书。

数字证书

数字证书是用来验证公钥所属的用户身份。在日常生活中,如果我们要验证一个人的身份,通常的做法是查看他的身份证。我们信任身份证颁发机构即政府机构的公信力,因此只要验证一个人的身份证不是伪造的,我们就相信这个人的身份和身份证上所描述的是一致的。
数字证书就是一个人或者组织在网络世界中的身份证,其发证机关是证书管理机构(certificate authority,CA)。CA用自己的私钥对用户的身份信息(主要是用户名和该用户的公钥)进行签名,该签名和用户的身份信息一起就形成了证书。

数字证书一般由数字证书认证机构签发,需要

  • 申请者通过非对称加密算法(RSA) 生成一对公钥密钥,然后把需要的申请信息(国家,域名等)连同公钥发送给 证书认证机构(CA)
  • CA构确认无误后通过消息摘要算法(MD5,SHA) 生成整个申请信息的摘要签名M, 然后 把 签名M和使用的摘要算法CA自己的私钥 进行加密

构成

  1. 证书的发布机构(Issuer)
    指出是什么机构发布的这个证书,也就是指明这个证书是哪个证书中心(certificate authority,简称CA)发布的的(只是创建证书,不是指证书的使用者)。
  2. 证书的有效期(Valid from , Valid to)
    也就是证书的有效时间,或者说证书的使用期限。 过了有效期限,证书就会作废,不能使用了。
  3. 公钥 (Public key)
    这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密解密的,是很长的一串数字。
  4. 证书所有者(Subject)
    这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
  5. 签名所使用的算法 (Signature algorithm)
    指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。指纹的加密结果就是数字签名
  6. 指纹以及指纹算法 (Thumbprint, Thumbprint algorithm)
    这个是用来保证证书的完整性的,也就是说确保证书没有被修改过。 其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值对得上,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。

其实任何个体/组织都可以成为CA(自签证书),但是你发发布的证书客户端是不信任的,也是就前文提及的需要权威。比如 Symantec、Comodo、Godaddy、Digicert

客户端信任这些CA,就会在其本地保持这些CA的 根证书root certificate),根证书是CA自己的证书,是证书验证链的开头。根证书没有机构(已经是权威了)再为其做数字签名,所以都是自签证书。

CA会通过 中介证书(intermediate-certificate) 替代根证书的去做服务器端的证书签名,确保根证书密钥绝对不可访问。

证书信任链

前文提到,在向CA 申请证书时是需要 CA的私钥 去对整个证书的签名摘要做非对称加密的,也就是证书是可以通过 CA的公钥 去解密得到证书的签名摘要的。当我们再次用 相同的摘要算法(证书里面有保存所使用的算法)对整个证书做签名,如果得到的签名和证书上的签名是一致的,说明这个证书是可信任的。

同理,中介证书 也是可以被这样的方式证明其可信任。这样的一整个流程称为 信任链(Chain of trust)。

就是我绝对相信你(A>B);你绝对相信他(B>C);等于我绝对相信他(A>C)

客户端得到服务端返回的证书,通过读取得到 服务端证书的发布机构(Issuer)

客户端去操作系统查找这个发布机构的的证书,如果是不是根证书就继续递归下去 直到拿到根证书(一般都存储在比较安全的地方,比如框架的源码等地方)。

根证书的公钥解密验证 上一层证书的合法性,再拿上一层证书的公钥去验证更上层证书的合法性;递归回溯。

最后验证服务器端的证书是 可信任 的。

RSA原理简介

1找出质数P 、Q-
2计算公共模数N = P * Q-
3欧拉函数φ(N) = (P-1)(Q-1)-
4计算公钥E1 < E < φ(N)E的取值必须是整数 E 和 φ(N) 必须是互质数
5计算私钥DE * D % φ(N) = 1-
6加密C = M E mod NC:密文 M:明文
7解密M =C D mod NC:密文 M:明文

参考文章:

https://blog.csdn.net/wzzvictory/article/details/9015155

https://cloud.tencent.com/developer/article/1130051