企业官网建设流程全解析

摘要

CC:2022 Part 1 第 8 章Tailoring Security Requirements（裁剪安全需求）回答的是一个极为务实的工程问题：CC Part 2/Part 3 里的安全功能组件（SFR）与安全保障组件（SAR）都是"通用模板"，厂商不能原样照抄进 ST，必须按自家产品的安全策略做合法的裁剪。第 8 章规定了裁剪的唯一合法手段——四种操作（Operations），以及裁剪后如何保证需求自洽完整——组件间依赖（Dependencies）。

对安全芯片团队而言，这一章是"读懂 ST 里每一个方括号"的钥匙：FCS_COP.1里[assignment: 密码算法]该填什么、FCS_RNG.1里[selection: physical, hybrid physical, hybrid deterministic]该选什么、为什么同一个组件会出现FCS_COP.1(1)/FCS_COP.1(2)两个实例——全部由第 8 章给出规则。

一、第 8 章规范原文解读

1.1 总述：组件的两种使用方式

CC 的功能/保证组件有两种使用方式：

1. 原样使用（exactly as defined）；
2. 通过允许的操作进行裁剪（tailored through permitted operations）。

四种允许的操作（原文定义）：

关键约束：赋值与选择仅允许在组件明确标注处执行；迭代与细化允许用于所有组件。使用操作时，作者须注意"依赖本需求的其它需求"的依赖仍被满足。

1.2 8.1.1 迭代（Iteration）

• 通过"包含基于同一组件的多个需求"实现；每次迭代必须与其它迭代不同（通过不同方式完成赋值/选择，或施加不同细化）。
• 不同迭代应唯一标识，以支持清晰的论证与双向追踪。
• 迭代 vs 赋值范围的权衡：有时可用"赋值一个范围/列表"替代迭代。作者应依据"需要为整个范围提供一个整体论证，还是为每个值单独论证"以及"是否需要单独追踪每个值"来选择更合适的方式。

1.3 8.1.2 赋值（Assignment）

赋值发生在组件元素含"作者可设置的参数"时，参数可以是不受限变量，也可以是"把变量收窄到特定值域"的规则。

• PP 作者有四种处理：a) 留空；b) 完成；c) 缩小范围（进一步限制允许值域）；d) 转为选择。
• ST 作者必须完成赋值（仅对应 b）；a/c/d 对 ST 不允许。
• 完成/缩小/转选择所选值必须符合赋值指示的类型；以集合完成时（如主体集合）可用"所有主体 / 所有类型 X 的主体 / 除主体 a 外的所有主体"等可明确推导的集合描述。

1.4 8.1.3 选择（Selection）

选择发生在组件元素需要"从若干项中做出选择"时。

• PP 作者有三种处理：a) 留空；b) 完成（选一项或多项）；c) 限制（删除部分选项，保留两项及以上）。
• ST 作者必须完成选择（仅对应 b）；a/c 对 ST 不允许。
• 所选项必须取自提供的列表。

1.5 8.1.4 细化（Refinement）

细化可用于每一条需求，通过"改动该需求"实现。

• 第一规则（更严格性）：满足细化需求的 TOE 也满足未细化需求，否则视为扩展需求。
• 例外（范围收窄）：允许细化到仅适用于部分主体/客体/操作/安全属性/外部实体；但不适用于声明符合的 PP 中的 SFR。
• 合法细化示例：纯编辑性改动（提升可读性/修正语法）；不改变需求范围、仅因 PP/ST 语境而收窄的改动。

1.6 8.2 组件间依赖（Dependencies）

• 依赖产生于"组件不自足，需依赖另一组件"；依赖可存在于功能组件之间、保证组件之间、以及功能组件与保证组件之间。
• 为确保 TOE 需求完整，纳入组件时应满足依赖。
• 三种处理方式（PP/ST 包含基于组件 A 的需求、且 A 依赖 B 时，必须含其一）：a) 基于 B 的需求；b) 层级高于 B 的组件的需求；c) 论证为何不含 B。
• 方式 c 的论证应说明：该依赖不必要/无价值；或已由运行环境处理（需描述运行环境安全目标如何覆盖）；或已由其它 SFR 以某种方式承接。
• 隐含满足需求（Implicitly Satisfied Requirements）：允许以附录表格声明被省略需求及"为何被满足"的理由（常见于用扩展组件替换标准依赖组件的场景）。

二、安全算法设计视角：操作即"算法选型"的规范落点

核心观点：CC 的"算法中立"并非"不关心算法"，而是把算法选择这一动作，精确地放到了赋值/选择操作这个合规槽位上。SOG-IS 密码评估方案（《Agreed Cryptographic Mechanisms》v1.3）则给出了"槽位里允许填什么"的候选值域与推荐清单——两者一"形"一"实"，共同约束算法选型。

2.1 FCS_COP.1：算法通过"赋值"落地

密码运算组件的标准形态是（示意）：

FCS_COP.1.1TSF 应依据[assignment: 密码算法]与密钥长度[assignment: 密钥长度]，执行[assignment: 密码运算列表]。

三个赋值槽分别对应算法设计的三个决策点：用什么算法、多长密钥、哪些运算（加解密/签名/MAC/哈希/密钥协商）。这正是 CC “实现无关"哲学的落点——标准本身不写死 AES/RSA/ECC，而是留给 ST 作者在赋值槽里填，而 SOG-IS 方案决定了这个槽能填的"合格候选”。

2.2 SOG-IS 的 R/L 分类：为"选择"提供候选域

SOG-IS《Agreed Cryptographic Mechanisms》用两类标签管理算法生命周期：

• R（Recommended，推荐）：当前应优先选用；
• L（Legacy，遗留）：标注有效期，如L[2025]、L[2030+]（默认遗留有效期为 L[2030+]）。

这意味着：算法的"赋值候选集"是随时间动态收窄的。例如 2048-bit MODP/FFDHE 组在 v1.3 中已被降级为 Legacy（L[2025]），3072-bit 及以上仍为 R。安全芯片团队在 ST 完成FCS_COP.1赋值时，必须对照当期 SOG-IS 清单：新系统应选 R 类算法与密钥长度，选用 L 类须以"向后兼容"为由给出正当性论证——这本身就是第 8 章"值须符合赋值指示类型 + 偏离须论证"的规则在算法域的实例化。

2.3 安全等级与密钥长度映射（赋值的"值域规则"）

SOG-IS 以 bit 数表达安全等级（攻击所需操作数取以 2 为底的对数）：

• 对称：128 / 192 / 256 bit，与密钥长度直接对应；
• 非对称：密钥/参数长度与安全等级的关系非线性，须按 RSA / FF-DLOG / EC-DLOG 分别映射，且非对称私钥的熵不得低于可接受对称密钥长度。

这是[assignment: 密钥长度]的"值域合法性"判据：填 3072-bit RSA、P-256 等，须满足对应的安全等级目标。

2.4 量子抗性：hybrid 方案进入赋值域

SOG-IS 明确建议：对需长期保护的数据，应结合"一个已认可机制 + 一个候选量子抗性机制"的hybrid（混合）方案，以抵御经典攻击并预留抗量子迁移路径。这直接进入 ST 的赋值内容——FCS_COP.1的算法槽可能出现"经典 + PQC 混合"的赋值。

2.5 随机源的"选择"操作（安全算法设计的关键实例）

SOG-IS 第 7 章将随机生成器分为：True Random Source（真随机源）/ DRBG（确定性随机比特生成器）/ 带特定分布的 RNG三类。这与安全芯片 PP 中FCS_RNG.1的[selection: physical, hybrid physical, hybrid deterministic]（物理 / 混合物理 / 混合确定性）完全对应——随机源的选型是 CC 中"选择"操作的直接应用：TRNG 架构（纯物理、物理+确定性后处理、混合）由 ST 作者在 selection 槽中择一，评估即按所选项验证。

三、安全芯片设计视角：操作是"PP 裁剪到具体芯片"的工具

核心观点：安全芯片 PP（如 BSI 认证的 Security IC Platform PP v2.0，即 PP0084-V2）本身就是第 8 章操作的工业级范本——它把通用 SFR 通过选择/赋值裁剪到"安全 IC"这一类 TOE，厂商再在 ST 中进一步裁剪到"某一颗芯片"。读懂 PP 里的每个方括号，就是读懂芯片安全架构需求的出处。

3.1 教科书实例：PP0084-V2 的 FCS_RNG.1

PP0084-V2 原文（6.1.6 随机数）：

FCS_RNG.1.1The TSF shall provide a[selection: physical, hybrid physical, hybrid deterministic]random number generator that implements:[assignment: list of security capabilities].

FCS_RNG.1.2The TSF shall provide[selection: bits, octets of bits, numbers [assignment: format of the numbers]]that meet[assignment: a defined quality metric].

这段真实文本几乎涵盖了第 8 章的全部操作类型：选择（RNG 类型、输出形态）、赋值（安全能力列表、数字格式、质量指标）、甚至嵌套（selection 内含 assignment）。对芯片设计团队的直接含义：

• 选physical→ 必须设计纯物理熵源（热噪声/振荡器抖动）并证明其熵质量；
• 选hybrid physical→ 物理熵源 + 后处理（如 SHA 压缩）的组合；
• [assignment: 质量指标]→ 须填入 AIS 20/31 或 NIST SP 800-90 系列的可量化指标，并接受评估方核验。

结论：RTL 阶段就要为"选择/赋值"预留电路与面积预算——熵源、后处理、在线自检（online test）都是 FCS_RNG.1 赋值后的硬性落地项。

3.2 芯片 SFR 的五大分类与裁剪

PP0084-V2 把安全 IC 的 SFR 归为五类（6.1.2–6.1.6），每一类都是通过操作裁剪后的结果：

细化的芯片落地：例如FPT_FLS.1（失效保安全）在芯片 PP 中被细化为"在电压/频率/温度超出技术极限但仍在降额范围内时，保持安全状态"——这正是第 8 章"细化=更严格 + 明确适用范围"的典型：通用组件被细化到具体的工作条件矩形（Figure 14 的内外虚线框）。

3.3 功能包（Functional Packages）与迭代/选择

PP0084-V2 提供多个功能包（Functional Packages）（如 Package Authentication of the Security IC、Package Loader、Package Cryptographic Services、Package Address-based Access Control）。功能包本质上是"可选增强"的集合，其纳入与否由 ST 作者选择；当同一类密码服务需支持多种机制时，用迭代生成多个FCS_COP.1实例。这解释了芯片里"基平台 + 可选模块"的 SoC 集成思路在 CC 需求层的对应物。

3.4 生命周期与依赖的芯片意义

PP0084-V2 将复合产品生命周期划分为 7 阶段（IC 嵌入式软件开发 → IC 开发 → IC 制造 → IC 封装 → 复合产品集成 → 个人化 → 运行使用）。依赖关系（8.2）在这里的现实含义是：芯片级认证的 SFR 依赖，必须在芯片 TOE 内自洽，而不能甩给应用层——例如 FCS_RNG.1 若依赖 FPT_TST.1（自检），则自检电路必须在芯片内实现，否则需按方式 c 论证"由运行环境承接"（这通常不被安全芯片 PP 接受）。

四、软件 COS 设计视角：把"已完成的操作"变成代码

核心观点：COS 是"芯片专用软件"（IC Dedicated Software），是把 ST 中已经完成赋值/选择/细化/迭代的 SFR翻译成可执行逻辑的载体。第 8 章对 COS 工程师的价值在于：ST 里每一个已完成的操作，都对应一段必须实现、且必须能被测试命中的代码。

4.1 赋值 → COS 的"硬参数"

ST 中已完成的赋值是 COS 的不可妥协参数。典型实例如FIA_AFL.1（鉴别失败处理），CC 原文示例：

FIA_AFL.1.1TSF 应检测[assignment: 4 到 9 之间的正整数]次失败鉴别尝试……

COS 落地：失败计数器的上限值直接取自该赋值（如 8 次），超过即锁定/拒绝——这是 PIN 暴力破解防护（对应侧信道之外的应用层攻击）的源头约束。COS 工程师应建立"SFR 赋值 → 常量/宏/配置项"的映射表，保证代码参数与 ST 严格一致，避免"代码写 5 次、ST 写 8 次"的评估失配。

4.2 迭代 → COS 的多算法驱动

FCS_COP.1(1)= AES-128、FCS_COP.1(2)= RSA-2048、FCS_COP.1(3)= ECC P-256——迭代操作在 COS 层的直接产物是"密码引擎的分发表"：

crypto_dispatch(alg_id, op) { switch (alg_id) { case ALG_AES128: return aes_masked(...); // FCS_COP.1(1) case ALG_RSA2048: return rsa_crt(...); // FCS_COP.1(2) case ALG_ECC_P256: return ecc_scalar_mult(...); // FCS_COP.1(3) } }

每个迭代实例都必须独立实现、独立测试——不能"测了 AES 就认为 RSA 也覆盖了"。这是第 8 章"不同迭代应唯一标识、单独追踪"在实现与测试层的落地。

4.3 依赖 → COS 的"配套功能不可省"

FIA_UAU.1（鉴别）依赖FIA_UID.1（标识）——COS 必须先完成"标识"（获得外部实体身份）才能"鉴别"（验证 PIN/密钥）。若 COS 只实现鉴别、跳过标识，则该依赖被破坏，ST 需求不完整。同理，FCS_RNG.1依赖自检/故障安全（FPT_TST.1/FPT_FLS.1），COS 必须在随机数调用链上接入在线自检与失效保安全逻辑。

4.4 细化 → COS 的安全状态机设计

细化（更严格 + 收窄适用范围）在 COS 的典型体现是安全状态机：把"访问控制"细化为"仅在已鉴别状态（AUTHENTICATED）下允许执行受限命令"。这是"细化到仅适用于部分主体/操作"的软件表达——一个被细化的FDP_ACF.1会在 COS 里落地为 `if (state != AUTHENTICATED) return SW_CONDITION_NOT_SATISFI