2026-10-18 08:44:31 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

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消息通常包含：

签名证书（Signature Certificate）
加密证书（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 {
 opaque ibc_id(1..21-1);
 ASN.1IBCParam ibc_parameter;
} Certificate;
其中：
a) ibc_id     服务端标识。
b) ibc_parameter    IBC公共参数，遵循ASN.1编码。

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

Server Key Exchange

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

消息结构体如下

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

struct {
    select (KeyExchangeAlgorithm) {

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

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

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

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

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

Certificate Request

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

其中结构体如下：

struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    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）{
 case ECDHE:
  opaque ClientECDHEParams(1..2^16-1):
 case IBSDH :
  opaque ClientIBSDHParams(1..2^16-1);
 case ECC:
  opaque ECCEncryptedPreMasterSecret(0..2^16–1) ;
 case IBC:
  opaque IBCEncryptedPreMasterSecret(0..2^16-1):
 case RSA:
  Opaque RSAEncryptedPreMasterSecret (0..2^16–1) :
 } exchange_keys;
} ClientKeyExchange;

Certificate Verify

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

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

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

struct {
 Signature signature;
} CertificateVerify;

Signature 的结构如下：

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

Change Cipher Spec

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

其消息内容固定为：

struct {
opaque type = 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值

双向身份鉴别

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

- END -

供稿：杨老师

编辑：小鱼

审核：王老师

点击回顾往期精彩

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

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

网络安全漏洞通告（2026年7月）

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

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

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

期待与您的合作！