国密(3)- 预主密钥/主密钥计算和Finished消息的加解密

本文详细解析了TLS协议中的ECC-SM3-SM4-CBC密码套件,包括pre-masterkey和masterkey的生成过程。介绍了masterkey的计算方法,以及PRF函数在生成client_write_MAC_secret和server_write_MAC_secret等工作密钥中的应用。同时,展示了Finished消息的加密解密流程,以及SM3和HMAC在验证消息完整性的关键作用。整个过程揭示了TLS协议确保数据安全的复杂性和严谨性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文给的例子是ECC-SM3-SM4-CBC;

GBT-38636-2020(传输层密码协议TLCP) 定义了pre-master key 和 master key;

Pre- master Key 48字节长度,version 2字节,随机数46字节,由客户端产生。采用SM2加密后的密文放在client key exchange 里发送;

 pre-master key:
0101  版本号

E582AAC5064CF164DCAC7A14BFEC7BF30AF646558DC7DC63CBC77265EDE6E7721D2161FA098EF3EC41FECBFEF107    46字节随机数

Master key 计算公式:

下面是标准的master key的计算方法;

如果客户端和服务端在hello消息都携带了extended_master_secret扩展项的话,将会采用扩展方法进行master key的计算,这个方法在RFC7627里定义。不在本国密规范定义;

  master_secret = PRF(pre_master_secret, "extended master secret", session_hash)[0..47];

A0 = seed = 6d617374657220736563726574B20653C9B35996333D8079CF401FE28791704502700584C4C6A0F04894597DE1D76E6BC156B1BA2A5CEA6C251B6C2038E00CBD8194132BC33452E22E0F324F2D
A1 = 45 AC 10 55 74 46 2C 6A 68 41 6C 93 22 94 F2 8F 88 C7 1C 76 EC 22 E9 09 29 D3 D1 ED 3A B3 41 2A 
A2 = FE 2A 0D B1 BD 8B F7 12 D4 54 B4 5E 6E 54 29 59 10 52 1B 20 0C E8 33 30 E0 68 61 20 78 50 1E 20 

HMAC(A1+Seed) = E6 4A 62 8E CE E2 F1 F1 E2 A3 E1 AD FB A7 E4 AE E7 35 81 77 21 25 94 F2 72 F9 75 92 B7 09 F0 DB 
HMAC(A2+Seed) = 65 99 5D 25 B1 16 FA E2 96 89 0B A1 A8 4F 6B FB 79 80 81 0D 0F 47 4F 42 56 7B 83 8F 00 E8 4E 73

取HMAC(A1+Seed) + HMAC(A2+Seed) 的前48字节,产生

master key = E6 4A 62 8E CE E2 F1 F1 E2 A3 E1 AD FB A7 E4 AE E7 35 81 77 21 25 94 F2 72 F9 75 92 B7 09 F0 DB  65 99 5D 25 B1 16 FA E2 96 89 0B A1 A8 4F 6B FB 79 80 81 0D 0F 47 4F 42 56 7B 83 8F 00 E8 4E 73 

工作密钥:最终用于加密和生成校验码的密码是通过对master key再推导出来的。 

本规范还定义了PRF函数:

Master key :E64A628ECEE2F1F1E2A3E1ADFBA7E4AEE7358177212594F272F97592B709F0DB65995D25B116FAE296890BA1A84F6BFB

A0=seed = 6b657920657870616e73696f6eD76E6BC156B1BA2A5CEA6C251B6C2038E00CBD8194132BC33452E22E0F324F2DB20653C9B35996333D8079CF401FE28791704502700584C4C6A0F04894597DE1

A1 = 0B 52 D1 CF 1A BF 3B 6F C6 5C 80 8B E1 7C 22 93 B5 CE A4 18 C2 DC 14 8B 1C 3B 02 6C 09 98 19 51 

A2 = 22 7C 0A D1 C5 0E F6 4A 33 35 24 0F 07 D5 8D 7B 4F 03 F9 54 AA 80 A0 38 EA 07 0C 2A EC 0A 11 25 

A3 = 0D E2 4D AC 1A A1 8F 45 9E 90 67 33 D5 A1 83 53 FD C0 BA 28 F6 70 3C 1A 49 DA 94 1C AA 61 0F 94 

client_write_MAC_secret(32字节):
HMAC(A1+Seed) = B1 8D 1B 2B 67 7E A3 AB 5C 08 1B 6B F2 81 05 9E C3 25 E9 ED 2A FA 64 A9 C9 BE 87 F0 92 5F A6 0E 
server_write_MAC_secret(32字节)
HMAC(A2+Seed) = E4 50 F3 DC 28 68 B9 63 DA B2 01 03 C4 05 93 45 F8 F8 A9 E7 B0 11 8F EE 48 A9 33 BC 88 36 64 EB 

HMAC(A3+Seed) =
client_write_key  (16字节)
E5 F8 54 2F 7B 23 01 C6 A3 BF 39 DA D8 15 E9 C8
server_write_key (16字节)
0F 31 84 20 AD 79 5B BE 66 DA 75 03 95 C8 1C 48 

Finshed 消息(即 encrpted handshake message):

Finished 消息加密后长度80字节(16字节IV+ciphered(16字节finished消息明文+32字节MAC+16字节的padding)),在wireshark里面显示为Encrypted handshake message,解密后可以显示为Finished消息

IV(16字节)
52f5403d3ea71482c81986ae42433c2e

Ciphered text(64字节)
2e89c8572989dada0e6840ce6b248c91
a703b727082505a40fadffb0c4972f73e64c585187df39ad084b26d2319aed0c
cbcd5cd877bd3a863956aa2824e85f14

 

SM4 CBC depher后:
client Finshed(16字节)
14 00 00 0C DE 57 BF 29 1C E3 3A EC 83 13 9E 58 

其中14 类型

    00 00 0C长度

DE 57 BF 29 1C E3 3A EC 83 13 9E 58  对以往handshake消息的hash值,从client hello消息开始,到change cipher spec消息结束(不包括change cipher spec,finished消息,hellorequest(注意不是client hello和server hello))

消息包括消息类型和长度以及内容,如下图蓝色所示。

通过下面式子计算后,取前12个字节

 PRF(master_secret, finished_label, SM3 (handshake_messages)) [0.11].

 

 

MAC code(32字节)
76 0E 49 8C 1E 9B C9 97 FA BB BC 4A 4B 55 9B 52 80 83 EC E8 C6 CC D5 F4 15 D7 6B 99 79 93 BF 25 
HMAC_hash(MAC_write_secret,seq_num+TLSCompresed.type+TLSCompresed.version+
TLSCompresedl.ength+TLSCompresed.fragment)
MAC_write_secret = B1 8D 1B 2B 67 7E A3 AB 5C 08 1B 6B F2 81 05 9E C3 25 E9 ED 2A FA 64 A9 C9 BE 87 F0 92 5F A6 0E

seq_num+TLSCompresed.type+TLSCompresed.version+
TLSCompresedl.ength+TLSCompresed.fragmen
00 00 00 00 00 00 00 00 seq 8字节
16       1字节type
01 01  2字节version
00 10  2字节长度值
14 00 00 0C DE 57 BF 29 1C E3 3A EC 83 13 9E 58 (16字节的finished消息)

HMAC_hash的hash算法是SM3

​​​​​​​

 

pading len + Pading content(共16字节padding)
0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F 

<think>好的,我现在需要回答用户关于SSL四次握手TCP三次握手的问题。首先,用户之前询问过SSL协议原理算法,现在进一步询问SSL四次握手TCP三次握手的区别。我需要确保回答准确,同时结构清晰,符合用户之前的要求。 首先,我需要确认自己对这两个概念的理解是否正确。TCP三次握手是建立连接的过程,而SSL四次握手(更准确地说,TLS握手)是在TCP连接之后建立安全通道的过程。用户可能想知道这两者的步骤区别,以及它们如何协同工作。 接下来,我需要回忆TCP三次握手的具体步骤:SYN、SYN-ACK、ACK。然后是TLS握手的步骤,通常包括ClientHello、ServerHello、证书交换、密钥交换等。不过TLS握手通常被称为四次握手,但实际步骤可能更多,可能需要更详细的解释。 需要注意的是,用户提到的“SSL四次握手”可能指的是TLS握手过程,因为SSL已经被TLS取代,但通常人们仍用SSL来泛指。我需要澄清这一点,避免混淆。 另外,用户可能希望了解这两个过程在建立安全连接中的顺序作用。TCP三次握手建立传输层连接,而TLS握手在应用层建立加通信。需要分步骤说明,并指它们分别属于不同层次。 同时,要确保使用中文,并且按照之前的格式,使用分点、数学公式等。例如,在解释密钥交换时使用数学公式,如Diffie-Hellman的公式,者RSA加的公式。 需要检查是否有错误的地方,比如是否混淆了SSLTLS,者步骤是否有遗漏。例如,TLS 1.3简化了握手步骤,可能需要提到版本差异,但用户可能要关注传统流程。 最后,总结两者的关系区别,帮助用户理解整个连接建立过程。可能还需要提到端口号,如TCP使用443端口进行HTTPS连接,而三次握手是任何TCP连接的基础。 现在需要组织这些信息,按照用户之前接受的格式,分步骤详细说明,使用适当的LaTeX公式,确保正确性,并保持结构清晰。</think>以下是TCP三次握手与SSL/TLS四次握手的详细对比说明(基于OSI模型分层解析): --- ### 一、TCP三次握手(传输层协议) **作用**:建立可靠的端到端连接,协商初始序列号 **数学表达**: 设客户端初始序列号$ISN_c$,服务端初始序列号$ISN_s$ 1. SYN:$Client \rightarrow Server$ $SEQ = ISN_c,\quad FLAGS = SYN$ 2. SYN-ACK:$Server \rightarrow Client$ $SEQ = ISN_s,\quad ACK = ISN_c+1,\quad FLAGS = SYN|ACK$ 3. ACK:$Client \rightarrow Server$ $SEQ = ISN_c+1,\quad ACK = ISN_s+1,\quad FLAGS = ACK$ **关键特征**: - 通过$\text{SEQ/ACK}$实现数据包顺序控制 - 典型端口:HTTP-80 / HTTPS-443 - 状态变迁:CLOSED → SYN_SENT → ESTABLISHED --- ### 二、SSL/TLS四次握手(应用层安全协议) **作用**:协商加参数,建立安全通信信道 **标准流程**(以RSA密钥交换为例): 1. **ClientHello** - 协议版本(TLS 1.2/1.3- 随机数$ClientRandom$ - 支持的加套件列表 $$ \text{示例:TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256} $$ 2. **ServerHello** - 选定加套件 - 随机数$ServerRandom$ - 发送数字证书(含RSA公钥) $$ \text{证书链验证:Root CA → Intermediate CA → Server Certificate} $$ 3. **ClientKeyExchange** - 生成预主密钥: $$ PremasterSecret = RSA\_Encrypt(ClientRandom, ServerRandom) $$ - 计算密钥: $$ MasterSecret = PRF(PremasterSecret, "master secret", ClientRandom + ServerRandom) $$ 4. **Finished** - 生成会话密钥: $$ SessionKeys = PRF(MasterSecret, "key expansion", ServerRandom + ClientRandom) $$ - 验证哈希: $$ VerifyData = HMAC\_SHA256(MasterSecret, handshake\_messages) $$ **密钥交换优化**(ECDHE方案): $$ \text{临时椭圆曲线参数:} Q_{server} = d_{server} \times G $$ $$ \text{共享密钥:} Z = d_{client} \times Q_{server} = d_{server} \times Q_{client} $$ --- ### 三、协议交互时序对比 | 对比维度 | TCP三次握手 | SSL/TLS四次握手 | |----------------|-------------------------------|-----------------------------------| | OSI层级 | 传输层(第4层) | 应用层(第7层) | | 要目标 | 建立可靠传输通道 | 建立加通信信道 | | 典型耗时 | 1-2 RTT | 2 RTT(RSA) / 1 RTT(TLS 1.3) | | 加保护 | 无 | 支持AES/ChaCha20等算法 | | 密钥管理 | 不涉及 | 包含密钥交换与协商机制 | | 数据完整性 | 仅校验序列号 | 使用HMAC-SHA256等验证 | --- ### 四、完整HTTPS连接建立流程 1. TCP三次握手(传输层连接) ```mermaid sequenceDiagram Client->>Server: SYN (SEQ=ISN_c) Server->>Client: SYN-ACK (SEQ=ISN_s, ACK=ISN_c+1) Client->>Server: ACK (SEQ=ISN_c+1, ACK=ISN_s+1) ``` 2. TLS四次握手(安全信道建立) ```mermaid sequenceDiagram Client->>Server: ClientHello (TLS版本+加套件+ClientRandom) Server->>Client: ServerHello (选定参数+ServerRandom) + Certificate Client->>Server: ClientKeyExchange (PremasterSecret) Server->>Client: ChangeCipherSpec + Finished (验证) ``` --- ### 五、性能优化实践 1. **TLS会话恢复**: - Session ID复用:服务端缓存$MasterSecret$ - Session Tickets:客户端存储加的会话状态 2. **协议升级**: - TLS 1.3 0-RTT:对安全请求允许首个数据包携带应用数据 $$ EarlyData = AES\_GCM\_Encrypt(early\_traffic\_secret, data) $$ 3. **硬件加速**: - 使用支持AES-NI指令集的CPU提升对称加性能 - 部署支持ECC加速的码卡(如:国密SM2算法)
评论 18
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值