|
|
51CTO旗下网站
|
|
移动端

大败“八卦女”、“猥琐男”,工程师男友如何反窃听?

谁都不想在通信过程中被别人“窃取”小秘密。本文借助一对情侣与八卦女、猥琐男的斗智故事,为大家科普密码学基础知识。

作者:覃应接来源:阿里技术|2018-08-31 09:23

事情是这样的,Alice 和 Bob 是一对 CP。两人之间难免要说一些 Secret,又不想被别人偷听,怎么办呢?

本文讲述这对 CP 之间如何安全隐秘地聊天。如何跟无(wěi)聊(suǒ)份子们斗智斗勇的故事。

先介绍一下将要登场的各个角色:

  • Alice:话唠,严重的倾诉欲,和 Bob 是 CP。
  • Bob:沉默男,理工男,和 Alice 是 CP。
  • Eve:Alice 的室友,热衷于偷听八卦。
  • Mallory:猥琐男,专业搞破坏 20 年。
  • Trent:长者,相当具有权威性,大家都相信他。

如何不被窃听:加密

刚开始时,Alice 和 Bob 没有安全意识。平时说话聊天没有什么防范措施,经常被 Eve 偷听。但碍于情面又不好直说,为此烦恼不已。

偷听过程如下图:

Bob 是个技术男,想到一个办法。既然有人偷听,那我为什么不加密呢?说干就干,他事先和 Alice 商定一个密钥(key),是个随机值,别人猜不出来。

从此这对 CP 之间聊天就用这个 Key 进行加密保护,如下图:

从图中可以看到,Alice 在说话前,先用 Key 对消息内容进行加密。发送消息时,不再直接传递“我刚买了个包包”这么直白的明文,而是 “*&2#%/Qw@##” 这种谁都看不懂的密文。

即使被 Eve 窃听,她也完全看不懂神马意思,只能表示 WTF。Bob 收到密文后,先用 Key 对其进行解密,得到原始的消息内容“我刚买了个包包”。

旁白:这种加密方案在密码学里称为对称密码,加密方和解密方使用的是相同的密钥。

知名的密码算法有 AES(2001)、Blowfish(1993)、DES(1977),再远一点,有二战时期的恩尼格码(转轮机原理,德国)、紫色密码(转轮机原理,日本),以及著名的凯撒密码(没错就是地中海北岸那个凯撒)、栅栏密码等。后续会写文章专门进行各个算法的性能比较、安全性比较。

友情提示: 密码学里的“密码”和现实生活中的“密码”不是一回事儿!后者一般指的是口令(password),比如登录淘宝、QQ、ATA输入的那个东西。

顺便说下,有些耿直的 Boy 会把自己的口令设置得炒鸡简单,比如 12345678 、HelloWorld 等。这是万万不能够的,小心被人猜出来。

言归正传,一切看起来是那么完美。Alice 和 Bob 以为可以高枕无忧了,却没想到道高一尺,Eve 高一丈。

如何交换密钥:非对称加密

自从 Alice 和 Bob 使用了“加密”这种秘密武器之后,Eve 什么都听不到了。为此她寝食难安,没有八卦的生活还有神马意义!?

还好,Eve 不是普通的 Eve,她并不只是一个八卦女,她是个懂科技的 Girl。

思考几天之后,Eve 意识到这对 CP 肯定是用了加密的。一不做二不休,Eve 找到了破解办法,请看下图:

Eve 观察到那对 CP 之间为了安全性,会经常更换 Key。为此,她寻找一个合适的时机,把 Key 窃取到手。

之后,Eve 又可以愉快的窃听了,终于可以睡个安稳觉。窃听过程如下:

有 Key 在手,Eve 截获消息之后,就可以像 Bob 一样把消息明文解密出来。

不过好景不长,相对于 Eve 来说,Bob 才是掌握核心科技的。他很快发现 Eve 的这一行为,想到另一个办法: 非对称加密。

具体过程如下:

  • Bob 事先生成一对公钥和私钥,私钥 pri 由自己保管,把公钥 pub 发给 Alice。
  • Alice 使用 pub 对消息内容进行加密,Bob 用 pri 进行解密。
  • 需要注意的是, 只有私钥才可以解密,所以即使 Eve 窃取到了 pub(只有 pub 被传输而容易被窃取),她也无法解密。

另外,这种方式还有个显著优点。假使 Bob 还有很多别的女友(严重抨击这种行为),他可以把同一个公钥 pub 都发给她们,各个女友都用这个 pub 和 Bob 进行通信。

构成“多对一”的通信关系,却不用担心女友 A 窃听到女友 B 和 Bob 之间的聊天内容,因为 pub 无法解密。

而在对称密码中,Bob 必须为每个女友都分发一个不同的 Key,这很难保管。

旁白:这种加密方式在密码学里称为非对称密码,所谓“非对称”指的是加密方和解密方用的密钥不一样。

知名的非对称算法有:DSA(数字签名算法,只能用于签名,1991)、ECC(椭圆曲线加密,1985)、RSA(公钥加密算法,1977)等。

这些算法除了用于加密外,还可以用于数字签名,本文后面会讲到。

非对称算法有个致命弱点: 性能很低。实际应用中一般采用混合加密体制、哈希签名体制。

好了,现在信道安全问题已经解决啦,不用再担心 Secret 被 Eve 偷听。但是情场多艰,猥琐男 Mallory 现在隆重登场。

如何防止数据篡改:MAC

文章开头说了,Mallory 是个专业搞破坏 20 年的男人,这次也不例外。请看下图:

Mallory 并不是八卦小女生,他对偷听秘密没有任何兴趣。生而不羁,他决定搞一些恶作剧,篡改一下消息吧。

于是他把 “我刚买了个包包” 改成“我决定跟你分手”,但 Bob 却不知道已被篡改,还以为是 Alice 的原话。那么问题来了,求此刻 Bob 的心理阴影面积。

经过一番狗血的情感纠葛之后,Alice 表示还是爱他的,Bob 终于意识到有人在从中作梗。

这还得了,之前我们一直强调,Bob 是个掌握核心科技的 Boy,他很快就想到了应对措施。

请看下图(为了简单起见,本例仅展示防篡改的情况,没有对 Message 做加密):

图中的 MAC 指的是消息认证码(Message Authentication Code),你现在不需知道它的原理,只需要记住 :

  • 传入两个参数 Message 和 Key,进行一系列计算后得到一个值叫 MAC。
  • 只有 Message 和 Key 相同的情况下,才能得到相同的 MAC。
  • 跟对称加密一样,这对 CP 之间会事先协商一个 Key。
  • Alice 使用 Key 对 Message 计算出一个 MAC1,并把 Message + MAC1 发给 Bob。
  • Bob 收到之后,用自己的 Key 对 Message 计算出一个 MAC2,再比较 MAC1 和 MAC2 是否一致。
  • 根据 MAC 的性质,如果 Message 被篡改,那么计算得到的 MAC2 一定不等于 MAC1,验证失败,Bob 得出结论:有人篡改了消息。
  • 由于仅 Alice 和 Bob 拥有 Key,所以别人无法篡改 Message 后伪造出一个有效的 MAC。
  • 在检测篡改方面,还可以用 HASH(散列)算法,包括 MD5、SHA1/224/256/384/512 等。比如版本控制系统 GIT 就使用 SHA1 来检查文件是否有修改。

旁白:消息认证码有多种实现方式,其中最常见的是 HMAC(Hash MAC),即使用哈希算法来实现 MAC,还有一种是基于分组密码算法的 MAC,不常见。

聪明如你,肯定会想到如果 Key 被窃取该怎么办?这就涉及到数字签名了,后文会讲到。

如何校验身份:MAC

Mallory 还有个小伎俩,那就是冒充身份,恰好 MAC 也可以对付这个。且看下图:

Mallory 发一个消息给 Bob,说“亲爱的,我是 Alice 哦,Balabala...”。如果没有校验措施,Bob 可能就中招了。

同样的,Bob 可以用以下方式进行防范:

只有 Alice 和 Bob 拥有相同的 Key,所以 Bob 只有在校验 MAC 成功时才会相信对方是 Alice。

而 Mallory 没有这个 Key,伪造的 MAC 肯定会校验失败的,所以计谋不能得逞。

旁白:MAC 包含几种实现方式,基于 HASH 的 MAC 称为 HMAC,应用比较广泛。

有些同学应该接触过阿里云的 Access Key,其实就是 HMAC 的原理。

有些同学在两个系统之间 API 调用时,会使用同一个 Key 做 MD5 计算来实现 API 鉴权,这称为“加盐HASH”,可以简单理解为 HMAC 的简化版。

同样的,如果 Key 被窃取该怎么办?这可以用数字签名来解决。

更进一步:数字签名

MAC 虽好,但是遇到和对称密码同样的问题:密钥如何交换。

其中一个解决方式就是数字签名,这个“签名”你基本可以想象成现实生活中的手写签名,具有类似的作用。

原理上和非对称加密有点像,但有个很大的区别,发送方是用私钥进行签名,而接收方用公钥进行验签,这跟加密情况正好相反。

Bob 可以用数字签名来校验消息是否被篡改,请看下图:

原理上和图 6 差不多,但区别在于:由 Alice 事先生成一对公钥 pub 和私钥 pri,并把 pub 发送给 Bob,前者用 pri 加签,后者用 pub 验签。验签失败说明消息被篡改。

也可以用于身份校验,请看下图:

Mallory 没有 Alice 的 pri,所以无论如何他也没法冒充 Alice 的身份。

看到这里,大家可能都松了一口气,以为这小俩口终于没事儿了。但情场多变,万一哪天 Alice 变心了呢,她给 Bob 发了一条消息,说“分手吧”,如下图:

可是发完之后又有点后悔,但他们使用的不是钉钉,并没有消息撤回功能。

怎么办?所以说 Alice 还是有点 Too Naive,她妄想可以矢口否认,把 Shit 盆子扣到破坏小王子 Mallory 身上,声称“刚才那句话是 Mallory 说的” 等云云。

Mallory 虽然猥琐,但也是个讲“原则“的 Man,你扣盆子也要讲基本法啊!于是他跳出来说, “表冤枉我,我又没有 Alice 的私钥”。

这是什么意思呢?原来数字签名还具有“抗否认”的神奇功效,Alice 讲的话里带有她的签名,是不能否认的(是不是有点类似现实生活中的手写签名?)。任何不讲基本法的栽赃陷害都是无效的...

公钥的身份证:数字证书

如果你以为 Eve 和 Mallory 就此屈服于非对称加密和数字签名的威力,那你就真的是图样了。

所谓 “两汪战一虎,四汪沉航母。六汪戏上帝,八汪创世纪”,他们决定联合起来,找出公钥机制的破绽。

伟大友谊自然会有效果,他们果真找到了破解之法(绝对不是剧情发展需要...)。

没错,就是伪造公钥。我们先拿公钥加密来举例子,图 4 中讲到,Bob 需要事先生成公钥 pub 和私钥 pri ,然后把 pub 分发给 Alice。

那么攻击过程就从这入手:

  • Eve 生成自己的一对公钥 pub' 和 私钥 pri',截获 Bob 的 pub,并用自己的 pub' 冒充 Bob 的公钥发给 Alice,如上图。
  • Alice 用 pub' 加密消息,发送出去。
  • Eve 截获 Alice 的数据,并用 pri' 解密得到消息明文。
  • Eve 伪造一个假数据“干嘛呵呵去洗澡”,并用 pub 加密后发给 Bob。
  • Bob 用 pri 解密,拿到伪造的数据,以为是 Alice 发给他的。

这是个“偷天换日”的过程,Eve 通过伪造公钥(中间人攻击),不光窃听到 Alice 的消息,还能保证整个过程中 Alice 和 Bob 都没有察觉!

再来看一下 Mallory 怎样用伪造公钥的方式来冒充身份。图10 中讲到,Alice 需要事先把自己公钥发给 Bob,所以攻击过程就从这入手:

  • Mallory 生成自己的公钥 pub' 和 私钥 pri',截获 Alice 的 pub,并用自己的 pub' 冒充 Alice 的公钥发给 Bob,如上图。
  • Alice 用正常私钥 pri 进行签名,并发给 Bob。
  • Bob 手里拿的是被伪造的公钥 pub',所以对 Alice 的 sign 会验签失败,认为对方不是 Alice。
  • Mallory 用自己私钥 pri' 进行签名,并发给 Bob。
  • Bob 用被伪造的公钥 pub' 进行验签,可以验签成功,认为对方是 Alice。

这个过程中,Mallory 通过伪造 Alice 公钥,成功冒充了 Alice 的身份。

这种伪造公钥的攻击方式让 Bob 很头疼,思考了很久,终于想到一个办法。这次他找来了帮手—Trent。

文章开头有介绍过,Trent 非常具有权威性,而且能保证自身不受攻击(或者别人不敢攻击),就像现实生活中的公安局。

Eve 不是喜欢伪造公钥吗,Bob 这次就要请 Trent 为自己的公钥注册一张 “身份证”—数字证书。

见证如见人,哦不对,见证如见公钥!以下是注册数字证书的过程:

  • Bob 请求 Trent 为自己的公钥 pub 注册一个证书。
  • Trent 收到请求后,用自己的私钥 pri' 对 pub(以及身份信息) 进行签名,得到一个 sign。
  • Trent 把证书 certificate = pub + sign 颁发给 Bob。
  • Bob 把自己的证书 pub + sign 发给 Alice。
  • Alice 使用 Trent 的公钥 pub' 对 sign 进行验签,如果校验成功则说明 pub 的确是 Bob 的公钥,因为她相信 Trent 的权威性。

Eve 不可能找 Trent 为她办一个 Bob 的数字证书,因为 Trent 不会同意的,就像警察蜀黍不会给我办一张别人的身份证一样。所以,Eve 无法伪造 Bob 的公钥。

同理,为了防止 Mallory 伪造公钥来冒充身份,Alice 也需要向 Trent 注册自己的公钥,得到一个数字证书,用于防止别人伪造公钥。

旁白:考虑到非对称算法的效率问题,实际应用中一般是先对数据进行哈希,然后才用私钥对哈希值(摘要)进行签名。

Trent 在密码技术领域中一般称为认证机构(Certification Authority,即 CA)。

以数字证书为基础,业界制定了一系列的规范和规格,比如由谁颁发证书、如何进行颁发、如何作废证书等,称为公钥基础设施(Public-Key Infrastructure,即 PKI)。

【编辑推荐】

  1. 手机下单工程师上门?东软与神州光大要造安全圈 “滴滴”!
  2. WebRAY权小文:产品就是工程师的尊严
  3. 软件工程师欲发动DDoS攻击白宫网站 抗议特朗普就任总统
  4. 网络安全工程师绝对不能错过的11张思维导图
  5. 除了人工智能工程师,还有一种工程师或许更抢手
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Eclipse插件开发方法与实战

本书分为4个部分共24章,以插件开发为中心,围绕插件开发主要介绍SWT/JFace的应用、插件扩展点的实现,以及GEF、EMF和RCP的相关知识。本书...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊