T/ZISIA 0105-2026 OS应用软件包签名／验证技术规范

ICS 35.240 CCS L 70/84

ZISIA

团体 标准

T/ZISIA 0105—2026

OS 应用软件包签名/验证技术规范

Format specification for OS application package signature files

2026-06-15 发布 2026-06-15 实施

中关村网络安全与信息化产业联盟发 布

目次

前言 III

引言 IV

1 范围 1

2 规范性引用文件 1

3 术语和定义 1

4 符号和缩略语 2

5 数据表示约定 2

6 应用软件包签名/验证 2

6.1 概述 2

6.2 CSP 存储 3

6.3 多重签名/验证 3

7 代码签名包 CSP 3

7.1 概述 3

7.2 包头(Packet Header) 3

7.3 签名版本(Signature Ver sion) 4

7.4 签名类型(Signature Type) 4

7.5 公钥算法(Public Key Algor ithm) 4

7.6 杂凑算法(Hash Algor ithm) 4

7.7 签名值(Signature Value) 4

7.8 签名证书(链)(Signature Certificate Info Set) 4

8 包内存放 CSP 方式 5

8.1 概述 5

8.2 deb 软件包签名与验证 5

8.3 rpm 软件包签名与验证 6

9 独立文件存放 CSP 方式 6

9.1 代码签名文件(CSF)格式 6

9.2 CSF 文件生成 8

9.3 签名验证 8

9.4 多重签名与验证 8

10 安全措施 8

10.1 证书管理 8

10.2 密钥安全 9

11 兼容性 9

附录 A (规范性 ) ASN.1 DER 长度编码规则 10

A.1 概述 10

A.2 编码规则 10

I

A.3 本文件中的特殊约定 10

A.4 编码示例 10

附录 B (资料性 ) 软件包签名/验签示例 11

附录 C (资料性 ) PKCS#7 SignedData 结构示例 21

C.1 ASN.1 结构示例 21

C.2 二进制编码示例 22

C.3 实现注意事项 23

C.4 Rust 实现示例 23

参考文献 28

II

前言

本文件按照GB/T 1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

本文件由中关村网络安全与信息化产业联盟提出并归口。

本文件起草单位：中关村网络安全与信息化产业联盟、麒麟软件有限公司、中科方德软件有限公司、兴唐通信科技有限公司、北京天威诚信电子商务服务有限公司、阿里云计算有限公司、长春吉大正元信息技术股份有限公司、北京三博安科技有限公司。

本文件主要起草人：张大朋、蒋杏松、王玉成、张超、郭亮、王戍靖、龚文、冯建茹、时圣亮、姚长远、王辉、王尧、李延昭、齐建新、张天佳、李世奇、何道君、王立臣、王克、胡金山、罗捷、刘海涛。

III

引言

当前，不同国产操作系统(OS)的应用软件包(如deb包、rpm包)在签名/验证方式上存在差异，应用软件跨系统互操作性受限，影响跨平台兼容性与用户信任建立。为此，需在保持现有软件包格式兼容的前提下，设计独立且可扩展的签名数据封装机制，确保不同系统间签名信息的统一解析与验证。

T/ZISIA 0101-2025 通用操作系统商用密码子系统安全轮廓【要求6.4-07】商密子系统应为宿主操作系统提供应用软件包数字签名/验证机制。本标准按照T/ZISIA 0101的要求对OS应用软件包签名数据包结构进行定义，规范特定软件包格式的签名方法以及适用于所有应用软件包的通用签名方法，为国产OS环境下各类应用软件包的签名生成与验证提供技术依据，从而提高国产OS应用软件的互操作性和软件供应链的安全性。

IV

1 范围

本文件规定了OS应用软件包签名/验证机制、代码签名包(CSP)以及代码签名文件(CSF)格式，给出软件包内存放CSP以及独立文件存放CSP的软件包签名/验证规范。

本文件适用于通用OS应用软件包签名/验证系统设计与实现。

2 规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件;不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

GB/T 16262. 1-2006 信息技术抽象语法记法一(ASN. 1)第1部分：基本记法规范

GB/T 20518-2018 信息安全技术公钥基础设施数字证书格式

GB/T 25069 信息安全技术术语

GB/T 16263. 1-2025 信息技术 ASN. 1编码规则第1部分:基本编码规则(BER)、正则编码规则(CER)

和非典型编码规则(DER)规范

GB/T 16264.8-2005 信息技术开放系统互连目录第8部分:公钥和属性证书框架GM/Z 4001-2013 密码术语

T/ZISIA 0101-2025 通用操作系统商用密码子系统安全轮廓

T/ZISIA 0103-2026 通用操作系统商用密码数字证书体系规范

IETF RFC 2315 PKCS #7: Cryptographic Message Syntax

3 术语和定义

GB/T 25069、GM/Z 4001-2013界定的术语和定义适用于本文件。

3.1

应用软件包 app lication package

包含可执行程序、库文件、配置文件等资源，用于在操作系统实现特定功能的软件集合。

3.2

ASCII 装甲格式 ASCII armor format

将二进制数据转换为可打印ASCII字符的编码格式，采用Base64编码。

3.3

证书链 certificate chain

从应用证书、中间证书到根证书的一系列证书，用于建立信任路径。

3.4

代码签名文件 code signature file CSF

将应用软件代码签名包(CSP)封装成的独立文件，用于验证软件包完整性及来源真实性。代码签名文件以".sea"为扩展名，采用ASCII装甲格式存储。

3.5

代码签名包 code signature package CSP

对应用软件包进行签名生成的数据集合，包含签名算法、签名值、证书链等相关信息，是签名/验证的基本数据单元。

3.6

deb 软件包 deb software package

以.deb为扩展名，用于Debian、Ubuntu及其衍生操作系统上进行软件分发、安装和管理的数据包。

1

3.7

多重签名 multi-signature

多个责任主体，如开发者、发行者、检测机构等，针对同一软件包分别进行签名操作，以此提升应用软件的可信度与安全性。各主体的签名过程与验证过程相互独立，互不影响。

3.8

多精度整数格式 multip le precision integer format MP I

用于存储大整数的编码格式，包含2字节长度字段(大端序)和后续的整数二进制数据(大端序)。

3.9

rpm 软件包

以.rpm为扩展名，用于Red Hat、Fedora、CentOS、openSUSE及其衍生操作系统上进行软件分发、安装和管理的数据包。

4 符号和缩略语

下列缩略语适用于本文件。

ASN. 1：抽象语法记法一(Abstract Syntax Notation One)

CA：证书认证机构(Certification Authority)

CRL：证书吊销列表(Certificate Revocation List)

CSF：代码签名文件(Code Signature File)

CSP：代码签名包(Code Signature Package)

CMS：加密消息语法(Cryptographic Message Syntax)

DER：可辨别编码规则(Distinguished Encoding Rules)

MPI：多精度整数格式(Multiple Precision Integer)

OCSP：在线证书状态协议(Online Certificate Status Protocol)

OID：对象标识符(Object Identifier)

OS：操作系统(Operating System)

PKCS：公钥密码学标准(Public Key Cryptography Standards)

RFC：征求意见稿(Request for Comments)

UTC：协调世界时(Coordinated Universal Time)

5 数据表示约定

除特别说明或算法编码格式要求之外，本文件中所有整数(包括多字节整数、长度字段等)均采用大端序(Big-Endian)表示，即最高有效字节(Most Significant Byte)在前，最低有效字节(Least Significant Byte)在后。

多精度整数(Multiple Precision Integer, MPI)采用以下格式存储：

- 前2字节：16位无符号整数，表示后续数据的比特长度(大端序);

- 后续字节：整数的二进制表示(大端序);

- 整数数据按字节对齐，不足8比特的剩余比特在最高位补0。

本文件中的可变长度编码采用ASN. 1 DER长度编码规则，详见附录A：

- 长度≤127：单字节直接编码，最高位为0，低7位表示长度;

- 长度>127：首字节最高位为1，低7位表示后续长度字节数，后续字节以大端序表示实际长度。

6 应用软件包签名/验证

6.1 概述

本文件按照T/ZISIA 0101【要求6.4-07】商密子系统应为宿主操作系统提供应用软件包数字签名/验证机制的要求规范OS应用软件包签名/验证机制。

2

OS应用软件包签名/验证机制是依托公钥密码学原理，运用数字签名技术保障软件包在分发、传输及安装过程中的完整性、真实性与可追溯性。

本文件在保持现有OS应用软件包格式兼容的前提下，设计和规范独立且可扩展的签名数据封装机制，即在应用软件发布之前，软件责任主体(开发者、发行者或检测机构等)对应用软件包实施数字签名，生成代码签名包(CSP)，当OS安装应用软件包时，对软件包对应的CSP进行验证，若验证通过，则安装运行该应用软件。

6.2 CSP 存储

可采用“包内存储 ”或“独立文件存储 ”方式对CSP进行存储。包内存储方式将CSP存储于应用软件包(如deb包、rpm包)文件中，独立文件存储方式将CSP存储于独立生成的CSF中，在进行签名验证时，依据CSP的存储方式采用不同方法对CSP进行解析与验证。

6.3 多重签名/验证

多个责任主体(如开发者、发行者或检测机构等)针对同一应用软件包进行独立签名/验证，即多重签名/验证， 以达成多方共同确认应用软件包有效性的目标，实现权责分离，进而增强软件的可信度和安全性。OS可分别对各主体的签名进行独立验证，互不影响。

系统可根据实际制定多重签名验证策略，确定多重签名验证结果处置方式，例如，只验证某个、某些、或全部主体签名。

7 代码签名包 CSP

7.1 概述

OS应用软件包CSP在签名时生成，是系统验证签名的基本数据单元。

CSP结构如表1所示：

表1 CSP结构

字段名称

长度(字节)

描述

包头(Packet Header)

10

包类型、包长度

签名版本(Signature Version)

签名格式文件版本

签名类型(Signature Type)

二进制文件签名、文本文件签名

公钥算法(Public Key Algorithm)

公钥算法标识

杂凑算法(Hash Algorithm)

杂凑算法标识

签名值(Signature Value)

可变

对应用软件包进行签名的结果

签名证书(链)(Signature Certificate Info Set)

采用PKCS#7结构封装，包含证书链、CRL等验证信息(ASN. 1 DER编码)

7.2 包头(Packet Header)

长度：10个字节。

第1字节：包类型0xC2，其二进制为1100 0010，是CSP类型的固定值。后续9字节：采用ASN. 1 DER长度编码规则表示包体长度(不含包头)。

3

7.3 签名版本(Signature Version)

长度：1字节，值为0x04，表示本文件定义的CSP格式版本为4。

7.4 签名类型(Signature Type)

长度：1字节，值定义：

0x00：二进制软件包文件签名，用于可安装的应用软件包签名;

0x10：备用，用于文本软件文件签名，如脚本文件签名。

注： 本文件定义的CSP可拓展至非应用软件包签名。

7.5 公钥算法(Public Key Algorithm)

0x01：RSA(加密和签名);

0x11：DSA(仅签名);

0x16：ECDSA(椭圆曲线数字签名算法);

0x19：SM2(椭圆曲线公钥算法);

0x22：EdDSA(Ed25519)。

7.6 杂凑算法(Hash Algorithm)

0x08：SHA - 256;

0x09：SHA - 384;

0x0A：SHA - 512;

0x0D：SHA3 - 256;

0x10：SM3。

7.7 签名值(Signature Value)

签名值是对应用软件包进行签名的结果。采用多精度整数格式MPI存储(EdDSA除外)。

长度：可变，取决于公钥算法和杂凑算法，结构如下：

- RSA 签名：签名值为单个大整数。前 2 字节为后续数据的比特长度(大端序)，后续数据为签名值整数的二进制数据(大端序表示);

- DSA 签名：连续存放 r、s 两个数据项，每个数据项前 2 字节，为后续数据的比特长度(大端序)。对于 160 位 DSA，每个数据项前 2 字节为 0x00 0xA0(160 位)，后续 20 字节为整数 r 或 s 的二进制数据;

- ECDSA 签名：结构同 DSA，长度随椭圆曲线参数确定(参见 SM2 签名);

- SM2 签名：SM2 使用 256 位曲线，r 和 s 各为 256 位(32 字节)。每个数据项前 2 字节为后续数据的比特长度(大端序)0x01 0x00(256 位)，后续 32 字节为整数 r 或 s 的二进制数据(大端序);

- EdDSA(Ed25519)签名：数据项前 2 字节为后续数据的比特长度(大端序)。

7.8 签名证书(链)(Signature Certificate Info Set)

长度：可变。

内容：签名证书链字段采用IETF RFC 2315 PKCS#7标准的SignedData结构进行封装。

签名证书(链)包含以下内容：

- 证书集合(certificates字段)：包含签名者证书，必要时可存放完整的证书链。

- CRL集合(crls字段，可选)：可包含相关证书的证书吊销列表(CRL)，CRL格式遵循X.509 CRL v2格式，包括签名证书和中间CA证书的CRL(如果可用)。

签名证书(链)采用ASN. 1 DER编码。符合以下要求：整个SignedData结构进行DER编码，编码后作为ContentInfo的content字段，ContentInfo进行DER编码，最终编码字节流存储在CSP的签名证书(链)字段中。

4

存储方式：签名证书(链)的DER编码字节流紧跟在签名值之后，按应用证书、中间证书、根证书次序存放。验证方应直接将此字节流作为完整的证书对象进行解析。

证书格式：SM2证书遵循GB/T 20518-2018规定的数字证书格式，其他算法证书(如RSA、ECDSA、 DSA)遵循X.509标准。

8 包内存放 CSP 方式

8.1 概述

在应用软件包内追加CSP的签名方式适用于deb软件包、rpm软件包等预留有签名数据段的软件包格式。

注：deb软件包、rpm 软件包是Debian、Ubuntu 等主流OS的应用软件文件，由开发者在开发结束后生成，需由OS包管理工具(如 dpkg 或 apt)解析、安装到系统中，方可运行。软件包格式参见参考文献。

8.2 deb 软件包签名与验证

8.2.1 CSP 嵌入

deb软件包的CSP通过在其文件末尾追加一个名为OSSG.sig的新字段(或称“数据段 ”)进行嵌入。 CSP符合第7章规范。

8.2.2 签名生成

deb软件包签名生成遵循以下步骤：

a) 数据提取与杂凑计算：提取目标 deb 包中 control数据段与 data 数据段的全部内容，使用杂凑算法(如 SM3)计算其杂凑值;

b) 数字签名：使用签名者私钥，采用公钥签名算法(如SM2)，对步骤 a)中得到的杂凑值进行数字签名运算，生成签名值;

c) 数据包封装：将签名值、签名者证书(链)及其他必要信息，按照第 7 章的规范组装成完整的 CSP;

d) 字段追加：将生成的 CSP，以 OSSG.sig 为字段名，追加至原 deb 包文件的末尾。

8.2.3 签名验证

deb软件包签名验证遵循以下步骤：

a) CSP 提取：从待验证的 deb 包中提取 OSSG.sig 字段的 CSP;

b) 证书验证：从 CSP 中解析出 PKCS#7 SignedData 结构，提取证书链，验证证书链的有效性、合法性及吊销状态;

c) 公钥提取与验签：从已验证合法的证书中提取软件包签名者公钥，计算 deb 包中 control 与 data数据段内容的杂凑值(如 SM3 杂凑值)，使用提取的公钥、CSP 中的签名值以及计算得到的杂凑值，执行验签运算;

d) 验证结论：若证书(链)验证与数字签名验证均成功，则判定软件包通过验签;否则，判定验签失败。

8.2.4 多重签名与验证

8.2.4.1 多重签名生成

当需对同一deb包追加多个签名主体签名时，遵循以下步骤：

a) 按第 8.2.2 条 a) 至 c) 款生成新的 CSP;

b) 检查目标 deb 包中是否已存在 OSSG.sig 字段：

若不存在，则按本标准第8.2.2条d) 款追加该字段及内容;

若已存在，则读取该字段的现有内容，在其末尾首先追加分隔符“--next ”，然后追加a)生成的CSP，最后将更新后的完整内容写回OSSG.sig字段(同时更新OSSG.sig字段数据大小)。

8.2.4.2 多重签名验证

5

对包含多重签名的deb包进行验证时，遵循以下步骤：

a) 提取 OSSG.sig 字段的全部内容;

b) 使用分隔符“--next”对字段内容进行分割，得到一个或多个独立的 CSP;

c) 对于分割得到的每一个 CSP，按第 8.2.3 条 a) 至 c) 所述流程进行验证。

8.3 rpm 软件包签名与验证

8.3.1 CSP 嵌入

将CSP嵌入rpm软件包的签名分区。在此分区中，须新增一个标签名(tag)为OSSG.sig的专用标签，用于存放符合第7章组装的CSP。

8.3.2 签名生成

rpm软件包的签名生成遵循以下步骤：

a) 数据提取与杂凑计算：读取目标 rpm 包的头部与载荷分区的全部数据，使用杂凑算法(如 SM3)计算其杂凑值;

b) 数字签名：使用签名者私钥，采用公钥签名算法(如 SM2)，对步骤 a)得到的杂凑值进行数字签名运算，生成签名值;

d) 标签写入：将生成的 CSP 以 OSSG.sig 为标签名，写入 rpm 文件的签名分区。

8.3.3 签名验证

rpm软件包签名验证遵循以下步骤：

a) CSP 提取：从待验证 rpm 包的签名分区中，读取 tag 为 OSSG.sig 的标签，获得 CSP;

b) 证书验证：从 CSP 中解析出 PKCS#7 SignedData 结构，提取证书链和 CRL 信息，验证证书链的有效性、合法性及吊销状态;

c) 公钥提取与验签：从已验证合法的软件包签名者证书中提取公钥，计算 rpm 包中头部与载荷分区数据的杂凑值，使用提取的公钥、CSP 中的签名值以及计算得到的杂凑值，使用公钥算法(如 SM2)执行验签运算;

d) 验证结论：若证书验证(链)与数字签名验证均成功，则判定软件包通过验签，否则，判定验签失败。

8.3.4 多重签名处理

8.3.4.1 多重签名生成

当需对同一rpm包追加多个签名时，遵循以下步骤：

a) 按第 8.3.2 条 a) 至 c) 款生成新的 CSP;

b) 检查目标 rpm 包的签名分区内是否已存在tag 为 OSSG.sig 标签：

若不存在，则按第8.3.2条 d) 款创建该标签并写入内容;

若已存在，则读取该标签的现有内容，在其末尾首先追加分隔符“--next ”，然后追加新生成的CSP，最后将更新后的完整内容写回OSSG.sig标签(同时更新OSSG.sig标签数据大小)。

8.3.4.2 多重签名验证

对包含多重签名的rpm包进行验证应遵循以下步骤：

a) 从签名分区读取 OSSG.sig 标签的全部内容;

b) 使用分隔符“--next ”对标签内容进行分割，得到一个或多个独立的CSP;

c) 对于分割得到的每一个 CSP，按本标准第 8.3.3 条 a) 至 c) 所述流程进行验证。

9 独立文件存放 CSP 方式

9.1 代码签名文件(CSF)格式

6

CSF格式适应于所有应用软件包签名/验证。

CSF(扩展名为.sea)是对应用软件包签名后生成的文件，依据.sea文件格式对应用软件包进行签名验证。

9.1.1 文件名命名

CSF文件命名中应包括被签名的应用软件包完整文件名(含文件扩展名)，CSF文件命名格式如下：

<软件包文件名>_<主体角色标识符>_<时间戳>.sea

各字段定义如下：

- <软件包文件名>：被签名的应用软件包完整文件名，包括扩展名。

例如，应用软件包文件名为example_app_v1.0.tar.gz，则CSF文件名此部分为

"example_app_v1.0.tar.gz"。

- <主体标识符>： 由 5 位字符组成，表示不同类别的签名主体，取值如下：

a) deveX：软件包开发者，X 取值 0-9 代表不同开发者;

b) issuX：软件包发行者，X 取值 0-9 代表不同发行者;

c) testX：软件包检测机构，X 取值 0-9 代表不同检测机构;

d) reguX：软件包监管者，X 取值 0-9 代表不同监管者;

e) otheX：其他责任主体，X 取值 0-9 代表不同主体。

- <时间戳>：14 位数字，格式为 YYYYMMDDHHMMSS，表示签名生成时间(UTC 时间)。其中：

- YYYY：4位年份

- MM：2位月份(01- 12)

- DD：2位日期(01-31)

- HH：2位小时(00-23)

- MM：2位分钟(00-59)

- SS：2位秒钟(00-59)

文件名各部分之间以下划线“_ ”分隔。

命名示例：

软件包原文件名：example_app_v1.0.tar.gz

不同主体签名生成的CSF文件名：

- example_app_v1.0.tar.gz_test1_20250102110000.sea

- example_app_v1.0.tar.gz_test2_20250102120000.sea

- example_app_v1.0.tar.gz_regu1_20250103154530.sea

注：同一软件包可由多个主体在不同时间进行签名，每个签名生成独立的.sea文件。

9.1.2 文件名长度限制

考虑到不同操作系统的文件名长度限制，建议：

a) 软件包文件名不应超过 128 字符;

b) 完整.sea 文件名(含扩展名)不应超过 255 字符;

9.1.3 CSF 总体结构

CSF文件由文件头和CSP构成，以ASCII装甲格式存储。

ASCII 装甲格式：将文件头与 CSP 的二进制数据进行 Base64 编码，编码后在数据前添加文件起始标识：

“-----BEGIN OS CODE SIGNATURE-----”，

在数据后添加文件尾标识：

“-----END OS CODE SIGNATURE-----”。

CSF文件ASCII装甲格式总结构如表2。

表 2 CSF 总体结构

文件域

7

头标识

-----BEGIN OS CODE SIGNATURE-----

文件头

包含文件标识魔数、文件格式版本号、注释和保留字段等域

CSP

第 7 章组装的 CSP

尾标识

-----END OS CODE SIGNATURE-----

9.1.4 文件头

CSF的文件头由文件标识魔数、文件格式版本号、注释和保留字段四个域组成，如表3所示：

表 3 文件头结构表

文件标识魔数

固定值 0x4F535347(“OSSG”ASCII 码)，OS应用软件包 CSF 的标识

文件格式版本号

当前签名文件(.sea)格式版本，如代码签名工具版本。ASCII 编码格式存储，以换行符(\n 或\r\n)结束。

注释

维护者信息，如签名工具、OS 厂家信息。 utf-8编码格式存储，以换行符(\n 或\r\n)结束。

保留字段

预留，暂未使用，填充为 0

文件头与CSP之间以空行(连续两个换行符)分隔。

9.2 CSF 文件生成

CSF文件生成应遵循以下步骤：

a) 生成 CSP：按第 8 章生成 CSP;

b) CSF 生成：按照 9. 1 条格式要求，组合文件头和 CSP，生成.sea 签名文件。

9.3 签名验证

CSF文件验证应遵循以下步骤：

a) 读取.sea 文件：解析.sea 文件，提取 CSP;

b) 按第 8.2.3 条 a) 至 d) 所述流程进行验证。

9.4 多重签名与验证

9.4.1 CSF 文件生成

当多个主体对同一软件包进行签名时，每个签名按照9. 1、9.2条生成相应的CSF( .sea)。

9.4.2 签名验证

可按照9.3条分别对每个CSF进行验证。

10 安全措施

10.1 证书管理

8

a) OS 应用软件包签名证书遵照 T/ZISIA 0103-2026 8.5 规范管理;

b) OS 应及时更新 CRL;

c) 应用软件包签名验证时，应使用系统最新的CRL 验证证书是否被吊销;

d) 验证应用软件包签名证书链，应确保根证书是系统授信的根证书。

10.2 密钥安全

应使用国家密码管理部门检测认证的密码产品进行软件包签名私钥的生成、存储和使用，确保私钥不被非授权访问或泄露。

11 兼容性

本文件兼容性：

- 保持向后兼容：支持旧版本签名格式验证，新格式不破坏现有验证系统。

- 跨平台兼容：确保签名验证在不同平台的一致性，包括字节序处理规范和字符编码统一。

9

附录 A

(规范性)

ASN.1 DER 长度编码规则

A.1 概述

本附录详细说明ASN. 1 DER长度编码规则在本文件中的应用。

A.2 编码规则

长度字段编码分为短格式和长格式两种：

1. 短格式(长度≤127)：

- 单字节编码

- 最高位(比特7)为0

- 低7位(比特6-0)表示长度值

- 示例：长度50编码为0x32

2. 长格式(长度>127)：

- 首字节最高位(比特7)为1，低7位表示后续长度字节数N

- N的范围为1- 127(实际应用中N通常为1-4)

- 后续N个字节以大端序表示实际长度

- 示例：长度500(0x01F4)编码为：

首字节：0x82(表示2个长度字节)

后续：0x01, 0xF4

A.3 本文件中的特殊约定

在本文件中，为保持包头固定10字节长度，对长度编码做以下特殊约定：

1. 长度字段占用固定8字节u int64

2. 实际编码后，未使用的字节填充0x00

3. 长度值不得使用超过8个字节表示(即N≤8)

A.4 编码示例

表A.1 长度编码示例

实际长度

16 进制值(示例)

说明

0

00 00 00 00 00 00 00 00 00

短格式，全填充

50

32 00 00 00 00 00 00 00 00

短格式 0x32，后填充

128

81 80 00 00 00 00 00 00 00

长格式，N= 1，长度 0x80

255

81 FF 00 00 00 00 00 00 00

长格式，N= 1，长度 0xFF

256

82 01 00 00 00 00 00 00 00

长格式，N=2，长度 0x0100

65535

82 FF FF 00 00 00 00 00 00

长格式，N=2，长度 0xFFFF

65536

83 01 00 00 00 00 00 00 00

长格式，N=3，长度 0x010000

16777215

83 FF FF FF 00 00 00 00 00

长格式，N=3，长度 0xFFFFFF

500

82 01 F4 00 00 00 00 00 00

长格式，N=2，长度 0x01F4

附录 B

(资料性)

软件包签名/验签示例

本附录给出一个Rust示例，有两个应用软件责任主体(开发者和检测机构)使用 SM2/SM3 算法对同一软件包进行签名和验证的过程。实际应用中，私钥的存储和管理需遵循严格的安全规范，证书的签发也应通过合法的CA机构进行，以确保签名和验证过程的安全性和可靠性。

Rust的标准库不支持SM2，使用第三方库，如sm-crypto。

所需依赖(Cargo.toml)

[package]

name = "os_package_signing"

version = "0. 1.0"

edition = "2021"

[dependencies]

serde = { version = " 1.0", features = ["derive"] }

bincode = " 1.3"

base64 = "0.21"

chrono = "0.4"

sm-crypto = "0.6" # SM2/SM3 实现(示例)

x509-parser = "0.15" # 证书解析

实现代码示例：

use std::fs:: {self, File};

use std::io::{Read, Write};

use std::path::Path;

use base64::{Engine as _, engine::general_purpose::STANDARD as BASE64};

use chrono::Utc;

use serde::{Deserialize, Serialize};

use anyhow::{Result, anyhow};

// 假设我们使用 sm-crypto 库进行商密算法操作

// 这里用伪代码表示，实际需要替换为真正的商密库

mod sm_crypto {

pub fn sm3_hash(data: &[u8]) -> Vec { // 实际调用 SM3 实现

vec![0u8; 32] // SM3 输出 32 字节

}

pub fn sm2_sign(hash: &[u8], private_key: &[u8]) -> Vec { // 实际调用 SM2 签名实现

// SM2 签名结果为 (r, s) 各 32 字节

let mut signature = vec![0u8; 64];

signature[..32].copy_from_slice(b"r_value_placeholder_32_bytes");

signature[32..].copy_from_slice(b"s_value_placeholder_32_bytes");

signature }

pub fn sm2_verify(hash: &[u8], signature: &[u8], public_key: &[u8]) -> bool { // 实际调用 SM2 验签实现

signature.len() == 64 // 简单验证

11

// 定义 CSP 结构

#[derive(Debug, Serialize, Deserialize)]

pub struct CodeSignaturePackage { packet_header: PacketHeader, signature_version: u8,

signature_type: u8,

public_key_algorithm: u8, hash_algorithm: u8,

signature_value: Vec, // MPI 格式的签名值

certificate_data: Vec, // PKCS#7 结构(简化表示)

pub struct PacketHeader {

packet_type: u8, // 0xC2

body_length: [u8; 9], // ASN. 1 DER 编码的长度 }

// 主体标识符

#[derive(Debug, Clone, Copy)] pub enum SubjectIdentifier {

Developer(u8), // deveX, X = 0-9

TestingOrg(u8), // testX, X = 0-9 }

impl SubjectIdentifier {

fn to_string(&self) -> String {

match self {

SubjectIdentifier::Developer(x) => format!("deve{}", x),

SubjectIdentifier::TestingOrg(x) => format!("test{}", x), }

fn from_str(s: &str) -> Result {

if s.starts_with("deve") && s.len() == 5 {

let x = s[4..5].parse::()?;

if x <= 9 {

Ok(SubjectIdentifier::Developer(x)) } else {

Err(anyhow!("Invalid developer identifier")) }

} else if s.starts_with("test") && s.len() == 5 {

Ok(SubjectIdentifier::TestingOrg(x)) } else {

Err(anyhow!("Invalid testing organization identifier")) }

} else {

Err(anyhow!("Invalid subject identifier")) }

// 软件包签名器

12

pub struct PackageSigner {

subject_id: SubjectIdentifier,

private_key: Vec, // SM2 私钥

certificate: Vec, // X.509 证书(简化表示) }

impl PackageSigner {

pub fn new(subject_id: SubjectIdentifier, private_key: Vec, certificate: Vec) -> Self {

PackageSigner { subject_id, private_key, certificate,