对称密钥密码体制
所谓对称密钥密码体制,就是加密密钥与解密密钥是使用同样的密码体制
公钥密码体制
所谓公钥密码体制,就是使用不同的加密密钥与解密密钥
在公钥密码体制中,加密密钥PK(
public key
,即公钥)是向公众公开的,而解密密钥SK(secret key
,即私钥或密钥)则是需要保密的。加密算法和解密算法是公开的。
公钥密码体制产生的原因
- 对称密钥密码体制的密钥分配问题
- 对数字签名签名的需求
数字签名
推荐一个博主的博客,讲的贼明白,个人感觉,下面我的内容大部分都来自于他的灵感,或者是摘抄的他的东西。数字证书工作原理即工作流程,还有一个数字签名—原理。
数字签名是基于非对称密钥加密技术与数字摘要技术的应用,是一个包含数据信息(报文)以及发送者身份并能够鉴别发送者身份以及发送信息是否被篡改的一段数字串。
一段数字签名数字串包含了电子文件经过Hash编码后产生的数字摘要,即一个Hash函数值以及发送者的公钥和私钥三部分内容。
函数加密原理
Hash函数又叫加密散列函数,其特点在于正向输出结果唯一性和逆向解密几乎不可解,因此可用于与数据加密。
正向输出容易且结果唯一:由数据正向计算对应的Hash值十分容易,且任何的输入都可以生成一个特定Hash值的输出,完全相同的数据输入将得到相同的结果,但输入数据稍有变化则将得到完全不同的结果。
Hash函数逆向不可解:由Hash值计算出其对应的数据极其困难,在当前科技条件下被视作不可能。
数字签名要实现的三点功能
- 报文鉴别:即接收者能够核实发送者对报文的签名。
- 报文的完整性:即接收者确信所收到的数据和发送者发送的完全一样而且没有被篡改过。
- 不可否认:即发送者事后不能抵赖对报文的签名。
数字签名的工作机理
发送加密
- 发送方发送报文时,发送方通过Hash函数对报文进行加密生成数据摘要(digest);
- 发送方用自己的私钥SK(虽然私钥也叫做解密密钥,但为什么说是对数据进行加密,此处不要纠结了,记住就行,哈哈)对数据摘要进行加密,私钥加密后的摘要即为数字签名;
- 数字签名作为报文的附件将一起发送给接收方。
接收解密
- 接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要;
- 接收方用发送方的提供的公钥来对报文附加的数字签名进行解密,得到一个数字摘要;
- 如果以上两个摘要相一致,则可以确认文件内容没有被篡改。
- 发送方的公钥能够对数字签名进行解密,证明数字签名由发送方发送。
数字证书
为了防止大佬把文章删掉,我复制他一份,啊哈哈哈
目标
场景:甲要给乙发送一段机密信息
要保证这次信息传递的机密性、完整性、可信赖性,需要规避以下几条潜在风险:
风险一:明文在传递时被截获并读取;
风险二:密文在传递过程中被篡改;
风险三:密文可能并不是来自于甲;
对应解决方案
方案一(对称加密):针对上文中说到的风险一,最直接的方案就是对明文进行加密,这里用到的是对称密钥,然后将密文和密钥分开发送;
问题:就算是分开发送,明文和密钥还是有被同时截获的可能,这就跟没加密一样;
方案二(非对称加密):针对上面这种情况,只要保证对称秘钥在传递时不能读取或解析出来就齐活了。这时需要用到非对称加密算法。乙的公钥是公开的,甲可以拿它来对上文中的对称秘钥进行加密并发送,因为只要乙的私钥不上网,黑客就不能解密出加密过的对称秘钥,也就不能解密密文;
问题:虽然黑客不能解密密文,但是他还没有放弃,他想:至少我可以让乙得不到真正的密文。他的具体做法是:把甲发出的密文和加密过的对称秘钥截获,揉成一团,然后进垃圾桶里。接着伪造了一份明文,创建了一份属于自己的对称秘钥,并用自己的秘钥加密了伪造的明文。因为乙的公钥是公开的,所以黑客也可以轻易的获得,他装模做样的用乙的公钥加密了自己的对称秘钥,然后把秘钥和密文一起发给了乙;
方案三(数字签名):要解决上面的问题,关键在于让乙可以确认他收到的消息确实来自甲。所以就有了数字签名,这次要用到甲的非对称秘钥,不过不是用来加密,而是用来签名。甲在发送消息之前,要先基于明文,应用摘要算法运算出一段摘要,一般用到的就是hash算法,这个算法是公开的,用到的算法要实现两个特性:
- 如果原文动一点,产生的摘要就会不同;
- 摘要结果是不可逆的,你不可能在知道加密算法的情况下基于摘要计算出原文;
产生摘要还不够,甲还需要用自己的私钥对摘要进行重编码。注意,这不是加密,只能称之为重编码,因为甲用私钥加密的密文可以用甲的公钥解密,而甲的公钥也是公开的,任何人都可以用甲的公钥解密出上面说到的那段重编码过的摘要,所以不具有保密性。但是,但是,也只有甲的公钥能正确地解码由甲的私钥重编码过的内容。现在乙会收到三个东西,对称加密过的密文,用乙的公钥非对称加密过的对称秘钥,用甲的私钥重编码过的原文摘要,乙需要做的:首先用自己的私钥解密出加密过的对称秘钥,然后用这个秘钥解密密文的原文。乙现在的疑问是:我怎么知道这段明文是甲发出的?这时候就用到那段摘要了。这段摘要现在还是加密状态,需要配合甲的公钥先解密(甲的公钥是这次交互之前,提前从别的渠道弄到的)。解密之后会得到摘要,这时候乙得到摘要不是要去反推原文,一方面原文已经到手了,另一方面由于摘要算法的特性,也不可能反推的出来。现在需要做的,是验证已经得到的原文是不是被篡改过,是不是甲发出的?乙只需用同样的算法处理原文,得到一段摘要,与之前解密出的摘要对比,只要一模一样,就说明这段信息却是来自甲,中途也没有被篡改过。
问题:得出上面的结论是有一个逻辑前提的 ,那就是你提前获取过一份甲的公钥,并且你认为这就是甲的公钥,用这份公钥能正确解码的内容是可以信赖的。但这种想法可能很天真,因为你没有遇到一位技术高超并蓄谋已久的的黑客。如果这位黑客在你第一次获取甲的公钥的时候就将其掉包,那么你后面通讯时所做的所有事情就是一个彻头彻尾的骗局。
方案四(数字证书):因为甲身处网络的另一端,无法到现场确认你手里的公钥,所以要想确认你得到的公钥确实是属于甲的,就需要一个可以信赖的第三方介入了,这个第三方组织要么是政府机构,要么是美国某个经常发布规则的牛X组织。不管这个第三方组织隶属于谁,他都有一个统称,叫CA,他会给甲颁发一个叫数字证书的东西,里面至少包含这个组织的数字签名,公钥,以及甲的公钥。把这些信息绑定在一起的意义在于,甲就可以数字证书的形式发布自己的公钥,所有人在得到证书信息时候首先用CA的公钥对CA的数字签名进行验签,确认证书确实来自这个可以信赖的组织,既然它可以信赖,那他说证书里的公钥是属于甲的,乙就可以相信了。
补充
其实这里还有一个疑问,乙怎么知道他拿到的证书是来自那个可信赖的组织而不是别的土鳖?解决方案是,这些主要的CA机构的数字证书会预置在主流浏览器的安装包内,只要你是从官方渠道下载的浏览器,这种证明链条就可以安全的延伸开。
所以说,机器总是会骗人的,对一段信息的信任最终还是要落到对人的信任上。