1. 认证证书的含金量PSA L2在物联网安全体系中的真实分量说句实在话做物联网嵌入式的这些年我越来越觉得安全这个东西在圈子里的处境很尴尬。一方面云平台、网关、设备商口头上都在喊安全是底线另一方面到了产品定义阶段硬件成本、功耗、上市周期往往把安全需求一路往后挤。在这种背景下PSA Certified认证等级就成了一个很关键的参照系——它不是给开发者看的花架子而是能直接影响选型决策的硬指标。最近英飞凌的PSoC 64标准安全MCU拿到PSA Certified Level 2认证消息出来之后不少同行都在群里聊但聊着聊着就跑偏了有人以为L2就是芯片很安全的盖章有人觉得认证过了就万事大吉。我觉得有必要把这个L2到底意味着什么、PSoC 64又是怎么做到的掰开揉碎聊一聊。1.1 从Level 0到Level 3认证梯度到底差在哪PSA Certified是Arm联合多家实验室、芯片厂商、系统集成商推出的安全认证体系它的前身是Arm在2017年发布的Platform Security Architecture平台安全架构。这套体系不是只有一个过/不过的判定而是分了四个层级每个层级考察的侧重点完全不同我画个表大家感受一下认证等级评估方式核心考察内容适合场景Level 1自评估安全清单产品对PSA安全模型的理解、威胁建模、安全流程概念验证、轻量级IoT设备Level 2第三方实验室评估安全机制的有效性包括安全启动、安全生命周期、隔离、密钥保护接入云端、处理业务数据的量产设备Level 3第三方实验室物理攻击测试抗侧信道、故障注入、芯片物理防护能力高价值资产、支付终端、关键基础设施Level 3专项物理防护针对特定攻击路径的深度评估军用、银行级场景关键点在这Level 1说白了还是你自己说自己安全的阶段到了Level 2才真正进入有第三方替你把关的阶段。PSoC 64拿到的L2认证表示它的安全方案经过了独立实验室的评估在安全启动、安全隔离、密钥保护、生命周期管理这些关键维度上确实做到了在软件层面无法被轻易攻破这个程度。注意L2还不涉及物理层面的侧信道和故障注入测试那是L3才会碰的东西。所以准确理解L2的定位就是面向量产物联网设备、以软件攻击为主要威胁模型的可靠安全等级。1.2 L2评估时实验室实际上在测什么很多人不知道L2认证的测试不是芯片厂商自己说了算也不是Arm拍板盖章就完事而是由独立的第三方安全实验室比如Brightsight、Riscure、UL这些实际操作。我有一年跟实验室打过几次交道可以分享一下他们的典型测试路径安全启动逆向分析检查启动过程的每一段代码确认不可信代码无法在启动早期注入。他们会盯着Boot ROM的每一条分支判断寻找绕过签名校验的路径。调试接口攻击面评估JTAG、SWD接口能否被非授权访问测试人员会尝试各种方式去建立调试连接试图读取安全域的内存。隔离机制穿透测试尝试在非安全域运行恶意代码看能不能通过侧信道日志、共享外设、DMA等方式触达安全域的敏感资源。固件更新流程篡改测试伪造一个固件包下发到设备看系统是否会拒绝安装还会尝试降级到旧版本固件检验回滚保护机制是否真的生效。密钥存储暴力破解/逻辑攻击试图通过各种方式从安全存储中导出密钥包括内存转储、缓存攻击、供电异常等。这些测试做完实验室会出一份详细的评估报告指出所有发现的漏洞和风险等级。如果发现中级以上问题芯片厂商必须修复后重新提交测试。所以PSoC 64这个L2认证背后实际上是经历了多轮发现问题—修复—复测的硬碰硬过程。这不是营销词汇而是真金白银的工程投入。2. PSoC 64如何从底层把安全做成了独立子系统聊完认证的宏观背景咱们落到具体芯片上。PSoC 64是英飞凌原赛普拉斯PSoC 6系列中的安全版本它最核心的设计思路是把安全功能从普通MCU的附加模块变成了独立子系统。这个思路跟传统MCU在安全上的做法有本质区别很多芯片是把安全功能塞进主核旁边靠软件库去调用但PSoC 64的做法是再造一个独立的执行环境让安全逻辑和业务逻辑在物理层面和逻辑层面都分开。这个设计从根上决定了它能过L2也决定了开发者在用它的时会遇到一些跟普通MCU完全不同的坑。2.1 双核架构下的安全域与非安全域切割先看PSoC 6的整体架构。PSoC 64内部有两个Arm Cortex-M内核一个主核Cortex-M4最高跑到150MHz负责跑业务逻辑一个从核Cortex-M0跑系统服务和安全相关工作。这两个核不是简单的大小核任务分工而是配合Arm TrustZone技术把整个芯片的逻辑运行环境切成了两个世界安全世界TrustZone Secure World运行安全固件、密钥管理、安全启动验证、加密运算等敏感操作。非安全世界TrustZone Normal World运行用户的RTOS、应用逻辑、通信协议栈。这两个世界之间通过TrustZone的硬件机制进行隔离。中断、内存、外设都会被标记为安全或非安全属性非安全世界的代码不能直接访问安全资源。有一种常见的误解是双核就是每个核各跑一边实际不是这样两个核都可以在安全/非安全世界之间切换TrustZone决定的是当前执行上下文能碰什么资源而不是某个核被锁死在某个世界里。从实际攻击面来看这套设计的价值在于就算你的业务代码跑在非安全世界被攻破了比如缓冲区溢出被利用了攻击者也只拿到非安全世界的权限这离拿到密钥、篡改固件还有一道很难跨越的隔离墙。L2实验室折腾半天很大程度上就是在测试这道隔离墙到底结不结实。2.2 Security Subsystem一颗芯片里的独立安全岛TrustZone只是逻辑隔离PSoC 64更狠的一招是硬件层面的Security Subsystem安全子系统。这个子系统不属于任何一个CPU核它是一组独立的硬件模块包括Crypto协处理器支持AES、RSA、ECC、SHA、TRNG等算法密钥可以留在片内不经过CPU。Secure Key Storage安全密钥存储密钥保存在专门的存储区域受硬件访问控制保护软件无法直接读取明文的密钥。Secure Boot ROM上电后第一个执行的代码负责验证固件签名的有效性。生命周期控制器Lifecycle Controller管理芯片从生产到设备生命周期结束的安全状态。这套子系统的独立性意味着就算主核被完全控制攻击者也无法直接调用安全子系统的加密能力来签名固件或者导出密钥。举个例子固件签名私钥放在Security Subsystem里应用层只能请求帮我用这个密钥对某个哈希值签名但永远拿不到私钥本身。这就像你把保险箱钥匙分别锁在银行金库的不同隔间里营业员可以帮你开保险箱但你自己一辈子碰不到金库总钥匙。2.3 安全启动从ROM复位到应用运行的信任根传递PSoC 64的安全启动链是L2认证里的重头戏值得好好说一下。整个启动流程可以简化成一条信任链Boot ROM固化在硅片中不可修改→Root of Trust固件→安全固件包→应用固件每一步都要验证下一段代码的数字签名只有验证通过才执行。而且验证是环环相扣的前面任何一环被篡改后续的启动就直接中止。具体的流程大致是这样芯片上电CPU从Boot ROM开始执行。Boot ROM检查eFuse里记录的安全策略决定是否加载固件、从哪个地址加载、允许哪些调试操作。加载Root of Trust固件时用芯片内置的公钥验证其签名这个公钥是出厂时烧进eFuse里的无法在运行时被修改。Root of Trust验证安全固件包的签名确认安全固件来自合法的固件链。安全固件验证用户应用固件的签名然后才把控制权交给应用。这条链路的每一环都有对应的密钥而且密钥数量不多需要开发者自己去生成和管理。平时开发调试阶段可以关闭签名校验但到了量产阶段必须完整打开。这里一定要注意量产固件的签名密钥一旦丢失或泄露整批设备的安全体系就崩了这个我在后面实操部分会专门讲。3. 通过L2考核的关键技术点密钥、存储与生命周期PSoC 64能过L2认证光有架构还不够得看具体的安全技术点做得扎不扎实。我研究过很多安全MCU的评估报告也在实际项目里被各种安全机制折磨过这里挑三个我认为最关键的点展开——密钥存储方案、生命周期状态机、固件升级回滚防护。这三个问题在L2实验室评估里都是必测项也是产品落地时最容易踩雷的地方。3.1 密钥怎么存才不算裸奔很多开发者第一次接触安全芯片会觉得我有AES加密了数据安全了但根本没想过密钥本身存哪儿。把密钥明文放在Flash里那加密就是掩耳盗铃固件被拖出来就能找到。在PSoC 64上密钥的管理逻辑是这样的密钥要么存储在Security Subsystem的专用Key Storage里要么由eFuse保护普通应用代码没有任何路径可以读取密钥的明文值。应用想用某个密钥做加解密通过PSA Crypto API发起请求Security Subsystem在内部完成运算只把结果返回给应用。密钥可以设置使用策略比如只允许加密、不允许解密或者只在特定生命周期状态下可用。有一个概念需要澄清PSA Crypto API是一套统一的软件接口不代表安全实现方式。PSoC 64把PSA API跑在Security Subsystem之上也就是说API调用的背后有硬件隔离兜底。这跟某些MCU只在软件层实现了PSA API、密钥还是存在普通Flash里的情况完全不同。选型的时候别只看支持PSA API这个宣传语要深挖一层密钥到底存在哪儿、由谁保护。3.2 生命周期状态机与RMA/设备返厂的处理PSoC 64的生命周期管理对很多工程师来说是第一次接触时会懵的概念。简单理解芯片的安全状态不是一成不变的而是跟着一个状态机走从出厂到量产再到用户使用状态逐步迁移每一步迁移都可能涉及权限的收紧或开放生命周期状态主要特征调试权限适用阶段SECURE_AUTH可执行安全配置允许恢复/重烧受限工厂烧录阶段SECURE安全启动完整启用调试默认关闭关闭量产设备交付RMA返厂维修专用状态允许厂商安全擦除受限设备返修这里有个细节很容易踩坑设备一旦从SECURE_AUTH切换到SECURE状态SWD调试口默认就关闭了。你说芯片变砖了想连个JTAG看看是怎么回事对不起没有任何厂商调试捷径。唯一的例外是设备进入了RMA状态原厂可以通过特殊的RMA流程把芯片恢复到可调试状态但是标准产品里用户自己是没有这个权限的。所以量产前的调试阶段一定要把调试接口的状态安排好。我们的常规做法是开发阶段用SECURE_AUTH状态跑完整测试到量产工装烧录脚本的最后一步统一切换到SECURE固件里加一个标志位在切换到SECURE前做一轮自检确保没问题再锁状态。3.3 回滚保护与固件升级安全L2实验室必测的另一个项目是固件升级安全性。攻击者最经典的招数之一是把一个旧版本的含漏洞固件塞回设备里利用新旧版本之间的差异来绕过安全检查。PSoC 64的安全升级机制里有两个层次的防护签名验证固件包必须用合法的私钥签名验签失败直接拒绝写入。回滚保护固件版本号保存在受保护的存储区通常是eFuse或安全Flash区域只允许递增不允许递减。就算攻击者拿到了一个旧版固件包只要版本号低于当前记录值照样被拒。实际操作中回滚保护会带来一个比较麻烦的产品体验问题OTA升级之后如果新固件有bug用户没法降级到上一版先顶着用。这在消费电子产品上尤其头疼。我的建议是在固件里做一个临时回滚区和稳定版备份区……不对PSoC 64的安全机制是不允许这种灵活的。更好的做法是每次OTA升级前先在测试环境完整验证固件确保没有致命问题再推给设备。安全芯片给了你强大的防护但同时也在逼你做好质量管理这本身就是一种取舍。4. 拿到认证之后普通开发者真正能用到什么前面讲了那么多架构和技术细节现在说点更贴近实际的PSoC 64过了L2认证对像我这样搞产品开发的工程师到底意味着什么毕竟芯片买回来不是用来晒认证的是要跑业务、连云端、做升级的。这一节我把认证转化为实际能力聊几个最常用的场景。4.1 云端连接证书安全注入流程物联网设备连云端最常见的安全做法是每个设备出厂时烧录一唯一的证书和密钥用于设备与云平台之间的身份认证。证书密钥的生成和烧录如果做得不严谨就等于把自家大门钥匙量产了。PSoC 64支持的安全能力让证书注入流程可以达到设备自己生成密钥对、自己签名CSR的程度设备在出厂阶段进入SECURE_AUTH状态内置的Security Subsystem生成一个ECC密钥对。私钥直接保存在Key Storage里永远不导出设备。公钥通过安全API导出由工厂系统拿去生成设备证书。设备证书写回Flash之后切换生命周期到SECURE状态出货。这套流程的价值在于私钥从未离开过芯片的硬件保护区即使工厂的生产电脑被入侵攻击者拿到的也只是公钥和证书无法伪造设备身份。我们当时用这个流程给网关产品做过证书烧录整个环节的安全体验比之前在ST芯片上写私钥进Flash的方式好了两个数量级。4.2 安全OTA与防回滚的工程实践OTA是物联网产品躲不开的需求但OTA也是最容易把设备搞成砖或者搞成肉鸡的入口。PSoC 64的L2安全能力把OTA的工程实践推到了一条更硬核的轨道上签名验证回滚保护隔离升级。我分享一下实际项目中搭OTA的推荐配置固件包签名使用ECDSA签名私钥离线保存在HSM里硬件安全模块签名脚本放在CI/CD流程中。升级包格式头信息固件镜像签名值头信息包含版本号、固件类型、目标槽位等。双槽位升级A/B双镜像机制新固件写入非激活槽验证通过后切换启动槽位。失败回滚策略因为防回滚存在不能依赖降级到旧版本所以必须在启动新固件后做自检自检失败就标记启动失败下次启动自动切回上一个可用的槽位。PSoC 64的安全性在这里是一把双刃剑。防回滚关上了降级漏洞的门但也关上了临时退回旧版的门。产品团队必须在发布策略上做足功夫比如灰度发布、小批量验证、远程日志监控确保推出去的固件不会变成用户手上的终身遗憾。4.3 调试接口关闭与生产配置的注意事项前面提到生命周期切换到SECURE之后调试口就关了。这一点在可量产性和可维护性之间制造了一个非常现实的张力。我从实际项目中总结出来的经验是CPU的SWD接口在生产测试时还有用比如烧录蓝牙固件、校准射频参数。所以不要在出厂前过早切换到SECURE。我建议把生命周期切换放在最后的出厂工位所有产能测试、校准、证书烧录都完成之后由产线软件统一执行状态切换。保留一个出厂测试固件的调试途径在SECURE_AUTH状态下烧录一个专门的测试固件测试通过后再烧正式固件并切换状态。这块如果流程没设计好最坏的结果就是——设备都封装好了突然发现射频校准漏做了一步但芯片已经进入SECURE状态没法再调试整批返工。所以流程里的每一道工序都得排顺序。5. 实战复盘在ModusToolBox上做安全固件开发的经验理论聊了不少我知道大家最需要的是实操层面的干货。PSoC 64开发跟普通MCU开发有明显差异安全机制多了一层坑也就多了一批。这一节我把在ModusToolBox上做PSoC 64安全固件开发的经验拉出来复盘一遍。5.1 工具链与项目结构开发PSoC 64官方推荐的IDE是ModusToolBox基于Eclipse做的支持Windows/Linux/macOS。它的项目结构跟STM32CubeMX工程类似也有一个设备配置器来生成初始化代码但多了一个安全相关的配置面板CySecureTools。项目里有两个跟安全强相关的目录很多人会忽略security/存放密钥、证书、固件签名相关的配置和输出。application/存放用户应用源码。第一次建PSoC 64工程时最容易被绕晕的是构建流程默认情况下ModusToolBox编译代码时会在中间环节执行CySecureTools去生成并签名固件包。这意味着你的电脑上必须配置好一套可用的密钥和证书否则编译会报错。很多初学者在这步就卡住了报错信息看得一头雾水。解决方法是把工程自带的默认密钥先用起来跑通了再换自己的正式密钥。5.2 证书生成与签名流程PSoC 64的应用固件签名和证书链管理是绕不开的环节。标准的证书链结构大致是根证书自签名最顶层的信任锚对应的私钥保存在HSM中不进入开发环境。固件签名证书由根证书签发用于签具体固件包。中间证书有些产品为了密钥轮换会再加一层中间证书。生成这套证书用到的命令跟我们平时做HTTPS证书差不多整理一下我常用的流程# 1. 生成根密钥和根证书 openssl ecparam -name prime256v1 -genkey -noout -out root.key.pem openssl req -new -x509 -key root.key.pem -out root.cert.pem -days 3650 -subj /CNPSoC64 Root CA # 2. 生成固件签名密钥和证书签名请求 openssl ecparam -name prime256v1 -genkey -noout -out signing.key.pem openssl req -new -key signing.key.pem -out signing.csr -subj /CNPSoC64 Firmware Signer # 3. 用根证书签发固件签名证书 openssl x509 -req -in signing.csr -CA root.cert.pem -CAkey root.key.pem -CAcreateserial -out signing.cert.pem -days 730 # 4. 将密钥转换成PSoC 64安全工具需要的格式 # 这一步通常在ModusToolBox的CySecureTools里通过图形界面配置完成有一个细节很重要签名算法建议用ECC P-256。虽然RSA也支持但是ECC在物联网设备上计算更快、密钥更短且PSoC 64的Crypto协处理器对ECC支持很成熟。实际项目中坑得最狠的地方是这个不要把私钥文件留在开发电脑的工程目录里。我们曾经有个项目开发工程师为了方便把固件签名私钥直接丢在工程源码里结果源码被推到Git仓库私钥裸奔了。后来及时发现更换了密钥对但这事如果发生在量产阶段后果不堪设想。我现在的习惯是本地开发用一个临时的测试密钥对只用来跑通流程。正式密钥放在HSM或离线机器上签名操作通过独立的签名服务完成绝不能进代码仓库。5.3 实测中遇到的坑日志输出、中断隔离、eFuse烧录再分享几个我实测PSoC 64时踩过、也花了不少时间才爬出来的坑。第一个坑安全域和非安全域之间的日志输出问题。PSoC 64上安全固件跑在Secure World应用跑在Normal World但很多人用的是同一个串口输出日志。如果安全固件和应用固件同时往同一个UART写数据会相互干扰输出乱码。而且更麻烦的是安全固件的日志输出还要考虑安全性——随便把安全固件的调试日志都打印出来等于把安全状态广播给所有人。我的做法是发布版本里把安全固件的日志等级调到最低只在非安全域保留应用层的日志。第二个坑中断处理的分域问题。TrustZone隔离下同一个外设的中断可能被路由到Secure World或Normal World配置不对会导致中断丢失或者一直触发。有一次我们的I2C外设中断没响应最后排查了半天发现中断源被配置成了Secure但ISR在Normal World注册两者不匹配。所以配置外设中断时一定要明确这个外设归哪个世界管。第三个坑eFuse烧录是单向操作烧错了就改不回来。PSoC 64的关键配置信息比如根公钥的哈希、安全策略的开关都是通过eFuse烧录的。这个跟Flash不一样不是写了可以擦掉重写而是物理熔丝断掉了就没法恢复。所以量产流程里必须有一个独立的eFuse策略复查步骤最好由专人复核之后再执行烧录。6. 横向对比PSoC 64和同类安全MCU的差异点文章最后一部分我想把PSoC 64放到同类产品里做一次横向对比。毕竟很多人选型时会同时看好几个方案不只是盯着某一家。跟它形成竞争关系的主要是ST的STM32L5/U5系列、NXP的LPC55xx系列、以及Silicon Labs的EFM32系列。6.1 与STM32L5、EFM32等主流安全MCU的关键差异我用一个表格把几个核心维度放一起对比对比维度PSoC 64STM32L5/U5NXP LPC55xxEFM32安全隔离方案TrustZone 独立Security SubsystemTrustZone TrustZone相关的安全外设TrustZone PrinkeyTrustZone安全启动ROM级验证Boot ROM 固件链签名支持安全启动但启动链代码需要自己实现/集成TF-M支持安全启动Converged Security相对简单部分型号安全启动不是强项密钥存储独立Security Subsystem硬件保护依赖PKC/OTP但不在独立子系统中内置安全密钥存储普通Flash/OTP为主PSA L2认证已通过部分型号有PSA L2认证如STM32L5的SESIP 3级对应部分型号有PSA L2认证情况相对少开发生态ModusToolBox、PSoC 6 HALSTM32CubeMX、TF-M、Azure RTOSMCUXpresso、TF-MSimplicity Studio性价比中等偏高安全功能集成度高型号丰富成本灵活中高功耗场景有优势从安全架构角度PSoC 64最大的不同在于独立的Security Subsystem。ST和NXP的方案更多的还是依赖TrustZone加安全启动以及一组安全外设的组合但安全运算、密钥存储、生命周期管理还是散布在芯片各处由软件来调度。PSoC 64把这一块集中到了一组专用的硬件模块里攻击面更小安全性更容易验证这也是为什么它敢直接申明PSA L2认证而且在实际评估里能通过的原因。不要误解不是说其他家不行而是说PSA L2认证这个结果对很多不太熟悉安全方案评估的团队来说是一个很好的参考锚点。它等于帮你做了一次第三方的安全面审查你要做的只是在这个基础上根据应用场景去补充额外需求比如是否有物理攻击威胁、是否有合规要求等。6.2 自研安全方案 vs 采购认证安全MCU怎么选还有一个动不动被人问起的问题我能不能自己写一套安全的启动和密钥管理方案省掉买安全MCU的钱我的回答是看你的团队规模和风险承受能力。自研安全方案听上去很酷实际上是在给公司挖坑安全领域最大的难点不是写代码而是你不知道你不知道什么。有一个经典说法是自研密码算法的人基本都会掉进自以为安全的陷阱里。L2认证对实验室设备、测试方法、专家经验的要求很高不是有个工程师看几篇论文就能搞定的事。自研方案的维护成本是隐性的每次芯片换型号、工具链升级、密码学算法淘汰都得重新适配和审计。我见过几个自研安全方案的项目无一例外都出现了严重的安全问题比如密钥硬编码在固件里、随机数生成器没有真正随机、启动验证的某个分支可以被跳过等等。这些漏洞不是开发者笨而是安全问题实在太容易默认觉得没问题了。反过来采购一款已经过了PSA L2认证的安全MCU等于把安全实现这个最烧脑的部分外包给了专业团队你只需要专注于业务逻辑和管理好密钥流程。这笔账算清楚了就知道值不值。说实话PSoC 64这个L2认证给我的直观判断不是它比其他MCU安全一万倍而是它在安全这件事上给到一个普通开发团队可以信任的基线。在这个行业里能有一个可靠的基线就已经比很多产品走得更远了。 PSoC 64通过PSA L2认证：安全架构与物联网实践解析
1. 认证证书的含金量PSA L2在物联网安全体系中的真实分量说句实在话做物联网嵌入式的这些年我越来越觉得安全这个东西在圈子里的处境很尴尬。一方面云平台、网关、设备商口头上都在喊安全是底线另一方面到了产品定义阶段硬件成本、功耗、上市周期往往把安全需求一路往后挤。在这种背景下PSA Certified认证等级就成了一个很关键的参照系——它不是给开发者看的花架子而是能直接影响选型决策的硬指标。最近英飞凌的PSoC 64标准安全MCU拿到PSA Certified Level 2认证消息出来之后不少同行都在群里聊但聊着聊着就跑偏了有人以为L2就是芯片很安全的盖章有人觉得认证过了就万事大吉。我觉得有必要把这个L2到底意味着什么、PSoC 64又是怎么做到的掰开揉碎聊一聊。1.1 从Level 0到Level 3认证梯度到底差在哪PSA Certified是Arm联合多家实验室、芯片厂商、系统集成商推出的安全认证体系它的前身是Arm在2017年发布的Platform Security Architecture平台安全架构。这套体系不是只有一个过/不过的判定而是分了四个层级每个层级考察的侧重点完全不同我画个表大家感受一下认证等级评估方式核心考察内容适合场景Level 1自评估安全清单产品对PSA安全模型的理解、威胁建模、安全流程概念验证、轻量级IoT设备Level 2第三方实验室评估安全机制的有效性包括安全启动、安全生命周期、隔离、密钥保护接入云端、处理业务数据的量产设备Level 3第三方实验室物理攻击测试抗侧信道、故障注入、芯片物理防护能力高价值资产、支付终端、关键基础设施Level 3专项物理防护针对特定攻击路径的深度评估军用、银行级场景关键点在这Level 1说白了还是你自己说自己安全的阶段到了Level 2才真正进入有第三方替你把关的阶段。PSoC 64拿到的L2认证表示它的安全方案经过了独立实验室的评估在安全启动、安全隔离、密钥保护、生命周期管理这些关键维度上确实做到了在软件层面无法被轻易攻破这个程度。注意L2还不涉及物理层面的侧信道和故障注入测试那是L3才会碰的东西。所以准确理解L2的定位就是面向量产物联网设备、以软件攻击为主要威胁模型的可靠安全等级。1.2 L2评估时实验室实际上在测什么很多人不知道L2认证的测试不是芯片厂商自己说了算也不是Arm拍板盖章就完事而是由独立的第三方安全实验室比如Brightsight、Riscure、UL这些实际操作。我有一年跟实验室打过几次交道可以分享一下他们的典型测试路径安全启动逆向分析检查启动过程的每一段代码确认不可信代码无法在启动早期注入。他们会盯着Boot ROM的每一条分支判断寻找绕过签名校验的路径。调试接口攻击面评估JTAG、SWD接口能否被非授权访问测试人员会尝试各种方式去建立调试连接试图读取安全域的内存。隔离机制穿透测试尝试在非安全域运行恶意代码看能不能通过侧信道日志、共享外设、DMA等方式触达安全域的敏感资源。固件更新流程篡改测试伪造一个固件包下发到设备看系统是否会拒绝安装还会尝试降级到旧版本固件检验回滚保护机制是否真的生效。密钥存储暴力破解/逻辑攻击试图通过各种方式从安全存储中导出密钥包括内存转储、缓存攻击、供电异常等。这些测试做完实验室会出一份详细的评估报告指出所有发现的漏洞和风险等级。如果发现中级以上问题芯片厂商必须修复后重新提交测试。所以PSoC 64这个L2认证背后实际上是经历了多轮发现问题—修复—复测的硬碰硬过程。这不是营销词汇而是真金白银的工程投入。2. PSoC 64如何从底层把安全做成了独立子系统聊完认证的宏观背景咱们落到具体芯片上。PSoC 64是英飞凌原赛普拉斯PSoC 6系列中的安全版本它最核心的设计思路是把安全功能从普通MCU的附加模块变成了独立子系统。这个思路跟传统MCU在安全上的做法有本质区别很多芯片是把安全功能塞进主核旁边靠软件库去调用但PSoC 64的做法是再造一个独立的执行环境让安全逻辑和业务逻辑在物理层面和逻辑层面都分开。这个设计从根上决定了它能过L2也决定了开发者在用它的时会遇到一些跟普通MCU完全不同的坑。2.1 双核架构下的安全域与非安全域切割先看PSoC 6的整体架构。PSoC 64内部有两个Arm Cortex-M内核一个主核Cortex-M4最高跑到150MHz负责跑业务逻辑一个从核Cortex-M0跑系统服务和安全相关工作。这两个核不是简单的大小核任务分工而是配合Arm TrustZone技术把整个芯片的逻辑运行环境切成了两个世界安全世界TrustZone Secure World运行安全固件、密钥管理、安全启动验证、加密运算等敏感操作。非安全世界TrustZone Normal World运行用户的RTOS、应用逻辑、通信协议栈。这两个世界之间通过TrustZone的硬件机制进行隔离。中断、内存、外设都会被标记为安全或非安全属性非安全世界的代码不能直接访问安全资源。有一种常见的误解是双核就是每个核各跑一边实际不是这样两个核都可以在安全/非安全世界之间切换TrustZone决定的是当前执行上下文能碰什么资源而不是某个核被锁死在某个世界里。从实际攻击面来看这套设计的价值在于就算你的业务代码跑在非安全世界被攻破了比如缓冲区溢出被利用了攻击者也只拿到非安全世界的权限这离拿到密钥、篡改固件还有一道很难跨越的隔离墙。L2实验室折腾半天很大程度上就是在测试这道隔离墙到底结不结实。2.2 Security Subsystem一颗芯片里的独立安全岛TrustZone只是逻辑隔离PSoC 64更狠的一招是硬件层面的Security Subsystem安全子系统。这个子系统不属于任何一个CPU核它是一组独立的硬件模块包括Crypto协处理器支持AES、RSA、ECC、SHA、TRNG等算法密钥可以留在片内不经过CPU。Secure Key Storage安全密钥存储密钥保存在专门的存储区域受硬件访问控制保护软件无法直接读取明文的密钥。Secure Boot ROM上电后第一个执行的代码负责验证固件签名的有效性。生命周期控制器Lifecycle Controller管理芯片从生产到设备生命周期结束的安全状态。这套子系统的独立性意味着就算主核被完全控制攻击者也无法直接调用安全子系统的加密能力来签名固件或者导出密钥。举个例子固件签名私钥放在Security Subsystem里应用层只能请求帮我用这个密钥对某个哈希值签名但永远拿不到私钥本身。这就像你把保险箱钥匙分别锁在银行金库的不同隔间里营业员可以帮你开保险箱但你自己一辈子碰不到金库总钥匙。2.3 安全启动从ROM复位到应用运行的信任根传递PSoC 64的安全启动链是L2认证里的重头戏值得好好说一下。整个启动流程可以简化成一条信任链Boot ROM固化在硅片中不可修改→Root of Trust固件→安全固件包→应用固件每一步都要验证下一段代码的数字签名只有验证通过才执行。而且验证是环环相扣的前面任何一环被篡改后续的启动就直接中止。具体的流程大致是这样芯片上电CPU从Boot ROM开始执行。Boot ROM检查eFuse里记录的安全策略决定是否加载固件、从哪个地址加载、允许哪些调试操作。加载Root of Trust固件时用芯片内置的公钥验证其签名这个公钥是出厂时烧进eFuse里的无法在运行时被修改。Root of Trust验证安全固件包的签名确认安全固件来自合法的固件链。安全固件验证用户应用固件的签名然后才把控制权交给应用。这条链路的每一环都有对应的密钥而且密钥数量不多需要开发者自己去生成和管理。平时开发调试阶段可以关闭签名校验但到了量产阶段必须完整打开。这里一定要注意量产固件的签名密钥一旦丢失或泄露整批设备的安全体系就崩了这个我在后面实操部分会专门讲。3. 通过L2考核的关键技术点密钥、存储与生命周期PSoC 64能过L2认证光有架构还不够得看具体的安全技术点做得扎不扎实。我研究过很多安全MCU的评估报告也在实际项目里被各种安全机制折磨过这里挑三个我认为最关键的点展开——密钥存储方案、生命周期状态机、固件升级回滚防护。这三个问题在L2实验室评估里都是必测项也是产品落地时最容易踩雷的地方。3.1 密钥怎么存才不算裸奔很多开发者第一次接触安全芯片会觉得我有AES加密了数据安全了但根本没想过密钥本身存哪儿。把密钥明文放在Flash里那加密就是掩耳盗铃固件被拖出来就能找到。在PSoC 64上密钥的管理逻辑是这样的密钥要么存储在Security Subsystem的专用Key Storage里要么由eFuse保护普通应用代码没有任何路径可以读取密钥的明文值。应用想用某个密钥做加解密通过PSA Crypto API发起请求Security Subsystem在内部完成运算只把结果返回给应用。密钥可以设置使用策略比如只允许加密、不允许解密或者只在特定生命周期状态下可用。有一个概念需要澄清PSA Crypto API是一套统一的软件接口不代表安全实现方式。PSoC 64把PSA API跑在Security Subsystem之上也就是说API调用的背后有硬件隔离兜底。这跟某些MCU只在软件层实现了PSA API、密钥还是存在普通Flash里的情况完全不同。选型的时候别只看支持PSA API这个宣传语要深挖一层密钥到底存在哪儿、由谁保护。3.2 生命周期状态机与RMA/设备返厂的处理PSoC 64的生命周期管理对很多工程师来说是第一次接触时会懵的概念。简单理解芯片的安全状态不是一成不变的而是跟着一个状态机走从出厂到量产再到用户使用状态逐步迁移每一步迁移都可能涉及权限的收紧或开放生命周期状态主要特征调试权限适用阶段SECURE_AUTH可执行安全配置允许恢复/重烧受限工厂烧录阶段SECURE安全启动完整启用调试默认关闭关闭量产设备交付RMA返厂维修专用状态允许厂商安全擦除受限设备返修这里有个细节很容易踩坑设备一旦从SECURE_AUTH切换到SECURE状态SWD调试口默认就关闭了。你说芯片变砖了想连个JTAG看看是怎么回事对不起没有任何厂商调试捷径。唯一的例外是设备进入了RMA状态原厂可以通过特殊的RMA流程把芯片恢复到可调试状态但是标准产品里用户自己是没有这个权限的。所以量产前的调试阶段一定要把调试接口的状态安排好。我们的常规做法是开发阶段用SECURE_AUTH状态跑完整测试到量产工装烧录脚本的最后一步统一切换到SECURE固件里加一个标志位在切换到SECURE前做一轮自检确保没问题再锁状态。3.3 回滚保护与固件升级安全L2实验室必测的另一个项目是固件升级安全性。攻击者最经典的招数之一是把一个旧版本的含漏洞固件塞回设备里利用新旧版本之间的差异来绕过安全检查。PSoC 64的安全升级机制里有两个层次的防护签名验证固件包必须用合法的私钥签名验签失败直接拒绝写入。回滚保护固件版本号保存在受保护的存储区通常是eFuse或安全Flash区域只允许递增不允许递减。就算攻击者拿到了一个旧版固件包只要版本号低于当前记录值照样被拒。实际操作中回滚保护会带来一个比较麻烦的产品体验问题OTA升级之后如果新固件有bug用户没法降级到上一版先顶着用。这在消费电子产品上尤其头疼。我的建议是在固件里做一个临时回滚区和稳定版备份区……不对PSoC 64的安全机制是不允许这种灵活的。更好的做法是每次OTA升级前先在测试环境完整验证固件确保没有致命问题再推给设备。安全芯片给了你强大的防护但同时也在逼你做好质量管理这本身就是一种取舍。4. 拿到认证之后普通开发者真正能用到什么前面讲了那么多架构和技术细节现在说点更贴近实际的PSoC 64过了L2认证对像我这样搞产品开发的工程师到底意味着什么毕竟芯片买回来不是用来晒认证的是要跑业务、连云端、做升级的。这一节我把认证转化为实际能力聊几个最常用的场景。4.1 云端连接证书安全注入流程物联网设备连云端最常见的安全做法是每个设备出厂时烧录一唯一的证书和密钥用于设备与云平台之间的身份认证。证书密钥的生成和烧录如果做得不严谨就等于把自家大门钥匙量产了。PSoC 64支持的安全能力让证书注入流程可以达到设备自己生成密钥对、自己签名CSR的程度设备在出厂阶段进入SECURE_AUTH状态内置的Security Subsystem生成一个ECC密钥对。私钥直接保存在Key Storage里永远不导出设备。公钥通过安全API导出由工厂系统拿去生成设备证书。设备证书写回Flash之后切换生命周期到SECURE状态出货。这套流程的价值在于私钥从未离开过芯片的硬件保护区即使工厂的生产电脑被入侵攻击者拿到的也只是公钥和证书无法伪造设备身份。我们当时用这个流程给网关产品做过证书烧录整个环节的安全体验比之前在ST芯片上写私钥进Flash的方式好了两个数量级。4.2 安全OTA与防回滚的工程实践OTA是物联网产品躲不开的需求但OTA也是最容易把设备搞成砖或者搞成肉鸡的入口。PSoC 64的L2安全能力把OTA的工程实践推到了一条更硬核的轨道上签名验证回滚保护隔离升级。我分享一下实际项目中搭OTA的推荐配置固件包签名使用ECDSA签名私钥离线保存在HSM里硬件安全模块签名脚本放在CI/CD流程中。升级包格式头信息固件镜像签名值头信息包含版本号、固件类型、目标槽位等。双槽位升级A/B双镜像机制新固件写入非激活槽验证通过后切换启动槽位。失败回滚策略因为防回滚存在不能依赖降级到旧版本所以必须在启动新固件后做自检自检失败就标记启动失败下次启动自动切回上一个可用的槽位。PSoC 64的安全性在这里是一把双刃剑。防回滚关上了降级漏洞的门但也关上了临时退回旧版的门。产品团队必须在发布策略上做足功夫比如灰度发布、小批量验证、远程日志监控确保推出去的固件不会变成用户手上的终身遗憾。4.3 调试接口关闭与生产配置的注意事项前面提到生命周期切换到SECURE之后调试口就关了。这一点在可量产性和可维护性之间制造了一个非常现实的张力。我从实际项目中总结出来的经验是CPU的SWD接口在生产测试时还有用比如烧录蓝牙固件、校准射频参数。所以不要在出厂前过早切换到SECURE。我建议把生命周期切换放在最后的出厂工位所有产能测试、校准、证书烧录都完成之后由产线软件统一执行状态切换。保留一个出厂测试固件的调试途径在SECURE_AUTH状态下烧录一个专门的测试固件测试通过后再烧正式固件并切换状态。这块如果流程没设计好最坏的结果就是——设备都封装好了突然发现射频校准漏做了一步但芯片已经进入SECURE状态没法再调试整批返工。所以流程里的每一道工序都得排顺序。5. 实战复盘在ModusToolBox上做安全固件开发的经验理论聊了不少我知道大家最需要的是实操层面的干货。PSoC 64开发跟普通MCU开发有明显差异安全机制多了一层坑也就多了一批。这一节我把在ModusToolBox上做PSoC 64安全固件开发的经验拉出来复盘一遍。5.1 工具链与项目结构开发PSoC 64官方推荐的IDE是ModusToolBox基于Eclipse做的支持Windows/Linux/macOS。它的项目结构跟STM32CubeMX工程类似也有一个设备配置器来生成初始化代码但多了一个安全相关的配置面板CySecureTools。项目里有两个跟安全强相关的目录很多人会忽略security/存放密钥、证书、固件签名相关的配置和输出。application/存放用户应用源码。第一次建PSoC 64工程时最容易被绕晕的是构建流程默认情况下ModusToolBox编译代码时会在中间环节执行CySecureTools去生成并签名固件包。这意味着你的电脑上必须配置好一套可用的密钥和证书否则编译会报错。很多初学者在这步就卡住了报错信息看得一头雾水。解决方法是把工程自带的默认密钥先用起来跑通了再换自己的正式密钥。5.2 证书生成与签名流程PSoC 64的应用固件签名和证书链管理是绕不开的环节。标准的证书链结构大致是根证书自签名最顶层的信任锚对应的私钥保存在HSM中不进入开发环境。固件签名证书由根证书签发用于签具体固件包。中间证书有些产品为了密钥轮换会再加一层中间证书。生成这套证书用到的命令跟我们平时做HTTPS证书差不多整理一下我常用的流程# 1. 生成根密钥和根证书 openssl ecparam -name prime256v1 -genkey -noout -out root.key.pem openssl req -new -x509 -key root.key.pem -out root.cert.pem -days 3650 -subj /CNPSoC64 Root CA # 2. 生成固件签名密钥和证书签名请求 openssl ecparam -name prime256v1 -genkey -noout -out signing.key.pem openssl req -new -key signing.key.pem -out signing.csr -subj /CNPSoC64 Firmware Signer # 3. 用根证书签发固件签名证书 openssl x509 -req -in signing.csr -CA root.cert.pem -CAkey root.key.pem -CAcreateserial -out signing.cert.pem -days 730 # 4. 将密钥转换成PSoC 64安全工具需要的格式 # 这一步通常在ModusToolBox的CySecureTools里通过图形界面配置完成有一个细节很重要签名算法建议用ECC P-256。虽然RSA也支持但是ECC在物联网设备上计算更快、密钥更短且PSoC 64的Crypto协处理器对ECC支持很成熟。实际项目中坑得最狠的地方是这个不要把私钥文件留在开发电脑的工程目录里。我们曾经有个项目开发工程师为了方便把固件签名私钥直接丢在工程源码里结果源码被推到Git仓库私钥裸奔了。后来及时发现更换了密钥对但这事如果发生在量产阶段后果不堪设想。我现在的习惯是本地开发用一个临时的测试密钥对只用来跑通流程。正式密钥放在HSM或离线机器上签名操作通过独立的签名服务完成绝不能进代码仓库。5.3 实测中遇到的坑日志输出、中断隔离、eFuse烧录再分享几个我实测PSoC 64时踩过、也花了不少时间才爬出来的坑。第一个坑安全域和非安全域之间的日志输出问题。PSoC 64上安全固件跑在Secure World应用跑在Normal World但很多人用的是同一个串口输出日志。如果安全固件和应用固件同时往同一个UART写数据会相互干扰输出乱码。而且更麻烦的是安全固件的日志输出还要考虑安全性——随便把安全固件的调试日志都打印出来等于把安全状态广播给所有人。我的做法是发布版本里把安全固件的日志等级调到最低只在非安全域保留应用层的日志。第二个坑中断处理的分域问题。TrustZone隔离下同一个外设的中断可能被路由到Secure World或Normal World配置不对会导致中断丢失或者一直触发。有一次我们的I2C外设中断没响应最后排查了半天发现中断源被配置成了Secure但ISR在Normal World注册两者不匹配。所以配置外设中断时一定要明确这个外设归哪个世界管。第三个坑eFuse烧录是单向操作烧错了就改不回来。PSoC 64的关键配置信息比如根公钥的哈希、安全策略的开关都是通过eFuse烧录的。这个跟Flash不一样不是写了可以擦掉重写而是物理熔丝断掉了就没法恢复。所以量产流程里必须有一个独立的eFuse策略复查步骤最好由专人复核之后再执行烧录。6. 横向对比PSoC 64和同类安全MCU的差异点文章最后一部分我想把PSoC 64放到同类产品里做一次横向对比。毕竟很多人选型时会同时看好几个方案不只是盯着某一家。跟它形成竞争关系的主要是ST的STM32L5/U5系列、NXP的LPC55xx系列、以及Silicon Labs的EFM32系列。6.1 与STM32L5、EFM32等主流安全MCU的关键差异我用一个表格把几个核心维度放一起对比对比维度PSoC 64STM32L5/U5NXP LPC55xxEFM32安全隔离方案TrustZone 独立Security SubsystemTrustZone TrustZone相关的安全外设TrustZone PrinkeyTrustZone安全启动ROM级验证Boot ROM 固件链签名支持安全启动但启动链代码需要自己实现/集成TF-M支持安全启动Converged Security相对简单部分型号安全启动不是强项密钥存储独立Security Subsystem硬件保护依赖PKC/OTP但不在独立子系统中内置安全密钥存储普通Flash/OTP为主PSA L2认证已通过部分型号有PSA L2认证如STM32L5的SESIP 3级对应部分型号有PSA L2认证情况相对少开发生态ModusToolBox、PSoC 6 HALSTM32CubeMX、TF-M、Azure RTOSMCUXpresso、TF-MSimplicity Studio性价比中等偏高安全功能集成度高型号丰富成本灵活中高功耗场景有优势从安全架构角度PSoC 64最大的不同在于独立的Security Subsystem。ST和NXP的方案更多的还是依赖TrustZone加安全启动以及一组安全外设的组合但安全运算、密钥存储、生命周期管理还是散布在芯片各处由软件来调度。PSoC 64把这一块集中到了一组专用的硬件模块里攻击面更小安全性更容易验证这也是为什么它敢直接申明PSA L2认证而且在实际评估里能通过的原因。不要误解不是说其他家不行而是说PSA L2认证这个结果对很多不太熟悉安全方案评估的团队来说是一个很好的参考锚点。它等于帮你做了一次第三方的安全面审查你要做的只是在这个基础上根据应用场景去补充额外需求比如是否有物理攻击威胁、是否有合规要求等。6.2 自研安全方案 vs 采购认证安全MCU怎么选还有一个动不动被人问起的问题我能不能自己写一套安全的启动和密钥管理方案省掉买安全MCU的钱我的回答是看你的团队规模和风险承受能力。自研安全方案听上去很酷实际上是在给公司挖坑安全领域最大的难点不是写代码而是你不知道你不知道什么。有一个经典说法是自研密码算法的人基本都会掉进自以为安全的陷阱里。L2认证对实验室设备、测试方法、专家经验的要求很高不是有个工程师看几篇论文就能搞定的事。自研方案的维护成本是隐性的每次芯片换型号、工具链升级、密码学算法淘汰都得重新适配和审计。我见过几个自研安全方案的项目无一例外都出现了严重的安全问题比如密钥硬编码在固件里、随机数生成器没有真正随机、启动验证的某个分支可以被跳过等等。这些漏洞不是开发者笨而是安全问题实在太容易默认觉得没问题了。反过来采购一款已经过了PSA L2认证的安全MCU等于把安全实现这个最烧脑的部分外包给了专业团队你只需要专注于业务逻辑和管理好密钥流程。这笔账算清楚了就知道值不值。说实话PSoC 64这个L2认证给我的直观判断不是它比其他MCU安全一万倍而是它在安全这件事上给到一个普通开发团队可以信任的基线。在这个行业里能有一个可靠的基线就已经比很多产品走得更远了。