GB/T 38636-2020 信息安全技术 传输层密码协议(TLCP)

GB/T 38636-2020 信息安全技术 传输层密码协议(TLCP)
仅供个人学习
反馈
标准编号:
文件类型:.pdf
资源大小:2.3M
标准类别:环境保护标准
资源ID:211116
下载资源

标准规范下载简介

GB/T 38*3*-2020 信息安全技术 传输层*码协议(TLCP)

*.*.3.2关闭通知

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

GB/T *10**.2-2022 石油天然气钻采设备 海洋石油半潜式钻井平台 第2部分:建造安装和调试验收GB/T38*3*—2020

*.*.3.3错误报警

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

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

*.*.*握手协议总览

GB/T38*3*—2020

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

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

*.*.5.1结构定义

图2重用的握手消息汤

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

GB/T38*3*—2020

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

*.*.5.2Hello消息

5.*.5.2.1 Client Hello 消息

.5.2.1Client Hello 消岛

GB/T 38*3*2020

*.*.5.2.2 Server Hello 消息

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

GB/T38*3*—2020

*.*.5.3ServerCertificate消息

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

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

.5.*Server Key Excha

GB/T38*3*—2020

5.*.5.5CertificateRequest消息

*.*.5.*ServerHelloDone消息

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

*.*.5.7ClientCertificate消息

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

*.*.5.8ClientKeyExchange消息

GB/T38*3*—2020

主*钥的数据结构如下

*.*.5.9CertificateVerify消息

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

*.*.5.10Finished 消息

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

GB/T38*3*—2020

A.1.1 GCM简众

附录A (规范性附录) GCM可鉴别加*模式

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

A.1.2GCM的要素

A.1.2.1分组*码

GCM的工作依赖于底层的对称*钥分组*码的选择,因而可以被看作是分组*码的工作模式。 GCM*钥是分组*码*钥。 对于任何给定的*钥,模式的底层分组*码由两个互函数组成。分组*码的选择包括将分组* 码的两个函数之一指定为前向*码函数 前向*码函数是一个定长的比特串上的置换,这个串被称为分组,分组的长度称为分组大小。*钥 用K表示,由此产生的分组*码的前向*码函数表示为CIPHk。 底层分组*码的分组大小应为128比特,*钥长度应至少为128比特。*钥应随机均匀,或近似随 机均匀生成。因此,*钥有很高的概率不同于任何以前的*钥。并且*钥仅用于GCM所选的分组 *码。

A.1.2.2GCM的两个要素

A.1.2.2.1可鉴别加*函数

A.1.2.2.1.1输入数据

根据分组*码和*钥的选择,可鉴别加*函数有三个输入字符串: 明文,表示为P; 附加的可鉴别数据(AAD),表示为A; 初始向量,表示为IV。 明文和AAD是GCM保护的两类数据。GCM保护明文和AAD的真实性;GCM也保护明文的机 *性,而AAD则被保留是明文的。 示例:在网络协议中,AAD可以包括地址、端口、序列号、协议版本号,以及说明如何处理明文的其他字段

GB/T38*3*—2020

A.1.2.2.1.2输出数据

下面的两个比特串组成了可鉴别加*函数的输出数据: *文,表示为C,其比特长度与明文相同。 可鉴别标签(或简称标签),表示为T。 标签的比特长度(表示为t)是一个安全参数。一般来说,t可以是下列五个值中的任何一个:128、 120、112、10*或9*。对于某些应用程序,t可以是**或32。

下面的两个比特串组成了可鉴别加*函数的输出数据: *文,表示为C,其比特长度与明文相同。 可鉴别标签(或简称标签),表示为T。 标签的比特长度(表示为t)是一个安全参数。一般来说,t可以是下列五个值中的任何一个:128、 120、112、10*或9*。对于某些应用程序,t可以是**或32。

1.2.2.2可鉴别**函娄

根据分组*码、*钥和相关联的标签长度的选择,可鉴别**函数的输人为IV、A、C和T的值,如 上面A.1.2.1所述。输出是下列之一: 与*文C相对应的明文P,或 一个特殊错误代码,在本文档中表示为FAIL。 输出P表明T是IV、A和C的正确的可鉴别标签:否则.输出是FAII

根据分组*码、*钥和相关联的标签长度的选择,可鉴别**函数的输人为IV、A、C和T的值 面A.1.2.1所述。输出是下列之一: 与*文C相对应的明文P,或 一个特殊错误代码,在本文档中表示为FAIL。 输出P表明T是IV、A和C的正确的可鉴别标签:否则,输出是FAIL

A.1.3GCM 的数学基础

A.1.3.1比特串的基本运算和函数

对于一个实数,表示≥x的最小整数,例如2.1=3,*=*。 给定一个正整数$,0°表示包含s个“0"的比特串,例如0°=00000000。 比特串之间的拼接操作用“11”表示,例如0011110111=00110111。 给定两个相同长度的比特串,它们的异或运算用“④”表示,又称为模2加,例如10011④10101= 00110。 给定一个比特串X,其长度用len(X)表示,例如len(00010)=5。 给定一个比特串X和一个非负整数s,其中len(X)≥s,LSB(X)和MSB,(X)分别表示比特串X 的最低位(最右)s比特和最高位(最左)s比特。例如LSB:(111011010)=010,MSB.(111011010)= 1110。 给定一个比特串X,单比特右移函数表示为X》1,其右移结果为MSBspX>(0|X),例如0110111》 1=0011011。 给定一个正整数s和一个非负整数,其中<2s,整数转比特串的函数记为[α]s,即将整数表 示为二进制字符串。例如,一个十进制整数39,其二进制表示为100111,[39]8=00100111。 给定一个非空比特串X.比特串转整数的函数记为int(X).例如int(00011010)=2*

1.3.2递增函数inc.(X)

A.1.3.3分组之间的乘法运算

设R是一个比特串1110000111012°,给定两个分组X和Y,算法1计算乘积X·Y: 算法1:计算X·Y。 输人:分组X,Y。 输出:X·Y。 开始 a)令。,{127表示X的比特序列; b)令 Z。=0128,Va=Y; c)对于i从0~127 计算分组Z;+1和V;+1如下: [2;当 X,=0 Z;+2= IZ:④V;当X;=1 [V:1 当LSB2(V.)=0 V;+2= [(V,》1)R当LSB2(V,)=1 d)返回2128 分组乘法运算符“,”表示有限域中的2128个元素之间的乘法运算。固定的分组R确定了有限域的 二进制多项式的表示。从比特串到二进制多项式之间的转换是小端格式(littleendian),即如果令u 多项式的变量,则分组。"127对应多项式。十1u十127u127。异或运算用于多项式的相同 数项的系数的模2相加。模约多项式是一个次数为128的多项式,即R111。 对于一个正整数i,分组X的第i次方表示为X',例如H²=H·H,H"=H·H·H

A.1.3.*GHASH泛杂漆函数

GB/T38*3*—2020

A.1.3.5 GCTR 函数

图A.1GHASH泛杂涛函数流程图

GB/T 38*3*2020

DB11/T 1322.30-2018 安全生产等级评定技术规范 第30部分:尾矿库A.1.*.1可鉴别加*函数算法

图A.2GCTR函数流程图

GB/T38*3*—2020

A.1.*.2可鉴别**函数算法

图A.3GCM可鉴定加*算法流程图

GB/T 38*3*2020

图A.*GCM可鉴别**算法流程图

GB/T38*3*—2020

GB/T 2*591-2019 高压给水加热器用无缝钢管1 GB/T32905201*信息安全技术SM3*码杂凑算法 [2] GB/T32907一201*信息安全技术SM*分组*码算法 [3] GB/T32918(所有部分)信息安全技术SM2椭圆曲线公钥*码算法 [*] GM/T00**一201*SM9标识*码算法 [5] RFC *3**The Transport Layer Security(TLS)Protocol Version 1.1 [*] RFC **92 Elliptic Curve Cryptography(ECC) Cipher Suites for Transport Layer Security TLS) L7 RFC 5116An Interface andAlgorithms forAuthenticatedEncryption 『81RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2

©版权声明
相关文章