安全系列讲座之1 - 签名和加密


#1

第一部分: 签名

我们都签过名. 不论是去学校报道, 还是为了办个上网卡好随时浏览 avboost.com

签名这种东西, 作用就是申明文件的出处. 去老大哥的办事处去办事的时候, 通常要写一堆的表格, 临了, 你都需要在表格上签字, 有时候还得画押.

为啥签字有证明文件出处的作用呢? 因为每个人都有特定的字迹, 很难模仿.

在计算机的世界里, 一切都要电子化, 自然签名也是. 电子签名应该要比手写的签名更可靠, 更方便. 电子签名广泛应用在交易授权, 用户认证等待地方.

  • 当银行的服务器收到了转帐的要求时, 它要做的事情就是对收到的数据包执行 “数字签名校验” . 以确定这份数据发自客户之手, 而不是由黑客伪造.
  • 当系统的自动更新下载到了更新文件的时候, 它就要对下载来的文件执行 “数字签名校验”, 以确定更新可靠的来自系统供应商, 而不是黑客伪造的更新.
  • 当然, 据说恐怖分子相互联系也都要数字签名, 以确保这份 “自杀袭击” 的命令确实来自老大.

数字签名用到了两样重要的技术

  • 非对称加密
  • 信息熵摘要

首先, 对将要发出的数据进行 信息熵摘要 算法, 提取消息指纹. 通常这步使用的是 MD5 算法, 自从 MD5 算法被某天朝牛人找到了碰撞的办法, 向上升级为 SHA1 算法以应对.

接着, 将 消息指纹利用私钥 执行 非对称加密. 得出的数据就是原始消息的数字签名了, 通常将此数据和原始消息一起发送. 如将数字签名嵌入到 可执行文件的头部, 就可以让系统校验 exe 文件的出处了.

如果是电子邮件, 将数字签名作为附件发送, 或者将数字签名和原始文本按照一定的格式组织起来. ( TODO 参考 GPG )

验证签名的办法很简单, 首先将签名数据利用信息发送方的公钥解密(这里就引入了公钥可信度的问题了, 下面讲到) 得到信息摘要, 然后对原始信息执行同样的信息摘要, 通过比较这两个信息摘要, 如果一致, 则签名有效. 否则无效.

在数字签名领域, 两个重要算法的安全性是这样要求的

  • 信息熵摘要 需要非常难寻找碰撞.
  • 非对称加密 要求非常的难破解出私钥

当然, 要数字签名真正的有 “签名的意义”, 需要对 解密签名所用的 “公钥” 进行认证.

有2种办法

  • 第一种办法就是面对面的交换公钥. > 比如你要亲自去银行柜台办理 U盾. 这个过程中, 实质上你和银行相互交换了对方的公钥. ( U 盾是一种智能卡设备, 将私钥保存于其内部的存储空间, 并无法以任何手段读取.) 使用的时候网银程序将要加密的数据送给 U 盾 , U 盾返回加密后的数据, 因此保证了私钥的绝对安全. (保存在硬盘上太不安全了, 参考天朝的某 爱扫描用户硬盘的程序)

  • 第二种办法是使用公共证书体系.

由一些证书机构对公钥执行认证, 你只要信任"证书机构"即可, 无需亲自去确认. 这些麻烦事情全部由他们代劳.

第二部分: 加密

在签名的课程里我提到, 签名就是对信息摘要利用私钥进行加密. 对方利用公钥解密. 这样的信息谁都可以解密, 以验证签名. 签名要接受公开的验证, 这当然是可行的.

如果要防止数据被第三方知晓, 只需将 签名后的消息 再次利用对方的公钥加密. 如此以来, 除了信息接收方, 没有任何第三方能对信息进行解密.

注意, 为啥要将 签名后的消息 加密, 而不是直接加密呢? 因为公钥是公开的, 如果不签名, 接收方虽然能正确的获得原始消息, 但是无法确定发送方.

加密优化

但是这个过程需要执行多次非对称加密操作, 非常的费时. 而 对称加密 有着密钥泄露就不安全的问题. 于是引入了 随机密钥 , 但是双方在通信初期, 需要交换 这个随机密钥. 为了安全的交换随机密钥, 他们使用 非对称算法加密随机密钥并进行数字签名. 安全的交换随机密钥后, 后续通信就可以使用快速的 “对称加密” 进行了. 如 DES 算法, RC4 算法.

这就是 SSL 的原理. 首先交换随机密钥. 在交换随机密钥的时候, 验证对方的 公钥. 然后后续通信使用对称加密. 至于使用何种对称加密算法, 都是握手的时候确定的.

在 Web 体系里, 通常服务器无需认证用户 (银行还是需要认证客户的, 呵呵) 所以客户使用的是随机的. 服务器则使用固定的, 并使用 CA 认证.

浏览器其实都支持客户端证书的, 也就是说客户端也可以使用固定的密钥, 所以说啊, 银行利用浏览器支持的客户端证书即可做到免插件. 浏览器也支持标准的智能卡设备! 所以银行使用标准智能卡的U顿, 彻底解决 IE only 问题.


安全系列讲座之2 - 为什么需要智能卡加密
#2

不错不错! 讲的很详细!


#4

感谢博士开课,学习学习


#5

回复错对象了吧, 啊喂!


#6

菜菜博士老厉害,学习了!!


#7

能看懂就行了,博士,jack也经常开课的,一样的啦


#8

原来如此,我明白免插件的原理了


#9

仔细看完了后有点疑问想请教博士,关于第二部分:加密 小弟还有一点概念很模糊,既然说利用公钥可以解密对方签名后的再公钥加密的内容,虽然能获取原始消息内容,就算不能确定发送方,如果这是一封E-mail的话其实在header中包含有了的,岂不是没有啥作用?


#10

email 的 header 可以伪造.

黑客总有办法伪造.各种协议的数据, 不是么?


#11

如果你用过 sendmail 和相关绑定,可能你就会发现,Email 的发信人地址都是可以随便填的(当然,这种邮件如今可能会归类为垃圾邮件)。

PGP 是安全的保障。


#12

其实如果是那样的话对于恐怖袭击的邮件正文(时间地点目标),最重要的信息其实还是已经被解密了。


#13

对方签名后的再公钥加密的内容仅用公钥就可以得到原始消息内容感觉还是不是那么清晰,是否目的只是加大hack冒充我使用私钥加密并签名发送邮件的难度,而并没办法阻止到数据传输途中被截获并使用公钥解密邮件内容这个过程?


#14

用公钥加密, 只能用私钥解密。 你如何得出内容已经被破解的?


#15

是不是如果说SSL是重复造轮子,那SSH也同样是重复造轮子呢? 我还能不能这样理解?我们在使用网银的时候,私钥只有自己的u盾中才有,将银行密码使用(私钥 or 公钥加私钥 ?)加密后发送给银行,而银行只拥有公钥,它能通过公钥得到解密出MD5后又用私钥加密后的数据吗?


#16

使用网银的时候,以及一些所谓的数字证书“专业版”,因为他们从本质上来讲,所有的运行代码都是在电脑内存中运行的,用户所有的操作都有可能被木马所截获。理论上讲,黑客完全可以伪造用户进行系统登录的吧。


#17

哪个银行这么做了?


#18

你发给银行的时候,用的是银行的公钥。银行发给你的时候,是用的你的公钥。A要给B发消息,需要用B的公钥对消息加密, B用自己的私钥解密。 B给A发消息,需要用A的公钥加密, A用自己的私钥解密。


#19

前辈的意思是指的两者各有公钥和私钥一共两枚,总共双方持有4枚钥匙?


#20

我认为浏览器plugin的另外一个很大作用就是为了防止Hook全局钩子程序用的吧


#21

在数字安全体系里, 认为不安全的因素发生在数据传输通道里, 而不是在发送者和接受者本身的电脑里。

这个安全问题不是数字安全能解决的问题, 而是 OS 安全需要解决的问题。 通过设计更安全的系统, 权限控制更完善的系统来解决。

也就是说, 基本上使用 windows 系统是很难保证安全的。木马病毒什么的太多。