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。为了把差异说清楚我用一个表格来对比维度5G手机/宽带终端5G C-IoT终端算力资源强多核SoC弱MCU/轻量级SoC系统复杂度完整OS应用生态RTOS/精简Linux功能固定通信模式连续在线用户主动交互低功耗间歇通信大部分时间休眠生命周期2~3年换代5~10年甚至更长攻击面应用、OS、外设、WiFi/蓝牙等空口、SIM接口、物理接口、本地固件典型布设环境用户随身、家庭/办公户外机柜、表箱、农田、管道井等无人环境威胁后果个人隐私泄露、财产损失计量数据篡改、批量终端被控、网络侧影响这个表格说明了一个关键问题C-IoT终端的使用场景往往是无人的、长周期的一旦终端被攻破可能很久都不会被发现。比如一个采集终端如果被注入恶意固件它可以持续上传错误数据而运维人员可能一两个月后对账才发现异常。所以测评C-IoT终端时不能只用“手机安全测试”的思维去衡量得从它真实的部署形态去倒推威胁场景再设计对应的测试项。1.2 老测评方法失效的三个直接原因第一空口协议层面5G引入的SUCISubscription 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增强特性支持得不够完整调试周期长。商用仪表方案比如运营商和检测机构常用的综测仪、核心网模拟器协议栈成熟、支持用例丰富适合做标准符合性测试但价格高而且用例逻辑是封闭的你想测一个“非标准”的异常场景往往需要原厂定制。我做测评的经验是如果机构本身有预算、需要批量出具检测报告商用仪表是必须的它的可重复性和标准度是开源方案比不了的但如果是在项目初期做技术预研、探索新的攻击面和威胁场景开源方案灵活得多。我自己的技术研究项目是从开源方案起步的先搞清楚测试思路再逐渐在商用仪表上固化用例。这里给出一个典型的测评环境组成供参考组成模块作用关键要求5G核心网模拟器含AMF/SMF/UPF/AUSF/UDM控制终端注册、鉴权、会话建立支持SUCI/SUPI处理、支持异常信令注入基站侧模拟gNB模拟承载空口协议栈转发NAS消息支持目标频段、支持RRC状态控制和干扰注入USIM卡写卡工具写入测试专用USIM配置支持5G鉴权参数Milenage/5G AKA配置空口抓包工具采集RRC/NAS信令、用户面数据支持5G NR接口解析终端供电与控制台控制终端开关机、复位、异常断电可程控便于自动化测试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必测直接影响接入安全和网络侧安全鉴权流程、SUCI生成、加密算法协商、完整性保护、默认口令P1应测影响终端自身安全和数据安全固件签名校验、调试接口、OTA升级安全、敏感数据存储P2抽测/评估影响业务可运营性和合规性日志审计、远程管理通道强度、系统剪裁项核查P0级别的每一项我都会要求测试环境里必须有可复现的用例并且判定标准要明确P1级别则可以允许一定的人工评估P2级别通常结合项目背景做抽样。这样既保证了测评体系的严谨性又不至于让测评过程重到无法落地。3.3 指标权重的设置从“平均用力”到“风险导向”初版测评报告里我把五个域的指标权重设成平均分配结果被甲方一句话问住了“你这套体系到底想引导厂商把预算花在哪”后来我改了思路权重应该跟着威胁发生的可能性和影响程度走。以电网配电终端为例它最核心的业务是遙信遙测数据链路一旦被篡改直接后果就是运维误判。这类终端的测评权重就应该向传输域和数据域倾斜接入域保证身份可信平台域作为基础门槛。而如果是智能燃气表长期暴露在公共区域被物理接触的概率高平台域和数据域就应该占更高的权重。目前我在项目中常用的一个权重参考是这样的安全域通用型C-IoT终端室外公共区域终端关键基础设施终端接入域25%20%20%传输域25%25%20%平台域20%25%25%应用域15%15%15%数据域15%15%20%这个权重不是一成不变的每个项目开始之前都要用“威胁场景-影响程度”的方法重新校准一遍明确告诉评审方我们为什么这么配权重。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 威胁等级、评分模型和结果分级测评结果最终要转化为一个“决策语言”方便甲方采购、入网、招标时使用。我采用的做法是每个问题按威胁等级打分再按权重汇总最后划分安全等级。威胁等级定义参考等级定义典型问题示例整改要求严重可直接导致终端被完全控制或密钥泄露调试接口暴露且无口令、固件无签名校验、鉴权可被绕过必须整改复测通过后才能放行高危可导致数据泄露或关键指令被篡改空口明文传输业务数据、硬编码超级口令、OTA无签名校验原则上必须整改中危特定条件下可利用影响单一或局部功能日志缺失、告警信息明文存储、算法协商策略偏弱建议限期整改低危不影响核心安全但存在合规差距固件版本回退提示不完善、文档缺失可接受持续跟踪综合评分的公式可以设计成“各域得分乘以权重后累加”。实践中我会在报告里同时给出汇总分数和每一域的明细因为汇总分可能掩盖短板——某一项严重缺陷即使其他项全满分这个终端也不能算安全。所以最终的等级判定采用“木桶原则”只要出现一个严重等级问题综合等级就限制为“不合格”。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.5015G安全架构、TS 38.300/38.331空口协议、CCSA相关终端安全测评标准等公开文档。具体测评环境配置参数建议以实际被测终端的硬件能力和项目需求为准不同厂商模组在协议实现上的差异较大需要以样机实测结果作为最终判定依据。
