密评专栏丨TLCP协议概述

admin 2026-08-04 07:19:53 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文概述了TLCP协议(GB/T38636),一种基于国产密码算法的传输层安全协议。它支持SM2、SM3、SM4等算法,并采用双证书体系。文章详细介绍了握手过程、密码套件及密钥交换协议,如ECDHE和SM2。该协议旨在满足我国商用密码应用要求,为通信提供身份认证、数据加密和完整性保护。 综合评分: 75 文章分类: 技术标准,安全建设,应用安全


cover_image

密评专栏丨TLCP协议概述

创信华通

2026年7月29日 16:47 四川

在小说阅读器读本章

去阅读

TLCP(Transport Layer Cryptography Protocol,GB/T 38636)是一种基于国产密码算法体系设计的安全通信协议,其主要功能包括:

  • 通信双方身份认证;
  • 会话密钥协商;
  • 数据机密性保护;
  • 数据完整性校验;
  • 抗重放攻击保护。

TLCP在整体架构上继承了TLS协议成熟的设计思想,同时结合国产密码算法体系进行了适配和扩展,形成了一套符合我国商用密码应用要求的传输层安全协议。与 TLS 相比,TLCP最大的特点是支持SM2、SM3、SM4等国产密码算法,并引入双证书体系(签名证书和加密证书)以满足我国密码管理要求。

TLCP握手过程

Client Hello

客户端hello消息结构定义如下:

struct {
    ProtocolVersion client_version:
    Random random;
    SessionID session_id :
    CipherSuite cipher_suites(2..2^16-1) :
    CompressionMethod compression_methods(1..2^8-1);
} ClientHello;

Client Hello用于向服务端发起会话请求,client_version表示客户端支持的最高TLCP协议版本(0x0101),random 为客户端产生的随机数信息,session_id 为客户端连接使用的会话标识,cipher_suites 为客户端所支持的密码套件。

TLCP与TLS版本号对比

| | TLCP | TLS1.0 | TLS1.1 | TLS1.2 | TLS1.3 | | — | — | — | — | — | — | | 版本号 | 0x0101 | 0x0301 | 0x0302 | 0x0303 | 0x0304 |

Sever Hello

Sever Hello用于响应Client Hello的请求,server_version 表示服务端支持的最高TLCP协议版本,random 为服务端产生的随机数,session_id 为服务端连接使用的会话标识,cipher_suite 为服务端从 ClientHello 中选取的一个密码套件,compression_method 为服务端从 ClientHello 中选取的一个压缩算法。

服务端hello消息结构定义如下:

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id:
    CipherSuite cipher_suite;
    CompressionMethod compression_method
;} ServerHello;

TLCP支持的密码套件如下表所示

| 名称 | 密钥交换 | 加密 | 效验 | 值 | | — | — | — | — | — | | ECDHE_SM4_CBC_SM3 | ECDHE | SM4_CBC | SM3 | {0xe0,0x11} | | ECDHE_SM4_GCM_SM3 | ECDHE | SM4_GCM | SM3 | {0xe0,0x51} | | ECC_SM4_CBC_SM3 | ECC | SM4_CBC | SM3 | {0xe0,0x13} | | ECC_SM4_GCM_SM3 | ECC | SM4_GCM | SM3 | {0xe0,0x53} | | IBSDH_SM4_CBC_SM3 | IBSDH | SM4_CBC | SM3 | {0xe0,0x15} | | IBSDH_SM4_GCM_SM3 | IBSDH | SM4_GCM | SM3 | {0xe0,0x55} | | IBC_SM4_CBC_SM3 | IBC | SM4_CBC | SM3 | {0xe0,0x17} | | IBC_SM4_GCM_SM3 | IBC | SM4_GCM | SM3 | {0xe0,0x57} | | RSA_SM4_CBC_SM3 | RSA | SM4_CBC | SM3 | {0xe0,0x19} | | RSA_SM4_GCM_SM3 | RSA | SM4_GCM | SM3 | {0xe0,0x59} | | RSA_SM4_CBC_SHA256 | RSA | SM4_CBC | SHA256 | {0xe0,0x1c} | | RSA_SM4_GCM_SHA256 | RSA | SM4_GCM | SHA256 | {0xe0,0x5a} |

Server Certificate / Client Certificate

TLCP采用双证书体系,Certificate消息通常包含:

  1. 签名证书(Signature Certificate)
  2. 加密证书(Encryption Certificate)

签名证书用于握手签名验证;加密证书用于预主密钥加密

对于证书消息结构如下:

opaque ASN.1Cert(1..2^24-1>:
struct {
ASN.1Cert certificate<0..2^24-1>:
} Certificate:
Certificate;

IBC标识及公共参数结构:

opaque ASN.1IBCParam(1..2²-1>;struct {
&nbsp;opaque ibc_id(1..21-1);
&nbsp;ASN.1IBCParam ibc_parameter;
} Certificate;
其中:
a) ibc_id &nbsp; &nbsp; 服务端标识。
b) ibc_parameter &nbsp; &nbsp;IBC公共参数,遵循ASN.1编码。

密钥交换算法和证书密钥交换的关系如下表所示

Server Key Exchange

该消息传输信息用于客户端计算产生 48 字节的预主密钥

消息结构体如下

enum {
&nbsp; &nbsp; ECDHE,
&nbsp; &nbsp; ECC,
&nbsp; &nbsp; IBSDH,
&nbsp; &nbsp; IBC,
&nbsp; &nbsp; RSA
} KeyExchangeAlgorithm;

struct {
&nbsp; &nbsp; select (KeyExchangeAlgorithm) {

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;ECDHE:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerECDHEParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque client_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque server_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerECDHEParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } signed_params;

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;ECC:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque client_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque server_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque ASN.1Cert<1..2^24-1>;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } signed_params;

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;IBSDH:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerIBSDHParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque client_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque server_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerIBSDHParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } signed_params;

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;IBC:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerIBCParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque client_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque server_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ServerIBCParams params;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque IBCEncryptionKey[1024];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } signed_params;

&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;RSA:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque client_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque server_random[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque ASN.1Cert<1..2^24-1>;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } signed_params;
&nbsp; &nbsp; };
} ServerKeyExchange;

Certificate Request

如果服务端要求认证客户端,则发送此消息,用于让客户端发送自己的证书。

其中结构体如下:

struct {
&nbsp; &nbsp; ClientCertificateType certificate_types<1..2^8-1>;
&nbsp; &nbsp; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

certificate_authorities:如果ClientCertificateType是ibc_params,本字段的内容是IBC密管理中心的信任域名列表。否则是服务端信任的CA的证书DN列表,包括根CA或者二级CA的DN。

Server Hello Done

用于表示握手过程的 Hello 消息阶段完成

服务端hello完成消息结构如下:

struct { } ServerHelloDone;

Client Key Exchange

该消息用于传输预主密钥或者传输计算预主密钥所需的客户端密钥交换参数

消息结构体如下:

struct {
select(KeyExchangeAlgorithm){
&nbsp;case&nbsp;ECDHE:
&nbsp; opaque ClientECDHEParams(1..2^16-1):
&nbsp;case&nbsp;IBSDH :
&nbsp; opaque ClientIBSDHParams(1..2^16-1);
&nbsp;case&nbsp;ECC:
&nbsp; opaque ECCEncryptedPreMasterSecret(0..2^16–1) ;
&nbsp;case&nbsp;IBC:
&nbsp; opaque IBCEncryptedPreMasterSecret(0..2^16-1):
&nbsp;case&nbsp;RSA:
&nbsp; Opaque RSAEncryptedPreMasterSecret (0..2^16–1) :
&nbsp;} exchange_keys;
} ClientKeyExchange;

Certificate Verify

当客户端发送 Client Certificate 消息,并且该证书具有签名能力时,客户端需要发送 CertificateVerify 消息

该消息用于证明客户端确实持有其证书对应的签名私钥,从而完成客户端身份认证。客户端使用自己的签名私钥对此前所有握手消息的摘要值进行签名,服务端收到后使用客户端证书中的公钥进行验证。

证书校验消息的数据结构如下:

struct {
&nbsp;Signature signature;
} CertificateVerify;

Signature 的结构如下:

enum { rsa_sha256,rsa_sm3,
&nbsp; &nbsp; &nbsp; &nbsp; ecc_sm3,
&nbsp; &nbsp; &nbsp; &nbsp; ibs_sm3 &nbsp;SignatureAlgorithm;
struct {
&nbsp; &nbsp; select(SignatureAlgorithm)
&nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;rsa_sha256:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;opaque sha256_hash[20];
&nbsp; &nbsp; &nbsp; &nbsp; };
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;rsa_sm3:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; opaque sm3_hash[32];
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;};
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;case&nbsp;ecc_sm3://当ECC为SM2算法时,用这个套件
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;opaque sm3_hash[32];
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;case&nbsp;ibs_sm3:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;digitally-signed struct {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;opaque sm3_hash[32];
&nbsp; &nbsp; &nbsp; &nbsp; };
} Signature;

Change Cipher Spec

Change Cipher Spec 消息用于通知通信对端,

其消息内容固定为:

struct {
opaque&nbsp;type&nbsp;= 1;
} ChangeCipherSpec;

Finished

Finished 消息用于验证握手过程的完整性和双方是否成功协商出了相同的主密钥(Master Secret)。

握手结束消息数据结构如下:

struct {
opaque verify_data[12];
} Finished;

密钥交换协议:

ECDHE:

  • 工作模式为双向身份认证

  • 基于SM2密钥交换协议详见GT/T GBT 35276-2017 9.6

  • 要求服务端具有签名密钥、签名证书、加密密钥、加密证书。

  • 要求客户端具有身份认证密钥、认证证书、加密密钥、加密证书。

  • 密钥交换协议:

  • 通信双方需要相互交换数字证书。

  • 通双方使用加密密钥生成并交换EC临时公钥。

  • 根据GB/T 35276-2017 9.6 计算共享密钥,作为预主密钥。

  • 特别的服务端密钥交换使用 加密密钥对,签名密钥对仅作为验证使用。

SM2

  • 工作模式支持:单向身份认证、双向身份认证,取决于服务端配置。

  • 要求该协议需要服务端具有签名密钥、签名证书、加密密钥、加密证书。

  • 密钥交换协议:

  • 客户端生成预主密钥。

  • 客户端通过服务端加密证书的公钥加密预主密钥,发送给服务端。

  • 服务端通过加密密钥私钥解密得到预主密钥。

  • 在双向身份认证模式下:

  • 要求客户端具有身份认证密钥、认证证书。

  • 客户端发送客户端证书。

  • 客户端使用认证密钥对签名生成证书认证消息。

  • 服务端验证客户端证书以及签名值。

TCLP身份鉴别

单向身份鉴别

签名原文:客户端随机数 | 服务端随机数 | 加密证书长度 | 加密证书的hex值

双向身份鉴别

签名原文:SM3(Client Hello字节流 | Server Hello字节流 | Server Certificate字节流 | Server Key Exchange字节流 | Certificate Request字节流 | Server Hello Done字节流 | Client Certificate字节流 | Client Key Exchange字节流)

参考标准:GB/T 38636-2020《信息安全技术 传输层密码协议(TLCP)》

– END –

供稿:杨老师

编辑:小   鱼

审核:王老师

点击回顾往期精彩

创信华通斩获第四届“熵密杯”密码安全挑战赛全国三等奖

四川省密码管理局、教育厅联合主办密码应用技能公益培训,创信华通助力学子解锁“密评”新技能

网络安全漏洞通告(2026年7月)

成都创信华通信息技术有限公司

成都创信华通信息技术有限公司是川内首家同时拥有“等保”与“密评”双资质的网络安全合规检测服务商,以“等保测评+密码测评+软件测试+信息系统工程监理+数据安全服务+网络安全服务”为主的“6+N”服务模式,已成功为党的二十大、中国共产党成立100周年、北京冬奥会、第31届世界大学生运动会、第12届世界运动会等大型活动提供等保、密评、网络安全应急保障服务。

公司以“竭尽全力为国家网络安全保驾护航”为使命,凭借多年积累荣获四川省“专精特新”企业、四川省新经济100强企业、四川省数字经济100强企业、成都市网络信息安全产业影响力TOP30企业等。

期待与您的合作!


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:创信华通 《密评专栏丨TLCP协议概述》

评论:0   参与:  0