1. 5G C-IoT终端安全测评为什么不能照搬老套路

在物联网安全这个圈子里待久了，你会发现一个特别明显的变化：4G时代做物联网终端安全测试，手段相对单一，跑一遍端口扫描、抓一抓升级包、看看调试接口是否暴露，基本就能交差。但到了5G时代，尤其是C-IoT（蜂窝物联网，Cellular IoT）终端大规模落地之后，这套“老经验”越来越不够用。

我最早接触5G C-IoT终端安全测评是在一个智慧表计项目上，当时厂商送测的是一批NB-IoT水表终端，按照传统测评流程走了一遍，结果发现很多问题根本没测到位。后来换了基于5G核心网模拟环境的测评方案，才真正暴露出终端在鉴权、加密、数据保护上的实质缺陷。从那时候起我就确定了一件事：5G C-IoT终端安全测评，必须有一套独立的、能够量化的测评体系，而不是简单复用手机或宽带的测试用例。

先说清楚一个概念。C-IoT通常涵盖NB-IoT、LTE-M以及5G的RedCap（轻量化）终端，它们的特点是低功耗、低成本、数量海量、业务垂直化。5G网络引入服务化架构、网络切片、边缘计算之后，终端的接入方式、身份管理、数据路径都发生了变化，安全测评的对象、手段和评价标准也必须跟着变。

那到底为什么不能照搬老套路？我拆成三点来讲。

1.1 C-IoT终端和手机、宽带终端的本质差异

很多刚入行的朋友会把“5G终端安全测评”等同于“5G手机安全测评”，这是一个很大的误区。手机是通用计算平台，算力强、存储大、系统更新频繁，有完整的应用生态，安全测评的重点在操作系统、应用层和用户数据。而C-IoT终端是专用嵌入式设备，CPU主频低、内存可能只有几百KB到几MB，运行的是裁剪过的实时操作系统或者轻量级Linux。

为了把差异说清楚，我用一个表格来对比：

这个表格说明了一个关键问题：C-IoT终端的使用场景往往是无人的、长周期的，一旦终端被攻破，可能很久都不会被发现。比如一个采集终端如果被注入恶意固件，它可以持续上传错误数据，而运维人员可能一两个月后对账才发现异常。

所以测评C-IoT终端时，不能只用“手机安全测试”的思维去衡量，得从它真实的部署形态去倒推威胁场景，再设计对应的测试项。

1.2 老测评方法失效的三个直接原因

第一，空口协议层面，5G引入的SUCI（Subscription Concealed Identifier，签约标识符加密）机制改变了传统IMSI暴露的测试思路。4G时代测试SIM卡安全时，我们会去抓空口信令里有没有明文IMSI，到了5G和C-IoT场景，终端是否正确生成SUCI、是否在USIM卡不支持加密算法时仍能完成初始接入，这些都需要专门构造测试场景。用老的空口抓包分析方法是覆盖不了的。

第二，终端能力受限导致很多测试工具跑不动。很多安全扫描器是按照PC或者手机的配置设计的，你把它装到一个只有几十MHz主频、几百KB内存的NB-IoT模组上，根本不现实。所以对C-IoT终端很多测试必须从“终端内自测”改成“外部注入和协议侧验证”。

第三，业务场景碎片化，单点测评解决不了问题。同样是5G C-IoT终端，电网用的配电终端、燃气公司用的远传表、工厂用的传感器网关，它们的安全边界完全不一样。以前我们做测评是“一台终端跑全套用例”，现在更合理的做法是针对业务形态做测评项的组合裁剪。

1.3 安全测评体系的核心逻辑：从“查漏”到“度量”

我理解的测评体系，不是一份测试用例的集合，而是一个“度量框架”。它的目标不只是告诉厂商“你有哪些漏洞”，而是要给出一个可比较、可复用的安全能力基线：终端在身份安全、通信安全、数据安全、固件安全等维度上分别处于什么水平，是否满足入网或者集采的要求。

这也是为什么“5G C-IoT终端安全测评体系和技术研究”这个题目值得认真去做。测评体系的本质是把安全要求从定性描述变成定量指标，再落到具体的测试环境和用例上。有了这套体系，你在招标测试、产品选型、存量终端排查时才能拿出让人信服的结论。

我在实际项目中用的思路是：先定义测评对象的安全基线，再针对每一类安全属性去枚举威胁场景，最后把威胁场景映射到可执行的协议测试、固件测试和业务测试上面。这个映射表是整个测评体系最核心的资产。

2. 测评环境搭建：没有一套“干净的网”，测什么都像是隔靴搔痒

做C-IoT终端安全测评，环境问题直接决定了测试结果的可靠性。如果直接拿真实运营商的现网去测，一是不能随意构造畸形信令，二是终端接入的是真实网络，很多安全测试动作是受限的，搞不好还会影响到现网业务。我在项目里的做法是自建一套模拟5G核心网加空口环境，把被测终端圈在一个“可控制、可观测、可破坏”的测试网里。

这套环境的定位很像汽车碰撞测试里的“封闭试验场”：你可以放心地撞、放心地试，不用担心把马路上的车撞到。安全测评里，我们需要的就是这种能够“主动构造异常”的能力。

2.1 核心网模拟器怎么选：开源方案还是商用仪表

核心网模拟器的选择，本质上是在成本、可塑性和协议完整性三者之间做权衡。

• 开源方案（比如基于Open5GS、UERANSIM等开源项目搭建的测试环境）优点是成本低、代码开放，可以按需修改信令流程，很适合做协议级异常注入；缺点是协议兼容性需要自己调，很多5G增强特性支持得不够完整，调试周期长。
• 商用仪表方案（比如运营商和检测机构常用的综测仪、核心网模拟器）协议栈成熟、支持用例丰富，适合做标准符合性测试，但价格高，而且用例逻辑是封闭的，你想测一个“非标准”的异常场景，往往需要原厂定制。

我做测评的经验是：如果机构本身有预算、需要批量出具检测报告，商用仪表是必须的，它的可重复性和标准度是开源方案比不了的；但如果是在项目初期做技术预研、探索新的攻击面和威胁场景，开源方案灵活得多。我自己的技术研究项目是从开源方案起步的，先搞清楚测试思路，再逐渐在商用仪表上固化用例。

这里给出一个典型的测评环境组成，供参考：

2.2 空口侧最容易忽略的三个细节

空口侧是整个环境里最容易出问题的部分，我踩过的坑可以单独写一篇文章，这里先挑三个最关键的细节。

一是频段和带宽配置必须和被测评终端的硬件能力匹配。C-IoT终端很多是单频段的，比如只支持700MHz或者800MHz的NB-IoT，或者只支持2.6GHz的RedCap。如果核心网模拟器和gNB模拟配置的频点不在终端支持的范围内，终端会一直在小区搜索状态，你会看到终端“沉默不语”，还以为是终端坏了，实际上根本不是。

二是TDD和FDD的选择。国内很多5G网络用的是TDD制式，但C-IoT终端可能有FDD版本，比如支持LTE-M的终端在FDD频段上更常见。测试环境必须同时支持两种制式的切换配置，否则会漏掉某些与帧结构、定时相关的安全问题。

三是空口抓包的位置要选对。抓包工具如果接在终端和gNB模拟器之间，抓到的是标准空口协议，适合分析RRC和NAS；但如果你想分析终端和真实基站之间的物理层行为，需要专门的射频探头。多数情况下我们关注的是NAS层以上的安全行为，接口位置选在核心网侧抓包会更全面，能同时看到SBI接口的消息。

2.3 把终端“圈”进测试网：接入控制与测试隔离

安全测评里经常要做一些“不太礼貌”的操作，比如给终端下发错误的鉴权参数、强制终端走降级算法、模拟网络侧发起的注销请求等。这些操作在真实网络里可能影响用户体验，在测试网里就可以放开手脚，但要保证两点：

第一，被测终端必须被限定在测试PLMN（公共陆地移动网络）里。一般通过写卡工具将USIM卡的PLMN列表配置成只包含测试网络的PLMN，并且关闭自动搜索其他网络，避免终端在信号弱的时候自动切到周边真实基站上去。

第二，测试环境要和办公网络、真实业务系统做物理隔离。C-IoT终端测评涉及大量数据包抓取和畸形报文注入，一旦流量串到其他网络，轻则干扰内网，重则触发安全设备的误报。我的习惯是测试网单独划分VLAN，核心网模拟器的管理口和数据口分开，所有抓包数据只在测试网内部处理。

另外，如果要做批量终端的对比测评，建议在环境里加一个终端身份识别模块。C-IoT终端通常没有屏幕，你从外观上根本分不清哪台是哪个样机。用IMEI、IMEISV或者SUPI对应的号码建立映射表，测试结果才能准确落在对应的设备上。

3. 测评指标体系拆解：五个域，一层层剥开

测评体系最核心的就是指标体系。我刚开始做5G C-IoT安全测评的时候，踩过一个大坑：列了上百项测试用例，看起来铺得很全，但真正执行的时候发现很多用例互相重叠，有些关键风险反而没有被覆盖到。后来我换了一种拆解方式——按安全域拆，而不是按测试手段拆。

我现在的框架是把C-IoT终端安全拆成五个域：接入域、传输域、平台域、应用域和数据域。每个域回答一个问题：终端在这个环节的某个安全属性是否有效、可被绕过、可被滥用。

3.1 五维拆解法：接入域、传输域、平台域、应用域、数据域

接入域解决的是“你是谁”的问题。C-IoT终端接入5G网络时，身份认证是否可靠、SUCI是否按规范生成、3GPP定义的鉴权流程是否完整执行，都属于这一域。测试点包括：USIM卡鉴权参数校验、异常鉴权响应处理、SUCI隐藏标识的生成、IMEI/IMEISV上报与校验等。

传输域解决的是“数据在传输过程中是否安全”的问题。空口链路的加密和完整性保护是这一域的重点。具体到5G，需要验证终端是否支持并优先使用5G定义的加密算法，是否允许空口加密关闭，用户面数据在网络侧和终端侧是否都严格遵循PDP上下文限制等。

平台域解决的是“终端本身是否可靠”的问题。这个域最接近传统物联网安全测试，包括固件签名校验、调试接口暴露情况、存储芯片数据加密、安全启动链路、安全的OTA升级机制等。平台域是C-IoT终端最容易出问题的地方，因为成本压力大，很多模组厂商会去掉安全芯片或者简化启动校验。

应用域解决的是“终端上跑的业务是否可控”的问题。C-IoT终端业务比较单一，但应用层风险依然存在，包括：业务配置是否支持强口令、远程管理通道是否加密、对业务指令是否有校验、是否存在硬编码的超级口令等。

数据域解决的是“终端里的数据是否被保护”的问题。比如计量终端里的累计用量、位置信息、费率参数等，是否加密存储；本地调试接口能否直接导出敏感数据；业务数据导出是否有审计等。

3.2 分级测评：哪些必须测，哪些可以抽测

C-IoT终端资源受限、成本敏感，如果每一个型号都测全套指标，检测机构压力大，厂商成本也扛不住。所以我习惯把测评项分成三个等级：

P0级别的每一项，我都会要求测试环境里必须有可复现的用例，并且判定标准要明确；P1级别则可以允许一定的人工评估；P2级别通常结合项目背景做抽样。这样既保证了测评体系的严谨性，又不至于让测评过程重到无法落地。

3.3 指标权重的设置：从“平均用力”到“风险导向”

初版测评报告里我把五个域的指标权重设成平均分配，结果被甲方一句话问住了：“你这套体系，到底想引导厂商把预算花在哪？”后来我改了思路：权重应该跟着威胁发生的可能性和影响程度走。

以电网配电终端为例，它最核心的业务是遙信遙测，数据链路一旦被篡改，直接后果就是运维误判。这类终端的测评权重就应该向传输域和数据域倾斜，接入域保证身份可信，平台域作为基础门槛。而如果是智能燃气表，长期暴露在公共区域，被物理接触的概率高，平台域和数据域就应该占更高的权重。

目前我在项目中常用的一个权重参考是这样的：

这个权重不是一成不变的，每个项目开始之前都要用“威胁场景-影响程度”的方法重新校准一遍，明确告诉评审方我们为什么这么配权重。

4. 关键测评项的实操方法与踩坑点

指标体系和环境搭建好之后，就到了“真刀真枪”做测试的阶段。这一部分我挑四个最关键、也最容易被测出问题的测评项展开讲，每个都会给到具体的操作思路和判定方法。

4.1 身份与SIM卡安全：不跳出规范，你就发现不了问题

很多人测USIM卡安全，就是把卡插到终端里，看能不能正常入网，然后下结论说“鉴权正常”。这种测法等于没测。真正有效的做法是通过核心网模拟器控制鉴权过程，主动制造异常，观察终端和USIM卡的反应。

我常用的几个测试动作：

• 在核心网侧发送一个错误的鉴权参数（比如RES值不匹配），看终端是否会报错并终止接入过程。如果终端在鉴权失败后仍然继续后续的注册流程，说明终端的协议栈对鉴权结果校验不严，这是P0级别的缺陷。
• 在SUCI解码阶段构造一个无法正确解密的SUCI，看终端和网络侧如何交互。有些终端实现得不好，在加密标识解析失败时会把SUPI直接泄露到空口信令里，这正好可以通过抓包来验证。
• 检测终端是否支持USIM卡的访问控制机制。很多运营商在USIM卡里配置了PIN码或者管理通道的访问限制，终端如果绕过这些机制直接读写卡文件，就说明终端存在身份冒用的风险。

这一项最容易踩的坑是：很多C-IoT模组是“卡贴片”式的，SIM卡焊死在主板上，你没有办法像手机评测那样方便地换卡测试。遇到这种情况，建议在测评环境里先用标准的测试卡做完协议测试，再针对贴片卡做固件级的文件系统检查，看有没有把ICCID、鉴权密钥直接明文存储在Flash里。

4.2 空口与NAS信令安全：加密和完整性保护到底开没开

5G系统里，空口加密和完整性保护是安全通信的基石。C-IoT终端为了省电，有些厂商会在实现上偷懒，默认关闭加密或者只支持空算法（NEA0/NIA0）。这种终端如果流入市场，空口抓包就能直接在明文里看到用户的业务数据，在电网抄表、远程开关控制这类场景里，后果是灾难级的。

具体测试方法：

第一步，先在核心网模拟器上配置只允许加密算法（比如NEA2、NEA1），看终端能否注册、能否建立PDU会话。如果终端完全无法连接，说明它可能只支持空加密或者算法协商逻辑有问题。

第二步，配置允许空算法，然后强制终端选择空算法。正常实现下，终端必须经过网络侧显式协商才能使用空算法，而且空算法的选择应当被记录在信令里。测试时我们要确认：终端是被动接受空算法，还是主动发起空算法协商请求。如果终端在没有被要求的情况下主动使用空算法，这就是明确的安全缺陷。

第三步，检查完整性保护。5G接入层信令的完整性保护覆盖范围很广，包括RRC信令和NAS信令。测试方法是抓取注册请求和PDU会话建立请求，核对信令里的完整性保护参数是不是真实参与计算。有些实现会在完整性保护失败后仍然接受消息，这说明完整性校验逻辑存在问题。

操作提示：抓包时不要只盯着RRC层，NAS消息是在RRC消息里封装透传的，要逐层拆。我见过不少人拿着空口抓包文件分析半天，最后发现因为抓包软件版本太老，NAS层消息解析错误，误报了“完整性保护缺失”的结论。

4.3 固件与系统安全：不是跑一遍漏扫就完事

C-IoT终端的固件测评，如果只是把固件解包后跑一遍已知漏洞扫描，效果非常有限。我更关注的是三条链路：固件来源可信、启动过程可信、更新过程可信。

固件来源可信的测试，是把从终端调试口读取出来的固件和厂商提供的官方固件做哈希比对，看两者是否一致。如果不一致，就要进一步分析固件里是否存在额外注入的模块。很多户外终端长期无人看管，物理接触攻击是现实威胁。

启动链测试，是验证从BootROM到Bootloader再到系统内核，每一级有没有校验签名。测试手段包括：通过调试接口写入一个修改后的Bootloader、把签名校验跳过的内核刷进去，看终端是否还能正常启动。如果跳过校验后终端照常启动，说明信任链断裂了，攻击者在拿到物理接触的情况下可以直接植入持久化后门。

OTA更新测试的重点是更新包的加密和签名校验。实际操作是构造一个篡改过的升级包（比如在合法升级包基础上改动一个字节），然后模拟升级服务器给终端下发，观察终端是否拒绝升级。同时还要检查升级过程是否回传固件版本给服务器，便于后续审计。

补充一个实战经验：很多C-IoT终端的“加密存储”只是做了简单的XOR变换或者Base64编码，并没有真正的密钥管理。测试数据域时一定要区分“混淆”和“加密”。用256位AES-GCM加密并用独立密钥管理芯片保护密钥的，才能算真正的数据加密；只做编码转换的，在测评报告里应直接判定为不合规。

4.4 业务与数据安全：结合典型场景做用例设计

C-IoT终端最终是承载业务的，业务安全测试需要结合具体的部署场景来设计用例。举几个我能想到的通用场景：

• 远程控制指令类：测试终端是否校验控制指令的来源和完整性。常见做法是抓取一次合法的控制指令，然后用重放工具原样重发一遍，看终端是否再次执行。如果终端对重放指令照单全收，说明缺少时间戳或随机数机制。
• 本地配置导出类：很多终端支持通过本地红外口、蓝牙口或者USB口导出配置。测试时要确认这些接口是否有口令保护，导出的内容是否包含密钥、口令、通信参数等敏感信息。有些终端的“导出配置”功能直接把整个Flash分区镜像导出了。
• 业务口令类：终端的管理口令、业务下行指令口令是否支持修改，是否存在硬编码默认口令。C-IoT终端不像手机有成熟的账户体系，很多设备出厂口令是统一的，而且不强制修改，这在实际项目里属于高频风险点。
• 计量数据完整性类：对水表、电表、气表这类终端，要测试本地累计数据的可信性。通过物理接口修改数据存储区，或者通过业务指令“快速校时”，看终端是否产生异常累计数据，以及超限和篡改是否被记录。

业务安全的用例设计原则是：把终端放到真实业务链条里看一遍，找到“人、数据、指令”这三个要素交叉的地方，风险往往就藏在交叉点上。

5. 从单次测评到可复用的测评体系

一套测评体系要想真正有价值，不能只靠一两次测试的“手感”，必须把流程、用例、评分、工具沉淀成资产。这一节讲的是我如何在完成多个项目之后，把零散的测试工作收拢成一套可持续运作的体系。

5.1 测评流程的正向拆解和逆向验证

我现在的测评流程分为五个阶段，每个阶段都有明确的输入和输出：

正向流程之外，我还会做一轮逆向验证，也就是拿到厂商的整改说明后，针对每个整改项重新跑相关用例，确认修复不是“表面修复”。比如厂商说“我们已经增加了固件签名校验”，逆向验证时就要看它是只挡了Bootloader层，还是连恢复分区、中间升级包也做了签名校验。

5.2 威胁等级、评分模型和结果分级

测评结果最终要转化为一个“决策语言”，方便甲方采购、入网、招标时使用。我采用的做法是：每个问题按威胁等级打分，再按权重汇总，最后划分安全等级。

威胁等级定义参考：

综合评分的公式可以设计成“各域得分乘以权重后累加”。实践中我会在报告里同时给出汇总分数和每一域的明细，因为汇总分可能掩盖短板——某一项严重缺陷，即使其他项全满分，这个终端也不能算安全。所以最终的等级判定采用“木桶原则”：只要出现一个严重等级问题，综合等级就限制为“不合格”。

5.3 测评工具链和基线库的沉淀

做测评体系如果没有工具链支撑，每次都用人工方式去改核心网模拟器配置、手动抓包、肉眼判断结果，不仅效率低，还容易漏判。

我在项目中沉淀的测评工具链大致包括四类：

• 协议测试脚本：用脚本控制核心网模拟器发起异常注册流程、异常鉴权、算法降级协商、业务面异常数据注入，每次测试后自动采集终端响应和行为日志。
• 固件分析流水线：自动解包固件，识别文件系统类型，提取关键配置，比对已知漏洞库，同时生成MTD分区表、启动链校验关系图。
• 信令处理脚本：批量解析空口和NAS信令，自动提取加密算法协商结果、完整性保护参数、SUCI使用情况，并和预期配置做比对，输出差异表。
• 用例与基线库管理：把P0/P1/P2用例全部编号入库，记录每个用例的适用终端类型、测试步骤、预期结果和判定标准。新项目启动时直接按安全域和终端类型调用基线库中的子集。

这个部分的工作看起来很“软”，但恰恰是它决定了测评体系能不能持续运转。没有基线库，人一走，经验就散掉了；有了一套可以不断复用的用例库和脚本，不管是新同事接手还是批量测评，都能保持结论的一致性。

6. 实测中踩过的坑，替你提前排一遍

最后这部分，我想把实际测评过程中遇到的几个典型问题直接摆出来。这些坑在公开文档里基本查不到，但几乎每个人都会遇到一两次。

第一个坑：频段不匹配导致终端全程沉默。有一次测评一款RedCap终端，配置好核心网模拟器和gNB模拟后，终端始终找不到小区。排查了两天，最后才发现终端硬件只支持一个特定频段的RedCap，而我们在模拟器里配置的是另一个频段。重新配置频点后，终端一次入网成功。从那以后我要求所有样机摸底必须第一时间确认频段支持清单和制式能力，再开始环境配置。

第二个坑：核心网参数和USIM卡配置冲突。有一款终端总是注册成功后又立刻注销，抓包发现终端在PDU会话建立请求阶段反复上报“PDU session type not supported”。排查发现是USIM卡写入的APN配置和核心网模拟器的DNN配置不一致，导致会话建立失败。这类问题在C-IoT终端测评里特别容易出现，因为NB-IoT和RedCap终端的PDU会话类型、S-NSSAI配置和手机差异很大。

第三个坑：用通用的eMBB用例去测RedCap终端。在早期项目里，我们直接套用5G手机的标准测试用例，结果大量用例报“不适用”。原因是RedCap终端在带宽、MIMO层数、天线数目上做了裁剪，很多针对增强移动宽带场景的测试项根本没有意义。后来我们专门为RedCap和NB-IoT终端建立了独立的用例裁剪规则，才算把测试有效率提上来。

第四个坑：协议版本混乱。5G NR的R15、R16、R17版本在NAS流程上有不少差异，C-IoT终端有的实现了Release 16的增强特性，有的还在老版本上。如果你用高版本的协议特征去测试低版本实现，或者反过来，很容易把“设备没实现”误判成“设备安全缺陷”。处理方式是在测试开始前通过信令协商流程确认终端上报的协议版本和能力参数，再选择对应版本的测试基线和判定标准。

来源：全网公开资料结合本人项目经验整理

技术资料和标准依据可参考3GPP TS 33.501（5G安全架构）、TS 38.300/38.331（空口协议）、CCSA相关终端安全测评标准等公开文档。具体测评环境配置参数建议以实际被测终端的硬件能力和项目需求为准，不同厂商模组在协议实现上的差异较大，需要以样机实测结果作为最终判定依据。