6.2.1基本数据类型

定义了六种基本数据类型，分别为opaque、uint8、uint16、uint24、uint32、uint64。所有类型都以网 络字节顺序表示，最小数据的大小是一个8位字节。 opaque：任意类型数据，1个字节。 uint16：无符号的16位整数，2个宇节。 uint24：无符号的24位整数，3个字节 uint32：无符号的32位整数，4个字节， uint64：无符号的64位整数，8个字节，

向量（Vectors)是给定类型的数据序列。向量分为两种：定长和变长。定长向量以x来表示；变长 向量以来表示，其中x代表下限，y代表上限，如果只需表达上限时，用表示。所有向量的长 度都以字节为单位。变长向量首部表示向量实际长度玩具标准，其首部大小为能够容纳变长向量最大长度的最 小字节数。

枚举（Enumerateds)是一系列特定值的字段集合，通常每个字段都包括一个名称和值。如果包含 一个未命名的值，这个值表示指定的最大值。如果只包含了名称而不定义值，只能用来指代状态值，不 能在实际编码中使用。例如，enum《red（0），green（1），（255）>color。枚举变量大小为能够容纳最大枚 举值的最小字节数

结构类型（ConstructedTypes）用struct来定义，与C语言的struct语法类似。struct中的字段按

照先后顺序串连起来进行编码。如果一个struct包含于另一个struct中，则可以省略该struct的名字。

变体（Variants)类型用select、case来定义，用于定义依赖外部信息而变化的结构，类似于C语言中 的union或ASN.1的CHOICE

记录层协议是分层次的，每一层都包括长度字段、描述字段和内容字段。记录层协议接收将要被传 输的消息，将数据分块、压缩（可选）、计算HMAC、加密，然后传输。接收到的数据经过解密、验证、解压 缩（可选）、重新封装然后传送给高层应用。 记录层协议包括：握手、报警、密码规格变更等类型。为了支持协议的扩展，记录层协议可支持其他 的记录类型。任何新的记录类型都应在针对上述类型分配的内容类型值之外去分配。如果接收到一个 不能识别的记录类型应忽略 ?

连接状态是记录层协议的操作环境。包括四种典型的连接状态：当前读状态、写状态、未决的读状 态、未决的写状态。其中，读表示接收数据，写表示发送数据。所有记录都是在当前读写状态下处理的， 未决状态的安全参数可以由握手协议设定，而密码规格变更消息可使未决状态变为当前状态。除了最 初的当前状态外，当前状态应包含经过协商的安全参数。 连接状态的安全参数结构如下

GB/T 386362020

记录层接收从高层来的任意大小的非空连续数据，将数据分段、压缩、计算校验码、加密，然后传输， 接收到的数据经过解密、验证、解压缩、重新封装然后传送给高层应用

记录层将数据分成214字节或者更小的片段

GB/T38636—2020

6.3.3.3压缩和解压缩

ContentType type; ProtocolVersion version; uintl6length; opaque fragment[TLSCompressed.length]; }TLSCompressed; 其中： a）type、version的定义同6.3.3.2中的a）、b）。 b)length 以字节为单位的TLSCompressed.fragment长度，小于或等于214十1024 c fragment

GB/T38636—2020

LSPlaintext.fragment的压缩形式

6.3.3.4加密和校验

6.3.3.4. 1概述

加密运算和校验运算把一个TLSCompressed结构的数据转化为一个TLSCiphertext结构的数据 运算则是执行相反的操作。 加密后数据结构如下

4.2校验算法的数据处

6.3.3.4.3分组密码算法的数据处理

使用分组密码算法加解密数据时，加密运算和校验运算用于将一个TLSCompressed.fragment结 构的数据转换成一个TLSCiphertext.fragment结构的数据。被加密的数据包括了校验运算的结果。 加密处理前数据结构如下：

GB/T38636—2020

6.3.3.4.4认证加密算法（AEAD)的数据处理

AEAD的输出是由AEAD加密操作的密文输出组成。其长度通常比TLSCompressed.length 是多出的长度在AEAD密码算法中并不统一。因为密码算法可能包括了填充，所以开销的数量 着不同的TLSCompressed.length值而不同。每个AEAD密码算法生成的扩展应不能多于1

屋手办设联由密规格变更你设、隆于成 一协议组成，用于双方协商出供记录层 用的安全参数，进行身份验证以及向对方报告错误等， 握手协议族负责协商出一个会话，这个会话包含： a 会话标识：由服务端选取的随意的字节序列，用于识别活跃或可恢复的会话。 b 证书：X509v3格式的数字证书，符合GB/T20518。 压缩方法：压缩数据的算法。 d） 密码规格：指定的密码算法。 e） 主密钥：客户端和服务端共享的48个字节的密钥。 重用标识：标明能否用该会话发起一个新连接的标识。本标准仅支持会话标识的重用模式，表 明是否能重用已有的或者现在的会话，不重新协商安全参数 利用以上数据可以产生安全参数。利用握手协议的重用特性，可以使用相同的会话建立多个连接

6.4.2密码规格变更协议

6.4.3.1结构定义

报警协议用于关闭连接的通知以及对整个连接过程中出现的错误进行报警，其中关闭通知由发起 者发送，错误报警由错误的发现者发送。该协议由一条消息组成，该消息用当前的压缩算法压缩，并用 当前的密码规格加密，如果是首次协商，该消息为明文。 报警消息的长度为两个字节，分别为报警级别和报警内容。 报警消息结构定义如下

GB/T38636—2020

6.4.3.2关闭通知

除非出现致命报警，客户端和服务端任何一方在结束连接之前都应发送关闭通知消息。对于 的发送方，该消息通知对方不再发送任何数据，可以等待接收方回应的关闭通知消息后，关闭本 ，也可以立即关闭本次连接。对于接收方，收到该消息后应回应一个关闭通知消息，然后关闭本 ，不再接收和发送数据。

GB/T38636—2020

6.4.3.3错误报警

当发送或接收到一个致命级别报 部应立即关闭连接，废弃出错连接的会话标识和

对于没有明确指出级别的错误报警，发送者可以自行决定是否致命，如果发送者认为是致命的， 收者发出关闭通知，最后关闭本次连接；如果接收到一个警告级别的报警，接收者可以自行决定 命，如果接收者认为是致命的，应向发起者发出关闭通知，最后关闭本次连接

6.4.4握手协议总览

GB/T38636—2020

握手协议涉及以下过程： 交换hello消息来协商密码套件，交换随机数，决定是否会话重用。 交换必要的参数，协商预主密钥。 交换证书或IBC信息，用于验证对方 一 使用预主密钥和交换的随机数生成主密钥。 一向记录层提供安全参数， 验证双方计算的安全参数的一致性、握手过程的真实性和完整性。 握手过程如下：客户端发送客户端hello消息给服务端，服务端应回应服务端hello消息，否则产生 个致命错误并且断开连接。客户端hello和服务端hello用于在客户端和服务端进行基于SM2、RSA 或IBC的密码算法协商，以及确定安全传输能力，包括协议版本、会话标识、密码套件等属性，并且产生 和交换随机数。 在客户端hello和服务端hello消息之后是身份验证和密钥交换过程。包括服务端证书、服务端密 钥交换，客户端证书、客户端密钥交换。 在服务端发送完hello消息之后，接着发送自已的证书消息，服务端密钥交换消息。如果服务端需 要验证客户端的身份，则向客户端发送证书请求消息。然后发送服务端hello完成消息，表示hello消 息阶段已经结束，服务端等待客户端的返回消息。如果服务端发送了一个证书请求消息，客户端应返回 一个证书消息。然后客户端发送密钥交换消息，消息内容取决于客户端hello消息和服务端hello消息 协商出的密钥交换算法。如果客户端发送了证书消息，那么也应发送一个带数字签名的证书验证消息 供服务端验证客户端的身份。 接着客户端发送密码规格变更消息，然后客户端立即使用刚协商的算法和密钥，加密并发送握手结 束消息。服务端则回应密码规格变更消息，使用刚协商的算法和密钥，加密并发送握手结束消息。至此 握手过程结束，服务端和客户端可以开始数据安全传输。 握手消息流程如图1所示

如果客户端和服务端决定重用之前的会话，可不必重新协商安全参数。客户端发送客户端hello 消息，并且带上要重用的会话标识。如果服务端有匹配的会话存在，服务端则使用相应的会话状态接受 连接，发送一个具有相同会话标识的服务端hello消息。然后客户端和服务端各自发送密码规格变更 肖息和握手结束消息。至此握手过程结束，服务端和客户端可以开始数据安全传输。如果服务端没有 匹配的会话标识，服务端会生成一个新的会话标识进行一个完整的握手过程。 会话重用的握手消息流程如图2所示

6.4.5.1结构定义

图2重用的握手消息汤

握手协议是在记录层协议之上的协议，用于协商安全参数。握手协议的消息通过记录层协议传转 握手消息结构定义如下：

GB/T38636—2020

finished(20),(255) HandshakeType; 握手协议消息应按照规定的流程顺序进行发送，否则将会导致致命的错误。不需要的握手消息 被接收方忽略

6.4.5.2Hello消息

5.4.5.2.1 Client Hello 消息

.5.2.1Client Hello 消岛

GB/T 386362020

6.4.5.2.2 Server Hello 消息

该消息为服务端hello消息。 如果能从客户端hello消息中找到匹配的密码套件，服务端发送这个消息作为对客户端h 的回复。如果找不到匹配的密码套件，服务端将回应handshakefailure报警消息。 服务端hello消息结构定义如下：

GB/T38636—2020

6.4.5.3ServerCertificate消息

该消息为服务端证书消息。 服务端应发送一个服务端证书消息给客户端，该消息总是紧跟在服务端hello消息之后。当选中 的密码套件使用RSA或ECC或ECDHE算法时，本消息的内容为服务端的签名证书和加密证书；当选 中的密码套件使用IBC或IBSDH算法时，本消息的内容为服务端标识和IBC公共参数，用于客户端与 服务端协商IBC公开参数 证书格式为X.509v3，证书类型应能适用于已经确定的密钥交换算法。密钥交换算法与证书密钥 类型的关系见表3。

表3密钥交换算法与证书密钥类型关系表

.5.4Server Key Excha

GB/T38636—2020

5.4.5.5CertificateRequest消息

6.4.5.6ServerHelloDone消息

表示握手过程的hello消息阶段完成。发送完该消息后服务端会等待客户端的响应消息。 客户端接收到服务端的hello完成消息之后，应验证服务端证书是否有效，并检验服务端的hel 参数是否可以接受。如果可以接受，客户端继续握手过程。否则发送一个Handshakefailure致 服务端hello完成消息结构如下： struct () ServerHelloDone:

6.4.5.7ClientCertificate消息

本消息为客户端证书消息。如果服务端请求客户端证书，客户端要随后发送本消息。 如果协商的密码套件使用IBC或IBSDH算法，此消息的内容为客户端标识和IBC公共参数，用 端与服务端协商IBC公开参数。 客户端证书消息的结构同6.4.5.3定义的结构

6.4.5.8ClientKeyExchange消息

GB/T38636—2020

主密钥的数据结构如下

6.4.5.9CertificateVerify消息

本消息为证书校验消息。 该消息用于鉴别客户端是否为证书的合法持有者，只有ClientCertificate消息发送时才发送此消 息，紧跟于客户端密钥交换消息之后。 证书校验消息的数据结构如下： struct《 Signature signature; CertificateVerify:

路灯标准6.4.5.10Finished 消息

本消息为握手结束消息。 服务端和客户端各自在密码规格变更消息之后发送本消息，用于验证密钥交换过程是否成功，并校 验握手过程的完整性， 本消息用本次握手过程协商出的算法和密钥保护。 本消息的接收方应检验消息内容的正确性。一且一方发送了握手结束消息，并且接收到了对方的 屋手结束消息并通过校验，就可以使用该连接进行数据安全传输。 握手结束消息数据结构如下：

GB/T38636—2020

A.1.1 GCM简众

附录A （规范性附录） GCM可鉴别加密模式

伽罗瓦/计数器模式（GCM)是一种对数据的加密鉴别模式，GCM使用了加密的计数器运算模式来 确保数据的机密性，并且通过使用有限域上的通用的杂凑函数来保证机密数据的完整性。GCM对于 无需加密的附加数据提供了认证农业标准，确保其没有被修改。 如果GCM的输入被限制为没有加密的数据，那么GCM的输出结果可被称为GMAC,GMAC是 对输人的数据提供可鉴别模式。 GCM有两个相关函数分别被称为鉴别加密和鉴别解密，每一个函数都相对高效的，并且能够并行 化的处理。

A.1.2GCM的要素

A.1.2.1分组密码