加密、数字签名(摘要)和HTTPS

priority
Updated
Jul 2, 2021 05:49 AM
date
May 19, 2021
type
Post
URL
slug
encrypt-singature-https
Created
May 19, 2021 05:27 AM
status
Published
tags
Website
summary
之前业务接触的开放API使用了数字签名进行加密和验证,在查看代码的过程中,又好奇之前看的HTTPS的验证过程。这里简单从两个服务信息交互的信息安全,一步步了解加密、数字签名的必要性,初步介绍下HTTPs的实现
在信息的传输过程中,存在两个问题:
  1. 防泄漏:关键信息明文传输,容易被第三方拦截
  1. 防篡改:防止第三方拦截后,对信息进行篡改
其对应的解决办法就是加密和数字签名。

加密算法

当我们需要把一段信息传输给别人,又不希望其他人看到的时候,就会想到对信息进行加密,把信息加密的方法就是加密算法,分为对称加密和非对称加密。

对称加密

加密和解密都是使用同一个密钥。
常见的对称加密算法有 DES、3DES、AES、RC2、RC4、RC5和Blowfish等。
AES 的意思是 “高级加密标准”(Advanced Encryption Standard),密钥长度可以是 128、192 或 256。它是 DES 算法的替代者,安全强度很高,性能也很好,而且有的硬件还会做特殊优化,所以非常流行,是应用最广泛的对称加密算法。
notion image
ChaCha20 是 Google 设计的另一种加密算法,密钥长度固定为 256 位,纯软件运行性能要超过 AES
对称加密优缺点如下:
  • 优点:算法公开、计算量小、加密速度快、加密效率高,适合加密比较大的数据。
  • 缺点:
      1. 交易双方需要使用相同的密钥,也就无法避免密钥的传输,而密钥在传输过程中无法保证不被截获,因此对称加密的安全性得不到保证。
      1. 每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一密钥,这会使得发收信双方所拥有的钥匙数量急剧增长,密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难,主要是因为密钥管理困难,使用成本较高。

非对称加密

加密和解密需要使用两个不同的密钥:公钥(public key)和私钥(private key)。公钥与私钥是一对,如果用公钥对数据进行加密,只有用对应的私钥才能解密;如果用私钥对数据进行加密,那么只有用对应的公钥才能解密。
常用的算法有比如 DH、DSA、RSA、ECC 等。
  • RSA 可能是其中最著名的一个,几乎可以说是非对称加密的代名词,它的安全性基于 “整数分解” 的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的。10 年前 RSA 密钥的推荐长度是 1024,但随着计算机运算能力的提高,现在 1024 已经不安全,普遍认为至少要 2048 位。
notion image
  • ECC(Elliptic Curve Cryptography)是非对称加密里的 “后起之秀”,它基于“椭圆曲线离散对数” 的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名。
比起 RSA,ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA,而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短,所以相应的计算量、消耗的内存和带宽也就少,加密解密的性能就上去了,对于现在的移动互联网非常有吸引力。
  • 优点:加密和解密使用不同的钥匙,私钥不需要通过网络进行传输,安全性很高。公钥可以任意分发
  • 缺点:计算量比较大,加密和解密速度相比对称加密慢很多。

基于非对称加密的信息传输

现实社会中,有⼈使⽤公钥加密,私钥解密,也有反过来⽤私钥加密,公钥解密,这得看具体的场景。
这里假设Jack持有私钥,并把公钥给Mike,Mike传输信息给Jack的过程如下。
notion image
这里有一个问题:Jack的公钥是公开给所有人的,如果有人截获了Mike的信息,然后换成别的信息,重新用公钥加密后给Jack,那么Jack就会得到错误的信息,而误以为是Mike发的。公钥私钥传输,解决了被拦截后的信息泄漏问题,但是没有解决被拦截后的信息篡改。
所以,需要证明信息发送方的身份和发送的数据没有被篡改,这里引入了数字签名的概念。

数字签名

通过加密,可以保证数据在传输中对其他人是不可见的,但是却并不是绝对安全的。信息被拦截后,攻击者可以对信息进行篡改,导致解密后的数据不是原始传输的,甚至针对网站对解密数据的响应,推测出解密的数据或者达到篡改目的。
所以需要一种方式,让信息接受者确认你传输的数据和我收到的一致,在现实中,我们一般通过水印或者签名的方式,在代码的世界里,就是数字签名。
数字签名是对原始传输的信息,通过摘要算法,获得一个比较短的字符并加密后作为原始信息的签名。

摘要算法

实现完整性的手段主要是摘要算法(Digest Algorithm),也就是常说的散列函数、哈希函数(Hash Function)。
摘要算法主要把大量的数据生成一个比较短的字符,便于传输,且不可逆。原信息的任何微小的修改都会引起摘要的变化。评价一个摘要算法的好坏的主要方法是碰撞概率。
常见的hash算法有MD5,sha-1和sha-2(sha-256,sha-224,sha-384)

摘要算法实践

由于摘要算法会出现碰撞,所以会出现重放攻击,如何尽可能的避免重放攻击呢?
  1. 消息序号
  1. 消息中加入时间戳,不在接受时间范围内的消息,可视为不可靠
  1. 添加nonce参数
    1. Nonce是或Number once的缩写,在密码学中Nonce是一个只被使用一次的任意或非重复的随机数值。
      在通信之前,接收者先向发送者发送一个一次性的随机数(or字符串),nonce也参与到签名中。
      如果是加密的数据传输,nonce也可以由发送方生成。

包含数字签名的信息传递

这次,Mike也有一个公钥和私钥,并且把公钥给了我。这次,mike先把传输的信息用Jack的公钥加密,然后对信息计算hash,将hash使用mike的私钥加密作为签名,上面两个信息一起给Jack。
Jack使用自己的私钥解析信息,然后也计算hash,并利用Mike的公钥揭秘签名,比对二者是否相等,如果一致则可以认为这条信息是Mike传输的原始信息。
notion image

中间人攻击

这样就Ok了?NONONO,如果有人黑了Jack的电脑,然后修改了Jack电脑上Mike的公钥换成自己的。这样他依旧可以拦截Mike的信息,然后使用Jack的公钥加密新的信息,使用自己的私钥制作签名,伪装成Mike,这就是中间人攻击。
notion image

证书机构:最最后的办法

Mike看到有⼈在伪造他的公钥,想了想,他只能和Jack找了个⼤家都相信的永不作恶的权威的可信机构来认证他的公钥。这个权威机构,⽤⾃⼰的私钥把Mike的公钥和其相关信息⼀起加密,⽣成⼀个证书。
此时,Jack就可以放⼼地使⽤这个权威机构的证书了。Mike只需要在发布其信息的时候放上这个权威机构发的数字证书,然后Jack⽤这个权威机构的公钥解密这个证书,得到Mike的公钥,再⽤Mike的公钥来验证Mike的数字签名。
notion image
知名的 CA 全世界就那么几家,比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等,它们签发的证书分 DV、OV、EV 三种,区别在于可信程度。
DV 是最低的,只是域名级别的可信,背后是谁不知道。EV 是最高的,经过了法律和审计的严格核查,可以证明网站拥有者的身份(在浏览器地址栏会显示出公司的名字,例如 Apple、GitHub 的网站)。
不过,CA 怎么证明自己呢?
这还是信任链的问题。小一点的 CA 可以让大 CA 签名认证,但链条的最后,也就是 Root CA,就只能自己证明自己了,这个就叫 “自签名证书”(Self-Signed Certificate)或者 “根证书”(Root Certificate)。你必须相信,否则整个证书信任链就走不下去了。
操作系统和浏览器都内置了各大 CA 的根证书,上网的时候只要服务器发过来它的证书,就可以验证证书里的签名,顺着证书链(Certificate Chain)一层层地验证,直到找到根证书,就能够确定证书是可信的,从而里面的公钥也是可信的。

HTTPS协议

详细可以看
由于非对称加密的效率比较低,所以实际应用中,只有链接的建立使用非对称加密,后续的数据传输都是对称加密。
整个流程是:访问服务器→服务器通过证书机构私钥CPR加密公钥M,得到证书C→客户端获得服务器的证书C→利用证书机构的公钥CPU获得服务方公钥M→客户端生成随机字符作为对称加密密钥A→公钥M加密A传输到服务器→服务器使用M对应的私钥解密→服务端得到密钥A,后续使用密钥A对称加密传输的数据即可。
这个过程,省略了数字签名。

参考

  1. 深入浅出 HTTPS (详解版) - huansky - 博客园
  1. 极客时间-左耳听风专栏-《65区块链技术细节:加密和挖矿》
 

© Song 2015 - 2021