Security & Cloud Computing (24)
Last updated
Last updated
对称加密使用相同的 key 来加密 (encryption) 和解密 (decryption)，如下图所示：
这种加密容易被 tampering 和 replay attacks 破解。
一种简单的加密方式可以直接对消息与 key 执行 XOR 操作，这种方案实现很容易，但也容易被频度分析 (frequency analysis) 破解。
为了改善上述方案，可以对不同的消息使用不同的 key 加密，但这就要求双方都能够知道具体使用的 key。
更复杂的加密算法通常将消息分段 (block) 加密：
Data Encryption Standard (DES) 在 19 世纪 70 年代由 IBM 研发，由 NBS/NIST 标准化。它使用长度为 56 bits 的 key 进行加密。但一些定制化的硬件可以在 24 小时内将其破解，如今许多金融机构使用 Triple DES 进行加密，key 的长度达到 168 bits。
Advanced Encryption Standard (DES) 是 2002 年提出的 DES 的替代算法，它使用长度为 128，192 或 256 bits 的 key 对数据进行加密。它的加密强度并没有被严格证实，但已经被广泛使用。
A 与 B 相互通信，需要向对方证明自己的身份。利用对称加密：
A 和 B 事先商量好一个共同的 secret key
A 生成一个随机数 x，然后用 key 加密后发送给 B
B 用 key 解密消息后将随机数返回给 A
如下图所示：
这种验证方式容易被中间人 (man-in-the middle) 攻击。
另一个加密算法的使用场景就是验证数据的完整性。可以利用加密哈希算法将正确的数据计算一次 hash，数据接收方获取数据后只要重新计算一遍 hash 验证二者是否相等即可。
数据发送方使用 H(x) 求数据的 digest，即上文的 hash，的方案如下：
H(x) 是一个大家都知道的哈希函数
Digest d = HMAC(K, m) = H(K | H(K | m))
当接收方获取消息后，使用共享的 secret key K 来重新计算 HMAC(k, m) 并比对即可。
一些标准的加密哈希函数罗列如下：
名称 | 说明 |
MD5 (Message Digest version 5) |
|
SHA-1 (Secure Hash Algorithm) |
|
SHA-2 (2001) | 包含一系列算法，SHA-224,SHA-256,SHA-384, SHA-512 |
非对称加密的核心思想是利用两个 key，一个用来加密 (e)，一个用来解密 (d)，并且要求两个 key 不能互相推导，即知道 e 并无法推导出 d。这样 e 可以被公开，即所谓公钥。这时候，消息加密与解密的过程如下所示：
假如 Alice 想要向 Bob 发送消息，她就需要先获取 Bob 的公钥 (公开)，并且利用公钥加密消息。即便 Alice 是加密消息的人，她也无法解密消息，世界上只有 Bob 能够利用私钥解密 Alice 发送的消息。抽象地说：
发送方利用接收方的公钥加密数据
接收方利用私钥解密数据
非对称加密在 19 世纪 70 年代被提出，它的原理来自于数论 (Number Theory)。最成熟的方案是 RSA，由 Rivest、Shamir 和 Adleman 在 1977 年提出，并写入 RFC 3447。另外一个成熟的方案是 ECC (Eliptic Curve Cryptography)，基于 Galois-field space 的曲线原理，使用的 key 比 RSA 更短。
RSA 需要生成很大的随机质数、求大数的指数值，现已存在效率较高的算法能够生成它们。总体上，RSA 比对称加密方案的速度要慢很多。
利用非对称加密做身份验证的过程如下图所示：
A 和 B 互相知道对方的公钥：
A 生成一个随机数 x，用 B 的公钥将自己的身份 A，随机数 x 一同加密，发送给 B
B 用自己的私钥解密消息，同时生成一个随机数 y，将 x、y 以及自己的身份 B 用 A 的公钥加密后发送给 A
这样 A 就知道 B 是 B，但 B 尚未知道 A 是 A。这时，A 需要将 B 生成的随机数和自己的身份 A 用 B 的公钥加密后一同发送给 B
这时候，A 和 B 之间就能够互相确信对方身份。
假设 Alice 有一个公钥 KE，如果她想证实自己是谁，可以直接将消息 m 用自己的私钥加密后发送出去，由于 Alice 的公钥已经公开，那么大家就可以通过她的公钥验证这条消息的来源。此时 Alice 已经无法否认自己发送的消息，这种性质被称为 non-reputation。
这种方式也可以用来产生文档的电子签名。但产生电子签名时，我们如何知道 Alice 的公钥真的是她的公钥，而不是其它人在欺骗我们？
这时就需要一个可以信赖的第三方机构 (Trusted Authority)，负责为大家的公钥签名，然后以电子证书 (digital certificate) 的形式发布，这样每个人都可以用 TA 的公钥来验证证书中的信息是否正确。
那么我们又如何知道 TA 的公钥真的是它的公钥？TA 的公钥会被编译进浏览器的源码中，因此这一层保护浏览器会帮我们做。(HTTPS)
先引入一些概念：
HTTPS: Use HTTP over SSL/TLS
SSL: Secure Socket Layer
TSL: Transport Layer Security (successor to SSL), 在 TCP 之上提供一层加密抽象层 (authentication, encryption)
当你访问 https://www.amazon.com 时，发生了什么？
浏览器 (Client) 通过 TCP 与 Amazon HTTPS 服务器建立连接 (TCP 连接)
Client 发送一系列自己支持的加密协议给 Server
Server 从列表中选择一个，并将自己的证书发送给 Client。证书中的信息包括
名称 (Amazon)
Amazon 的 RSA 公钥
其它附带信息，如 Amazon 的地址、证书类型以及过期时间
发证方
以及以上所有信息的签名
Client 验证证书是否有效
整个原理如下图所示：
验证证书有效后，Client 和 Server 之间还需要商量一个 session key 用于后续的消息传输：
浏览器 (Client) 生成一个随机数 K 作为 session key (用于后续的数据传输)，用 Server 的公钥加密后发送给 Server
Server 表示同意
至此 Client 与 Server 之间就完成了验证和 session key 的确认，后续的消息直接用对称加密的方式进行即可。
本节略，主要就是一些基本介绍，没有多少实质内容。
lecture note 24
