好的，这是系列文章的第九篇。我们已经全面剖析了PUCI的威胁，现在我们将转向至关重要的下一章——安全要求。

深度解析 3GPP TR 33.937：6 Security Requirements (安全要求)

本文技术原理深度参考了3GPP TR 33.937 V18.0.0 (2024-03) Release 18规范中，关于“Chapter 6 Security Requirements”的核心章节，旨在为读者揭示IMS网络中，PUCI系统必须满足的九大安全需求，这些需求构成了评估所有防骚扰解决方案的“圣经”和“验收标准”。

引言：从“问题”到“目标”，李雷的“需求清单”

在前面的系列文章中，我们的工程师李雷已经成功地从各个维度，将非请所求通信（UC）的威胁（5章）解剖得体无完肤。他清楚地知道，这个“敌人”不仅侵犯安宁，掠夺财产，甚至能劫持设备，瘫痪网络。李雷深知，仅仅理解问题还不够，要真正解决问题，必须将这些威胁转化为可衡量、可实现、可验证的安全要求。

安全要求，是任何安全系统设计的“生命线”。它们如同建筑蓝图上的关键尺寸和功能规格，定义了系统建成后必须具备的能力。在TR 33.937的第六章，3GPP的专家们将PUCI研究的核心挑战，凝练成了九条明确的安全要求（Security Requirements）。这些要求不仅仅是技术规范，更是连接“威胁分析”与“解决方案”之间的关键桥梁。

今天，我们将跟随李雷的脚步，深入第六章，逐一解读这九大“圣经”级安全要求。他将把这些抽象的文字，与他熟悉的UC场景、他的朋友小王被劫持的经历等相结合，理解每一条要求背后的深层含义，以及它们将如何指导PUCI系统的设计与验证。

1. 总纲：来源于TISPAN的启发 (6.1 Void, 6.2 3GPP Security Requirements)

规范的6.1节被标记为“Void”，这意味着它不包含任何内容，只是一个占位符。真正的核心内容集中在6.2节 3GPP Security Requirements。

NOTE 1: The following requirements were adapted from the TISPAN UC requirements in. Following are security requirements on PUCI:

深度解析：

开篇的注1再次强调了我们之前在2章“参考文献”中讨论过的观点：3GPP的PUCI研究，是站在TISPAN TR 187 009这份先行研究的肩膀上进行的。这些安全要求并非凭空创造，而是借鉴并“适配”了TISPAN在NGN（下一代网络）反骚扰方面的经验。这保证了研究的延续性和广泛适用性。

接下来，我们将逐一解读这九条安全要求，并融入李雷的场景故事进行理解。

2. 第一条：用户举报通道 (3GR-UC-1)

3GR-UC-1: The IMS should provide a means for IMS-users to report communication as a UC.

深度解析：

• 含义：IMS网络必须提供一个机制（means），让像李雷这样的IMS用户能够方便地报告某个通信是UC（非请所求通信）。
• 为什么重要：用户的感受是判断是否为骚扰的最终标准。即使最智能的算法也可能漏报或误判。用户的实时反馈是PUCI系统最重要的“情报来源”和“人工校准”。
• 李雷的场景理解：李雷在接到一个他认为是骚扰的电话后，他应该能立即在通话界面点击一个“举报”按钮，或者通过发送一条特定短信，将这个骚扰号码和来电信息实时反馈给运营商。这就像为用户提供了拿起“手机”直接报警的权力。

3. 第二条：举报审计记录 (3GR-UC-2)

3GR-UC-2: Reports of UC relating to IMS-users should be auditable by the IMS.

深度解析：

• 含义：所有用户关于UC的举报，必须在IMS网络中可审计（auditable），即能被记录、追溯和验证。
• 为什么重要：审计是责任界定和系统优化的基石。
  1. 责任追溯：当李雷举报了一个诈骗电话，这份举报记录可以作为后续运营商调查、与警方合作的证据。
  2. 防止滥用：如果李雷恶意举报他竞争对手的号码，审计记录可以揭露这种滥用行为。
  3. 系统优化：通过分析大量举报数据，运营商可以发现新型骚扰模式，优化识别算法。
• 李雷的场景理解：李雷举报的每一通骚扰电话，系统都应该记录下举报时间、被举报号码、李雷的号码以及举报类型（如“广告”、“诈骗”）。这些记录就像是一本“举报日志”，随时可供查询。

4. 第三条：请求UC评级 (3GR-UC-3)

3GR-UC-3: The IMS should provide the ability for a user who is party to a communication to request whether a communication was rated as UC.

深度解析：

• 含义：IMS用户应该有能力查询某个通信是否被PUCI系统评级为UC。

• 为什么重要：这是赋予用户知情权和质疑权。

  1. 用户知情权：如果李雷接到一个陌生号码，犹豫是否接听，他可以先查询一下，看看这个号码是否已经被系统标记为高风险骚扰。
  2. 质疑与申诉：如果李雷自己的正常业务电话被系统错误地评级为UC，他需要有一个途径来了解原因并进行申诉。

• 李雷的场景理解：他设想，如果他给客户打电话，客户抱怨说显示是“骚扰电话”，李雷可以向运营商发起一个查询请求，询问“我这个号码最近是否被评级为骚扰？”。

• 重要附注：

  NOTE 2: Requirement 3GR-UC3 risks making PUCI mechanisms vulnerable to circumvention attacks through repeated probing of the identification outcome. Consequently, special care must be taken to include safe guards against circumvention attacks, for instance through rate limitations on responding to queries.

  这个附注非常关键！它指出了一个潜在的安全漏洞：查询机制可能被恶意利用。攻击者可能会反复查询自己的不同号码，试图探测PUCI系统的识别阈值，从而找到绕过防御的方法。因此，实现此功能时必须引入查询速率限制等保护机制。

5. 第四条：挑战UC识别 (3GR-UC-4)

3GR-UC-4: The IMS should provide the ability for an affected user to challenge the justification why the communication was identified as UC.

深度解析：

• 含义：受影响的用户（例如，自己的号码被错误标记为UC）应该有能力挑战PUCI系统给出的UC识别结果及其理由。
• 为什么重要：这是赋予用户申诉权，维护其声誉和正常通信权利的关键。我们在4.3章讨论过“冤枉的好人”问题。如果李雷的同事张三因为恶意举报而电话被标记为骚扰，他需要一个官方渠道来证明自己的清白。
• 李雷的场景理解：张三可以向运营商提交申诉，要求运营商解释为什么自己的号码被标记为骚扰，并提供相关证据来证明自己是正常的商业呼叫。运营商则需要根据审计记录和自身数据进行核查。

6. 第五条：运营商信息提取 (3GR-UC-5)

3GR-UC-5: The IMS should provide the ability to the operator to extract information from the signalling and other means to provide an indication of the likelihood whether the communication is unsolicited.

深度解析：

• 含义：IMS网络必须具备能力，让运营商能够从信令以及其他来源中提取信息，从而判断一个通信是UC的可能性。
• 为什么重要：这是构建PUCI系统的核心技术要求，它要求网络提供“情报搜集”能力。这是“识别（Identification）”步骤的技术基础。
• 李雷的场景理解：当李雷的手机收到一个陌生来电时，IMS网络需要能够从SIP信令中提取出主叫号码、呼叫发起时间、会话类型（语音/视频/消息）、QoS参数，甚至结合外部信誉库数据，来综合判断这个呼叫是不是UC。这个要求直接对应了4.1章架构中的“Identification”模块。

7. 第六条：UC指示传递 (3GR-UC-6)

3GR-UC-6: The IMS should provide a mechanism to convey the UC indication in the signalling, such that intermediary network entities are not affected.

深度解析：

• 含义：IMS必须提供一个机制，能够通过信令来传递UC指示（即某个通信是UC的判断结果），同时确保中间网络实体不受负面影响。
• 为什么重要：这是“标记（Marking）”步骤的技术基础。为了让PUCI系统能做出“反应”，它首先需要将“识别”的结果告诉给网络中的其他相关实体。而“中间实体不受影响”意味着这种传递机制不能导致正常网络功能故障或性能下降。
• 李雷的场景理解：如果运营商的PUCI AS将一个来电评级为高风险UC，它需要通过SIP信令在IMS网络中传递这个“UC指示”。例如，可以在SIP头域中添加一个扩展字段（如X-UC-Score: 90），告知接收端的S-CSCF或终端，这是一个高风险的骚扰电话。这个字段必须是可选的，即使中间的CSCF不认识这个字段，也必须能正常转发整个SIP消息。

8. 第七条：多样化通信处理 (3GR-UC-7)

3GR-UC-7: The IMS should provide a mechanism to allow variation in communication handling based on UC likelihood indication.

深度解析：

• 含义：IMS必须提供一个机制，能够根据UC的可能性指示（即UC评分），对通信进行多样化的处理（variation in communication handling）。
• 为什么重要：这是“反应（Reacting）”步骤的技术基础，是PUCI系统发挥作用的关键。不同的UC风险等级，需要不同的处置方式。
• 李雷的场景理解：
  • 低风险UC（如，合法营销电话但用户不感兴趣）：可以将其转入语音信箱，或显示为“疑似推销”。
  • 中风险UC（如，可疑号码，但未被确认为诈骗）：可以先播放一个“来电可能为骚扰，请注意接听”的语音提示，再连接给李雷。
  • 高风险UC（如，已确认的诈骗电话或已知恶意网址）：直接在网络侧拦截，不让李雷的手机响铃。 这种分级处理能力，能够最大化防护效果，同时减少对正常通信的误伤。

9. 第八条：用户防护请求审计 (3GR-UC-8)

3GR-UC-8: Requests for UC protection made by IMS users should be auditable by the IMS.

深度解析：

• 含义：IMS用户发起的UC防护请求（例如，开启黑名单、设置勿扰模式），也必须在IMS中可审计。
• 为什么重要：与“举报审计”（3GR-UC-2）类似，这是确保运营商对用户配置行为有记录，以便：
  1. 责任界定：如果李雷开启了某个防护功能后导致了问题，审计记录可以证明这是用户主动配置的。
  2. 合规性：符合数据安全和隐私保护法规对用户行为记录的要求。
• 李雷的场景理解：李雷通过App将某个号码添加到黑名单的操作，或者他设定“勿扰模式”的时段，这些行为都应该被系统记录，并且能够被查询。

10. 第九条：兼容互通场景 (3GR-UC-9)

3GR-UC-9: The solution should also work in interworking scenarios with legacy networks and devices, in particular when using Single Radio VCC, IMS Service Continuity, and IMS Centralized Services.

深度解析：

• 含义：PUCI解决方案必须在与传统网络的互通场景下也能工作，特别是要考虑SRVCC、IMS Service Continuity和IMS Centralized Services等业务连续性技术。
• 为什么重要：这是PUCI解决方案的普遍适用性要求。IMS网络并非孤立存在，它必须与各种传统网络（2G/3G CS域、PSTN）无缝互通。正如我们在4.4章中讨论的李雷高铁上的“时空穿越”经历，即使在接入技术发生变化时，PUCI功能也应尽可能保持一致的用户体验。
• 李雷的场景理解：PUCI不能仅仅在5G网络下有效，当他的通话通过SRVCC切换到2G网络时，至少最基础的UC防护（如已有的黑名单拦截）仍应发挥作用，或者提供可替代的带外反馈机制。

11. 总结：评估解决方案的“黄金标准”

至此，李雷已经完成了对TR 33.937所有九条安全要求的深度解读。他清晰地看到，这份“需求清单”涵盖了从用户交互（举报、查询、挑战）、到网络能力（信息提取、指示传递、多样处理）、再到系统合规性（审计）和兼容性（互通场景）的方方面面。

这些要求不仅仅是文字，它们是：

• 指南针：为后续的解决方案设计指明方向。
• 试金石：任何被提出的PUCI方案，都必须用这九条要求进行检验和评估。
• 连接器：将“我们遇到的问题”与“我们要实现的目标”紧密连接在一起。

掌握了这份“黄金标准”，李雷已经为深入下一章，即对各种“解决方案替代方案”的探索与评估，做好了最充分的准备。他知道，所有的技术“武器”，都将用这把尺子来衡量。

---

FAQ 环节

Q1：为什么PUCI的安全要求中有这么多关于“审计（Auditable）”的要求（3GR-UC-2, 3GR-UC-8）？ A1：审计对于安全系统来说至关重要，它主要服务于以下几个目的：

1. 责任认定：当发生纠纷或法律诉讼时，审计记录可以作为重要的证据，明确责任方。
2. 合规性要求：许多国家和地区的法律（如数据保护法规）都要求通信服务提供商保留用户的操作记录，以确保服务合法合规。
3. 系统优化和故障排查：通过分析审计日志，可以发现系统异常、用户行为模式，从而持续优化PUCI算法，或者在系统出现故障时进行有效排查。
4. 防止滥用：无论是用户举报，还是用户对自身防护功能的配置，都可能被恶意利用，审计记录可以帮助识别和阻止这些滥用行为。

Q2：3GR-UC-3（请求UC评级）的风险点在哪里？它可能被攻击者如何利用？ A2：风险点在于攻击者可能利用该功能进行“系统探测”或“规避测试”。例如，攻击者拥有多个号码，他可以频繁地向不同的号码发起少量呼叫，然后用另一个号码（可能伪装成无辜用户）去查询这些呼叫的UC评级。通过大量试探，攻击者可以逐渐摸清PUCI系统的识别规则和阈值，从而调整自己的骚扰策略，以规避检测。因此，规范特别强调需要引入“查询速率限制”等安全防护措施。

Q3：3GR-UC-6强调“中间网络实体不受影响”，这意味着什么设计原则？ A3：这意味着PUCI功能在设计信令时，必须遵循**向后兼容（backward compatibility）和非强制性（non-mandatory）**原则。例如，在SIP消息中添加的UC指示信息，应该作为一个可选的、可忽略的头域。如果中间的路由器、代理服务器或CSCF等实体不认识这个头域，它们也必须能够正常转发整个SIP消息，而不能因此报错或丢弃消息。这确保了网络升级的平滑性，避免了因新功能而导致旧系统瘫痪的风险。

Q4：3GR-UC-7（多样化通信处理）为PUCI系统带来了哪些能力上的提升？ A4：它使得PUCI系统从“一刀切”的拦截，升级为精细化、差异化的处理。这意味着系统不再是简单地判断“是骚扰”或“不是骚扰”，而是可以给出“骚扰可能性为XX%”的评分，并根据这个评分，结合用户自定义的策略，采取多种灵活的“反应”措施。例如：高风险直接拦截，中风险语音提示并转语音信箱，低风险正常接续但附带风险警示。这极大地提升了PUCI系统的准确性和用户体验。

Q5：3GR-UC-9（兼容互通场景）与4.4节的“共存”讨论有何关联？ A5：3GR-UC-9是4.4节“共存”讨论的直接结果和目标。4.4节分析了在SRVCC等场景下，PUCI功能面临的挑战和功能降级风险。3GR-UC-9则将“在互通场景下工作”明确列为一项安全要求，旨在指导解决方案设计者，即使在复杂的异构网络环境中，也要尽可能地保持PUCI功能的有效性，或者至少提供可替代的防护措施，从而满足用户对通信连续性和安全性的期望。