GM-T0128-2023 数据报传输层密码协议规范.docx

ICS35.030CCS1.XO中华人民共和国密码行业标准GM/T01282023数据报传输层密码协议规范Specificationofdatagramtransport1.ayercryptographyPrOtOCO1.2024-0D1.实施2023-12-04发布国家密码管理局发布目次wFmIIII越困I2规范性引用文件I3术语和定义I4缩珞语I5密码算法和密铜种类I5.1 概述15.2 密码算法25.3 格钢种类26协议36.1 ftt述36.2 数据类型定义36.3 Vattttttttatttttttt36.4 握手协议族66.5 密钥计算13参考文献14前言本文件按照GB,，T1.12020%标准化工作导则第1部分：标准化文件的结构和起隼规则3的规定起草。请注意本文件的某些内容可能涉及专利.本文件的发布机构不承担识别专利的责任.本文件由密码行业标准化技术委员会提出并归口。本文件起草单位：中电科网络安全科技股份有限公司、四川大学、格尔软件股份有限公司、北京信安世纪科技股份有限公司、山东得安信息技术有限公司、北京海泰方圆科技股份有限公司、兴唐通信科技有限公E.本文件上耍起电人：罗俊、龚勋、郑强、汪宗斌、马洪海、蒋红宇'王娓娜.数据报传物层密码协议规范1%9本文件规定了数据报传赫层密眄力议.包括记录层协议、握手协议族和密钥计算.本文件适用于数据报传输层密码协议相关产品(如网关、终剂等)的斫制、检测、管埋和使用.2规范性引用文件下列文件中的内容通过文中的规他性引用而构成本文件必不可少的条款.其中，注日期的引用文件，仅该日期对应的版本适用于本文件：不注日期的引用文件，其最新版本(包括所有的脩改单)适用于本文件.GB/T38636-2020信息安全技术传输层密码办议(T1.CP)GM/Z4001率码术语3 #三mXGM/Z4(X)1界定的以及下列术语和定义适用于本文件.3.1路径大传单元pathmaximumtransmissionunit遹信的源节点和目的节点之间的路径上的任一-通信链路所能支持的胜路最大传怆单元(MTU)的设小值.3.2用户初8报的议userdatagraaPrOtoCo无连接的传输处议，为应用程序提供一种无需建立连接就能发送封装的IP数据包的方法.4 MHB下列缩略语适用于本文件.AEAD:带关联数据的可鉴别加密(AUthCnIiCatCdEncrjptionwithAssociatedData)DT1.CP:,数据报住输层密码协议(DaIagnUnTranSPOn1.ayerCryptographyProtoco1.)MAC:消息鉴别码(MeSSageAu1.hentica1.ionCodes)PMTU:路位最大传怆单元(PathMaximumTransmissionUnit)UDP:用户数楙报协议(USCrDatagramPrOtoCOI)5宙码算法和密钥美1.1.1DTiX-P在传输层梏码协议(T1.CP)的基础上针对用户数据报协议的特点进行改进，采用密码技术为使用UDP例议的两个应用程序之间提供保密性和数据的完整性。仍议用到的率码算法包含非对称密码算法、分组密码算法、密用杂凌兜法、数据扩展函数和伪!机函数.协议用到的密件种类包含服务端密物.客户端密的、顶主密的、主密用和工作a?的.1.1.2 ，法1.1.3 对彝解3用于身份鉴别、数字签名、密到交换等.5.2.2 分组密码真法用于定切交换数据的M密保护和批文数据的加密保护.采用的工作模式应为GaIOiSi效；K模式(GCM)或密文分组摄接(CBC)模式.5.2.3 亩研趣埠法用于对称密钥生成和充整性校验。5.2.4 ftWT*aftPhashPhash函数的定义和使用方法应符合GB/'T386362020中5.2.4的规定.5.2.5 伪机函StPRFPRF的计W方法应符合GB,T386362020中5.2.5的规定.5.3MM5.3.1 3在本文件中采用非对称密码就法迸行身份将别和密钥交换，身份箱别通过后协商预主密钥，双方各白计徵主密钥，进而推导出工作密切，使用工作密钥进行加解率和完整性校验，5.3.2 KMf1.HH服务维密钥为非对称去码竦法的监钥对，包括答名第钥对和加密密钥对，其中签名密钢用于握手过程中服务端身份症别,加诙密钥对用于预主密钥的称商，5.3.3 客户密IR客户端密用为非对称密码算法的烹例对.包括签名密件对和加密潜税对.其中经名密税用于弗干过程中客户端身份鉴别，加密密的对用于倏主密的的协商。5.3.4 f1.1.e*!但E密的(prc_master_sccrcO是双方协商生成的常钠素材.用于牛.成主雷税“5.3.5 ±ra主密尚(mastCjSCaa)由预主密钥、客户端的机数.服务掂随机数*常量字符小，经计*生成的48字节衡钥素材，用于生成工作密钢，5.3.6 工作宙，I：作密W1.包括tt据加密密的和校验包柄.其中数据加密密作用于数据的加密和解密.校奥密钥用于数据的完整性计算和校验.在本文件中,发送方使用的工作密包称为写密钥，接收方使用的工作密钥称为读密钥.6Wtt6.1 蚪DT1.CP包括记录层协议和握手协议族.握手协议故包含密码规格变更协仅，报部协议及握手协议.6.2 脓集Stft义数据类里定义应符合GBZT386362020中6.2的规定.6.3 记录J1.傍设&rim记录层协议是分层次的.每一层都包括长度字段、描述字段和内容字段.记录层协议接收将要被传输的消息.将数抠分块、Jk缩（可选）、计究采用带密阴杂诿的消息鉴别码（HMAG、加密.然后传输.接收到的数据经过解定、验证、解压缩（可选）、成新封装然后传送给高层应用。通过记录层协议消息进行传输的侨议类型包括握手伊议族和应用数据等，为了支持协议的犷展,记录层协议宜支持其他的记录类里.任何新的记录类型都应在针对上述炎型分配的内容类里依之外去分配.如果接收到一个不能识别的记录类里应忽略，6.3.2连接状态是记录层协议的操作环境.与传输层密码力议（T1.CP）I1.1.同，DT1.CP也包括四种奥戈的连接状h当前读状态、写状态、未决的读状态、未决的写状态,何种状态的定义,以及连接状态的安全参数结构、定义和使用方法，应符合'GBT386362020中6.3.2的设定.6.13&3.3,1«62记录层接收从高层来的任意大小的非空连续数据，将数据分段、收缩、计翼校验码、加密，然后传输，接收到的数据经过解密、验证、解压缩、史新对装然后传送给高层应用.&3.12分IS为避免IP分片,记录层将数据分成不超过PMTU的消息记录.拇个DT1.CP消息记录应在单个UDP报文内，多个DT1.CP消息记录可放在同一个UDP推文中，UDP报文栽荷的第一个字节应为DT1.CP济息记录的开始，DT1.CP消息记录不能府UDP报文传输.位于同一个UDP报文的多个DT1.CP济息记录可连续放置,并根据DT1.CP消息记业的数据结构决定每个记录的边界。按照GBJT386362020中6.3.3.2规定的记荥层协议报文,数据报传输层密码协议在记录层协议批文中增加了显式的序列号字段.使得接收端能正确的5i三MACtfi.每个消息记录结构如卜丁siruct（ContcntTypctype:ProtocoIVcrsionversion:uint16epoch;uint48SeqUenCjnUmber:uirn1.61.ength;OPaqUCfragment!DT1.SPIaintcxtJcngthI;)DT1.SP1.aiinexc其中：a)Type:记录层协议类型。定义为：enum(changc_ciphcr_spcc(20),a1.crt(21).handshakc(22),app1.ication-data(23).(255)IContentType;b)Versio11:所用协议的版本号。本文件的版本号为1.1.定义为：struct!Uint8major=0x01.UinI8IniiKH=OxOk)Protoco1.Vcrsion;c)ep<ch一个计数值，数据报传输层蟒码协议新增字段，年次密码规格变更都应增加该值.d)seqUenCe_iIUmber本记录的序列号，数据报传输层密码协议新增字段.e)1.ength以字节为取位的记录长度，小于或等于PMTU,0fragment将传输的数据.记录层协议不关心具体数据内容.DT1.CP使用显式序列号，位于记录中的SeQUenCenUmber域。对于每个epoch,sequence,number序列号都单独维护，每个epoch对应的SeqUenCe.number都初始化为0口在每次发送一个DT1.CP记录层数据报文时单调递增。斑个epoch初始化为0I1.在每次发送一个密E3规格变更(ChangeCipheiSpec)Bt单调递增:当同时有几个握手并行时，有可能出现不同握手的记录序列号重宓的情况，epoch用于区分这种情况”为确保CPodvScqUCnCJnUmbCr对的唯一性,在相当于2倍TCP的MS1.(最大分段生存期)时间内叩OCh的值不能由用，基于UDP的DT1.CP怖议报文存在乱序可能性,属于前一个epoch的记录也可能出现在后一个epoch开始之后。般情况下属于早期epoch的记录应予丢弁，但密钿素材等信息可被保留相当于TCP的最大分段生存期(MS1.)时间以进行报文重排序，在本次握手结束之附，属于前个epoch的报文应被接收.序列号(SeqUenCe.number)或epoch回绕之前应终止旧的连接，重新握手建立-一个新的连接。SiraisM所有的记录都应使用当前会话状态指定的压缩算法进行压缩。当前会话状态指定的压缩算法被初始化为空算法。默认压缩算法为空算法，压缩算法将一个DTIP1.aintext结构的数据转换成一个DTICompressed结构的数据.压缩后的侬据长哎最多只能增加1024个字节，如果解压缩后的数据长度超过了21，个字节，则报告一个decompressionfai1.ure致命错误。与T1.CP相比，DT1.CP压缩后数据结构增加epoch和ScqUence_numbcr字段：SIniCHContcnfIypctype:Pnj1.oco1.Versionversion：uint16epoch;uint48scqucncc_numbcr;uind61.ength;opaquefragmentDT1.SCompressed.1.eng(h;)DT1.SComprcssod;其中:a)typeversion、epoch、sequencenumber的定义同6.3.3.2°b)1.ength以字节为单位的D1.SComprcsscd.fragment长度.小于或等于21024.C)fragmentDT1.SPiaintext.fragment的压缩形式。&3.3.4mmt加密运算和校骁运算把一个DT1.SeO<npressed结构的数据转化为一个DT1.SCiPhCrIeXt结构的数据.解密运算则是执行相反的操作.加密后数据结构如K：s1.rctComentTypetype;ProuxroIVersionversion;uint16epoch:Ui1.N48SeqUenCJnumber;uint1.61.ength;sc1.oct(CiphcrSpcc.ciphcrjypc)(caseb1.ock：GeneriCBIoCkCiPher;caseaead:GeneriCAEADCiPher;)f11gmen1.:DT1.SCipbertcxt:其中：a)typeversionepoch、SeqUencejn三ber的定义|可6,3.3.2b)!ength以字节为单位的DT1.SCiPhCrtCXt.f11gmcn1.长健.小于或等于22048c)fragment带有校验码的DT1.SCOmPrCSWd.fmgmcnt加密形式a3.3.42校”法的EM1.校脸码的计算是在加密之前进行,运算方法如RHM/C_hiish<wnie_M/C_M：crc1.,DT1.SC0mprcNsed.cp<K：h+I>T1.SC(>mpressed.sc|ucnce_nufn-ber+DT1.SComprcsscd.(ype+DT1.SComprcsscd.version+D,1.SComprcsscd.1.ength÷DT1.S-ConIPrCSSCd.fragment)其中，a)HMAjhaSh计算校骗码时使用的密码杂凑兑法.bwrijMAJsccrct客户玷为C1.ienjWrkJMAJsecrek服务端为Servejwri1.JMAQsecM其计算方法应符合GBT386%2020中6.5.2的规定.DT1.CP的序列号是显式传送,MAC计算值与前后的记录层数据报文没有关联关系对于MAC忸误,DT1.CP的实现可中断连接,也可简单地丢弃MAC忸误记求然后缚续维持连接，如果在收到个MAC无效的消总时选择生成一个警报应生成一个fata1.级别的badccord_macakrt并且中止它的连接。6 .X3.4.3分If1.密码算法的败触总使用分组密码算法加解空数据的处理过程及卷数应符合GB，T386362020中6.3.3.4.3的规定。7 .3.3.4.4AEAI)算法的JkIRft理ft/11AEAD克法加解密的处理过程及咨数应符合GB，T386362()20中6.3.3.4.4的规定.附加鉴别数据(additionI1.1.data)定义中的64位序列号由CPOCh+Scqucncjnumbcr构成：additiona1.-dau-X11-SCompressed.epoch+DT1.Compressed.sequence-number+DTI.SCiMiipress«d.type+DT1.SCompresxed.ven«ion+OTICompressed.Iengih6.115MSUtDT1.CP记录包含个序列号SeqUCnCjjwmbcr以提供重放保护.序列号的校脸应遵循下面的滑动窗I流程：会话的接收批文的H数应在会话建立时被初始化为0。对于年个已接收到的记求,接收者应验证记录中包含的序列号没有与在这个公话的生命周期内接收到的任何其他记录的序列号很父,这是在与公话M配后应用F数据包的第一个松衣，以加快对更好记录的拒绝，丢弃Ift1.I数据通过一个滑动接收窗口来实现,应支持G小为32的窗口大小，推荐大小是64的窗口(设置为默认值).其他的窗U大小(大于坡小值)可由接收先选择(接收者不能告颊发送行窗I的大小).窗I的右边缘代表着当前会话接收到的报高有效序列号的假,序列号比窗U左边缘低的记业应被丢弃.落入窗门范附内的记录应依据在窗口中接收到的记录的列表进行检杳，执行这种检食的个有效的方法是使用位掩眄。如果接收到的记录落入像口中且是新的，或者记录处于窗口的右边缘，接收并进行MAC会征。如果MAC验证失败接收者应丢弃接收到的非法记求.仅当MAC验证成功时接收窗口才能更新.6.4手协议，&41m握手协议族应符合GBJT386362020中6.4的规定，由密科规格变更协议、弗手协议和报警协议三个子协议组成，用于双方协商出供记录层使用的安全参数.进行身份验证以及向对方报告错误等.6.4.2密码装格变更械应符合GBrT386362020中6.1.2的规定。&&3应符合GB/T386362020中6.4.3的规定，6.4.4提r协议应符合GB/T38636-2020中6.1.4的设定涉及以下过程，a）交换be1.k消息来协商密码套件，交换1机数.决定是否会话地用：b）交换必要的参数，协商预主洛钥；C）交换证书或基于标识的密码SBG信息,用于险证对方：d）使用僚主宓钥和交换的附机数生成主浙钊：O向记录层提供安全参数：f）验让双方计尊的安全参数的一致性、握手过程的直实性和完整性。基于UDP数据报的安全协议易遗受各种DoS（拒绝犀务）攻击,为了应对DOS攻击，DT1.CP使用无状态cookie技术。当客户端发送它的QiCrnHdE消息给服务端时，服务端用HdIoVcnfyRopeM消息来响应。这个消息包含了个随机生成的无状态cookie客户端应正传添加这个CoOk沁的CIigtHe1.Io消息。然后服务验Ifcookia仅当Cgkie存效时才能继续进行握手处理，这个机制强迫攻击者/客户辎能够接收COoki%使得使用虚假IP地址的DoS攻击难以进行。握手消息中无状ookie是可选的C服务端接收到携带无效CQokie的CIicniHeIIo消息时，作为无COOkie的GiemHeIIo消息处理。当使用无状态CoOki。和HeUoVeiifyRoques1.济息时,后续的CeHifiaHeVerify消息的哈布后算和Finished消息的校蛤数据计尊中不包含He）1.oVerifyRCqUg消息和最初的C1.iE1.HCHo消息。握手消息流程如国1所东，属于同一轮的消息既可放在同一个UDP报文中也可分开在不同的UDP报文中发送，客户或C1.icnt1.1.c1.1.o服务制一)Hr1IoVerifyKcues1.4(COntdin3cookie)第】轮淅息海Z能/您C1.icnt1.ieIo*C1.Ihcookie)Scrvcrik1.IoCertificateScrvcrIcyExchantfc*Car1.if10eRQqS夕1，(Sexvei1.fe1.1.o1.>xe簿确消£1Ctifictc*CHcntKcjfxchaniicCeEnCateVer1.r产ChanRcCiphcrSpecJFinished->第5他消总ICtwngeC1.1.wM5ec(-Fini第6轮俯总注i*示可透般俵较J上下文关条的酒0,不是纤次机发送【】不品先手种议论总，n1手徜息床程不使用无状态cookie和He1.1.。VerifyReqUe31消息的会话求用过程应符令GBjT386362020中6.4儆规定，使用无状态和HMOVegReqU网消息的会话重用过程如图2所示.客户殖服务餐一1一例息CIicntHdIoHdIoVerihRcqucM*CIicntHdkVcoutinco1.>苑珑沟.2<wi(hcxk>ScrvcrHdIo第4轮炳儿(H<fK'p0S<cFinithcdCbarvGpiwfSpa1.，Finished第5轮价总B2的手涌流«!44.a1W½X握户协议是在记玳层协议之上的协议.用协商安全参数.握手协议的消息通过记玳层协议传输.握手消息结构定义如下：s(r>ct(HandshakeTypeinsg_(ype;uint241.ength;uint1.6InCSSagJSCquint24fragrnen1._offseUuinc24fragn11jeng(h;SdeC1.(InSgjyPe)<casehc1.1.o-rcqcs:Hc1.1.oRcqucsi;caseC1.ienche1.1.o:ChientHeIIo;casescncrJic1.1.o:ServerHeIIo:casehc1.1.o-vcrify-rcqucst:Hcik>Vc11fyReq>es1.:casecertificate:Certificate;caseserver_kcy_exchange:ScncrKcyExchangc:casecenifica(e_n?ques(:CcrtificatcRcqucst;caseSCrVCJhCHQdOnc:ServcrHe)oDone:casecer(ifica(e_veri:CcnifkatcVcrify;casec1.icnt_kcy_cxchangc:C1.icniKcyExchangc:casefinished:Finished;)bod):Handshake;握手消息类型定义如下：enum(he1.k>.requet(0),C1.icntJicI1.aI).SerVcrJKIIO(2).hc1.1.o_vcrify_rcqucst(3).ccrtitk<1.e(11)erver_kcy_e.xchange(12),CCrtiikaIJreqUeSI(13).sener_he1.1.o_done(14),ccrtitkatc-vcrify(15).c1.icnt_kcy_cxchangc(16).finished(2O).(255)HandshakeType;提T-协议消息应按照规定的流程顺序进行发送.不需要的握手消息可被接收方忽略.按照GBJT386362020中6.4.5.1规定的握手消息结构，数据报传输层去码出议DT1.CP的握手消息堵加message.seq、fragmcnjoffset和fragmentCngth三个字段和hd1.o_Vcrify.request这个消息类型在铎次握手时传输的第一个消息的m三现JSa1.始绻为0.新游崽生成时，messugjso)的值应加1.左血握手的情况下，HdIuRequeM的messagjs为0,Server1.Id1.u的message.Seq为1.当一个消息被收传时,使用相同的KeSSiIgeseq。握F的两谕都应维杼一个nextreceive.Seq计数零.理于初始化时该计数器置零.当接收到的提予消息的messagecq,jncxt_rcccivcseq计数零相同时.ncxt_rcocivc!cq计数器加1并处理理丁消息.mcssagc_scq小jFncx1.rcccivjscq计数器的消息疑被丢弃.mcssagc_scq大于ncxt_rcccivc_scq计数器的消息应被排队缓存(当空间不足时可丢弃).6.4.5.2消息分片与«&每个DT1.eP消息应在单个UDP报文内，对于超出聂大记荥大小的握手济总.DT1.CP提供消息分片与Ift出机制，将一个握手消息分片为多个记录，旬个记录可被分别传送，从而避免了IP分片.当传输握手消息时,发送者将消息分为N个连续的数据序列.这些序列不能大于收大握手分片大小且应共I可包含整个握手消息.这些序列不应重登.发送者应为这个连续的数据序舛产生N个握手消息，这些消息具有与原始的握手消息相同的messagJSeq.俸个新消息都由fragBen1.OffSet(前个分片包含的字节数)和伍师nemeng<h(这个分片的长度)来标识.所有消息的Iengih域都应与原始的消息相同.对于未分片的消息:fragjneni.offst=0且frag三entIength=Iength,在CCMifiea1.CYCrify消息的哈希运性和FiniShed消息的校验数据计处中，分片的消息应作为一个整体进行分片重组后参与运郎.当收到一个分片的握手消息时,应馔存该分片直到收到整个握手济息,应能处理重登的分片序列,使发送者在PMTU值发半.变化时能使用更小的分片大小很传握手消息，6.45.3调IUBw传DT1.CP的握手消息可分成多个消息如.每个消息组中的多个不同消息作为一个整体在不同轮次中一起依次进行发送.如图I所示.每轮的消息发送可包含多个消息.但在福时重传的时候作为一个单整体处理，即全部重传.DTI.CP使用基于状态机的个简单的超时和巫传机制.DT1.CP状态机有四个基木状态：PREPARING状态，WArnNG状态，SENDING状态,FINISHED状态,状态外换如图3所示.在PREPAR1.*G状态.进行将发送消息的相关计算和构造消息,并将消息缓存起来用于传怆,完成后进入SEND1.NG状态.在SENDING状态,传蝴纵存的消息.消息传输完成后,如果是展手的最后一个消息就进入HN-ISHED状态，如果需要收到更多消息，设置一个重传定时霜然后进入WArnNG状态杓三种方式退出WAmNG状态。a）重传定时器超时：转换到SENDING状态.整轮重传已发送的消息，重置型传定时器,然后回到WAITING状态.b）从对端接受到电传消息：转换到SENDING状态.整轮电传已发送的消息.里置或传定时器.然后回到WArnNG状态，（收到重传消息可能是对端派传定时得到期的结果，表示先前本端发送的一轮消息可能忏部分丢失）c）接收到F轮消息：如果是最后个消息，转换到FINISHED.如果需要发送个薪的消息，转换到PREPAR1.NG状态.眦分接收（接收到消息的部分或轮消息中的辐分消息）不应导致状态转换或定时密重置.DTirp客户端发送第个消息（C1.ientHe1.】。），开始于PREPARING状态ODT1.CP服务端开始于WAITING状态，缓存为空目.没行4.传定时器.当厦务东温耍设新握手时,根务端应从MN1.SHED状态找换到PREPAR1.NG状态,传送He1.1.。R-CqUE,当客户漏收到一个He1.1.。Ra1.UCW时，客户端应从HNISHED状态转换到PREPAR1.NG状态,传送CIien1.HeIk）.在同NISHED状态达到至少两个欧认的TePMSuM同时，传输用后一个报文的节点（处于普通握手过程中的服务端或处于握手恢复过程中的客户端）应电传最后个报文来响应对端此后个报文的重传,以避免当以后一个报文丢失时产生死领.在客户端等侍FiniSCd消息时.客户端的承传定时涔应启动井由时正传客户端的FiniSIKd消息，服务端应用眼务端的FiniShed消息来响应，完成握手.同样的逻辑也适用于佚复握手过程中的限务玳.由于可能存在的丢包,握手的一端可能在另一端还没有收到FiniShed消息的时候就开始发送应用数据.DT1.CP的实现应丢弃或者限存所有用于新epoch的应用数据报文直到收到当前epoch的Finished消息，如果收到当前epoch的Finished消息之前,收到新CPoCh的应用数据报文，意味着出现1.'乱序或丢包,应立即电传当前epoch的最后个报文.对近传定时器的招说处理会导致产田的阻塞问题，血传定时器的初始值宜i殳为1%集次血传时加倍,直到61s.DT1.CP仅握手消息使用消息取传机制,不会导致严隶的拥塞问题。里传定时器的值在完成一次无丢包的传输后或存在不少于10倍当前假的空闲时间之后应重置到初始值。A1.crt报警济患不进行Ift传,但在收到敢传的筋误消息后应触发个新的报警消息，w,VkgrJSESrHMI9:I1!XcJttttAi屹m.11.JIi;:发均的总簸爻IZI*72U富笈痔发送C1.iCnach的息:?；nt>)：1.-J1.-III-SAn1.NGU!tW½WSMMII-“RNtSHED1.1 I：III.I：您到Rft第9迨*士*的此洲SH3DT1.CP超时传状毒回6.4.5.4He1.1.om&411C1.ientHe1.1.oWB该消息为客户端hdki消息，客户以he1.1.o消息作为理T协议的第一条消息.客户福在发送客户端hd1.o消息之后.等待服务端回为眼务端he1.1.o消息。客户端he1.1.o消息结构定义如下；structIProuxro1.Vcrsiofic1.ient-version：RandOmrandom:SessianIDsession_»d;opaquec<x)kic<0.2A8-1.>:CiphcrSuitcciphcr-suitcs<2.2-16-1>：ConiprcssionMcthodcomprcssion_mcthods<1.2-8-1.>:X：1.iemHe1.1.o:其中.COOk论字段为DT1.CP新增.此余字段应符合GBTT386%2020中6.%52.1的规定，发送第一个CIientHe1.1.o消息时，cookie域应由空(0长度.当响应一个HCIkVerifyRo1UE时，客户端应使用与原始的C1.iciitHc1.1.o相同的参数值(板本、地机故、会活ID、密码套件、乐缩算法).服芬端应使用这些值来生成cookie.并使用收到的COokiC来验证这些值是否正确。当收到第二个C1.i-CniIIeIIo时，服务端验证Cgkie是否合法.DT1.CP支持的密码套件列表应符合GBjT386362020中6,4.52.1的规定.1.1.1.1.2 HeIIoVerifyRequest服务端HCIIOVCrifyRCqUCS1.消息结构定义如下struct(Protoco1.VersionSCrVer.version:OPaqUecokie<0.2-8-1.>OHe1.IoVerifyRequcs1.:共中：<)serverVerSiOn该字段衣示服务端支持的协议版本'本文件的版木号是1.1.b)kic眼务然产生的CoOkie.服务端应使用与原始的QieMHeII。相同的参数值(版本、Rfi机数、会话ID、定码套件、压缩算法来生成CoOkie并使用收到的coOkie求验证这些值是否正确DT1.CP服务端的cookie生成方式应为无状态，健在服务端不保存任何c1.ient状态的情况下的证COokie,为了避免序列号在多个Hc1.1.oVcrifyRcqucst中重51.服务球应制CIiCn1.Hd1.O中的记录序列号用作Hc1.1.oVcriIyRaiuest中的记录序列以应用如下的方式产生cookie:cookie=HMAC_hash(secr«.c1.icnt1.P+C1.ientHc1.1.o.c1.i«H_version+C1.ientHc1.1.o.random+C1.icntHc1.1.o.scssion_id+C1.icntHc1.1.o.ciphcr_suitcs*C1.icntHprcssion-mcihods);其中：a)HMAC-1.wsh计算Cookie时使用的密码杂潴兑法，由6.1.5.4.I中的密码套件确定.b)sccret服务端的机产生的秘密值.不针对特定的c1.ient.应定期更新。c)C1.ieniIP服务端所见客户端IP地址，即服务端收到的客户桀数据报文的源【P地址，1.1.1.1.3 ServerHeIIoiWJft该消息为服务端he1.1.。消息如果发送了He1.IoVerifyRguz消息，帐务端应在第二个Qien1.HC1.b消息CookiC验证通过后才能使用。Hc1.bVcrifyRgucst中使用的相同的板本号来发送一个ServerHdkh记录序列号从初始化开始正常递增在收到SerVerHd1.U时，客户端应验证眼务端版本号是否匹配.如果服务端收到了一个带有无效CoOkiC的C1.iCmHC1.k)消息,应将共当依无CoOkiC的QiCnIHe1.1.o消息处理,即触发新的He1.1.oVeri“Request消息.消息结构及其他处理过程应符合GB/T386362020中6.4.5.2.2的熄定.1.1.1.1.4 He1.1.oRequestjWA该消息通知客户端开始轮新的握手.消息结构定义如下IMruct(IHc1.IoRcquea>6.4.5.5 ServerCertificatejMA该消息为服务端证传消息，消息结构及处理.过程应符合GB,T38636-2O2O6.I.5.3的煤定.6.4.5.6 ServerKeyExchangeM*本消息为服务端密钥交换消息.消息结构及处理过程应符合GBJT38636-2020中6.4.5.4的规定.6.4.5.7 CertificateRequestjNA本消息为证书请求消息，消息结构及处理过程应符合GB/T38636-2020中6.4.5.S的规定，6.4.5.8 ServerHe1.1.oDonoM*我示握手过程的hdo消息阶段完成.发送完该消息后服务哨应等恃客户端的明向消息.消息结构及处理过程应符合GBjT386362020中6.4.5.6的规定.6.4.5.9 C1.ientCertificated本消息为客户福证书消息。如果服务端请求客户端证书，客户端应发送本消息,消息结构及处理过程应符合GB门38636-2020中6.1.5.7的规定.6.4.5.10 C1.ientKeyExchangeM*本消息为客户端佬钠交换消息，消息结构及处理过程应符合GB/T386362020中6.4.5.8的规定.6.4.5.11 CertificateVerWyMA本消息为证书校验消总.消息结构及处理过程应符合GBJT386362020中6.4.5.9的煤定，初始ff1.CIientHcIIo和Hc1.1.oVerifyRcqucst消息不应被包含在本消息的故字卷名的计算中.6.4.5.12 Finishedft本消息为握F油束消息,消息结构及处理过程应符合GB,叮386362020中6.4.5.10的块定.初始的CkntHenOWHc1.1.oVcrifyRcqucst浦息不庾被包含在本消息的校验数据的计算中，.5密Bm6.5.1主由胡计璋主率斜培构和计算方法应符合GBJT386362020中6.5.1的规定.6.6.2工作富胡工作青钥结构和计算方法应符合GBZT386362020中6.5.2的规定.