Crypto - 标签 - 有价值炮灰

深入浅出 SSL/TLS 协议

Sun, 15 May 2022 12:40:00 +0800

有没有那么一个人，几乎每天都在你身边，但某天发生一些事情后你会突然发现，自己完全不了解对方。对于笔者而言，这个人就是 TLS，虽然每天都会用到，却并不十分清楚其中的猫腻。因此在碰壁多次后，终于决定认真学习一下 TLS，同时还是奉行 Learning by Teaching 的原则，因此也就有了这篇稍显啰嗦的文章。

前言

关于 SSL/TLS 和 HTTPS 这些基本概念也就不多废话了，相信看笔者文章的朋友都有一定基础，因此本文的重点主要放在其中的握手流程。下文分别以目前最为常用的 TLS1.2 和 TLS1.3 协议分别进行分析，涉及到对称加密和椭圆曲线加密的相关介绍可以参考之前的一些文章，比如:

对称加密与攻击案例分析
椭圆曲线加密与NSA后门考古
Elliptic Curve Cryptography: a gentle introduction (强烈推荐这篇)

TLS 1.2

在深入握手细节之前我们可以先抓一个 HTTPS 的包去对整个握手流程有个大致感受，如下所示:

其中绿色部分是为了便于理解已经解密了的 http-over-tls 明文。从上面的数据包中我们可以得到一些初步印象:

从握手开始，到发送第一个数据包之前，客户端与服务端之间经历了 5 次传输；
每次传输中带有一个或者多个数据包；

这里的数据包称为 TLS Record，每个 Record 都是典型的 TLV (Type-Length-Value) 结构，而其中 Value 的具体类型又与 Record 的类型有关。

Record 的结构如下:

struct {
    uint8 major;
    uint8 minor;
} ProtocolVersion;

enum {
    change_cipher_spec(20), alert(21), handshake(22),
    application_data(23), (255)
} ContentType;

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

在实际的网络传输中，一个 Record 可以分割为多个 Fragment，每个 Fragment 的大小最多不超过 2^14 = 16384，而 Record 的 length 字段为 uint16，最大可以到 65535 字节。之所以这么设计是因为对于加密的数据，解密方需要收到整个 Record 才能开始解密，太大会影响解密性能，从而增加交互延时。

从上述定义可以看到 Record 的前两字节是用于定义协议版本，但是从上图我们发现 TLS 1.2 对应的版本为 0303，这乍看起来有点别扭，但其实是历史发展的结果。历史上 TLS 由 SSL 进化而来，通常也统称为 SSL/TLS，因此版本对应关系分别是:

SSL 3.0 -> 0300
TLS 1.0 -> 0301
TLS 1.1 -> 0302
TLS 1.2 -> 0303
TLS 1.3 -> 0304
…

只需要记住这个版本号即可，并不是很重要。后文也会将 SSL、TLS、SSL/TLS 混用，如无特殊说明，都是指代当前分析的 TLS 协议。

另外值得一提的是 Record 类型，在 TLS 1.2 中主要有 4 个，基本上都出现在上述 Wireshark 截图里了。其中在实际传输明文(HTTP)数据之前的大部分 Record 都是 handshake 类型的子类型，但 change_cipher_spec 却是一个单独的 Record 类型，并不属于 handshake，这点后面也会提到。

下面，我们就来开始分析 TLS 握手的具体实现。

注: 下文中所使用到的公、私钥以及相关工具都来源于以下的仓库，并且相关介绍也参考了其中的流程，因此感兴趣的可以直接通过原文去进行学习:

Client Hello

在 TLS 握手中，总是以客户端的 ClientHello 为起始，就像 TCP 握手总是以 SYN 为起始一样，告诉服务器我们想建立一个 TLS 链接。在 ClientHello 请求的结构如下:

struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-2>;
    CompressionMethod compression_methods<1..2^8-1>;
    select (extensions_present) {
        case false:
            struct {};
        case true:
            Extension extensions<0..2^16-1>;
    };
} ClientHello;

client_version 指客户端版本，值为 0x0303，表示 TLS 1.2，前面已经说过。值得一提的是该值与 Record 中的版本不一定一致，后者由于兼容性的原因通常会设置为一个较旧的版本(比如 TLS 1.0)，服务端应当以 ClientHello 中指定的版本为准。

random 是客户端本地生成的 32 字节 随机数，在 RFC5246 中提到随机数的前四字节应该是客户端的本地时间戳，但后来发现这样会存在针对客户端或者服务端的设备指纹标记，因此已经不建议使用时间戳了。为方便后续计算，这里将该随机数固定为:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

session_id 主要用于恢复加密链接，需要客户端和服务端同时支持。由于秘钥协商的过程中涉及到很多费时的操作，对于短链接而言将之前协商好的加密通道恢复可以大大减少运算资源。如果服务器支持恢复会话，那么后续可以直接进入加密通信，否则还是需要进行完整的握手协商。该字段的长度是可变的，占 1 字节，也就是说数据部分最多可以长达 255 字节。

cipher_suites 表示客户端所支持的加密套件，带有 2 字节长度字段，每个加密套件用 2 字节表示，且优先级高的排在前面。使用 openssl 可以查看实现的加密套件列表，如下所示:

$ openssl ciphers -V | column -t
0x13,0x02  -  TLS_AES_256_GCM_SHA384         TLSv1.3  Kx=any       Au=any    Enc=AESGCM(256)             Mac=AEAD
0x13,0x03  -  TLS_CHACHA20_POLY1305_SHA256   TLSv1.3  Kx=any       Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
0x13,0x01  -  TLS_AES_128_GCM_SHA256         TLSv1.3  Kx=any       Au=any    Enc=AESGCM(128)             Mac=AEAD
0xC0,0x2C  -  ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH      Au=ECDSA  Enc=AESGCM(256)             Mac=AEAD
0xC0,0x30  -  ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH      Au=RSA    Enc=AESGCM(256)             Mac=AEAD
0x00,0x9F  -  DHE-RSA-AES256-GCM-SHA384      TLSv1.2  Kx=DH        Au=RSA    Enc=AESGCM(256)             Mac=AEAD
...

每个加密套件包含一个秘钥交换算法、一个认证算法、一个对称加密算法和一个用于完整性校验的 MAC 算法。例如后文中协商出的加密套件 0xC0,0x13 表示 ECDHE-RSA-AES128-SHA。

compression_methods 表示客户端所支持的一系列压缩算法。数据需要先压缩后加密，因为加密后的数据通常很难压缩。但是压缩的数据在加密中会受到类似 CRIME 攻击的影响，所以当前几乎所有的实现都默认禁用了压缩，而且在新版本的 TLS 中也将压缩的特性移除了。

extensions 是 TLS 具备拓展性的一个功能，用于告知服务端一些额外的信息或者启用某些新的特性。比如客户端所支持的 TLS 版本列表，支持的椭圆曲线种类，支持的签名算法等。其中一个常用的拓展为 SNI(Server Name Indication)，包含了服务器的明文域名，主要用于后端服务器的反向代理。

Server Hello

服务器在收到 ClientHello 后必须回应 ServerHello 进行下一步握手协商，否则就需要回复 Alert 类型的 Record 告诉客户端中断握手并关闭连接。

ServerHello 的类型和 ClientHello 基本一致，差别在于回应的 cipher_suite 和 compression_method 是选择后的固定值，而不是列表。另外需要注意的是服务端返回的 ServerHello 中的拓展必须是客户端中所提供的拓展。假设服务端返回的 cipher_suite 为 0x0c13 (ECDHE-RSA-AES128-SHA)，返回的随机数为:

70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f

Server Certificate

随后服务端接着返回自身的证书信息，X509 格式，使用 ASN.1 DER 编码。通常服务器会返回多个证书，因为当前域名往往不是由根证书直接签名的，而是使用由于根证书所签名的次级证书去签发具体域名的证书。

如果使用了多级证书，那么返回的证书列表中第一个必须是对应域名的证书，而后每个证书都是前一个证书的 issuer，且最后一个证书是由系统中某个根证书签发的，注意根证书本身并不会一起返回。

以 baidu.com 为例，实际返回的证书列表如下:

$ openssl s_client -connect baidu.com:443
CONNECTED(00000006)
...
---
Certificate chain
 0 s:/C=CN/ST=Beijing/O=BeiJing Baidu Netcom Science Technology Co., Ltd/CN=www.baidu.cn
   i:/C=US/O=DigiCert Inc/CN=DigiCert Secure Site Pro CN CA G3
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert Secure Site Pro CN CA G3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---

实际返回了两个证书，最后一个证书由 DigiCert Global Root CA 签发。如果服务端需要校验客户端证书的话，随后会发送一个 Certificate Request 请求，然后客户端返回对应的 Client Certificate 进行一轮额外的信息交换，当然这一步是可选的。

Server Key Exchange

服务器会在 server Certificate 消息之后发送 Server Key Exchange 消息，提供用于 ECDH 秘钥交换的信息。

关于 ECDH 的原理可以阅读文章开头的参考文章，简单来说，ECDH 可以在通信媒介不可信的情况下安全地完成秘钥交换。假设 A、B 双方的公私钥分别是 PA、SA，PB、SB，那么有:

PA * SB == PB * SA

双方只需要知道对方的公钥，可以在不暴露私钥的情况下实现信息的交换，防止中间人攻击，所交换的信息就是后续使用的对称加密秘钥。

更进一步，为了避免未来私钥泄露导致以前的通信被解密，通常交换时并不直接使用原始公私钥，而是一个随机生成的新公私钥对，只需要用原始私钥进行认证。这种交换方式也称为 ECDHE，其中 E 表示 Ephemeral，而这种做法所带来的称为 Forward Security，即前向安全。

令服务端端选择的椭圆曲线为 x25519，那么首先需要生成一个临时私钥，长度为 32 字节，只要随机生成即可，这里假设为:

909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

那么对应的公钥则是:

9fd7ad6dcff4298dd3f96d5b1b2af910a0535b1488d7f8fabb349a982880b615

可以通过 openssl 计算得出:

$ openssl pkey -noout -text < server-ephemeral-private.key

X25519 Private-Key:
priv:
    90:91:92:93:94:95:96:97:98:99:9a:9b:9c:9d:9e:
    9f:a0:a1:a2:a3:a4:a5:a6:a7:a8:a9:aa:ab:ac:ad:
    ae:af
pub:
    9f:d7:ad:6d:cf:f4:29:8d:d3:f9:6d:5b:1b:2a:f9:
    10:a0:53:5b:14:88:d7:f8:fa:bb:34:9a:98:28:80:
    b6:15

Server Key Exchange 的消息格式如下所示:

struct {
select (KeyExchangeAlgorithm) {
    case dh_anon:
        ServerDHParams params;
    case dhe_dss:
    case dhe_rsa:
        ServerDHParams params;
        digitally-signed struct {
            opaque client_random[32];
            opaque server_random[32];
            ServerDHParams params;
        } signed_params;
    case rsa:
    case dh_dss:
    case dh_rsa:
        struct {} ;
        /* message is omitted for rsa, dh_dss, and dh_rsa */
    /* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;

不同的加密套件有不同的格式，由于我们的是 dhe_rsa，因此在消息中应当包含椭圆曲线参数，以及 ClientRandom+ServerRandom+参数 的签名信息。使用原始私钥来计算最终的签名信息:

$ cat client_random >> /tmp/compute
$ cat server_random >> /tmp/compute
# 03 -> named_curve; 001d -> curve x25519
$ echo -en '\x03\x00\x1d' >> /tmp/compute
$ echo -en '\x20' >> /tmp/compute # 临时私钥长度 32 字节
$ cat server-ephemeral-public.key >> /tmp/compute # 上述生成的临时公钥
$ openssl dgst -sign server.key -sha256 /tmp/compute | hexdump
0000000 04 02 b6 61 f7 c1 91 ee 59 be 45 37 66 39 bd c3
... snip ...
00000f0 7d 87 dc 33 18 64 35 71 22 6c 4d d2 c2 ac 41 fb

Server Hello Done

服务端表示自己这一边的握手已经完成，接下来就等待客户端计算相关握手信息了。

Client Key Exchange

客户端收到 ClientKeyExchange 后，得知服务器选择了 x25519 曲线，那么也类似的生成响应临时秘钥。随机生成 32 字节私钥:

202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

对应的公钥计算方法与 Server Key Exchange 中介绍的一样:

358072d6365880d1aeea329adf9121383851ed21a28e3b75e965d0d2cd166254

Client Key Exchange 的数据格式如下:

struct {
    select (KeyExchangeAlgorithm) {
        case rsa:
            EncryptedPreMasterSecret;
        case dhe_dss:
        case dhe_rsa:
        case dh_dss:
        case dh_rsa:
        case dh_anon:
            ClientDiffieHellmanPublic;
    } exchange_keys;
} ClientKeyExchange;

其格式相对简单，对于我们选择的加密套件而言只需要包含临时生成的 ECDH 公钥。注意此处与 Server Key Exchange 不同，并没有对客户端的公钥进行签名，也就是说可以被中间人进行替换。不过协议设计的时候已经考虑到了这一点，因为此时双方已经有足够的信息去协商秘钥并且进行验证了，通过后文的计算过程也可以确认这一点。

Client Change Cipher Spec

该数据包告诉服务器客户端已经计算好了共享秘钥，并且后续客户端发送给服务器的数据都将使用共享秘钥进行加密。在下一个版本的 TLS 中该数据包类型将会被移除，因为加密数据是可以通过数据类型推断的。

那么，客户端是如何计算出共享秘钥的呢？目前客户端所已知的数据为:

client_random
server_random
server-ephemeral-public.key
client-ephemeral-private.key

首先根据前文对 ECDH 的介绍，通过对方的公钥和自己的私钥，可以计算出一个共同秘钥，这里称之为 PMS(Pre-Master-Secret)，具体计算方法可以参考curve25519-mult.c:

$ gcc -o curve25519-mult curve25519-mult.c
$ ./curve25519-mult client-ephemeral-private.key \
                    server-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

实际上服务端计算出的共享秘钥也是一样的:

$ ./curve25519-mult server-ephemeral-private.key \
                    client-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

该共享秘钥计算过程只涉及自身私钥和对方的公钥，为了进一步将共享秘钥关联当当前会话中，需要为其加入双方的随机数，当然不能直接相加，需要增加随机性，因此使用到了一个伪随机函数，称为 PRF(pseudorandom function)。其计算方式如下:

seed = "master secret" + client_random + server_random
a0 = seed
a1 = HMAC-SHA256(key=PreMasterSecret, data=a0)
a2 = HMAC-SHA256(key=PreMasterSecret, data=a1)
p1 = HMAC-SHA256(key=PreMasterSecret, data=a1 + seed)
p2 = HMAC-SHA256(key=PreMasterSecret, data=a2 + seed)
MasterSecret = p1[all 32 bytes] + p2[first 16 bytes]

所得到的的 48 字节拓展秘钥称为主密钥(Master Secret)，其值为:

916abf9da55973e13614ae0a3f5d3f37b023ba129aee02cc9134338127cd7049781c8e19fc1eb2a7387ac06ae237344c

最后，我们需要将该主密钥进行拓展(至任意长度)，并将结果的不同部分分别用作不同秘钥，如下所示:

seed = "key expansion" + server_random + client_random
a0 = seed
a1 = HMAC-SHA256(key=MasterSecret, data=a0)
a2 = HMAC-SHA256(key=MasterSecret, data=a1)
a3 = HMAC-SHA256(key=MasterSecret, data=a2)
a4 = ...
p1 = HMAC-SHA256(key=MasterSecret, data=a1 + seed)
p2 = HMAC-SHA256(key=MasterSecret, data=a2 + seed)
p3 = HMAC-SHA256(key=MasterSecret, data=a3 + seed)
p4 = ...
p = p1 + p2 + p3 + p4 ...
client write mac key = [first 20 bytes of p]
server write mac key = [next 20 bytes of p]
client write key = [next 16 bytes of p]
server write key = [next 16 bytes of p]
client write IV = [next 16 bytes of p]
server write IV = [next 16 bytes of p]

最终秘钥分成了 6 个部分，分别是客户端和服务端的 MAC 秘钥、数据加密秘钥和初始向量。这里涉及到几个有趣的问题，比如:

为什么客户端和服务端要使用不同的数据加密秘钥？
为什么客户端和服务端要使用不同的 MAC 秘钥？
为什么要单独指定 IV？

根据 RFC5246 中的介绍，使用不同的 MAC 秘钥是为了防止来自一方的数据被注入到另一方中；对于使用流密钥加密的情况，客户端和服务端使用不同的秘钥也能防止秘钥重用攻击。

在 TLS 1.0 中的 CBC 使用了前一部分 Record 的数据作为 IV 导致了选择明文攻击 (chosen plaintext attack)，因此这在新版本中的 TLS 协议明确指定了 IV 的生成方法。注意这个 IV 只有部分需要额外指定 IV 的 AEAD 算法会用到。

总而言之，通过 ECDHE 秘钥交换，客户端计算出了下述秘钥:

client MAC key: 1b7d117c7d5f690bc263cae8ef60af0f1878acc2
server MAC key: 2ad8bdd8c601a617126f63540eb20906f781fad2
client write key: f656d037b173ef3e11169f27231a84b6
server write key: 752a18e7a9fcb7cbcdd8f98dd8f769eb
client write IV: a0d2550c9238eebfef5c32251abb67d6
server write IV: 434528db4937d540d393135e06a11bb8

PS: ChangeCipherSpec 消息并不是 Handshake(22) 消息的子结构，而是一个单独的消息，与 Handshake 并列，类型为 20。这是为了解决握手期间管道阻塞的问题。

Client Handshake Finished

该数据包告诉服务器，客户端的握手流程也已经完成。同时，还携带了一部分加密数据，所加密的内容称为 Verify Data，用以验证握手成功且没有被中间人修改过。

Verify Data 的内容是该消息之前的所有握手包的 HASH 经过 HMAC 计算出来的一个 12 字节数据，其计算方法为:

seed = "client finished" + SHA256(all handshake messages)
a0 = seed
a1 = HMAC-SHA256(key=MasterSecret, data=a0)
p1 = HMAC-SHA256(key=MasterSecret, data=a1 + seed)
verify_data = p1[first 12 bytes]

在示例数据包中，verify_data 值为 cf919626f1360c536aaad73a，使用 client_write_key 进行加密，服务端收到后使用对应的秘钥进行解密，所使用加解密算法由之前协商的加密套件决定，这里是 aes-128-cbc。

Server Change Cipher Spec

服务端收到上述加密后的数据为(Record Body):

404142434445464748494a4b4c4d4e4f
227bc9ba81ef30f2a8a78ff1df50844d
5804b7eeb2e214c32b6892aca3db7b78
077fdd90067c516bacb3ba90dedf720f

为了进行验证，服务端使用相同的方式计算出共享秘钥 Pre Master Secret，由 ECDH 的特性以及前文的计算可以看到，服务端和客户端计算出的 PMS 是相同的，因衍生出来的对称加密秘钥、IV、MAC 秘钥也是相同的。

故，服务端收到加密数据后，可以使用协商出来的 client_write_key 对其进行解密:

hexdata=227bc9ba81ef30f2a8a78ff1df50844d5804b7eeb2e214c32b6892aca3db7b78077fdd90067c516bacb3ba90dedf720f
# client write key
hexkey=f656d037b173ef3e11169f27231a84b6
# record iv，保存在加密数据之前
hexiv=404142434445464748494a4b4c4d4e4f

$ echo -n $hexdata | xxd -r -p | openssl enc -d -nopad -aes-128-cbc -K $hexkey -iv $hexiv | rax2 -S
1400000ccf919626f1360c536aaad73a
a5a03d233056e4ac6eba7fd9e5317fac
2db5b70e0b0b0b0b0b0b0b0b0b0b0b0b

值得注意的是这里使用的 key 是协商的 client_write_key，但 IV 并不是 client_write_iv，而是一个随机生成的针对当前 Record 的 IV，并且附加到加密数据的前方。

在解密后的数据中， 1400000c 是 Record 的子协议头部，对应 Handshake/Finish，长度 0x0c 即 12 字节，数据正好是前面计算出的 verify_data 的值，即 cf919626f1360c536aaad73a。

末尾还有 32 字节的数据，是使用 client mac key 计算的签名，用于确保所接收数据的完整性，计算方法为:

### from https://tools.ietf.org/html/rfc2246#section-6.2.3.1
$ sequence='0000000000000000'
$ rechdr='16 03 03'
$ datalen='00 10'
$ data='14 00 00 0c cf 91 96 26 f1 36 0c 53 6a aa d7 3a'
### client MAC key
$ mackey=1b7d117c7d5f690bc263cae8ef60af0f1878acc2
$ echo $sequence $rechdr $datalen $data | xxd -r -p \
  | openssl dgst -sha1 -mac HMAC -macopt hexkey:$mackey

a5a03d233056e4ac6eba7fd9e5317fac2db5b70e

再使用 PKCS#5 填充至 32 字节即为末尾添加的数据。服务端通过将客户端发送的 verify_data 与自身计算的值进行比对，可确保整个握手流程的完整性；使用 HMAC 校验当前数据可以保证消息没有被中间人篡改。

在这些校验都完成后，服务端给客户端返回 Change Cipher Spec 消息，告知客户端接下来发送的数据都将经过协商秘钥进行加密。当然，和前文一样，其实这条消息是多余的，在 TLS 1.3 中已经被移除了。

Server Handshake Finished

此时，服务端已经完成了握手的所有流程，并且也确认这个握手流程没有被中间人篡改，但是客户端还不知道啊！因此，类似于 Client Handshake Finished，服务端也要发送一个加密并验签的数据给客户端，让客户端进行验证并确认整个握手流程的正确性。

发送的数据格式和 Client Finished 几乎一样，只有几点小差异。比如数据使用 server_write_key 进行加密(而不是 client_write_key)，HMAC key 也是类似。另外计算 verify_data 与前者相比还多了一个 Client Finished 消息，毕竟协议中说的是用于验证 “当前消息前的所有握手消息”。

客户端收到 Server Finished 后，同样进行解密并校验 HMAC，如果确认无误就可以开始发送应用数据了。

注: ChangeCipherSpec、Alert 以及其他非 Handshake 的消息都不参与 verify_data 的计算，另外根据 RFC 的规定，HelloRequest 请求也不参与哈希计算。

Application Data

Application Data 是一个单独类型的 Record (type=23)，准确来说已经不属于握手阶段了，不过这里还是提一下。

该消息格式中主要是使用协商秘钥加密的应用数据，客户端发送的数据使用 client write key 进行加密，服务端返回的数据使用 server write key 进行加密，并且明文数据末尾还加了 HMAC 校验数据，使用对应的 MAC key 进行签名，加解密和签名过程和 Client/Server Finished 消息的过程一致。因此每条应用数据都可以保证机密性和完整性。

在新版本的 Wireshark 中，TLS 流量可以通过指定 keylog 文件进行解密，许多应用如 curl、Chrome 都可以通过指定 SSLKEYLOGFILE 环境变量指定 keylog 的位置，例如:

$ SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt curl https://example.com
$ cat ~/SSLKEYLOGFILE.txt
CLIENT_RANDOM 54BA544490B18D32B4725E40493A0839CA64AACE14A3E119C0658C49E12A998C EA6B59F06F9E2C219535A02C31FEDBE60053E235A91FC36701B2871477C18E99CE6F2F33144EB6FC28031BB7D51BEF00

keylog 文件的格式为 NSS Key Log Format，上述输出是针对 TLS 1.2 的会话秘钥，第一部分为客户端随机数，用于与具体的 TLS 流进行对应；第二部分则是 48 字节的 Pre Master Secret 值。根据我们前面的分析，通过该秘钥可以获取到双方的对称加密秘钥，因此就可以解密对应的 TLS 数据了。

TLS 1.3

由于 TLS 1.3 是在 TLS 1.2 的基础上优化而来的，因此对于与上节实现相同的部分就不再详细介绍了，而只关注其中不同的部分。

总体来看，TLS 1.3 与 TLS 1.2 相比，较大的差异有下面这些:

去除了一大堆过时的对称加密算法，只留下较为安全的 AEAD (Authenticated Encryption with Associated Data) 算法；加密套件(cipher suite) 的概念被修改为单独的认证、秘钥交换算法以及秘钥拓展和 MAC 用到的哈希算法；
去除了静态 RSA 和秘钥交换算法套件，使目前所有基于公钥的交换算法都能保证前向安全；
引入了 0-RTT(round-trip time) 的模式，减少握手的消息往返次数；
ServerHello 之后所有的握手消息都进行了加密；
修改了秘钥拓展算法，称为 HKDF (HMAC-based Extract-and-Expand Key Derivation Function)；
废弃了 TLS 1.2 中的协议版本协商方法，改为使用 Extension 实现；
TLS 1.2 中的会话恢复功能现在采用了新的 PSK 交换实现；
……

下面就以一个完整的握手流程去分析这之中的差异，所使用的秘钥和数据包可以在下面的链接中找到:

Client Hello

与 TLS 1.2 一样，握手总是以 Client 发送 Hello 请求开始。但正如本节开头所说，TLS 握手时的协议协商不再使用 Handshake/Hello 中的 version 字段，虽然是 1.3 版本，但请求中 version 还是指定 1.2 版本，这是因为有许多 web 中间件在设计时候会忽略不认识的 TLS 版本号，因此为了兼容性，版本号依旧保持不变。实际协商 TLS 版本是使用的是 Supported Versions 拓展实现的。

client_random 是客户端生成的随机数，这里是:

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

session_id 字段在此前的版本中该字段被用于恢复 TLS 会话，不过在 TLS 1.3 中会话恢复使用了一种更为灵活的 PSK 秘钥交换方式，因此这个字段在 TLS 1.3 中是没有实际作用的。

在 Client Hello 消息中，有一个重要的拓展，即 Key Share，用于与服务器交换秘钥。前文说到在 TLS 1.3 中，Server Hello 之后的所有消息都是加密的，为了双方能够正确加解密数据，因此在 Client Hello 中通过该拓展告诉服务端自己的公钥以及秘钥交换算法。

这里客户端还是指定了 x25519 椭圆曲线加密，并且生成一个临时私钥:

202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f

对应的公钥计算方法前文已经说过，这里再重复一遍:

$ openssl pkey -noout -text < client-ephemeral-private.key

X25519 Private-Key:
priv:
    20:21:22:23:24:25:26:27:28:29:2a:2b:2c:2d:2e:
    2f:30:31:32:33:34:35:36:37:38:39:3a:3b:3c:3d:
    3e:3f
pub:
    35:80:72:d6:36:58:80:d1:ae:ea:32:9a:df:91:21:
    38:38:51:ed:21:a2:8e:3b:75:e9:65:d0:d2:cd:16:
    62:54

随后，该公钥就随着 Client Hello 发送给了服务端。

Server Hello

服务端根据客户端提供的选项，选择一个好自己支持的 TLS 版本以及加密套件，这里选的是 TLS_AES_256_GCM_SHA384，返回的 server_random 为:

70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f

由于涉及到了秘钥交换，服务端在收到请求后也需要先生成一对临时公私钥，所生成的私钥为:

909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

对应的公钥是:

9fd7ad6dcff4298dd3f96d5b1b2af910a0535b1488d7f8fabb349a982880b615

Key Share Extension 中返回的即为上述公钥。如果还记得上文的 ECDH 秘钥交换方法，这里就可以很容易计算出两端的共享秘钥:

$ ./curve25519-mult server-ephemeral-private.key \
                    client-ephemeral-public.key | hexdump

0000000 df 4a 29 1b aa 1e b7 cf a6 93 4b 29 b4 74 ba ad
0000010 26 97 e2 9f 1f 92 0d cc 77 c8 a0 a0 88 44 76 24

该秘钥用于生成后续握手包所需的秘钥，使用 HKDF 函数进行生成，如下所示:

early_secret = HKDF-Extract(salt: 00, key: 00...)
empty_hash = SHA384("")
derived_secret = HKDF-Expand-Label(key: early_secret, label: "derived", ctx: empty_hash, len: 48)
handshake_secret = HKDF-Extract(salt: derived_secret, key: shared_secret)
client_secret = HKDF-Expand-Label(key: handshake_secret, label: "c hs traffic", ctx: hello_hash, len: 48)
server_secret = HKDF-Expand-Label(key: handshake_secret, label: "s hs traffic", ctx: hello_hash, len: 48)
client_handshake_key = HKDF-Expand-Label(key: client_secret, label: "key", ctx: "", len: 32)
server_handshake_key = HKDF-Expand-Label(key: server_secret, label: "key", ctx: "", len: 32)
client_handshake_iv = HKDF-Expand-Label(key: client_secret, label: "iv", ctx: "", len: 12)
server_handshake_iv = HKDF-Expand-Label(key: server_secret, label: "iv", ctx: "", len: 12)

得到以下秘钥:

handshake secret: bdbbe8757494bef20de932598294ea65b5e6bf6dc5c02a960a2de2eaa9b07c929078d2caa0936231c38d1725f179d299
server handshake traffic secret: 23323da031634b241dd37d61032b62a4f450584d1f7f47983ba2f7cc0cdcc39a68f481f2b019f9403a3051908a5d1622.
client handshake traffic secret: db89d2d6df0e84fed74a2288f8fd4d0959f790ff23946cdf4c26d85e51bebd42ae184501972f8d30c4a3e4a3693d0ef0.
server handshake key: 9f13575ce3f8cfc1df64a77ceaffe89700b492ad31b4fab01c4792be1b266b7f
server handshake IV: 9563bc8b590f671f488d2da3
client handshake key: 1135b4826a9a70257e5a391ad93093dfd7c4214812f493b3e3daae1eb2b1ac69
client handshake IV: 4256d2e0e88babdd05eb2f27

客户端也可以计算出同样的秘钥值。

Server Encrypted Extensions

在计算完共享秘钥后，后续的流量将使用上述秘钥进行加密，因此对于 TLS 1.2 的情况服务端会先返回一个 ChangeCipherSpec，在 TLS 1.3 中可不必多此一举，不过在兼容模式下为了防止某些中间件抽风还是会多这么一步。

我们这里直接看加密的数据，服务端一般会先返回一个 Encrypted Extensions 类型的 Record 消息，该消息加密后存放在 Record(type=0x17)，即 Application Data 的 Body 部分，同时(加密后数据的)末尾还添加了 16 字节的 Auth Tag，这是 AEAD 算法用来校验加密消息完整性的数据。

数据使用 AES-256-GCM 进行加密和校验，解密代码可以参考 aes_256_gcm_decrypt.c，使用 server hanshake key/iv 进行解密的示例如下所示:

# server handshake key
$ key=9f13575ce3f8cfc1df64a77ceaffe89700b492ad31b4fab01c4792be1b266b7f
# server handshake iv
$ iv=9563bc8b590f671f488d2da3
### from this record
$ recdata=1703030017
$ authtag=9ddef56f2468b90adfa25101ab0344ae
$ recordnum=0
### may need to add -I and -L flags for include and lib dirs
$ cc -o aes_256_gcm_decrypt aes_256_gcm_decrypt.c -lssl -lcrypto
$ echo "6b e0 2f 9d a7 c2 dc" | xxd -r -p > /tmp/msg1
$ cat /tmp/msg1 \
  | ./aes_256_gcm_decrypt $iv $recordnum $key $recdata $authtag \
  | hexdump -C

00000000  08 00 00 02 00 00 16                              |.......|

这里解密后的拓展长度为空。一般与握手无关的额外拓展都会放在这里返回，这是为了能够尽可能地减少握手阶段的明文传输。

注: 如无特殊说明，后续的握手包都是使用相同方法进行加密的，并且只针对解密后的原数据进行分析。

Server Certificate

使用 server handshake key/iv 进行加密。解密后的数据与 TLS 1.2 的证书响应相同，因此不再赘述。

Server Certificate Verify

前文 Hello 阶段进行 ECDHE 秘钥交换的时候其实有个问题，即双方只交换了公钥，却没有认证这个秘钥，因此如果存在网络劫持，就可能被中间人进行攻击，那加密似乎也只是加了个寂寞。

但无需担心，这点早已在计划之中。虽然之前没有进行认证，但可以后面补上。Server Certificate Verify 就是这个作用。该消息将服务端证书的私钥与之前生成的临时公钥进行绑定，准确来说是使用证书的私钥对其进行签名，并将签名算法与结果返回给客户端。由于客户端可以认证证书的有消息，就间接地证实了之前所交换的秘钥的真实性。

struct {
    SignatureScheme algorithm;
    opaque signature<0..2^16-1>;
} CertificateVerify;

同理，如果服务端需要验证客户端的真实性，那么在提供客户端证书后也同样发送一个 Certificate Verify 消息即可。

Server Handshake Finished

至此服务端所需要发送的握手包已经发送完毕了，因此最后发送一个 Finished 数据给客户端并等待对方的握手完成。在 Finished 数据中，消息体的内容和 TLS 1.2 类似，是通过此前所有的握手数据计算得到的 verify_data，并使用 HMAC 进行认证，进一步确保此前的消息没有经过中间人修改。

计算方法如下:

finished_key = HKDF-Expand-Label(key: server_secret, label: "finished", ctx: "", len: 32)
finished_hash = SHA384(Client Hello ... Server Cert Verify)
verify_data = HMAC-SHA384(key: finished_key, msg: finished_hash)

server_secret 是指前文中协商得到的 server handshake traffic secret。

同时，服务端使用前面协商得到的 handshake secret 加上前面所有握手包的哈希重新计算出一个应用秘钥，用于加密实际的应用数据。计算方法如下:

empty_hash = SHA384("")
derived_secret = HKDF-Expand-Label(key: handshake_secret, label: "derived", ctx: empty_hash, len: 48)
master_secret = HKDF-Extract(salt: derived_secret, key: 00...)
client_secret = HKDF-Expand-Label(key: master_secret, label: "c ap traffic", ctx: handshake_hash, len: 48)
server_secret = HKDF-Expand-Label(key: master_secret, label: "s ap traffic", ctx: handshake_hash, len: 48)
client_application_key = HKDF-Expand-Label(key: client_secret, label: "key", ctx: "", len: 32)
server_application_key = HKDF-Expand-Label(key: server_secret, label: "key", ctx: "", len: 32)
client_application_iv = HKDF-Expand-Label(key: client_secret, label: "iv", ctx: "", len: 12)
server_application_iv = HKDF-Expand-Label(key: server_secret, label: "iv", ctx: "", len: 12)

之所以重新计算而不是使用 handshake key 是为了防止针对某些加密套件可能存在的选择密文攻击。最终得到:

server application key: 01f78623f17e3edcc09e944027ba3218d57c8e0db93cd3ac419309274700ac27
server application IV: 196a750b0c5049c0cc51a541
client application key: de2f4c7672723a692319873e5c227606691a32d1c59d8b9f51dbb9352e9ca9cc
client application IV: bb007956f474b25de902432f

相当于 TLS 1.2 中的 client/server write key/IV。

Client Handshake Finished

由于双方的 handshake secret 相同，那么由此派生出来的 application key/iv 必然也是相同的。

客户端在收到 Server Finished 之后会使用对应服务器证书对数据进行校验，确认无误后进行可选的 ChangeCipherSpec 将加密并签名的 verify_data 在 Finished 请求中发送给服务器。

# client handshake traffic secret
finished_key = HKDF-Expand-Label(key: client_secret, label: "finished", ctx: "", len: 32)
finished_hash = SHA384(Client Hello ... Server Finished)
verify_data = HMAC-SHA384(key: finished_key, msg: finished_hash)

可以这么理解，Server Finished 用来让客户端确认服务端没有被中间人攻击，而 Client Finished 则用来让服务端确认客户端没有被中间人攻击。双向认证之后则可以保证 TLS 握手的真实性和完整性，成功建立加密信道。

Server Session Ticket

这一步通常是可选的。服务端在握手完成后会发送若干个 ticket 给客户端，可以理解为 web 中的 cookie。客户端在后续如果需要重新发起握手，可以带上这个 ticket，用于恢复当前的 TLS 会话。从上面的握手流程可见 TLS 握手需要涉及许多计算和网络请求，如果能够恢复会话，将极大地降低云服务器资源和网络延时。

ticket 消息的格式如下:

struct {
    uint32 ticket_lifetime;
    uint32 ticket_age_add;
    opaque ticket_nonce<0..255>;
    opaque ticket<1..2^16-1>;
    Extension extensions<0..2^16-2>;
} NewSessionTicket;

包含有效期、随机数等信息。其中 ticket 字段对于客户端是透明的，但对于服务端而言需要是有效的会话凭据，可通过该数据恢复之前的 TLS 会话。

由于 ticket 是一次性的，综合考虑时间和空间成本，一般服务端都会返回两个 ticket 给客户端。由于是服务端返回的数据，因此使用 server application key/iv 进行加密。

Application Data

随后客户端发送的数据加密方式与 handshake 过程的加密类似，区别仅在于应用数据的加密使用的是 client application key/iv，服务端发送给客户端的数据使用 server application key/iv。

前文说到 Wireshark 支持导入 keylog 解密 TLS 1.2 流量，其实对于 TLS 1.3 也可以，但由于后者在 Server Hello 之后的握手包都经过了加密，因此要解密 TLS 1.3 数据流还分别需要握手阶段的秘钥。

以本节所涉及到的握手包为例，其 keylog 内容如下:

$ openssl s_client -keylogfile keylog.txt -connect example.com:443
$ cat keylog.txt
SERVER_HANDSHAKE_TRAFFIC_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 23323da031634b241dd37d61032b62a4f450584d1f7f47983ba2f7cc0cdcc39a68f481f2b019f9403a3051908a5d1622
CLIENT_HANDSHAKE_TRAFFIC_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f db89d2d6df0e84fed74a2288f8fd4d0959f790ff23946cdf4c26d85e51bebd42ae184501972f8d30c4a3e4a3693d0ef0
EXPORTER_SECRET 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 5da16dd8325dd8279e4535363384d9ad0dbe370538fc3ad74e53d533b77ac35ee072d56c90871344e6857ccb2efc9e14
SERVER_TRAFFIC_SECRET_0 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 86c967fd7747a36a0685b4ed8d0e6b4c02b4ddaf3cd294aa44e9f6b0183bf911e89a189ba5dfd71fccffb5cc164901f8
CLIENT_TRAFFIC_SECRET_0 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 9e47af27cb60d818a9ea7d233cb5ed4cc525fcd74614fb24b0ee59acb8e5aa7ff8d88b89792114208fec291a6fa96bad

同一个 TLS 流中的 RANDOM 值相同，且都是 client_random，使用 Label 来区分不同阶段的秘钥。值得一提的是 macOS 中的 LibreSSL 还不支持 -keylogfile 选项，因此上面的命令是在 Linux 中进行测试的。

至此，TLS 1.2 和 TLS 1.3 的常规握手流程基本上也分析完了，当然在这其中还存在一些减少 RTT 的优化，篇幅原因就留到以后分析 mmtls 的时候再说了。

Android 证书 hash

还记得前文中介绍 Server Certificate 的时候，服务端返回一直到除了根证书以外的的证书链，那么从最后一个证书是如何定位到根证书的呢？一般认为是通过 issuer 字段，但 issuer 字段只是一段文字(ASN.1)，很可能会重复，这样岂不是有歧义？。其实分析 Android 的验证流程就可以知道。

了解 Android 应用安全的朋友应该都知道系统的根证书存放在 /system/etc/security/cacerts/ 之中，里面的证书都是 xxxx.0 格式，这是个传统的 PEM 格式证书，但名字比较特殊，使用 openssl x509 -subject_hash_old 生成。

通过阅读 AOSP 相关代码会发现，这个文件名的前半部分也正是证书的 subject 字段的 MD5，后半部分的 .0 则是为了防止哈希碰撞预留的计数字段，如果有重复就加一，相关代码如下:

// frameworks/base/core/java/android/security/net/config/DirectoryCertificateSource.java
private Set<X509Certificate> findCerts(X500Principal subj, CertSelector selector) {
    String hash = getHash(subj);
    Set<X509Certificate> certs = null;
    for (int index = 0; index >= 0; index++) {
        String fileName = hash + "." + index;
        if (!new File(mDir, fileName).exists()) {
            break;
        }
        if (isCertMarkedAsRemoved(fileName)) {
            continue;
        }
        X509Certificate cert = readCertificate(fileName);
        if (cert == null) {
            continue;
        }
        if (!subj.equals(cert.getSubjectX500Principal())) {
            continue;
        }
        if (selector.match(cert)) {
            if (certs == null) {
                certs = new ArraySet<X509Certificate>();
            }
            certs.add(cert);
        }
    }
    return certs != null ? certs : Collections.<X509Certificate>emptySet();
}

我们也可以通过以下 Python 脚本去进行手动计算:

from cryptography import x509
import hashlib
import struct

with open("01419da9.0", "rb") as f:
    pem = f.read()
cert = x509.load_pem_x509_certificate(pem)
d = hashlib.md5(cert.subject.public_bytes()).digest()
out = struct.unpack(", d[:4])[0]
print("hash: %08x" % out)
assert(out == 0x01419da9)

SSL Pinning

SSL Pinning 又称为 Certificate Pinning，通常翻译为证书绑定。但个人感觉这个翻译其实不太准确，因为绑定关系通常是双向的，而 Pinning 操作实质上只是客户端应用限制了本身所信任的 CA 范围，类似于图钉将某个证书固定到对应域名上。

在 Android 应用中可以通过 NSC(Network Security Config) 来设置证书绑定规则，例如:

res/xml/network_security_config.xml:



    
         includeSubdomains="true">evilpan.com
         expiration="2022-01-01">
             digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=
            
             digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=

由于证书有效期的问题，客户端应用如果无法及时升级，可能会导致服务端证书更新后无法正常进行 HTTPS 通信，因此 Google 是不推荐应用使用证书绑定的。如果一定要用的话，最好提供一个备用的可控 pin(比如自签名的证书)，用以保障通信的可用性。

当然不使用 NSC 也是可以实现证书绑定。因为本质上只是对服务端证书的单独比对，将 TLS 握手过程中获取的服务端证书或者其中的公钥与本地保存的值进行额外的校验。这个校验过程可以放在 Java 层，比如 okhttp 的 CertificatePinner，也可以放在 native 层，比如抖音的 libttboringssl.so，但这都是具体实现问题了。

值得一提的是在 TLS 的文档里并没有证书绑定这一概念，倒是有一个独立的 RFC7469 介绍针对 HTTP 协议的公钥拓展(Public Key Pinning)，使用约定的 HTTP 头来提供 TLS 证书公钥的 HASH，不过目前使用并不是很广泛。

后记

本文主要介绍了 TLS 1.2 和 TLS 1.3 的常规握手过程，分别参考了 RFC5246 和 RFC8446。虽然有很多细节还没有涉及到，但总的来说对 TLS 的理解又加深了一点，也算没浪费这个周末。后续有时间的话会总结一些在客户端安全研究时的网络分析方法，以及一些关于 TLS 的有趣特性，Stay Tune!

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2022/05/15/tls-basics/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

从身份证芯片的“秘密”谈谈网络信息搜索

Sun, 31 May 2020 22:40:00 +0800

本文主要记录一下对身份证加密芯片和SAM密码模块的相关资料搜索过程，并(尽量)总结归纳一下搜索中的一些经验和心得。

注：本人未曾参与过身份证相关研发工作，文中内容全部来自于互联网公开信息

前言

每当我因为办事需要用到身份证时，就会看着卡片上自己英俊的照片陷入沉思：这张小小的身份证是如何证明我的身份的？经过简单的查询可以知道身份证里面有一张芯片，通过一些密码学的黑魔法可以读取和校验个人信息，仅此而已。这对于喜欢刨根问底的人而言显然不是一个满意的回答，因此在一个无聊的周末，我决定尝试认真研究一下，看看自己能挖得多深。在解决这单个无聊问题的同时，也让我对网络信息查询有了一点新的体会，不愿藏拙一并分享给大家。

Round1：模糊查询

要说搜索信息，我们第一个想到的肯定是百度，毕竟这是“最懂中国人的搜索引擎”。但事实上搜索技术发展到现在，各个搜索引擎的索引结果其实都大同小异，甚至一些国外的搜索引擎对于中文也有了比较高质量的搜索结果，比如Google、Bing、Yandex等等，而对于英文信息的搜索，无疑也是国际化的搜索引擎更胜一筹。

因为我们搜索的是中国的二代身份证芯片信息，所以还是选择中文搜索引擎，首先在百度中搜索关键字身份证芯片：

baidu

说实话，信息比我想象的要多。其实第一次搜索的目的主要是筛选关键字，并根据关键字进行下一步的精细搜索，通过百度上的内容我们可以得知的信息有：

二代身份证中使用的是非接触式IC卡
IC卡中包含加密模块，存有个人信息
IC芯片的疑似部分制造商信息
需要有专门的解密模块才能读取和写入个人信息

通过深度优先算法逐一查看这些搜索结果，并没有太多的额外内容，但是得知了解密模块的昵称为SAM模块，全称猜测是Security Authentication Module之类。在一些电子论坛中可以看到有相关行业人员的一些讨论，SAM模块由公安部提供，分为两种型号：

0501：只能解码身份证文字和头像图片信息
0503：除了0501能读的信息，还包括指纹信息

说到具体有哪些信息，搜索中也遇到了一些语焉不详故作神秘的回答：

sec

不能回答不要浪费我流量，OK？

总而言之，第一步的目的已经基本达到，我们获取了一些关键词：加密芯片、SAM模块等等，接下来就需要用这些关键词去进行下一步的搜索。值得一提的是，大部分问题是否能找到想要的回答，更多是取决于你是否Ask The Right Question，即是否问到了点上，模糊查询的目的就是找出这些点。

Round2：精确搜索

通过身份证SAM模块和加密芯片的关键字，我进行了第二轮的搜索，这次找到了一些其他内容：

sam

已经从小白式的问答逐渐转入了圈子内(开发者)的问答，这是个问对问题的好迹象。同样阅读这些搜索结果，我们得知身份证读卡模块有很多厂商在生产和销售，点进其中一个厂商的网站查看对应产品的信息，可以看到读卡模块长这样：

根据我粗浅的电路知识可以知道的是，右边为IC读卡线圈，将读取的IC芯片信息传输到左边的板子中进行解密，解密后的信息通过USB再读取到电脑或者其他设备中进行存储和进一步验证。

左边的电路板似乎就是我们要找的SAM模块，但仔细一想，功能单一的密码模块不可能这么庞大，所以这只是集成了密码模块的的一个完整系统，SAM模块只是其中的一部分(视力好的同学可以看看是哪个部分)。

在论坛和厂商的文档中，我们至少可以知道身份证芯片中所包含的内容包括姓名、民族、出生年月、照片等卡片上本来就有的信息，以及指纹信息。其中指纹信息解密后并不是常规的bitmap，而是特殊的特征信息，指纹特征比对算法是由公安部认证的算法提供商所提供的。

Round3：去伪存真

上面这些信息，其实更多的是一些“道听途说”的内容，出于严谨的考虑，还是希望能找到出处。因此，这一步的搜索就需要进一步限定范围。其实如果是公开信息，那么这些信息一般都会在国家标准中找到出处，现在假设我还不知道这点，就先用传统搜索方法，在公开论文中查找。

论文一般是别人花费心思的研究成果，因此查找论文的好处是可以尽可能保证信息的准确性，并在此基础上通过论文中的引用文献进一步确定我们需要寻找的方向。另外通过阅读高质量的论文对于我们快速了解一个领域也是很有帮助的，一个小技巧是在论文搜索中使用关键字+综述(英文论文则是关键字+survey)的查找方式，通过几篇论文就能大概知道特定领域的过去、现在以及未来发展。

回到身份证的问题上，搜索到的相关论文有：

《第二代居民身份证集成电路设计关键技术研究》—— 公安部第一研究所
《第二代居民身份证阅读器原理与应用》—— 公安部第一研究所证件部
《RFID技术在身份证系统中的应用》—— 公安部第一研究所
《身份证件的安全要求和可使用的密码学技术》—— 中科院信息工程研究所信息安全国家重点实验室
《身份证阅读器的研究与设计》—— 武汉理工大学
……

阅读理解后可以知道二代身份证系统主要分为两个部分，一个是制卡发证系统，另外一个是社会应用系统，前者主要由公安部直接进行管理和协调，后者则在一定程度上开放给各个厂商。制卡发证系统主要是将用户信息通过公安部私钥进行加密并写入身份证芯片中，写入后无法修改(ROM或者写入后烧断熔丝)。社会应用就是上面提到的身份证阅读器生态，主要是使用公安部预置公钥的安全密码模块对身份证芯片中读取的信息进行解密和校验。

身份证信息的读取在物理层上和其他IC卡(银行卡、公交卡、饭卡)类似，都是通过读卡器发送射频信号触发IC卡的电路从而进行数据交互，因此不多展开，重点是其中特有的安全认证过程。在上述论文的引用文献中，发现了一个官方的标准文档——GA 467—2013 :

该标准由公安部一所、公安部居民身份证秘钥管理中心和数据通信科学技术研究所联合起草，定义了身份证安全控制模块接口、信号时序、传输协议以及操作命令。其中定义的安全模块名称为SAM_A(Secure Access Module for Authentication)，即验证安全控制模块，从而订正了我们前面对SAM的错误缩写。值得一提的是，在该标准的前一版(2004版)中，安全模块的缩写为SAM_V，这也是很多厂商惯用的叫法。

SAM模块的内部实现是非公开的，因此我们就从接口本身去看。SAM模块的一方面通过射频模块接口与身份证IC卡通信，另一方面通过串口UART或者USB接口与业务终端进行通信。业务终端传输到SAM模块的命令分为两个部分，分别是命令码(CMD)和命令参数(Para)，各为1字节，一共有10个命令码，如下表所示：

cmd

SAM模块返回给业务终端的响应使用状态字(SW)表示，一共有3个状态字和一个帧数据内容(Data)段，分别表示返回结果以及返回的数据内容。

面向身份证IC卡的射频部分同样指定了读写协议，值得重点提一下的是SAM模块对于和身份证IC卡的交互中定义了精确的时序范围。为什么说这个呢？因为曾经出现过的一种方案就是使用手机作为读卡器，并将读取的IC卡裸数据转发到云端的SAM模块去解密，这样可以少买一点SAM模块。……不过这种方案对于网络延时是相当敏感的，根据标准中的定义很可能导致操作超时。

因此我想要了解的信息就基本满足了，在查找资料的过程中，通过对这些国标的交叉查阅，发现了另外关于身份证各个方面的详细定义，包括证件的UI布局、证件号码的格式与校验，还顺便找到了上面那个故作神秘的知乎回答(身份证芯片中保存的是什么信息)的真正答案：

出自《GA448—2013 居民身份证总体技术要求》

更进一步，我还顺便找到了身份证芯片中每个字段的内容含义以及存储空间大小：

数据项	字节数	备注
姓名	30
性别代码	2	GB/T 2261.1
民族代码	2	GB/T 3304
出生日期	16	格式为YYYYMMDD
住址	70
公民身份证号码	36	GB 11643
签发机关	30
有效期起始日期	16	GA/T 2000.16
有效期截止日期	16	同上
reserve	36	预留区
相片信息	1024	以二进制存储的WLT格式文件
指纹1	512	第一枚指纹特征数据
指纹2	512	第二枚指纹特征数据
追加住址1	70
追加住址2	70
追加住址3	70
追加住址4	70
电路序号	8
证卡序号	16

出自《GA490—2019 居民身份证机读信息规范》

总结

一开始对身份证芯片的疑惑现在已经基本得到满足，只剩下目前暂未公开的身份证芯片和SAM模块的内部实现。这部分有机会的话会进行进一步的逆向和研究，比如读取SAM芯片的固件进行分析，不过这就是不可说的部分了。

身份证的“秘密”本身并不是太过需要关注的重点，重点是挖掘秘密的过程。现代互联网中信息繁多且良莠不齐，再加上各种内容农场疯狂霸占搜索引擎的首页，如何在其中找到真正需要的信息其实对网民也是一种挑战。信息搜索说难不难，说简单也不简单，关键是要在正确的地方问到正确的问题。问问题的学问很多其他文章已经有介绍过了，问出正确的问题是需要有一定先验积累的，如果无法理解问题，又怎么能理解回答呢？

另外在正确的地方提问也十分重要，比如编程问题上stackoverflow，了解专业领域到专门的论文平台搜索等，国内的有知网、百度学术，国外的论文可以上arxiv.org找。而对于某些工业、设计上的问题，比如本文提及的身份证芯片，一般会有专门的标准文档进行介绍。

各类标准按照不同的行业和领域有自己的前缀，比如GB、GA、GM等等，分散在不同的标准网站中，其中政府的官方网站做了一个比较完整的聚合，可以查询各类标准的标题，具体标准还是要到具体的网站中搜索。

国家标准信息查询：http://www.gov.cn/fuwu/bmfw/zggjbzhglwyhgjbzxxcx/index.html

GB为国家标准：

标准信息公共服务平台：http://std.samr.gov.cn/
食品安全国家标准数据检索平台：https://sppt.cfsa.net.cn:8086/db

GA为公共安全行业标准，由公安部归口管理：

政府信息公开：http://app.mps.gov.cn/gdnps/index.jsp

GM为密码行业标准，目前由国家密码管理局（国家商用密码管理办公室）归口管理：

国家密码管理局标准规范：http://www.oscca.gov.cn/sca/xxgk/bzgf.shtml

其他各个行业的标准，可以参考知乎中行业标准文本查询下载方法的总结，毕竟标准文本的查询和加载也是个可以在网上找到答案的开放问题，这里就不再赘述了。

202408 更新

发现 NFC Wiki - 二代居民身份证一文写得不错，二代身份证中的射频芯片可以通过 NFC 读取，读取的数据为 SAM 加密，具体加密算法不明，但大概率为国密 SM1。

椭圆曲线加密与NSA后门考古

Sun, 17 May 2020 22:40:00 +0800

本文主要介绍椭圆曲线的基本原理以及基于椭圆曲线的密码学实现，包括ECC加密、ECDH秘钥交换以及ECDSA签名算法，并介绍其中潜在的一些安全问题。其中分析了两个ECC实现相关的真实案例，分别是索尼PS3的签名问题和美国国家安全局NSA留下的椭圆曲线后门。

前言

上周写过一篇关于RSA实现的介绍文章。相对于RSA对称加密，椭圆曲线加密要复杂得多，以至于多数的介绍文章都难免涉及大量的数学理论和公式。作为一个非密码学专业的业余爱好者，我的目的只是希望对这些概念有个宏观的理解，因此本文会对涉及到的概念在尽量保证正确的前提下进行简化描述。

椭圆曲线

作为梦开始的地方，椭圆曲线(Elliptic Curve)真的只是一个曲线，和其他曲线一样，都是函数在坐标轴中的一个映射。根据mathworld中给出的椭圆曲线定义，描述椭圆曲线的函数可以定义如下：

y^2 = x^3 + a*x + b

其中a、b是曲线的特征参数，决定了椭圆曲线的形状。当43*a^3 + 27*b^2 = 0时，椭圆曲线退化成奇异曲线，因此不再是合法的椭圆曲线。上述方程的表示方法也称为Weierstrass nomal form。椭圆曲线在坐标系上的形状参考如下：

通过观察或者证明都可以得知椭圆曲线是关于x轴对称的。为了理解椭圆曲线，还需要引入一个无穷远点作为曲线的一部分，也称为理想点，用符号0表示。椭圆曲线本身比较直观，在不同取值范围中会存在不同的特性，下面会分别进行介绍。

实数集

在数学中，**群(Group)**表示一个特殊的集合，对于集合中的元素我们可以执行二元运算，比如加法(+)。一个集合成为群的前提是需要满足以下4个条件

封闭性：若a和b属于群G，则a+b也属于群G
结合性：(a+b)+c = a+(b+c)
存在单位元θ，使得a + θ = θ + a = a
群中每个元素都存在逆元素，即对于任意元素a存在b，使得a + b = θ

如果集合满足上述条件且满足第5条：

交换律：a + b = b + a

那么该集合也称为阿贝尔群(abelian group)。

单位元：在二元运算中，单位元与任意元素运算不改变其值，比如实数中加法单位元是0，乘法单位元是1

根据定义，整数集合是一个群(阿贝尔群)，但自然数集合不是一个群，因为不满足第4个条件。

如果一个集合是一个群，那么就可以推导出它也满足其他一些性质，比如单位元唯一性、逆元素唯一性等。

椭圆曲线和群有什么关系？实际上我们可以在椭圆曲线上定义一个群，具体来说：

群的元素是椭圆曲线上的点
单位元是无穷远点0
点P的逆是它关于x轴的对称点
加法的定义为：对于三个同一直线上的非零点P、Q和R，它们的和为P+Q+R =0

用图来表示就是：

GROUP

这只是一种几何表示，比如计算P+P，实际上是在P点作一条切线。为了能够进行计算，我们需要将几何加法转换成代数加法，即将上述规则转换为一组方程。其中涉及到三次方程的解，这里直接给结论，假设P、Q、R的坐标分别是(Px, Py)、(Qx, Qy)、(Rx, Ry)，则：

# 直线斜率为m
m = (Py - Qy) / (Px - Qx)
Rx = m^2 - Px - Qx
Ry = Py + m(Rx - Px)

因此，计算P+Q也就可以在代数上转化为对*(Rx, -Ry)*的计算。

有了加法，自然就可以推出乘法：

n * P = P + P + P + ... + P

其中n是自然数。写成以上形式需要计算n次加法，算法复杂度为O(2^k)，k为n的位宽。实际上可以转换为倍乘相加(double and add)的方式，例如：

151 * P = 2^4 * P + 2^2 * P + 2^1 * P + 2^0 * P

这样可以将算法复杂度减少到O(logn)，或者说O(k)。

有了乘法，自然有除法。给定n和P，我们至少有一种在多项式时间内计算出Q=nP的算法。那么反过来，给定Q和P，是否能计算出n呢？这个问题就是我们常说的对数问题(logarithm problem)。其实这里应该说是除数问题，但大多密码学算法是基于指数计算的，因此求逆称为对数。对数问题求解的时间远大于乘法的计算时间，但连续对数的解存在一些特点，因此并不算是个合格的难题，这里只是引出这个概念，以及我们下面将要看到的真正主角——离散对数问题。

有限域

接下来我们将椭圆函数的范围从实数集转到有限集，或者称为有限域(finite field)。域(field)在抽象代数是个专有名词，表示一种支持可进行加减乘除运算的代数结构，并且运算结果不会超出域的集合，其概念是数域和四则运算的拓展。

有理数集合、实数集合都满足域的概念，如果一个域中的元素个数有限，则成为有限域。有限域一个典型是伽罗瓦域(Galois Field)，记作GF(p^n)，其中p是素数，n是正整数。p^n也称为有限域的阶(order)，即有限域中的元素个数。n=1时称为素数域GF(p)。

GF(p)元素集合为所有从0到p-1的整数，其加法和乘法可以转换为模运算，也称为时钟算术，例如对GF(23)：

加法：(18+9) mod 23 = 4
减法：(7-14) mod 23 = 16
乘法：4 * 7 mod 23 = 5
加法逆元：-5 mod 32 = 18
- (5 + (-5)) mod 23 = (5 + 18) mod 23 = 0
乘法逆元：9^-1 mod 23 = 18
- 9 * 9^-1 mod 23 = (9 * 18) mod 23 = 1

使用拓展欧几里得算法，我们可以在O(logp)的复杂度内计算出某个数的乘法逆元，这也是除法计算的基础。

在将椭圆曲线的范围限制到有限域中后，椭圆曲线的算式定义也可以做出如下修改：

FORMULA

其中0依旧是无穷远点，而a、b是有限域集合中的两个整数。对于任意x，最多存在两个点，即两个y的解。

举个例子，对于椭圆曲线y^2 ≡ x^3 - 7x + 10 (mod p)，当p的值分别是19、97、127、487时，其在坐标轴上的图像如下：

ECD

注意这些点的集合在直角坐标中是关于直线y=p/2对称的。虽然之前连续的椭圆曲线现在变成了离散的点，但可以证明这些点的集合同样是一个阿贝尔群，因此也满足群的定义和推论。

那么，我们要如何定义和计算这些离散点的加法呢？与实数集中我们定义几何学上同一直线上的三个点P、Q、R之和为0，有限域中也类似，不过这里的直线并不是实数集中的直线，而是满足*ax + by + c ≡ 0 (mod p)*的点的集合。

举例来说，椭圆曲线y^2 ≡ x^3 - x + 3 (mod 127)，且P=(16, 20)，Q=(41,120)。注意连接它们的“直线” *y ≡ 4x + 83 (mod 127)*实际上在空间中是重复的：

LINE

计算对应几何表示的代数加法和前面类似，不过后面都需要加上(mod p)，这是可以推导出来的。

从加法到乘法同样可以使用倍乘加的算法加速运算，同时对于有限域的椭圆曲线，乘法还有个有趣的特点。例如对于椭圆曲线*y^2 ≡ x^3 + 2x + 3 (mod 97)*和点 P=(3,6)，在计算乘积时发现：

0P = 0
1P = (3,6)
2P = (80,10)
3P = (80,87)
4P = (3, 91)
5P = 0
6P = (3, 6)
7P = (80, 10)
…

乘积每5次一个循环，也就是说实际上该点的乘积只有5个可能的值，这个规律可以写成：

k * P = (k mod 5) * P

同时，这5个点本身也是封闭的，即这些点相加也是其中某个点：

n * P + m * P = (m + n) * P

因此，P的乘积所组成的集合也是一个群，称为循环子群，P称为该循环子群的生成器(generator)或者基点(base point)。循环子群是椭圆曲线加密的基础，在后面的章节会进行介绍。

循环子群的元素个数称为该子群的阶(order)，比如上述子群的阶为5。通过给定椭圆曲线和基点P我们可以计算出子群的阶。

在椭圆曲线加密中一个常见需求就是找到一个阶比较高的子群。假设椭圆曲线的阶为N，子群的阶为n，想要寻找的基点为P。根据拉格朗日定理h = N / n总是一个整数，h称为子群的余因子(cofactor)。考虑到椭圆曲线中所有点的和NP = 0，我们可以写成：

n(hP) = 0

假设n是一个素数，该等式实际上告诉我们：对于一个随机的点P，以点G = hP为基点的子群阶的阶为n(当G不为0时，G为0则子群阶为1)。当然该算法也要求n是一个素数，否则G的阶只是n的其中一个除数而已。

介绍完了乘法，最后就让我们来看除法：给定点P和Q，并且Q = kP，如何求k的值？这个问题就是椭圆曲线的离散对数问题，这个问题是一个公认的难题，目前没有一个多项式时间的求解算法可以计算出来。与大数分解问题类似，这个难题也只是实践上的，并没有严谨的数学证明不可解。

实际的加密系统中，如DSA签名算法、DH秘钥交换算法和ElGamal算法等，使用的是指数形式而不是乘法形式，即已知a和b，求解k以满足b = a^k mod p。椭圆曲线加密相比于RSA加密而言的优点之一是我们只需要更少位数的k就可以获得和RSA相同甚至更高的安全性。

ECC

ECC(Elliptic Curve Cryptography)即椭圆曲线加密算法。在上文中我们说了，在有限域中的椭圆曲线乘法(指数)是相对容易计算的，但是除法(对数)则很难计算，这也是椭圆曲线得以实现非对称加密的难题假设和理论基础。

椭圆曲线加密算法主要基于椭圆曲线在有限域中的循环子群，因此定义下面一些参数(domain parameters)：

p：定义了有限域大小的素数
a、b：定义椭圆曲线的特征参数
G：生成循环子群的基点
n：循环子群的阶(order)
h：循环子群的余因子(cofactor)

其中，组成ECC椭圆曲线加密算法的秘钥定义如下：

私钥：一个在*{1, …, n - 1}范围内的随机数d*
公钥：一个椭圆曲线上的点H = dG

就是这么的朴实无华。已知私钥d和G我们可以很容易通过乘法计算出公钥H，但是反过来从公钥计算私钥却要面临离散对数问题。虽然我们可以直接使用这个特性对信息(转换成数字)进行非对称加密，但实践上更多的是使用集成加密方案(IES, Integrated Encryption Scheme)，比如ECIES混合加密方法和EEECC (EC-based ElGamal)方法。

在openssl中使用也是通过ECC私钥生成对称加密的秘钥：

openssl ecparam -genkey -param_enc explicit -out priv.pem -name secp256k1
openssl pkeyutl -derive -inkey priv.pem -peerkey RecipientsPublicKey.pem -out SharedSecret.bin

详见Command Line Elliptic Curve Operations。

ECDH

DH即Diffie–Hellman，是两个提出者的名字，Whitfield Diffie和 Martin Hellman。ECDH则为DH的其中一个实现，而DH是一个秘钥协商协议。秘钥协商问题可以简化为：如何在通信链路不安全的安全下安全交换秘钥。DH的实现有很多，但本质上也是基于某种不可逆的拆分操作，WiKi中有个比较直观的例子介绍了交换秘钥的过程：

其中所基于的就是颜色混合容易但是分离难的假设，在这个假设前提下，双方可以获得共同的秘钥。注意双方的secret color是没有暴露在通信链路中的，因此即便被监听或者劫持也无法成功伪造对端进行中间人(MITM)攻击。

回到ECDH的实现上，这里的难题假设自然就是椭圆曲线的离散对数问题。假设通信双方还是Alice和Bob，则ECDH的工作流程为：

Alice和Bob使用同样的椭圆曲线，并分别随机生成它们自己的私钥和公钥，其中Alice的私钥为da，公钥为Ha = da * G，Bob的私钥和公钥分别为db和Hb；
Alice和Bob在不安全的信道中交换它们的公钥Ha和Hb；
Alice和Bob分别计算自己私钥和收到的对方公钥的乘积，有：

Sa = da * Hb = da * (db * G) = db * (da * G) = db * Ha = Sb

双方计算出了同样的乘积，即为安全的共享秘钥S，这个秘钥就可以用来作为对称加密的秘钥进行后续通信从而保证安全性。中间人通过偷听只能获得双方的公钥，如果它想要在没有私钥的情况下计算出该乘积，就相当于需要解决这么一个问题：给定椭圆曲线上三个点P、aP和bP，如何计算abP？这个问题在DH中也称为Diffie-Hellman problem，即构成安全秘钥交换基石的难题。

ECDSA

DSA(Digital Signature Algorithm)即数字签名算法。我们之前介绍RSA的时候说过RSA的签名方法，即对数据进行hash然后将其使用私钥加密，对端公钥解密并成功校验hash可认为数据没有被篡改。使用椭圆曲线实现的数字签名算法则称为ECDSA。

与RSA类似，ECDSA主要针对所校验数据的hash而不是数据本身。不同的是hash结果需要被截断，从而保证hash的位数与n(子群的阶)的位数相同，截断后的hash同样是一个整数，记为z。Alice使用私钥da对数据签名的流程如下：

从*{1,…,n-1}中随机选取一个整数k*
计算点P = kG
计算r = Px mod n (Px为点P的x坐标)
如果r=0，从新选一个k
计算s = k^-1 (z + r*da) mod n
如果s=0，从新选一个k

运算的结果*(r, s)则为签名。从计算过程中我们可以看到，s是与哈希z绑定的，而k可以理解为一个临时私钥，用来生成临时公钥r*。

Bob收到签名*(r, s)后，自己也计算一份数据的哈希z*，Ha是Alice的公钥，校验签名的过程如下：

计算整数u1 = s^-1 * z mod n
计算整数u1 = s^-1 * r mod n
计算点P = u1 * G + u2 * Ha
当r = Px mod n时，表示签名有效，数据未被篡改。Px为点P的x坐标

说实话我也不是很清楚为什么要搞这么绕，但ECDSA就是这么实现的。

安全性

和RSA一样，椭圆曲线加密的安全性根本在于其难题假设的“难度”，一旦这个前提被打破，椭圆曲线的安全性也会在根本上被动摇。打破难题假定的方法有很多，且不去谈量子计算这种未来的可能性，即便聚焦于当下也依然存在。

椭圆曲线的选择

我们说椭圆曲线在有限域上的的离散对数问题是个难题，这并不完全正确。前面看到了根据a、b不同，椭圆曲线可能有不同的形状，事实上存在一些类型椭圆曲线，它们的安全性是相当脆弱的。对于这些椭圆曲线，可以使用特殊的算法来高效的求解离散对数问题。

比如，对于所有p=hn的曲线(有限域的阶等于椭圆曲线的阶)，就受到一种特殊攻击的影响，攻击者可以用一个普通电脑在多项式时间内求解出离散对数问题。

如果我给你一组椭圆曲线参数(domain parameters)，并告诉你说”OMG! 用它”，这时有一种可能性，即我可能已经秘密地找到了一种方法可以快速地对这条曲线求解离散对数。为了解决这个问题，有时候我们额外引入一个参数，即随机数种子S，并用其生成椭圆曲线特征参数a、b或基点G：

S = random()
H = hash(S)
a = f(H)
b = g(H)
...

使用随机种子生成的椭圆曲线可被认为是验证随机的(verified random)，其中使用hash来生成的参数在密码学中也称为“我的袖子里可没藏东西”数(Nothing-up-my-sleeve number)。

一个生成和校验随机椭圆曲线的标准算法是ANSI X9.62，感兴趣的可以参考SECG标准中Verifiably Random Curves and Base Point Generators一节。

实践中不会每次生成新的椭圆曲线进行加密，因为我们实际上需要的是一个足够大的素数p以及子群阶n，并确保不含人为的预置。所以一般会根据标准如NIST、SECG中建议的方式去选择预置的曲线和随机数种子S，不同的椭圆曲线有不同的安全性、运算速度和不同的秘钥长度。

例如，比特币使用的椭圆曲线secp256k1的参数如下：

curve = EllipticCurve(
    'secp256k1',
    # Field characteristic.
    p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f,
    # Curve coefficients.
    a=0,
    b=7,
    # Base point.
    g=(0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,
       0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8),
    # Subgroup order.
    n=0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141,
    # Subgroup cofactor.
    h=1,
)

ECC秘钥的长度取决于所使用的椭圆曲线，在大多数系统中，如OpenSSL、OpenSSH和比特币中默认的ECC秘钥长度都是256位。在OpenSSL中预置的曲线可见：

https://github.com/openssl/openssl/blob/master/crypto/ec/ec_curve.c

ECDSA中的k

在生成ECDSA签名时，我们说到要从*{1, …, n}中随机选择一个整数k*。这个k需要秘密保存，一旦泄露就可能让攻击者找到签名方的私钥。秘密保存不只是不将k泄露给别人，也意味着生成k的随机数生成器不可预测，更进一步地，要求签名方不能使用同样的k来进行所有签名。

只不过使用了相同的k签名，会有什么问题呢？在这个场景中，我们假设攻击者有两份信息的签名*(r1, s1)和(r2,s2)，并且计算这两份信息的原始哈希z1和z2*，加上其他已知的椭圆曲线参数(公钥)，攻击方式如下：

注意到r1 = r2，因为r = Px mod n且P=kG，对两个信息是一样的
(s1 - s2) mod n = k^-1(z1 - z2) mod n
两边同时乘以k，则 k(s1 - s2) mod n = (z1 - z2) mod n
两遍同时除*(s1 - s2)，则k = (z1-z2)(s1-s2)^-1 mod n*

最后一个算式中我们可以直接通过两个文件的哈希和签名计算出k，得到k之后就可以计算出私钥d：

s = k^-1(z + r * d) mod n
d = r^-1(s*k - z) mod n

一个现实中的经典案例就是索尼。出于保护目的，PS3只能运行索尼自家ECDSA签名过的游戏，没有索尼签名的游戏或应用无法被PS3的系统加载。但问题是当年索尼的实现是用一个同样的k来对所有游戏进行签名的，最终被黑客发现导致了PS3的沦陷。直到现在我们都经常能看到索尼被人用下面这张XKCD的图片进行嘲讽：

EPIC

离散对数

除了文章中提到的安全陷阱或隐患，实际上也有其他问题会导致椭圆曲线离散对数的难题假设在一定程度上失效(或者变弱)。比如，有一种称为baby-step,gaint-step的算法可以将求解离散对数的算法和空间复杂度从暴力破解的O(p)降低为O(√n)，当所选的椭圆曲线子群阶n相对较小时，这种方式就能将离散对数的计算时间减少到可接受的水平，从而威胁加密的安全性。

同样类似的算法还有Pollard's rho算法，其进一步将求解离散对数的空间复杂度降到O(1)。对于一些破解椭圆曲线的比赛，如Certicom ecc challenge，通常就是使用该算法的变种求解的。目前的最新记录是2016年破解的117.35位通用椭圆曲线离散对数求解，使用FPGA实现并行Pollard’s rho算法，用到的算力为64至576个FPGA并行运行6个月时间。

除此之外，其他的攻击方式有：

Weil pairing / Tate pairing
Semaev-Smart-Satoh-Araki attack
Gaudry、Hess、Smart等提出的针对二进制域的度为小约数时的一种求解方法
…

NSA后门

在前一段时间介绍比特币的文章中，说到中本聪的一个特别之处就是他“避开了NSA的椭圆曲线后门”，当时听起来挺神奇的，但对于密码学家而言其实只是个正常的选择。

前面说椭圆曲线标准时提到了NIST，其全称为National Institute of Standards and Technology，即美国的国家标准技术研究所，负责制定一系列产业统一标准。NIST在2006年颁布了一个标准NIST SP 800-90A (SP表示特别发布)，其标题为 Recommendation for Random Number Generation Using Deterministic Random Bit Generators，这其实只是一个伪随机数生成器的定义标准，其中涉及了4个伪随机数生成器：

Hash_DRBG：基于hash函数
HMAC_DRBG：基于HMAC
CTR_DRBG：基于块加密
Dual_EC_DRBG：基于椭圆曲线加密

四个随机数生成器都是基于现有的密码学原语(cryptographic primitives)构建的。但是第4个比较特殊，用现在的俚语来说就是“画风和别人不太一样”，而且运行速度也较其他三个而言要慢几个数量级，之所以存在于NIST标准中的唯一原因是因为这是NSA建议的。

因此，早在该标准发表后不久，就有人提出了质疑。2006到2007年之间最早提出的主要观点是认为 Dual_EC_DRBG 这个随机数生成器的输出带有一定的偏好(bias)。

随后，在2007年8月的CRYPTO大会上，研究人员进一步提出了这个随机数生成器中的不合理之处。简单来说，就是Dual_EC_DRBG所使用的椭圆曲线是由一系列常数定义的，这些常数定义在NIST标准的附录中，但完全不知道是从何而来。研究人员提出这些常数和另外一个秘密的常数存在某种联系，如果知道了这个秘密常数，那么就可以通过获取Dual_EC_DRBG的32字节输出后预测该随机数生成器所生成的随机数。

然而研究人员并不知道这个秘密常数是什么，也许给出这组椭圆曲线参数的人会知道，也许没人知道。不过这种可能性的存在就足够让人警惕了。值得一提的是NIST在标准的附录中还指出可以通过其他随机数生成器来重新产生常数来替换默认的椭圆曲线参数，但这一步是可选的，实际上大部分Dual_EC_DRBG的实现都不会去额外做这个工作。

在比特币诞生之初，作为密码学专家的中本聪，自然也不会放过这个问题，所以避开这个后门也就理所当然了。

虽然Dual_EC_DRBG饱受质疑，但没有人能拿出实质性的证据，所以很多公司如RSA Security仍然使用Dual_EC_DRBG来实现一些加密项目，并表示问题不大。直到2013年，Edward Snowden跳了出来。在他披露的文件中显示，NSA曾给过1000万美金给RSA，条件是令其将NSA的随机数生成器设为默认。……所以一切就说得通了。

值得一提的是，除了在标准中留后门，NSA还灵活运用了其他方法，比如网络漏洞利用、网络劫持、和工业界进行py、和其他Agent(如英国的GCHQ)进行py等等……这一系列操作构成了网络行动——Operation Bullrun，感兴趣的可以去进一步了解。

2015年，NIST发布新版本的标准，默默地去掉了Dual_EC_DRBG。

参考文章

RSA安全与秘钥基础设施

Sat, 02 May 2020 22:40:00 +0800

之前写过一篇对称加密与攻击案例分析，而对于非对称加密，虽然接触的时间不短了，但一直没有很系统的记录过。因此趁着国庆家里蹲的五天长假，就来好好回顾总结一下。

前言

其实从加密的定语就能看出，对称加密表示通信双方是拥有同样信息的(即信息对称)。信息可以是预共享的秘钥(PSK)，也可以是事先约定的编解码方法(如凯撒密码)。非对称加密则将信息分为两部分，例如秘钥A和秘钥B，通过秘钥A加密的信息可以用秘钥B进行解密，反之通过秘钥B加密的信息也可以通过秘钥A进行解密。通常这对秘钥可以叫做公钥和私钥，公钥对外发布，私钥自己保留，从而在信息不对称的情况下实现加密和认证。

非对称加密的实现方法有很多，大都依赖于难题假设(hardness assumptions)。基于一个常量时间内被公认不可解的难题，将该问题的答案分为不同因子，组成对应非对称密码学算法的公钥和私钥。例如RSA基于大素数分解问题，(EC)DSA基于离散对数问题等。本文重点关注RSA非对称加密。

RSA原理

RSA应该是最早的公钥加密系统之一了，其名称是三个发明者的名字首字母缩写(Rivest–Shamir–Adleman)。其算法所基于的难题假设是质数分解问题，在此之前先简单介绍一下涉及到的数学基础。

欧拉函数：φ(n)，表示小于n的正整数中与n互质的数的数目。如果n能写做两个不同质数p和q的乘积，那么则有φ(n) = (p - 1)(q - 1)。证明：略。
同余：给定一个正整m，如果两个整数a和b满足*(a-b)被m整除，那么就称为a和b对模m同余，记作a≡b(mod m)*，其中≡是同余符号。同余的两个数有一些有趣的特性，比如反身性、对称性、传递性等等，详见《数论》。
模逆元：也叫模倒数(modular multiplicative inverse)。整数a的模逆元为整数x，则满足ax≡1(mod m)，其中m为模(modulus)。
欧拉公式：若a与n互为质数，则满足a^φ(n)≡1(mod n)，证明：参考拉格朗日定理。
lcm：least common multiple，最小公倍数。
gcd：greatest common devisor，最大公约数。
互质：co-prime，两个正整数a、b互质意味着能同时被它们整除的数只有1，即gcd(a, b) = 1

秘钥构成

有了上面的数学基础，再来看RSA公私钥的组成和生成过程。秘钥生成主要有以下几步，其实每一步在实践上都有注意事项，这个后面单独说。

找到两个不同的质数p和q
计算其乘积n=pq
计算φ(n)，由于p和q是质数，根据欧拉定理得φ(n) = lcm(p-1, q-1)
选择一个整数e，满足1 < e < φ(n)且gcd(e, φ(n)) = 1，即e和*φ(n)*互质
计算一个e的模逆元 d，对应模为φ(n)。计算过程涉及拓展欧几里得算法和贝祖恒等式，d就是其中一个贝祖系数(coefficient)

在上面的数字中挑选出构造非对称加密的元素：

公钥：(n, e)
私钥：(n, d)

e和d分别是公钥和私钥的核心，这两个数互为模逆元。要想通过公钥e推算出私钥d，就需要知道φ(n)；而计算φ(n)=(p-1)(q-1)则需要知道p和q；公私钥都已知n=pq，所以这就是难题假设的关键：当n很大的时候很难计算出对应的p和q。

加密与解密

假设我们有公钥*(n, e)，需要加密的内容为m*，m是个小于n的正整数。则密文c为：

m^e ≡ c (mod n)
c = m^e mod n

使用模指数运算，即便数字很大也可以很快算出。

对方拥有私钥*(n, d)，对密文c解密可获得明文m*，方法如下：

c^d ≡ (m^e)^d ≡ m (mod n)
m = c^d mod n

这里值得注意的是，由于明文m是通过模n获取的，所以要求m

举一个具体的例子，

p = 61, q = 53
n = 61 x 53 = 3233
φ(n) = lcm(p-1, q-1) = lcm(60, 52) = 780
e = 17
d = 413

公钥: (n = 3233, e = 17)
私钥: (n = 3233, d = 413)

加密和解密函数分别为：

enc(m) = m^e mod n
dec(c) = c^d mod n

假设加密的内容为1337，可以用python进行简单的验证：

enc(1337) = 1337**17 % 3233 = 1306
dec(1306) = 1306**413 % 3233 = 1337

感兴趣的可以自己尝试一下。

签名和校验

RSA算法除了可以用来进行加密，同样也能用来进行签名。签名的目的是确保发送的信息是由对应私钥的持有者发布的，而且信息没有遇到篡改。公钥签名则使用私钥校验，私钥签名则使用公钥校验，和加密方向类似。

签名所依赖的数学原理是指数的运算规则，对于整数h，有：

(h^e)^d = h^(e*d) = h^(d*e) = (h^d)^e ≡ h (mod n)

这里的h可以是我们所发送信息的哈希值，比如md5或者sha256。因此对于私钥的持有者而言，签名实际上就可以转换为用私钥对hash进行加密的过程。

消息的接收方收到信息以及加密的hash，使用发送者的公钥对签名进行解密，并计算消息的hash，将解密后的值与hash进行比对即可实现校验过程。

安全陷阱

回顾上面秘钥构成的一节，有几个地方说得其实有点含糊，比如选择p、q、e的地方，存在了一定的主观性。只要满足条件，就可以任意选择吗？事实上在有些场景下选择不当也会导致潜在的安全问题。

质数选择

我们知道在秘钥生成的第一步就是选择两个足够大的质数，这两个数都是需要秘密保存的，任何一个数泄露都会导致质数分解的难度假设无效。那么问题来了，多大的数才算够大？这两个数之间的关系会影响难题假设吗？

对于第一个问题，我们可以参考算力增长和近期的挑战情况判断。例如，一个称为YAFU工具可以在20分钟左右分解一个300位的质数，如下：

Bits	Time	Memory used
128	0.4886 seconds	0.1 MiB
192	3.9979 seconds	0.5 MiB
256	103.1746 seconds	3 MiB
300	1175.7826 seconds	10.9 MiB

截止至2019年，被分解的最大RSA数有795位，分解使用了900个CPU年的算力。

同时，对应权威机构的建议也是其中一个参考来源，例如NIST或者密码局。根据NIST的判断，非对称加密的秘钥强度和对称加密之间有近似的类比关系：

1024位的RSA秘钥强度相当于80位的对称加密秘钥
2048位的RSA秘钥强度相当于112位的对称加密秘钥
3072位的RSA秘钥强度相当于128位的对称加密秘钥

并且NIST建议目前的RSA秘钥安全强度是2048位，如果需要工作到2030年之后，就使用3072位的秘钥。

解决了秘钥长度的问题，我们再看p和q以及它们的关系。判断一个数是不是质数(素数)的方法称为素性测试。其中有一些算法可以提高测试速度，比如启发性测试和费马素性测试，后者通常用来在RSA秘钥生成中快速筛选数据。

在“A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”中提出，出于安全性考量，p和q应该随机选取，而且应该有相似的量级，但是在长度上又有若干位的不同，才能更难被计算机分解。这其实是从实践上考虑的，但也引出了一个问题：什么样的数好分解，什么样的数难分解？只可惜目前并没有明确的结论。也许在数学专家的钻研下，已经有了一种快速分解满足特定条件大数的方法，只不过出于“国家安全”并未公开，这大概也是我们推国密而舍RSA的原因之一吧。

私钥指数

私钥指数就是私钥中的d，在计算时我们提到这是模逆元算式的一个解。事实上该算式通常是多解的，那么在这种情况下如何选择呢？正确答案是随机选择一个解。曾经有过的情况是秘钥生成者为了解密时计算速度更快，选择一个比较小的d作为私钥指数。由于模指数运算的时间复杂度是log2(d)，在模为1024字节的情况下，一个较小的d甚至可以令运算速度提高10倍。

这样看似没怎么影响安全性，但实际上M. Wiener提出了一种攻击方法]令这种情况完全破坏了RSA加密的根基。Wiener定理如下：

因此，使用一个过小的私钥指数虽然提升了解密运算速度，但同时也提升了攻击者还原私钥d的计算效率。

详细的证明过程见: M. Wiener. Cryptanalysis of short RSA secret exponents. IEEE Transactions on Information Theory, 36:553-558, 1990

公钥指数

前面秘钥生成的过程中第四步我们说需要选择一个整数e，满足1 < e < φ(n)且gcd(e, φ(n)) = 1，即e和φ(n)互质。这个e是公钥的重要组成，因此称为公钥指数。

作为一个选择困难症患者，依旧是看到选择两个字就犯难。既然要求e和φ(n)互质即可，那么我随便选个满足要求的质数不就行了吗，比如e=3。估计抱有和我同样想法的人不在少数，但这样其实是有问题的，从结论上看会导致攻击者可以在特定情况下较为高效地还原私钥d，据不完全统计，涉及到的攻击场景有下面这些：

Hastad’s Broadcast Attack
Franklin-Reiter Related Message Attack
Coppersmith’s Short Pad Attack
Partial Key Exposure Attack
…

感兴趣的朋友可以查看文末的参考资料，这里就不展开了。值得一提的是这种情况的危害相对于前面选择过小的私钥指数情形而言相对较轻一些，即便选取了较小的公钥指数，距离成功的攻击也有不少的计算量。现实中私钥指数一般选择e = 2^16 + 1 = 65537就可以很好地防御攻击了，后面在拆解一些现实中的秘钥时也会看到。

Padding

我们前面所指的加密、解密和签名运算，明文和密文标的都是一个整数，该整数小于n。这种方式叫做plain RSA(Textbook RSA或裸加密)，在现实中很少直接使用。plain RSA实际上存在许多安全隐患，列举一些如下：

当使用较小的公钥指数e(比如3)加密较小的明文m(比如m)时，由于m^e严格小于模n，因此只要对密文进行e方根取整，就可以很容易解密获得明文。

如果同样的明文发送给e个以上的接收方，并且接收方的公钥指数e相同，p、q不同，那么通过中国剩余定理(孙子定理)，中间人就可以很容易解密出明文信息。可以参考前面提到的Coppersmith’s Attack。

《孙子算经》：有物不知其数，三三数之剩二，五五数之剩三，七七数之剩二。问物几何？

另外最最重要的一点，由于RSA加密本身没有随机数参与，因此是一种确定性加密算法，即同样的明文加密一定会出现同样的密文。从这点来看，裸RSA加密并不是语义安全的。

非语义安全的加密系统，很有可能会受到Chosen plaintext attack攻击的影响。举例来说，RSA的一个特性是两个密文的乘积等于对应明文的乘积：

m1^e * m2^e ≡ (m1m2)^e (mod n)

如果攻击者想要解密某个特定密文c ≡ m^e (mod n)，他可以让私钥持有方去解密一个构造的密文c′ ≡ cr^e (mod n)，r是攻击者选择的值。由于前面提到的乘积特性，实际上密文c’的明文值是mr (mod n)，因此如果解密成功，攻击者就可以计算出原本密文c的明文m。

除了上面介绍的这些，裸加密很存在许多其他隐患。为了缓解这些问题，真实的RSA实现中通常还会在明文加密之前进行一定的填充。填充要求能引入足够的随机性，但是也需要能够方便地对明文进行还原(unpading)。之前对称加密介绍的一种填充PKCS#5可以实现后者，但是没有随机性。

[PKCS#1][rfc]标准中最初就包含了精心设计的填充方法。虽然是精心设计，但在1998年Bleichenbacher在Crypto会议上对其展示了一种称为adaptive chosen ciphertext attack的攻击方法，两年后在Eurocrypt 大会上也有人提出一些潜在的不安全性。这期间PKCS#1标准也一直进行修订，比如引入OAEP填充方式等。

如果使用过高级语言中封装的RSA加密库，应该也会发现其提供的接口都是可以指定Padding的，比如Python的例子：

from Crypto.PublicKey import RSA from Crypto.Cipher import PKCS1_OAEP from Crypto.Hash import SHA256 def encrypt(key, plainText) pubkey = RSA.importKey(key) cipher = PKCS1_OAEP.new(pubkey, hashAlgo=SHA256) encrypted = cipher.encrypt(plaintext) return base64.b64encode(encrypted)

Java的例子：

String decrypt(String privateKeyStr, cipherText) { byte[] cipherTextBytes = DatatypeConverter.parseBase64Binary(cipherText); byte[] privateKeyBytes = DatatypeConverter.parseBase64Binary(privateKeyStr); KeyFactory kf = KeyFactory.getInstance("RSA"); PKCS8EncodedKeySpec ks = new PKCS8EncodedKeySpec(privateKeyBytes); PrivateKey privateKey = kf.generatePrivate(ks); Cipher c = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); c.init(Cipher.DECRYPT_MODE, privateKey, new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT)); byte[] plainTextBytes = c.doFinal(cipherTextBytes); String plainText = new String(plainTextBytes); return plainText; }

基础设施
介绍完了理论，想必很多人也觉得枯燥无味了。诚然，理论与实践结合才是密码学大放异彩的地方，我们日常生活中每天上网用到的https，手机系统用到的应用签名、Secure Boot，各种认证和校验，无不涉及到非对称加密。实践依赖于背后的数学根基，但同时也在易用性和标准化上做了很多工作，在此基础上构建了广泛应用的秘钥基础设施。值得一提的是，这里的基础设施并不是狭义的PKI，而是涉及到的标准和实践，下面会挑一些来进行介绍。

ASN.1
为了解决高级语言中结构化数据在磁盘、网络中传输后能够进行还原，我们早先有JSON、XML等表示，现在有protobuf、thrift等序列化方法。不过在更早之前就有了跨平台的抽象语法标准ASN.1(Abstract Syntax Notation One)，ASN.1定义在X.208中，提供了标准的IDL接口描述语言，可以用来表示一系列类型和值。

在ASN.1中，类型就是一组值。有些类型包含了有限的值，但是有些类型也可以包含无限的值。ASN.1包含四种类型：

简单类型，即没有组合的”原子“类型

结构类型，类型的组合

标记类型，从其他类型衍生的类型

其他类型，例如CHOICE和ANY类型

类型和名称都可以通过赋值符号::=进行命名。除了CHIOCE和ANY的每个ASN.1类型都包含一个标记(tag)，tag可以理解成唯一的标识符，当且仅当tag相等时对应类型才相等。tag也有4个种类：

通用标记(Universal)

应用标记(Application)

私有标记(Private)

上下文标记(Context-Specific)

通用标记是定义在X.208中的，具有全局唯一性，其他标记在不同应用中可能会有不同的含义。拥有通用标记的类型大部分是简单类型，如BIT STRGING、INTEGER、IA5String、OBJECT IDENTIFIER等，也有结构类型如SEQUENCE、SET等。一个简单的ASN.1文件如下：

Person ::= SEQUENCE { age INTEGER, name OCTETSTRING, birth Date, -- 注释：这里的组合类型在下面定义 } Date ::= SEQUENCE { year INTEGER, month INTEGER, day INTEGER }

ASN.1仅仅是一个抽象的表示方法，编码方式则定义在X.209中。常见的编码实现有：

BER：Basic Encoding Rules

DER：Distinguished Encoding Rules

XER：XML Encoding Rules

JER：JSON Encoding Rules

…

编码实现多种多样，和RSA相关的主要是DER编码。DER是BER的一个子集，编码方式为TLV(Type-Length-Value)结构，具体定义在X.509标准中。

X.509
在密码学中，X.509定义了公钥证书的标准(RFC5280)，其最常见的应用场景之一就是HTTPS中的TLS/SSL认证中。公钥证书中包括公钥和身份信息(如域名、组织或个人)，并且是经过签名的。权威认证的签名机构CA(certificate authority )公钥证书预置在我们的浏览器或者操作系统中，因此可以认证签名的有效性。

X.509同样使用ASN.1来描述，但经历了多个版本的变化，例如：

https://tools.ietf.org/html/rfc2459#appendix-A

https://tools.ietf.org/html/rfc3280#appendix-A

https://tools.ietf.org/html/rfc5280#appendix-A

事实上X.509是由国际电信联盟(ITU)管理的，权威版本可以在ITU的网站上看到，同时ITU也提供了X.509以及对应拓展包的ASN.1压缩包下载。

X509中定义了许多字段，列举一些常见的解释一下：

Serial Number：CA所签名的证书都都包含的一个针对该CA的序列号

Subject：主题名称，CA所签名的目标对象标识符，通常使用X.500或者LDAP格式来描述

Issuer：签发者名称，CA本身的标识符。对于自签名的证书而言，Issuer和Subject是相同的，例如根证书

Subject Public Key Info：Subject的公钥信息，包括公钥算法和对应的公钥，例如RSA公钥则包括之前介绍过的模n和公钥指数e的值

Signature：Issuer对Subject公钥证书的签名

Validity period：Issuer对Subject公钥证书签名的有效时间

以B站的的HTTPS证书为例，我们也可以使用openssl查看公钥详细信息：

$ openssl s_client -connect bilibili.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text -nameopt multiline,-esc_msb,utf8 Certificate: Data: Version: 3 (0x2) Serial Number: 27:6d:f4:81:02:c7:45:53:a7:ee:12:58 Signature Algorithm: sha256WithRSAEncryption Issuer: countryName = BE organizationName = GlobalSign nv-sa commonName = GlobalSign Organization Validation CA - SHA256 - G2 Validity Not Before: Sep 18 09:32:07 2018 GMT Not After : Sep 18 09:21:04 2020 GMT Subject: countryName = CN stateOrProvinceName = 上海 localityName = 上海 organizationName = 上海幻电信息科技有限公司 commonName = *.bilibili.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:ce:77:ab:d9:e2:99:25:28:c1:4c:8e:15:ac: 22:5a:8a:31:80:0f:20:3b:1d:a9:a6:d2:76:71:25: a0:8b:08:41:31:7a:7f:b9:d3:12:f4:c0:d6:d5:03: bf:7b:e7:56:f2:f0:5b:c4:69:ca:6f:aa:d5:eb:86: a7:06:2f:67:2b:93:d2:70:33:45:40:f7:18:48:68: d4:4f:65:5c:91:7c:aa:64:d4:e2:37:7b:7e:66:83: fe:b3:be:69:20:9b:20:5d:dd:1a:02:0d:53:e8:2a: 91:7a:84:c5:12:66:bb:51:6c:c0:40:4a:9d:b5:19: 39:35:3a:1d:80:55:7f:b0:85:61:8e:a5:87:24:7c: 32:59:35:0d:2c:2e:80:6d:f1:a4:96:1d:12:aa:c9: a6:88:90:15:18:b3:c6:93:8e:49:36:53:20:d7:23: 6c:5c:40:4e:23:87:8b:9f:6b:41:d2:52:ac:18:65: d8:6f:d9:a0:43:e6:e9:45:a2:81:e2:7e:f5:8b:0d: 91:d2:c0:93:9b:8c:65:18:93:c1:de:1f:f2:82:0c: 43:54:17:e9:79:7d:3d:d3:6b:bf:2b:d2:02:8a:93: 7c:13:8f:1f:4f:62:81:58:54:81:4f:70:83:57:b0: 47:62:1b:81:00:76:3c:46:6d:e7:07:1d:aa:35:5a: c8:f9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment Authority Information Access: CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 Subject Alternative Name: DNS:*.bilibili.com, DNS:bilibili.com X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 0D:DB:87:B5:F7:C5:57:18:2B:1F:71:56:19:64:1A:DE:C3:C9:12:06 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C 1.3.6.1.4.1.11129.2.4.2: ...i.g.u..u..Y|..C._..n.V.GV6.J.`....^......e.........F0D. ^.R..~AV|..A.....@..c.......u ... A$MqBP..iY1Jl]c......}..o.p.(.t..v.......X......gp .....e.........G0E. s.2...-.*+..!......+Ui..2....j;..!..v..v$-m.R..Z#J. TB....3...7x..Y.v.oSv.1.1.....Q..w.......).....7.....e.........G0E.!....v]W....'.\G.]....B..Hn.c....u. ..Cb.....l0L.-.......O....7..... Signature Algorithm: sha256WithRSAEncryption 35:13:01:e0:20:2c:84:ce:76:c9:91:9f:8e:74:f1:5e:49:0d: b9:2d:25:96:ae:e6:87:02:52:ce:0e:d7:64:71:81:8f:30:90: 85:24:e1:2c:17:9c:78:31:97:c7:e8:c2:b2:3d:fd:b7:b1:41: 25:94:1b:45:79:d4:33:8c:c0:1b:0c:0d:85:3b:8d:41:eb:0c: 34:51:54:26:80:e6:a0:d4:ac:75:b3:c9:e9:16:8b:ae:9d:bd: 2f:9a:2c:a2:29:49:20:aa:53:88:c7:70:64:ea:d6:67:a3:e7: c4:48:f1:16:64:a5:7a:6b:93:b0:af:00:ee:1c:5f:8d:d2:07: b7:ec:b7:da:1a:d8:e2:07:01:37:e0:78:6a:1c:d7:0d:9b:91: f0:7c:36:c6:8e:f2:59:d0:0a:f0:54:a8:db:a3:f5:c3:1a:24: 03:38:86:b0:37:da:89:c1:70:35:c0:1e:02:a2:65:2a:95:68: b1:0e:40:56:0c:82:00:5d:8a:9f:f1:50:d9:ed:4b:43:d9:59: c8:70:75:ab:85:37:13:89:09:07:08:81:ca:b2:0a:bd:b9:57: 52:d0:8d:4e:9c:64:06:4a:87:e3:71:3d:b5:47:91:a1:2d:0f: 75:46:55:81:ea:a1:31:64:ce:27:c5:59:2e:bf:b5:2c:82:07: a2:32:b9:91

可以看到实际中的公钥指数e为65537，这里的Modulus即为n，使用冒号分隔十六进制的方式表示，转换为整数是0x00dace77d9e2...，另外如名字所言，X509第三版(v3)包含了可选的拓展选项，对于HTTPS而言最重要的是Subject Alternative Name，即所认证的域名。其他拓展选项详细说明可以参考RFC5280的介绍。

秘钥分析
最后再来分析几个实际落到我们磁盘上的秘钥结构。

ssh
对于开发者而言ssh都不会陌生，其除了可以使用密码登录远程服务器，也可以通过私钥登录。使用ssh-keygen工具可以直接生成私钥id_rsa和公钥id_rsa.pub，格式为RSA-2048。先看公钥：

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDEkBTUATNtj5xzF8S+CXzh+8A3LzTXeHyIZams0g37hAFi1SmYK82QAANxUzypUSZSHTY+WnMjOmNEpqgEmE5MWg3tYp4hK7tSyI2/UYUQu8y9KUPa7dnwYA+gkPWxM4sEu3u3bh6dP6bf/t8u6I1fca4tmiEcIqlq3DRz9YQXwIHr27ld5gHFiyEO6vi1ECtddnz6DKuzpQ6Dj1QNVmCF6N81DXfpmTRmVIZV+vZbfD35f1/iw116jQ5lW5VVF00fz7NqYgdK3KH9TiSexJduXjMczyamrTjotNpWZo98JcltkxJF1vYRPIDgX7rTbOzIV/DiCzgROU3JmacI9lmf evilpan

其中重要的中间的base64，解码后hexdump出来如下：

00000000: 0000 0007 7373 682d 7273 6100 0000 0301 ....ssh-rsa..... 00000010: 0001 0000 0101 00c4 9014 d401 336d 8f9c ............3m.. 00000020: 7317 c4be 097c e1fb c037 2f34 d778 7c88 s....|...7/4.x|. 00000030: 65a9 acd2 0dfb 8401 62d5 2998 2bcd 9000 e.......b.).+... 00000040: 0371 533c a951 2652 1d36 3e5a 7323 3a63 .qS<.Q&R.6>Zs#:c 00000050: 44a6 a804 984e 4c5a 0ded 629e 212b bb52 D....NLZ..b.!+.R 00000060: c88d bf51 8510 bbcc bd29 43da edd9 f060 ...Q.....)C....` 00000070: 0fa0 90f5 b133 8b04 bb7b b76e 1e9d 3fa6 .....3...{.n..?. 00000080: dffe df2e e88d 5f71 ae2d 9a21 1c22 a96a ......_q.-.!.".j 00000090: dc34 73f5 8417 c081 ebdb b95d e601 c58b .4s........].... 000000a0: 210e eaf8 b510 2b5d 767c fa0c abb3 a50e !.....+]v|...... 000000b0: 838f 540d 5660 85e8 df35 0d77 e999 3466 ..T.V`...5.w..4f 000000c0: 5486 55fa f65b 7c3d f97f 5fe2 c35d 7a8d T.U..[|=.._..]z. 000000d0: 0e65 5b95 5517 4d1f cfb3 6a62 074a dca1 .e[.U.M...jb.J.. 000000e0: fd4e 249e c497 6e5e 331c cf26 a6ad 38e8 .N$...n^3..&..8. 000000f0: b4da 5666 8f7c 25c9 6d93 1245 d6f6 113c ..Vf.|%.m..E...< 00000100: 80e0 5fba d36c ecc8 57f0 e20b 3811 394d .._..l..W...8.9M 00000110: c999 a708 f659 9f .....Y.

这些数据怎么解析呢？查阅RFC4253我们可以发现ssh公钥的定义如下：

The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n

而在RFC4251中包含了string和mprint类型的定义：

string [...] They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used. [...] mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. [...]

说白了三个字段都是Length-Value格式，转换如下：

(4 bytes) 00 00 00 07 = 7 (7 bytes) 73 73 68 2d 72 73 61 = "ssh-rsa" 字符串 (4 bytes) 00 00 00 03 = 3 (3 bytes) 01 00 01 = 65537 (公钥指数e) (4 bytes) 00 00 01 01 = 257 (257 bytes) 00 c4 .. f6 59 9f = 模n

再看私钥：

-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn NhAAAAAwEAAQAAAQEAxJAU1AEzbY+ccxfEvgl84fvANy8013h8iGWprNIN+4QBYtUpmCvN kAADcVM8qVEmUh02PlpzIzpjRKaoBJhOTFoN7WKeISu7UsiNv1GFELvMvSlD2u3Z8GAPoJ ... -----END OPENSSH PRIVATE KEY-----

注意这里和网上很多文章说的不太一样了，因为之前ssh-keygen生成的直接是RSA私钥，比如：

-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUp wmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ5 1s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQABAoGAFijko56+qGyN8M0RVyaRAXz++xTqHBLh ... -----END RSA PRIVATE KEY-----

前者是PKCS#1定义的DER编码私钥，在下一节中详细介绍。以前openssh默认是支持PKCS#1的，不过现在使用了自己的一套格式，大致布局如下：

"openssh-key-v1"0x00 # NULL-terminated "Auth Magic" string 32-bit length, "none" # ciphername length and string 32-bit length, "none" # kdfname length and string 32-bit length, nil # kdf (0 length, no kdf) 32-bit 0x01 # number of keys, hard-coded to 1 (no length) 32-bit length, sshpub # public key in ssh format 32-bit length, keytype 32-bit length, pub0 32-bit length, pub1 32-bit length for rnd+prv+comment+pad 64-bit dummy checksum? # a random 32-bit int, repeated 32-bit length, keytype # the private key (including public) 32-bit length, pub0 # Public Key parts 32-bit length, pub1 32-bit length, prv0 # Private Key parts ... # (number varies by type) 32-bit length, comment # comment string padding bytes 0x010203 # pad to blocksize (see notes below)

详细关于OpenSSH新的私钥格式详情可以参考：

The OpenSSH Private Key Format

https://github.com/openssh/openssh-portable/blob/master/sshkey.c

AVB
AVB即Android Verified Boot，是安卓中对系统镜像完整性保护的方案。最近在工作中有对其进行了一点研究，不过这里并不是深入介绍AVB，而只看其中涉及到RSA的秘钥。

在我们自行编译安卓源码(AOSP)时，会发现一系列秘钥：

$ ls build/target/product/security/ Android.mk media.x509.pem shared.pk8 testkey.x509.pem verity_key README platform.pk8 shared.x509.pem verity.pk8 media.pk8 platform.x509.pem testkey.pk8 verity.x509.pem

每组秘钥分别负责用来对不同的组件进行签名，我们主要看Verified Boot相关的秘钥verity，安卓中使用该秘钥对boot.img进行签名，并自定义了签名的ASN.1格式：

AndroidVerifiedBootSignature DEFINITIONS ::= BEGIN formatVersion ::= INTEGER certificate ::= Certificate algorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } authenticatedAttributes ::= SEQUENCE { target CHARACTER STRING, length INTEGER } signature ::= OCTET STRING END

其中证书Certificate类型是在X.509中定义的。

私钥的存储格式有几种常见类型，比如PKCS#1(RFC3447)和PKCS#8(RFC5208)。

例如PKCS#1中定义私钥的ASN.1表示如下：

Version ::= INTEGER { two-prime(0), multi(1) } (CONSTRAINED BY {-- version must be multi if otherPrimeInfos present --}) RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

一般而言，我们保存的私钥都是der格式，即使用DER对相应的ASN.1定义进行编码。许多高级语言中提供了对应的库函数方便从DER中进行反序列化获取原始数据，比如Python的from Crypto.Util.asn1 import DerSequence。同时也有些在线工具可以方便查看DER的反序列化内容，比如：

https://lapo.it/asn1js

https://asn1.io/asn1playground/

回到上面的verity私钥，我们将其转换为PKCS#1格式：

openssl pkcs8 -nocrypt -in build/target/product/security/verity.pk8 -inform DER

解析对应的字段并将其与上面的ASN.1对比。

SEQUENCE (3 elem) INTEGER 0 SEQUENCE (2 elem) OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1) NULL OCTET STRING (1 elem) SEQUENCE (9 elem) INTEGER 0 INTEGER (2048 bit) 294034013011457495254632688690709311939827882765990777183788030470572… INTEGER 65537 INTEGER (2047 bit) 152690229409630177395988743674731983661872870808474054654559379297267… INTEGER (1024 bit) 172086361699816285157285992007634379277365906572602995588734914497382… INTEGER (1024 bit) 170864216145358483792372871509731496788274625374475577044849125456480… INTEGER (1024 bit) 121316723122128141459586606081095008794617691006109580880887598144682… INTEGER (1024 bit) 160008079977555979458768333051051332108378146438007378884805916911676… INTEGER (1024 bit) 111229147058742660120109027367598084873926761525467238165320120548663…

可以对应RSA秘钥的各个元素：

n = 2940340130…

e = 65537

d = 1526902294…

…

后记
本文主要介绍了RSA的基本原理以及常见的安全陷阱，其中大部分的实现隐患出在定义中关于选择的地方，比如对于质数p、q以及公钥指数e的选择，在某些情况下选择不当会导致在数学上求解难度骤减；RSA裸加密本身并非语义安全，容易受到CPA攻击。对于现代机器学习而言，通过学习语义从端到端还原明文也不是不可能的事。

除此之外，RSA还存在时序攻击、随机数以及侧信道等潜在威胁没有在文中介绍。即便小心翼翼地按照最佳实践去实现了RSA，也依然有不确定性：大质数分解真的很难吗？这个问题目前并没有确切证伪，只有经验性的结论。有人说RSA-2048坚不可摧，对于这点我还是持怀疑态度，不说NSA已经“破解”了RSA，至少对于满足某些条件的质数，可能存在特别的分解方式，毕竟历史上密码学的后门总是留得猝不及防。

虽然存在不确定性，RSA也已经是当今最为广泛使用的秘钥基础设施根基，所以文章也对常见的实现标准和一些常见秘钥进行了介绍和分析，一方面是对自己学习研究的记录，另一方面也希望能对感兴趣的朋友提供点参考。如果你也对密码学感兴趣，欢迎加群一起交流学习！

参考资料

WikiPedia - RSA cryptosystem

A Method for Obtaining Digital Signatures and Public-Key Cryptosystems

Twenty Years of Attacks on the RSA Cryptosystem

M. Wiener. Cryptanalysis of short RSA secret exponents. IEEE Transactions on Information Theory, 36:553-558, 1990

A Layman’s Guide to a Subset of ASN.1, BER, and DER

WiFi安全与攻击案例分析

Sun, 29 Mar 2020 22:40:00 +0800

本文主要分享WiFi相关的一些安全研究，以及分析几个实际的攻击案例，如PMKID、KARMA、Krack等。

WiFi起源
WiFi是一种无线局域网协议(WLAN)，经过多年的发展，WLAN基本上也等同于WiFi。史前时代的LAN可以追溯到1971年ALOHAnet提出的多址接入思想。

但我们不看那么远，直接跳到1985年，当时FCC(US Federal Communications Commission, 美国联邦通信委员会)首次开放2.4GHz等频段，允许节点在这些频段以扩频技术通信，为后续无线局域网的发展立下基础。

扩频(Spread Spectrum)通信的方法有很多，常见的是蓝牙用的跳频(Frequency Hopping)和WiFi用的直序扩频(Direct Sequence)

随后在1989年，第一个无线局域网产品WaveLAN出现；次年，IEEE 802.11委员会被正式成立，开始构建一个无线局域网的专用协议。期间WaveLAN经过了许多部署尝试，在产业界沉淀了实践基础。

WiFi，正确写法应该是Wi-Fi(Wireless-Fidelity)，即无线-高保真。无线都能理解，高保真则是要求在无线网络中可靠地传输数据。WiFi最初是一个独立的完整协议，其主要内容在后来被IEEE 802.11委员会接受并成了802.11a的标准。

1999年，Wi-Fi联盟成立，这多个厂商发起的非盈利联盟，致力于解决工业界的兼容性和统一问题，填补学术界和工业界之间的实现差异。

还是1999年，IEEE颁布了802.11b协议，这是WiFi协议的里程碑，早期笔记本电脑和PS游戏机中的无线功能都是基于802.11b的。同年，苹果也推出了基于WiFi原理的Airport技术。

一年后的2000年，802.11a才正式通过。但是因为当时5GHz开放的信道有限，802.11a并没有推广开来。

2003年，颁布802.11g协议标准，修改802.11a的不足，在2.4GHz频段上使用OFDM技术。

2004年，802.11i颁布，关键词是WiFi安全性。

2009年，802.11n，关键词是MIMO(多输入多输出)。

2014年，802.11ac，关键词是下行MU-MIMO。

…

2019年，802.11ax，WiFi6，关键词是双向MU-MIMO。

当然，这只是其中几个关键的标准。我们可以在802.11_Timelines中看到所有802.11颁布的协议和时间线。按照演进的方向，也可以概要为下图：

WPA/WPA2/WPA3
WiFi虽然广为人知，但是其物理层和链路层的实现也是相当复杂，念完研究生的无线网络课程也不敢说自己精通WiFi。因此，我们主要聚焦在协议安全性以及实现的安全性上。

WPA(Wi-Fi Protected Access)，即无线保护访问，是WiFi联盟为应对WEP(Wired Equivalent Privacy)中存在的各种安全问题而推出的解决方案。其中WPA最初只是作为草稿发布，并为后续更完善的WPA2铺路，二者都定义在802.11i(IEEE 802.11i-2004)的标准中。

我们目前广泛使用的WiFi安全保护访问就是WPA2的标准。在2018年1月，WiFi联盟又推出WPA3，在WPA2的基础上做了一些安全增强。

WPA是标准，而我们常见的WPA-PSK TKIP/AES-CCMP则是具体的加密模式和加密方法。

拓展阅读： what-is-the-difference-between-tkip-and-ccmp

4-Way Handshake
说到WiFi安全，就不能不说校验过程中涉及到的四路握手。四路握手的目的是为了安全地验证和交换秘钥，验证对端合法性，防止中间人攻击。

四路握手中涉及到的一些名词如下：

authenticator：即AP(Access Point)，可以理解成路由器

supplicant：即想要接入AP的Client，简写为STA(Station)

MSK (Master Session Key)

PMK (Pairwise Master Key)

GMK (Group Master Key)

PTK (Pairwise Transit Key)

GTK (Group Temporal Key)

ANonce：Authenticator Nonce

SNonce：Supplicant Nonce

MIC：Message Integrity Check

是否有很多问号？不要紧，待会回头再看就很清晰了。先放一张四路握手的大图，记得时不时拉回来看看：）

接下来就围绕着上图的握手流程进行分析。

802.11帧
既然我们不关注物理层，那么就可以从接受并解码后的数字信号说起。首先打开我们的WireShark抓一会儿包(monitor mode)，挑选其中任意一个无线数据包查看，可以看到最顶层的包头是IEEE 802.11 XXX frame，所以我们就从这个包说起。

实际上面还有一层radiotap，是抓包工具加的，提供额外信息，比如时间，信道等，这些内容不是标准中的一部分，详情可见：http://wifinigel.blogspot.com/2013/11/what-are-radiotap-headers.html

一个802.11帧就是这么朴实无华，且枯燥。但是后面的介绍会用到里面的一些字段，所以就先放出来。注意前两字节是帧控制(Frame Control)头，每个bit有不同的意思，具体可以看虚线下的展开。

接下来我们通过实际抓包来看WiFi连接认证的完整过程。测试使用我们自己搭建的WiFi，AP的SSID为evilpan，BSSID为66x6，WPA2密码为12345678，所连接的客户端为苹果手机。

Auth & Associate
一般情况下，AP会一直向周围广播宣告自己的存在，这样STA才知道周围有哪些热点，并选其中的一个进行连接。广播的数据称为Beacon Frame其中包括了热点的BSSID(即MAC地址)和ESSID(即热点名)。

Beacon Frame并不是必须的，路由器可以配置不广播，STA依然可以通过指定SSID和密码进行连接，即所谓的隐藏热点。

在WiFi握手前还可以看到两大类型的帧，Authentication和Association，分别是认证和连接。注意这里的认证和安全性无关，只是认证双方是和符合标准的802.11设备。而连接后则在链路层接入网络，如果是Open WiFi，此时已经接入LAN，如果需要WPA认证，即我们所讨论的情况，则正式开始四路握手。

回顾上面的四路握手大图。注意在握手开始之前，双方手上都有一个PMK，即配对主秘钥。这个秘钥是从哪来的呢？在IEEE 802.11i-2004标准中有定义，如果使用PSK(Pre-Shared Key)认证，那么PMK实际上就是PSK。而PSK则是通过WiFi密码计算出来的：

PMK = PSK = key_derivation_func(wifi_passwd)

key_derivation_func是一个秘钥推导函数(PBKDF1/2)，内部以SHA-1为哈希函数。

还注意到，AP端不止有PMK，还有一个GMK。这是AP自己生成的，GMK用来为每个连接的STA生成GTK，并分享给STA。为了避免GMK被STA猜解，有的AP可以设置定时更换GMK，如思科的设备中broadcast key rotation选项。

拓展阅读：Real 802.11 Security: Wi-Fi Protected Access and 802.11i

WPA中四路握手的协议也称为EAPOL(Extensible authentication protocol over LAN)，可以直接在wireshark等工具中使用eapol过滤出来。

握手1/4
握手第一阶段，AP向客户端发送随机数ANonce。

此时，客户端中有PMK、ANonce、SNonce(客户端自行生成的随机数)，以及双方的MAC地址信息。通过这些信息，计算PTK：

PTK = func(PMK + Anonce + SNonce + Mac (AA)+ Mac (SA))

func是个伪函数，表示经过某种运算。函数的实现细节不展开，下面都使用func作为伪函数名。

PTK是Pairwise Transit Key，根据参与运算的参数可见，该秘钥在每个客户端每次握手中都是不同的。PTK也可以理解为一个临时秘钥，用来加密客户端和AP之间的流量。

握手2/4
客户端生成PTK后，带着自己生成的SNonce发送给AP，目的是为了让AP使用同样的方法计算出PTK，从而确保双方在后续加密中使用正确的秘钥。

在这次发送的数据中，还包含MIC(Message Integrity Check)字段，AP用以校验该条信息的完整性，确保没有被篡改。

握手3/4
客户端收到第二阶段发送的SNonce之后，就可以算出PTK，并用PTK加密GTK后，发送给客户端，同样带有MIC校验。

发送的GTK是最初从GMK生成而来的，主要用来加密组播和广播数据(实现上切分为GEK/GIK，在CCMP和TKIP作为不同字段使用)。

握手4/4
此时双方都有了后续加密通信所需要的PTK和GTK，第四次握手仅仅是STA告诉AP秘钥已经收到，并无额外数据：

小结
根据秘钥的唯一性，可以分为两种：

Parwise Key：一机一密，每个客户端保存一个，AP端保存多个，用来加密单播数据

Group Key：一组一密，所有客户端和AP都保存一个，用来加密组播或广播数据

根据秘钥的类型，也可以分为两类：

Master Key：主秘钥，预先安装或者很久才更新一次

Temporal Key：临时秘钥，每次通过主秘钥去生成

这样，理解前面的各种Key也就更加直观了。注意由于Group Key是所有客户端共享的，所以当某个客户端离开AP之后，AP会重新生成Group Key，并通知其他终端进行更新；此外，前面也说了，某些AP也可以配置定期更新Group Key。

握手也可以简化描述为以下四步：

AP发送ANonce给STA

STA使用ANonce计算获得单播秘钥，发送SNonce给AP

AP使用SNonce计算获得单播秘钥，并将加密的组播秘钥发送给STA

完成握手，双方都有PTK和GTK，加密后续对应报文

攻击案例
对四路握手有个基本了解之后，再来看看一些经常听说的WiFi安全问题是如何造成的。对于一些年代久远的案例，比如WEP、WPS攻击就不再介绍，因为它们已经退出历史舞台了。

暴力破解
既然WiFi密码是PSK，使用预置共享的秘钥，那么就不可避免面临暴力破解的问题。当然这里说的暴力破解不是输密码连WiFi，提示密码错误了再不断尝试，那样效率太低了。

实际中的暴力破解要高效得多。暴力破解的本质是获取PSK即PMK的明文，根据上面介绍握手的流程，作为一个未验证终端，我们实际能获取到的是ANonce、SNonce、Mac地址以及加密的内容和MIC，通过不断变换PSK/PMK计算PTK并验证MIC从而寻找真实密码。

比如我曾经最喜欢玩的aircrack-ng，其内部实现就是：

EXPORT int ac_crypto_engine_wpa_crack( ac_crypto_engine_t * engine, const wpapsk_password key[MAX_KEYS_PER_CRYPT_SUPPORTED], const uint8_t eapol[256], const uint32_t eapol_size, uint8_t mic[MAX_KEYS_PER_CRYPT_SUPPORTED][20], const uint8_t keyver, const uint8_t cmpmic[20], const int nparallel, const int threadid) { ac_crypto_engine_calc_pmk(engine, key, nparallel, threadid); for (int j = 0; j < nparallel; ++j) { /* compute the pairwise transient key and the frame MIC */ ac_crypto_engine_calc_ptk(engine, keyver, j, threadid); ac_crypto_engine_calc_mic( engine, eapol, eapol_size, mic, keyver, j, threadid); /* did we successfully crack it? */ if (memcmp(mic[j], cmpmic, 16) == 0) //-V512 { return j; } } return -1; }

在CPU/GPU足够给力的情况下，上百GB的字典可以在十几分钟跑完。当然跑字典也有一些循序渐进的策略，比如：

当地的手机号

所有8-10位数字组合

Top xxx 密码字典

上述字典+变异

字典组合+变异

……

当然说这个不是教大家去暴力破解，而是根据上述策略去选取一个强度合适的WPA密码，保护自己的隐私安全。

RSN PMKID
上面最常见的暴力破解需要获取4路握手包，也就是说有个前提是需要有客户端去连接。通过一些手段，比如伪造Deauth可以让目标强制掉线重连从而获取握手包，但不管怎样都需要有客户端在线才行。

PMKID攻击是hashcat的作者在2018年提出的，他发现在一些AP的第一次握手数据包中，包含了额外的EAPOL字段RSN(Robust Security Network)，其中包含PMKID：

这个PMKID的计算方法是：

PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

因此，如果返回包含RSN PMKID，那么就可以在无需客户端在线的情况下发起本地的暴力破解。事实上，非常多路由器在第一次握手的EAPOL包中都会包含这个字段。

KARMA & MANA
还记得前面介绍的Beacon Frame吗？有的AP会定期像周围广播自己的存在，从而让客户端知道周围有哪些热点。但这只是其中一个方法，称为被动扫描；客户端还可以主动发送Probe Request探测周围的WiFi，如果有WiFi响应则返回Probe Response，返回对应的AP属性，从而让客户端发起连接，这称为主动扫描，主动探测又分为直接探测(Direct Probe)和广播探测(Broadcast Probe)。

KARMA攻击的本质就是，监听客户端发送的Directed Probe Request，然后伪造对应的热点信息，让客户端认为这是个之前连接过的热点，从而进行接入。

802.11协议中规定AP只能响应发给自己的Probe Request，但KARMA并不准守这个规定，如果STA准守802.11，那么就会认为这是个合法的响应从而进行连接。

最初版本的KARMA攻击在2004年提出(KARMA Attacks Radioed Machines Automatically )，但是在2014年时很多场景已经不再可用了，因此出现了更新的版本MANA。在更新的版本中，除了响应直接探测，还响应广播探测。

这一类伪AP的根本问题是802.11协议中没有清楚地定义客户端如何选择ESS以及如何在不同的ESS之间漫游，所以实现上就存在各种偏差。

一个使用MANA伪造AP和响应探测请求的例子如下：

下面的窗口是通过aireplay发送deauth包令客户端掉线，从而连接上我们的恶意热点。

Krack
Krack攻击可能大家都在新闻上看到过，前两年搞得沸沸扬扬，还做了官方网站和Logo，……Anyway，Krack就是Key Reinstallation Attacks，即秘钥重装攻击。

在我们前面介绍WiFi握手的时候见过了双方更新秘钥的过程，秘钥的更新也称为安装(Key Installation)。Krack攻击的原理就是通过重放握手信息，令客户端重新安装相同的秘钥。

当重装秘钥的时候，相关联的参数比如递增的发送包个数(即nonce)以及接收包数(即replay counter)会恢复到初始值。WPA协议中没有明确规定这种情况下如何处理，因此很多实现就是正常安装，即重置这两个值。

重置之后就可以归类到nonce重用的密码学问题，感兴趣的可以参考krack-paper中的2.4节如何通过重置nonce和counter实现解密。

总之，重置秘钥之后就可以让攻击者解密本该加密的WPA数据，从而读取受害者的网络流量。这个漏洞还根据重置的是PTK、GTK以及其他内容申请了多个CVE，大部分是影响STA的握手应用，在Linux中是wpa_supplicant，但对于GTK其实也影响了内核，这个是对应内核upstream的patch信息：

commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e Author: Johannes Berg Date: Tue Sep 5 14:54:54 2017 +0200 mac80211: accept key reinstall without changing anything When a key is reinstalled we can reset the replay counters etc. which can lead to nonce reuse and/or replay detection being impossible, breaking security properties, as described in the "KRACK attacks". In particular, CVE-2017-13080 applies to GTK rekeying that happened in firmware while the host is in D3, with the second part of the attack being done after the host wakes up. In this case, the wpa_supplicant mitigation isn't sufficient since wpa_supplicant doesn't know the GTK material. In case this happens, simply silently accept the new key coming from userspace but don't take any action on it since it's the same key; this keeps the PN replay counters intact. Signed-off-by: Johannes Berg

要说危害性，我感觉危害还是挺大的，好在目前的STA应用和内核大多已经修复了该问题。如果说存在密码学后门，这就是一个典型：利用理论和实现中的未定义行为造成偏差。

深入了解可参考下面的资料：

krackattacks

krack-paper

krack-scripts

Kr00k
这是2020年2月份RSA大会上披露的一个漏洞(KR00K - CVE-2019-15126 SERIOUS VULNERABILITY DEEP INSIDE YOUR WI-FI ENCRYPTION )，新鲜出炉。这是个芯片驱动实现的问题，主要影响Broadcom和Cypress网卡。

其核心漏洞点是在解除客户端关联后，其PTK会被置零，但是WiFi芯片会继续用置零的PTK发送缓冲中剩余的无线数据，攻击者收到这些数据后使用全零的PTK即可解密。

实际攻击中，攻击者需要不断令客户端关联/解除关联，即可不断地获得客户端发送的数据进行解密；同时由于部分路由器也受影响，因此可以获得下行的数据。

我个人的解读是这个漏洞可以泄露一些关键信息，但是不像Krack那样可以做到稳定的泄露，因此利用场景相对受限。比起后门般的Krack，Kr00t更像是一个漏洞。

漏洞详情以及PoC可以参考以下文章：

KR00K - CVE-2019-15126 SERIOUS VULNERABILITY DEEP INSIDE YOUR WI-FI ENCRYPTION

R00KIE-KR00KIE. EXPLORING THE KR00K ATTACK

启明星辰ADLab的分析

后记
本来这篇文章是想写如何偷WiFi密码的，但是写着写着就裂开展开了，因此顺便把之前放在Todo-List中的那些漏洞也一并拿出来进行研究分析。当然WiFi的安全问题不止这些，但是影响最大的还是协议设计中留下的坑。比如漫游的定义不清楚导致了KARMA，秘钥重装的不明确导致了Krack。这些坑还有多少谁也说不准，协议的更新到工业界的产品推出也需要时间，但我相信未来的无线安全性会越来越好——在众多学者、开发者以及安全研究人员的共同努力下。

参考资料

Wireless lan security - Key Management

Real 802.11 Security: Wi-Fi Protected Access and 802.11i

4-WAY HANDSHAKE - wifi professional

Evil Twin and Karma Attacks

krackattacks

KR00K - CVE-2019-15126 SERIOUS VULNERABILITY DEEP INSIDE YOUR WI-FI ENCRYPTION

对称加密与攻击案例分析

Sun, 02 Jun 2019 22:40:00 +0800

本文主要介绍常见的对称加密算法和它们的原理，然后分析一些实际存在的密码学攻击案例，包括流加密密钥重用漏洞、ECB块重排攻击以及CBC的Padding Oracle攻击等。

对称加密
当今我们所使用的加密算法，大致可以分为两类，即对称加密与非对称加密。其中非对称加密所能加密的内容长度一般受密钥长度的限制，且加密速度较慢，因此通常会与对称加密算法结合使用，即使用对称加密来对明文进行加密，再使用私钥对对称加密的密钥进行加密。本文主要关注对称加密。

对称加密在消息通信的两端共享相同密钥，加密算法一般分为两种类型：

流加密（Stream Ciphers）：逐字节加密数据

块加密（Block Ciphers）：逐块加密数据

其中块加密的块大小与具体加密算法的实现有关，常见的块大小有128、256位等。

流加密
流加密会逐字节加密数据，最常见的流加密算法就是SSL中用到的RC4算法了。其本质上是以密钥为种子（seed）产生的随机数来对明文进行逐字节异或。

0 xor 0 = 0 0 xor 1 = 1 1 xor 0 = 1 1 xor 1 = 0

流加密本质上依赖于随机数生成器的随机性，其随机性越强，加密强度就越大。

块加密
块加密也称为分组加密，也是大多数人比较熟悉的。AES、DES、3DES、Towfish等常见的加密算法都是块加密。在块加密中，原始数据会被分割成若干个大小为N的块，并分别对这些块进行加密。由于我们不能保证数据是N的倍数，因此需要对数据进行填充（Padding），这增加了实现的复杂度。一般来说，与流加密相反，块加密的解密流程和加密流程往往是不同的。

Padding
一种常见的填充方式是不论数据大小是否对齐块边界，都进行填充，而填充的内容为填充的字节数。比如块大小为8字节，那么可能有以下填充：

‘AAAAAAA’ + ‘\x01’

‘AAAAAA’ + ‘\x02\x02’

…

‘AA’ + ‘\x06’ * 6

‘A’ + ‘\x07’ * 7

‘\x08’ * 8

这就是PKCS#7中所定义的填充方式。

加密模式
块加密算法对数据进行逐块加密，有很多加密模式（mode）用于实现块的加密。这些加密模式大都可以归类为两种，即ECB模式和CBC模式。

ECB
ECB全称为Electronic CodeBook，是块加密中比较简单的加密模式。在ECB模式中，每一块明文数据都被独立地进行加密来生成加密块。这意味着如果你发现两个加密块有相同的内容，那么就可以确定这两个加密块的原文也是相同的。

这看起来好像没什么大不了的，但我们可以考虑这么一种情况，比如要加密的对象是一张图像，我们使用ECB加密算法，并且设置块大小为8字节（DES），加密后的图像如下：

虽然和原图有所区别，但也足以明显地看出原图的大致内容。

CBC
CBC全称为Cipher-Block Chaining，算是最常见的块加密模式了。在CBC模式中，每个明文块都会在加密前被使用前一个明文块的秘文进行异或；解密过程则正好相反。其中第一个明文块会被使用IV即初始化向量进行异或。

由于CBC模式中各个块会相互链接，在第一个加密块（Block0）中翻转某一位，则会在解密后导致对应的下一个明文块中（Block1）相同的位进行翻转。这项特性也导致了许多有趣的bug，后面会说到。

常见攻击
下面我们来介绍一下在现实中很常见的一些加密算法缺陷所导致的攻击场景。

流加密重用攻击
也常称为Stream Cipher Reuse Attack，指多次使用相同的流加密密钥可导致明文泄露。前面说过，流加密实际上是使用密钥生成随机序列，然后用该序列来对明文逐位异或加密。假设生成的随机序列为C(K)，加密函数为E()，那么对于明文A、B来说，则：

E(A) = A xor C E(B) = B xor C

进行简单的数学运算：

E(A) xor E(B) = (A xor C) xor (B xor C) = A xor B xor C xor C = A xor B

这意味着如果攻击者可以拿到A、B的密文E(A)、E(B)，以及攻击者自己的明文B，就可以在无需知道密钥的情况下计算出A的明文：

A = E(A) xor E(B) xor B

眼见为实，我们使用RC4流加密为示例，首先使用openssl生成两个文件的密文（使用相同密钥）：

$ cat 1.txt hello $ cat 2.txt world $ openssl rc4 -nosalt -in 1.txt > 1.enc $ openssl rc4 -nosalt -in 2.txt > 2.enc

接着，在已知1.enc、2.enc以及2.txt的情况下，还原1.txt的内容：

#!/usr/bin/env python3 def load(file): with open(file, 'rb') as f: data = f.read() print('loaded', len(data), 'bytes from', file) return data def xor(lhs, rhs): return bytes(a ^ b for a, b in zip(lhs, rhs)) # A = load('./1.txt') A_enc = load('./1.enc') B = load('./2.txt') B_enc = load('./2.enc') print('E(A) =', A_enc) print('E(B) =', B_enc) print('B =', B) print('A =', xor(xor(B, B_enc), A_enc))

输出：

$ python3 stream.py loaded 6 bytes from ./1.enc loaded 6 bytes from ./2.txt loaded 6 bytes from ./2.enc E(A) = b'\xa1\xb1`\x1b\xa7\x97' E(B) = b'\xbe\xbb~\x1b\xac\x97' B = b'world\n' A = b'hello\n'

在密钥未知的情况下，依然成功还原了1.txt的明文内容。防御这种攻击的方法就是尽可能不要重用流加密的密钥，常见的实现是在加密前将密钥与随机数nonce进行运算。

ECB块重排攻击
前文说过，在块加密中ECB模式中每个块都是独立加密的。因此攻击者可以在未知密钥的情况下，对密文中的块进行重新排列，组合成合法的可解密的新密文。

考虑这么一种场景，某CMS的cookie格式为DES-ECB加密后的数据，而明文格式如下：

admin=0;username=pan

由于DES使用的块大小是8字节，因此上述明文可以切分成三个块，其中@为填充符号：

admin=0; username =pan@@@@

假设我们可以控制自己的用户名（在注册时），那么有什么办法可以在不知道密钥的情况下将自己提取为管理员呢（即admin=1）？首先将用户名设置为pan@@@@admin=1;，此时明文块的内容如下：

admin=0; username =pan@@@@ admin=1;

我们所需要做的，就是在加密完成后，将服务器返回的cookie使用最后一个块替换第一个块，这样一来就获得了一个具有管理员权限的合法cookie了。

完整例子就不整了，这里只证明一下这种方式的可行性，首先使用DES-ECB加密明文：

$ cat admin.txt admin=0;username=pan $ openssl des-ecb -nosalt -in admin.txt > admin.enc $ xxd admin.enc 00000000: 0293 07cd 88f3 026e c61e 1284 1a6e 6853 .......n.....nhS 00000010: e0b2 7169 3ee4 0b9a ..qi>...

然后修改密文，将前两个块（8字节）替换，然后使用相同的密钥进行解密：

$ xxd admin1.enc 00000000: c61e 1284 1a6e 6853 0293 07cd 88f3 026e .....nhS.......n 00000010: e0b2 7169 3ee4 0b9a ..qi>... $ openssl des-ecb -nosalt -d -in admin1.enc usernameadmin=0;=pan

可以看到，该攻击方法确实是对ECB块加密算法有效的。

类似的利用方式还有在能够解密的情况下，将其他密文的对应块替换到自己的密文块中，从而获取其他密文块的明文数据。比如上述例子如果可以通过cookie获取用户名，那么可以将其他密文块放到用户名部分从而获取其他加密的信息。

该攻击和其他类似的攻击其实有一个共同点，我们无法获取和猜解原始数据，但可以通过修改密文数据并让服务器去成功解密。因此应对此攻击的方法就很明显了，即在加密后再添加MAC校验。

注意这里说的是先加密后MAC，如果顺序反了，那在处理数据时就要先解密再校验MAC，这有可能会导致一系列安全问题，比如下面将提到的密文填塞（Padding Oracle）攻击。

Padding Oracle Attack
在介绍该攻击之前，可以先回顾一下关于填充的知识。在PKCS#7系统中，我们可以通过最后一个块的最后一个字节得知填充的大小以及校验填充是否合法。

密文填塞（Padding Oracle Attack）攻击通常出现在CBC块加密模式以及PKCS#7填充的情况下。如果服务器在解密数据时对于填充合法的密文和填充不合法的密文有不同的返回，我们就能利用这种先验知识（Oracle）来填塞数据。

再回想一下我们介绍CBC块加密时说过，在一个加密块（Block N）中翻转某一位，则会在解密后导致对应的下一个明文块（Block N+1）中相同的位进行翻转。由于这个特性，我们可以在不知道密钥的情况下，使用服务器来猜解出明文数据。

最后一字节
具体怎么做呢？再次仔细思考一下CBC模式的解密流程，若要解密一个块，则需要其本身的密文C2以及前一个块的密文C1，解密的流程如下：

在这种攻击场景下，我们（攻击者）可以控制输入密文块的内容，并且获取服务器的差异化返回，即是否填充错误。假设C2是最后一个块，那么通过变异C1，就可以猜解C2明文。猜解过程如下：

将C1前15字节随机设置，第16字节设置为’\x00’

将修改后的密文块发送给服务器解密

由于我们修改了C1的最后一个字节，那么根据上文介绍，在解密后C2的明文P2最后一个字节也会进行改变，变成什么我们还不知道，但是我们知道：

P2[15] = I2[15] xor C1[15]

其中I2是解密算法如AES解密后的中间值，我们不关心具体解密算法，但总有这么个值。然后，根据服务器的返回我们知道有两种可能：

返回填充不合法。此时P2[15]未知。

返回填充合法。此时P2[15]肯定为0x01，因为只有这样才能出现合法的填充。

如果是第一种情况，我们就继续变异C1[15]，直到出现合法的填充，即第二种情况。假设我们在变异到C1[15] = 0x26时才出现合法填充，则此时有：

P2[15] = I2[15] xor C1[15] I2[15] = P2[15] xor C1[15] = 0x01 xor 0x26 = 0x27

回顾一下上图，I2的产生与C1无关，只与C2和密钥key相关，但是我们却计算出了I2[15]的值！因此我们可以用I2[15]异或上变异前的C1[15]从而获得原始的明文。

P2[15] = 0x27 xor C1[15]

这就是Padding Oracle攻击的思路。

下一个字节
为了完成攻击，我们继续使用类似方式猜解I2中更多的内容。

将C1前14字节设置为随机值

C1[14]设置为0x00

C1[15]设置为能令P2[15] = 0x02的值

P2[15] = I2[15] xor C1[15] C1[15] = P2[15] xor I2[15] = 0x02 xor 0x27 = 0x25

即将C1[15]固定为0x25，继续爆破C1[14]知道出现合法的填充，此时P2[14]=0x02，假设出现合法填充时候爆破的C1[14]值为0x68：

P2[14] = I2[14] xor C1[14] = 0x02 I2[14] = P2[14] xor C1[14] = 0x02 xor 0x68 = 0x6A

再一次，我们获得了真实的I2[14]值，从何可以算出原始的明文P2[14]。以此类推，最终我们可以计算出完整的明文P2内容。

下一个块
根据上述方法，我们已经可以还原最后一个密文块的明文了。而对于CBC模式，每个密文块的解密仅和当前块以及前一个块相关，因此上述攻击可以应用到所有块中，除了第一个。

第一个块的加解密使用初始化向量IV进行，对此没有通用破解方法。但是CBC加密中IV也不是必须保密的，因此在实践中通常会组合到密文的最前面或者最后面，其长度和块大小相同。如果一定要解密第一个块，可以使用这种猜测方法。

示例
实践出真知，我们来看一个具体的例子。首先用Flask写一个简单的应用，如下：

#!/usr/bin/env python3 import binascii import string import random from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad from flask import Flask, request app = Flask(__name__) db = {} BSIZE = 16 secret = b'\x26' * BSIZE def get_iv(): return b'\x00' * BSIZE def decrypt(data): data = data.encode() data = binascii.unhexlify(data) iv = data[:BSIZE] engine = AES.new(key=secret, mode=AES.MODE_CBC, iv=iv) data = data[BSIZE:] data = engine.decrypt(data) data = unpad(data, BSIZE) return data.decode() def encrypt(data): data = data.encode() iv = get_iv() engine = AES.new(key=secret, mode=AES.MODE_CBC, iv=iv) return binascii.hexlify(iv + engine.encrypt(pad(data, BSIZE))).decode() @app.route('/dec/') def dec(data): # print('dec:', data) try: key = decrypt(data) except Exception as e: return 'Error: ' + str(e) if key not in db: return 'Error: invalid key' return db[key] @app.route('/enc/') def enc(key): db[key] = 'valid' return encrypt(key) app.run(debug=False)

该应用可以接收一个明文返回其密文（enc），也可以接收密文返回对应信息。

$ curl http://localhost:5000/enc/See_you_in_Red_Square_at_4_pm 00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455 $ curl http://localhost:5000/dec/00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455 valid $ curl http://localhost:5000/dec/00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8466 Error: Padding is incorrect.

作为攻击者，我们拿到的只有加密后的信息，目的就是要将其解密，查看明文内容：

00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455

方便起见，我们假设已知服务器使用的是AES-128-CBC加密算法，且IV组合在密文头部。其实不知道也没关系，只不过需要多试几次罢了。根据前面介绍的原理，我们先将密文分割成128/8=16字节的3个块：

block[0] = '00000000000000000000000000000000' block[1] = 'c8ab1c881b40d54d81d1efab429ad239' block[2] = 'dac1d6573e7c26d533ffc3cbc23a8455'

经测试，当服务器遇到填充错误会返回Error: Padding is incorrect.或者Error: PKCS#7 padding is incorrect.，那么这就可以作为我们Padding Oracle攻击的依据。

首先将block[1]最后一字节从0x00开始到0xff不断变异尝试，发现当值为0x3b时候出现了非Padding错误，此时：

I2[15] = _C1[15] ^ _P2[15] = 0x3b ^ 0x01 = 0x3a

则明文最后一字节为：

P2[15] = I2[15] xor C1[15] = 0x3a ^ 0x39 = 0x03

依此类推，不断从后往前猜解每个字节的值。一个简单的自动化脚本如下：

#!/usr/bin/env python3 import time import requests import binascii url = 'http://localhost:5000/dec/' data = '00000000000000000000000000000000c8ab1c881b40d54d81d1efab429ad239dac1d6573e7c26d533ffc3cbc23a8455' BSIZE = 16 def test(data): r = requests.get(url + data) return r.text b = binascii.unhexlify(data) nblocks = int(len(b) / BSIZE) blocks = [] print('nblocks:', nblocks) for i in range(nblocks): blk = b[i*BSIZE: (i+1)*BSIZE] print(f'block[{i}] =', binascii.hexlify(blk)) blocks.append(blk) print('iv:', b[:BSIZE]) blockID = -1 prevID = blockID - 1 print(f'decrypting block[{blockID}], prev =', binascii.hexlify(blocks[prevID])) plaintext = bytearray(16) inter = bytearray(16) for byteIdx in range(BSIZE-1, -1, -1): prevBlock = bytearray(blocks[prevID]) print(f'mutating block[{prevID}][{byteIdx}]') origin = prevBlock[byteIdx] padValue = BSIZE - byteIdx # 将byteIdx之前的值可以任意随机设置 for i in range(byteIdx): prevBlock[i] = 0x11 # 将byteIdx之后的值设置为令其明文为padValue的值 for i in range(byteIdx + 1, BSIZE): prevBlock[i] = inter[i] ^ padValue print('begin:', prevBlock.hex()) found = False for val in range(0x100): prevBlock[byteIdx] = val _blocks = blocks.copy() _blocks[prevID] = bytes(prevBlock) payload = b''.join(_blocks) payload = binascii.hexlify(payload).decode() resp = test(payload) # print(f'testing', binascii.hexlify(prevBlock), '->', resp, end='\r') if 'incorrect' in resp: continue i2 = padValue ^ val p2 = origin ^ i2 inter[byteIdx] = i2 plaintext[byteIdx] = p2 print(f'found c={val}, i={padValue}^{val}={i2}, o={origin}, p={p2}') found = True break if not found: print('Error: no valid value found') break print('plaintext =', plaintext)

运算结果为：

$ python3 padding_oracle_exp.py nblocks: 3 block[0] = b'00000000000000000000000000000000' block[1] = b'c8ab1c881b40d54d81d1efab429ad239' block[2] = b'dac1d6573e7c26d533ffc3cbc23a8455' iv: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' decrypting block[-1], prev = b'c8ab1c881b40d54d81d1efab429ad239' mutating block[-2][15] begin: 11111111111111111111111111111139 found c=59, i=1^59=58, o=57, p=3 mutating block[-2][14] begin: 1111111111111111111111111111d238 found c=211, i=2^211=209, o=210, p=3 mutating block[-2][13] begin: 111111111111111111111111119ad239 found c=154, i=3^154=153, o=154, p=3 mutating block[-2][12] begin: 111111111111111111111111429dd53e found c=43, i=4^43=47, o=66, p=109 mutating block[-2][11] begin: 1111111111111111111111ab2a9cd43f found c=222, i=5^222=219, o=171, p=112 mutating block[-2][10] begin: 11111111111111111111efdd299fd73c found c=182, i=6^182=176, o=239, p=95 mutating block[-2][9] begin: 111111111111111111d1b7dc289ed63d found c=226, i=7^226=229, o=209, p=52 mutating block[-2][8] begin: 111111111111111181edb8d32791d932 found c=214, i=8^214=222, o=129, p=95 mutating block[-2][7] begin: 111111111111114dd7ecb9d22690d833 found c=48, i=9^48=57, o=77, p=116 mutating block[-2][6] begin: 111111111111d533d4efbad12593db30 found c=190, i=10^190=180, o=213, p=97 mutating block[-2][5] begin: 111111111140bf32d5eebbd02492da31 found c=20, i=11^20=31, o=64, p=95 mutating block[-2][4] begin: 111111111b13b835d2e9bcd72395dd36 found c=114, i=12^114=126, o=27, p=101 mutating block[-2][3] begin: 111111887312b934d3e8bdd62294dc37 found c=247, i=13^247=250, o=136, p=114 mutating block[-2][2] begin: 11111cf47011ba37d0ebbed52197df34 found c=115, i=14^115=125, o=28, p=97 mutating block[-2][1] begin: 11ab72f57110bb36d1eabfd42096de35 found c=209, i=15^209=222, o=171, p=117 mutating block[-2][0] begin: c8ce6dea6e0fa429cef5a0cb3f89c12a found c=169, i=16^169=185, o=200, p=113 plaintext = bytearray(b'quare_at_4_pm\x03\x03\x03')

这样，我们就在无需知道服务端密钥的情况下，成功还原了最后一个块的明文。逐块处理，就可以还原完整的内容了。当然还有值得优化的地方，比如爆破出最后一字节明文后，可以根据Padding原理直接跳过若干字节，加快爆破的速度，以及使用IV还原第一个块等。

小结
本文介绍了生活中常见的对称加密算法，包括流加密和块加密。其中流加密为逐字节加密，类如RC4等算法容易受到密钥重用攻击的影响，导致攻击者在无需知道密钥的情况下还原密文；而块加密将数据分割为一个个块再分别进行加密，ECB中各个块独立加密，容易收到重排攻击的影响，CBC中每个块加密后会与前一个块密文进行异或，在填充规律已知的情况下，容易收到Padding Oracle攻击的影响。缓解密钥重用的方式一般是增加随机数nonce，而绕过密钥获取/修改明文的攻击则可以通过对加密数据添加完整性保护（MAC）。加密算法本身没有漏洞，但是使用不当也能导致严重的安全问题，关键是需要理解所使用的加密算法基本原理。

参考链接

Block cipher mode of operation

Stream Cipher Attacks

The Padding Oracle Attack

非对称加密与OpenSSL

Sat, 29 Oct 2016 22:40:00 +0800

随着个人隐私越来越受重视, HTTPS也渐渐的流行起来, 甚至有许多网站都做到了全站HTTPS, 然而这种加密和信任机制也不断遭遇挑战,比如戴尔根证书携带私钥,Xboxlive证书私钥泻露, 还有前一段时间的沃通错误颁发Github根域名SSL证书事件. 因此本文从非对称加密说起, 介绍了证书的签证流程, 并且通过openssl的命令行工具对这些过程都转化为相对具体的命令, 也算是一个温故知新的简要记录吧.

前言
一般来说,常见的数字加密方式都可以分为两类,即对称加密和非对称加密. 对于对称加密来说, 加密和解密用的是同一个密钥, 加密方法有AES,DES,RC4,BlowFish等; 对应的, 非对称加密在加密和解密时, 用的是不同的密钥, 分别称为公钥或私钥. 非对称加密的加密方法有RSA, DSA, Diffie-Hellman等.

OpenSSL是一个开源项目,为传输层安全(TLS)和安全套接字(SSL)协议提供了比较完整的实现, 同时也致力于将自身打造为一个通用的密码学工具集. 其中包括:

libssl : 提供了SSL(包括SSLv3)和TLS的服务器端以及客户端的实现.

libcrypto : 通用的密码学库以及对X.509的支持

openssl : 一个多功能的命令行工具

本文主要使用openssl的命令行工具来示例非对称加密的流程, 如果有兴趣的话,也可以用其SDK 来实现更具体的操作.

加解密过程
创建公私钥对
首先用openssl生成私钥:

openssl genrsa -out private.pem 1024 当然为了更加安全,可以在生成私钥的时候同时指定密码, 这样即使不小心泻露了私钥,也能增加别人的盗用难度: openssl genrsa -aes256 -passout stdin -out private.pem 1024 openssl genrsa -aes256 -passout file:passwd.txt -out private.pem 1024 openssl genrsa -aes256 -passout pass:my_password -out private.pem 1024

其中 -passout 指定密码的输入方式,可以分别是stdin,从文件中读取或者紧接着pass:后面输入. 有了私钥,便可以从其中提取出公钥:

openssl rsa -in private.pem -pubout -out public.pem

用公私钥进行加解密
在一次秘密的信息传输中, 我们首先通过可信的方式(比如面对面)将公钥告知对方, 对方发送机密信息的时候就可以用我们的公钥加密:

openssl rsautl -encrypt -pubin -inkey public.pem -in file.txt -out file.txt.enc

在发送的过程中即便泄露了文件,也无法查看文件的明文信息. 而我们收到密文后, 用私钥解密即可:

openssl rsautl -decrypt -inkey private.pem -in file.txt.enc -out file.txt.dec

和对称加密协作
虽然公私钥加密很好用, 但事实上非对称加密的缺点是加解密速度要远远慢于对称加密, 在某些极端情况下, 甚至能比非对称加密慢上千倍. 另外由于RSA算法的工作机理, 如果密钥是n比特的,那么其加密的信息容量就不能大于(n-11)比特. 因此对于大文件的加密传输, 通常还是使用对称加密的方式, 例如

openssl rand -base64 128 -out aeskey.txt openssl enc -aes-256-cbc -salt -in file.txt -out file.txt.aesenc -pass file:aeskey.txt openssl enc -d -aes-256-cbc -in file.txt.aesenc -out file.txt.aesdec -pass file:aeskey.txt

其中aeskey.txt是我们随机生成密码文件, 并且用其可以对大文件进行对称的加解密, 在实际中, 通常还会将密码文件用公私钥加密的方式来发送给对方. 值得一提的是,这也正是PGP的工作方式, 如下图所示:

证书
对任一个体来说, 它都有公钥,私钥和证书. 其中私钥用来加密发出去的信息,公钥用来解密收到的信息, 而证书则用来证明自己的身份. 一般来说,证书中包含自己的公钥以及额外的信息,如签发机构(CA, Certificate Authority), 证书用途(比如适用的域名)和有效时间等. CA通常是个第三方的可信机构, 比如VeriSign, GeoTrust, DigiCert和沃通等, 当然也可以是未知的主体, 比如说自己.

获得一张证书的流程通常是: 1)用私钥生成证书签名请求(csr), 2)将csr文件发送给CA,待其验证信息无误后, CA会用自己的私钥对其进行签名表示确认.

生成证书签名请求
证书签名请求(Certificate Signing Request)通常以.csr为后缀, 包含了请求方的公钥和主体的详细信息, 如域名,公司名,国家,城市等信息, 其完整内容可以参考这里. 使用openssl也能很方便地生成csr:

openssl req -new -key private.pem -out pppan.csr

默认会在stdin中根据提示交互地输入主体信息,也可以通过 -config 选项来从文件中读取. 生成完之后可以通过:

openssl req -in pppan.csr -noout -text

来查看csr文件中的详细信息.

CA对csr文件进行签名
当CA收到csr文件并且对请求方的域名,公司等内容校验无误后,便可以对csr请求进行确认(签名),

openssl req -x509 -newkey rsa:4096 -nodes -keyout cakey.pem -out cacert.pem -outform PEM openssl ca -config openssl-ca.cnf -policy SP -extensions SR -infiles pppan.csr -out pppan.crt

虽然这不是重点, 但也稍微解释下这两个命令的意思吧. 第一个命令是CA一开始创建私钥和CA的证书, 第二个命令表示对csr文件进行签名确认, 用-config指定自定义的配置文件, 如果不指定则默认为/usr/lib/ssl/openssl.cnf, SP和SR都是自定义于配置文件中的信息, 此外配置文件中还包括CA证书路径和私钥路径,以及对req的默认校验策略等, 有兴趣的可以查看详细解释.

另外值得一提的是, 我们用自己的私钥也可以生成证书, 并且也能用这个证书来对自己的csr进行签名, 这通常称为自签名(self-signed), 上面CA生成的证书cacert.pem就是自签名的. 一般来说, 如果是自己随便生成自签名证书, 都是会被认为是不可信的, 除非对方也将其添加到信任CA证书列表中.

查看和验证证书
CA对csr进行签名后, 我们就能得到对应的证书, 这里是pppan.crt, 可以用openssl查看证书的详细信息:

openssl x509 -noout -text -in pppan.crt

可以看到具体的签发机构,签发时间和证书的有效时间等信息. 可以用命令验证证书是否有效:

openssl verify -CAfile Trusts.pem pppan.crt

其中Trusts.pem是一系列所信任的证书集合,其中也包括了上述CA的证书cacert.pem

其他
上面所有用到的证书及其组件,如公钥,私钥,csr等,其格式都是PEM的,这也是最常见的一种格式, 可以用文本便及其打开,通常是以-----BEGIN XXX------开头, 以-----END XXX-----结束, 中间的部分则是实际密钥的base64编码, 其二进制表示也称为DER格式, 两者可以用base64转化, 因此都属于x509实现的证书格式.

还有比较常见的证书格式,为PKCS7和PKCS12. 其中PKCS7是由JAVA使用的开放标准,并且也被 Windows所支持, 其内是不包含私钥信息的; 而PKCS12则是一种非公开的标准,用来提供比PEM的纯文本格式更高的安全性, 这是Windows建议使用的格式, 其中可以包含私钥信息.

不同格式的转换如下所示.

PEM <-> DER:

openssl x509 -in bar.pem -outform der -out bar.der openssl x509 -inform der -in foo.der -out foo.pem

PEM <-> PKCS7:

openssl crl2pkcs7 -nocrl -certfile foocert.pem -out foocert.p7b openssl pkcs7 -in foocert.p7b -print_certs -out barcert.pem

PEM <-> PKCS12:

openssl pkcs12 -inkey private.key -in foocert.pem -export -out foocert.pfx openssl pkcs12 -in foocert.pfx -nodes -out barcert.pem

后记
当今我们使用最多的https本质上就是在http协议的基础上对传输内容进行了非对称的加密, 当然实现过程多了很多复杂的交互, 感兴趣的可以去查看SSL和TLS协议. 我想说的是, 这一切信任机制的基石是对于CA的信任, 如果说CA的私钥泻露,或者我们错误地信任了一个坏CA, 那么https的隐私性也就不复存在了, 因为其可能对无效的csr进行签名, 从而使得https中间人攻击成为现实. 据说早在两年前伟大的防火墙就已经可以对https进行监听,敏感词识别和连接重置, 后来因为某种原因才从大范围应用转为只对特殊对象使用,不过那是后话了.