數(shù)據(jù)報(bào)傳輸層密碼協(xié)議規(guī)范國家密碼管理局發(fā)布I 1 1 14縮略語 1 1 1 2 2 3 36.2數(shù)據(jù)類型定義 36.3記錄層協(xié)議 36.4握手協(xié)議族 66.5密鑰計(jì)算 Ⅲ本文件按照GB/T1.1—2020《標(biāo)準(zhǔn)化工作導(dǎo)則第1部分：標(biāo)準(zhǔn)化文件的結(jié)構(gòu)和起草規(guī)則》的規(guī)定起草。請(qǐng)注意本文件的某些內(nèi)容可能涉及專利。本文件的發(fā)布機(jī)構(gòu)不承擔(dān)識(shí)別專利的責(zé)任。本文件由密碼行業(yè)標(biāo)準(zhǔn)化技術(shù)委員會(huì)提出并歸口。本文件起草單位：中電科網(wǎng)絡(luò)安全科技股份有限公司、四川大學(xué)、格爾軟件股份有限公司、北京信安世紀(jì)科技股份有限公司、山東得安信息技術(shù)有限公司、北京海泰方圓科技股份有限公司、興唐通信科技有限公司。1數(shù)據(jù)報(bào)傳輸層密碼協(xié)議規(guī)范本文件規(guī)定了數(shù)據(jù)報(bào)傳輸層密碼協(xié)議，包括記錄層協(xié)議、握手協(xié)議族和密鑰計(jì)算。本文件適用于數(shù)據(jù)報(bào)傳輸層密碼協(xié)議相關(guān)產(chǎn)品(如網(wǎng)關(guān)、終端等)的研制、檢測、管理和使用。2規(guī)范性引用文件下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。GB/T38636—2020信息安全技術(shù)傳輸層密碼協(xié)議(TLCP)GM/Z4001密碼術(shù)語3術(shù)語和定義GM/Z4001界定的以及下列水語和定義用于本文件通信的源節(jié)點(diǎn)和目的節(jié)點(diǎn)之間的路徑上的任一通信鏈路所能文持的鏈路最大傳輸單元(MTU)的最小值。無連接的傳輸協(xié)議，為應(yīng)用程序提供一種無需建立連接就能發(fā)送封裝的IP數(shù)據(jù)包的方法。4縮略語下列縮略語適用于本文件。AEAD:帶關(guān)聯(lián)數(shù)據(jù)的可鑒別加密(Authenticated-BneryptionwithAssociatedData)DTLCP:數(shù)據(jù)報(bào)傳輸層密碼協(xié)議(DatagramTransportLayerCryptographyProtocol)MAC:消息鑒別碼(MessageAuthenticationCodes)PMTU:路徑最大傳輸單元(PathMaximumTransmissionUnit)UDP:用戶數(shù)據(jù)報(bào)協(xié)議(UserDatagramProtocol)5密碼算法和密鑰種類DTLCP在傳輸層密碼協(xié)議(TLCP)的基礎(chǔ)上針對(duì)用戶數(shù)據(jù)報(bào)協(xié)議的特點(diǎn)進(jìn)行改進(jìn)，采用密碼技術(shù)為使用UDP協(xié)議的兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)的完整性。協(xié)議用到的密碼算法包含非對(duì)稱23通過記錄層協(xié)議消息進(jìn)行傳輸?shù)膮f(xié)議類型包括握手協(xié)議族和應(yīng)用數(shù)據(jù)DTLCP消息記錄的開始，DTLCP消息記錄不能跨UDP報(bào)文傳輸。位于同一個(gè)UDP報(bào)文的多個(gè)ProtocolVersionversion;4opaquefragment[DTLSPlaintext.lengthchange_cipher_spec(20),alert(21),hauint8major=0x01,DTLCP使用顯式序列號(hào)，位于記錄中的sequence_number域。對(duì)于每個(gè)epoch,sequence_number序列號(hào)都單獨(dú)維護(hù)，每個(gè)epoch對(duì)應(yīng)的sequence_number都初始化為0且在每次發(fā)送一個(gè)DTLCP記錄層數(shù)據(jù)報(bào)文時(shí)單調(diào)遞增。每個(gè)epoch初始化為0且在每次發(fā)送一個(gè)密碼規(guī)格變更5告一個(gè)decompressionfailProtocolVersionversion;uint48sequence_number;opaquefragment[DTLSCo以字節(jié)為單位的DTLSCompressed.fragment長度，小于或等于2?+1024。ProtocolVersionversion;uint16length;caseblock:GenericBlockCipher;6HMAC_hash(write_MAC_secret,DTLSCompressed.epoch+DTLSCompressed.sequence_nber+DTLSCompressed.type+DTLSCompressed.version+DTLSCompressed.length客戶端為client_write_MAC_secret,服務(wù)端為ser別數(shù)據(jù)(additional_data)定義中的64位序列號(hào)由epoch+additional_data=DTLSCompressed.epoch+DTLSCompressed.sequence_numbeCompressed.type+DTLSCompressed.version+DTLSCompressed.length。7應(yīng)符合GB/T38636—2020中6.4.3的規(guī)定。握手協(xié)議應(yīng)符合GB/T38636—2020中6.4.4的規(guī)定，涉及以d)使用預(yù)主密鑰和交換的隨機(jī)數(shù)生成主密鑰；無狀態(tài)cookie技術(shù)。當(dāng)客戶端發(fā)送它的ClientHello消息給服務(wù)端時(shí)，服務(wù)端用HelloVerifyRequesttHello消息。然后服務(wù)端驗(yàn)證cookie,僅當(dāng)cookie有效時(shí)才能繼續(xù)進(jìn)行握手處理。這個(gè)機(jī)制強(qiáng)迫攻擊可選的。服務(wù)端接收到攜帶無效cookie的ClientHello理。當(dāng)使用無狀態(tài)cookie和HelloVerifyRequest消息時(shí)，后續(xù)的CertificateVerify消息的哈希運(yùn)算和Finished消息的校驗(yàn)數(shù)據(jù)計(jì)算中不包含HelloVerifyRequest消息和最初的Clien握手消息流程如圖1所示，屬于同一輪的消息既可放在同一個(gè)UDP報(bào)文中也可分開在不同的注：*表示可選或依賴于上下文關(guān)系的消息，不是每次都發(fā)送。[]不屬于握手協(xié)議消息。8不使用無狀態(tài)cookie和HelloVerifyRequest消息的會(huì)話重用過程應(yīng)符合GB/T38636—2020中服務(wù)端第1輪消息第2輪消息第3輪消息第4輪消息第5輪消息9client_hello(1),servehello_verify_requestcertificate(11),server_key_ecertificate_request(13),server_helcertificate_verify(15),client_key_消息的message_seq與next_receive_seq計(jì)數(shù)器相同時(shí)，next_receive_seq計(jì)數(shù)器加1并處理握手消圖3所示。equest。當(dāng)客戶端收到一個(gè)HelloRequest時(shí)，客戶端應(yīng)從FINISHED狀態(tài)轉(zhuǎn)換到發(fā)送HelloRequest發(fā)送HelloRequest消息或接受HelloRequest消息并發(fā)送ClientHello消息PREPARPREPARNGProtocolVersionclient_vRandomrandom;CompressionMethodcompression_methods(1..2^8-1);發(fā)送第一個(gè)ClientHello消息時(shí)，cookie域應(yīng)留空(0長度)。當(dāng)響應(yīng)一個(gè)HelloVerifyRequest服務(wù)端應(yīng)使用這些值來生成cookie,并使用收到的cookieDTLCP支持的密碼套件列表應(yīng)符合GB/T38636—2020中6.4.5.2.1的規(guī)定。ProtocolXersionserveropaquecookie0..2-8-1>;}該字段表示服務(wù)端支持的協(xié)議版本。本文件的版本號(hào)是上上密碼套件壓縮算法)來生成coolac并使用收的coo來驗(yàn)證這些值是否正確。DTLCP服務(wù)端的cookie生成方戴應(yīng)為無狀態(tài)，能在服務(wù)端不何c狀態(tài)的情況下驗(yàn)證cookie。為了避免序列cookid=HMAC_hasbcseetcchc比ClientHIcllo該消息為服務(wù)端hello消息。如果發(fā)送了HelloVerifyRequest消息，服務(wù)端應(yīng)在第二個(gè)ClientHello消息cookie驗(yàn)證通過