上周参加了一场围绕Arm PSA安全架构与汽车数字钥匙的小型技术研讨会。会议规模不大但议题扎心数字钥匙把传统车钥匙从一个物理物件变成了手机里的数据资产可很多做钥匙业务的团队对“安全实践”的理解还停留在“用了TEE就算安全”的层面。活动开场主持人放了一段录像——用一台巴掌大的信号转发装置在停车场里直接把一辆支持数字钥匙的演示车解锁开走了整个过程不到三秒。录像放完会场安静了几秒。就是这几秒钟把一个核心问题摆到了所有人面前当车钥匙变成芯片里的数据Arm PSA安全架构这套东西到底能帮我们把哪几道门守住这场研讨会给我的感觉不太像常规的产品发布会更像一次把安全架构师、车联网团队和芯片原厂工程师凑到一起的“过堂”。几个关键话题都很有代表性PSA到底解决什么问题、数字钥匙的密钥应该放在哪、TEE和独立安全芯片怎么分工、落地时会被哪些工程细节绊倒。我结合现场讨论和自己做数字钥匙项目踩过的坑把有价值的内容整理成一篇相对完整的笔记。1. 数字钥匙的威胁面钥匙从实体变成数据后攻击方式完全变了1.1 数字钥匙不是“手机里多了一把钥匙”而是多了一整套业务链路过去用物理钥匙威胁模型相对简单——无非是钥匙被复制、被抢、被锁在车里。换成数字钥匙之后整个链路变成了用户手机App向云端申请钥匙、云端签发凭证、凭证下载到手机安全存储、手机靠近车辆时通过NFC/BLE/UWB与车端握手、车辆验签后执行解锁或启动。任何一个环节出问题都可能让“开锁”这件事失控。研讨会上有人总结得很到位数字钥匙的安全实践本质上是给“手机-云端-车机-安全芯片”这条链路上的每一跳都设置可验证的信任边界。这里借用PSA常用的方法先给数字钥匙画了一张资产图核心资产数字钥匙私钥、证书链、密钥版本号、使用状态传输链路手机与车之间的蓝牙/UWB/NFC通道、手机与云端的TLS通道载体环境手机App运行的应用处理器AP、可信执行环境TEE、独立安全单元SE物理环境手机丢失、维修、越狱后的设备甚至被拆解分析1.2 研讨会上演示的中继攻击本质是把“距离”骗了活动上讨论最热烈的攻击方式是中继攻击Relay Attack。它不破解任何密码学算法而是同时靠近车辆和手机的两个攻击者协同把车端和手机端的无线信号实时转发。车端感受到的信号强度、响应速度都跟“钥匙就在身边”几乎一致于是就直接放行了。现场演示让人印象深刻的不是攻击多复杂而是中继攻击对NFC和BLE数字钥匙的威胁几乎是结构性的。NFC的通信距离短中继设备可以做成一个超薄的“桥接贴片”BLE的通信距离远中继设备甚至可以放在停车场另一个角落。有工程师提出“把信号强度做成阈值判断不就行了”这个说法被车厂安全负责人直接否了信号强度受天线方向、车身金属遮蔽、人体遮挡、电池电量影响极大阈值定高了用户经常解不了锁定低了中继攻击照样过。后来话题转到UWB超宽带测距UWB用飞行时间ToF做物理层测距中继链路会引入额外纳秒级延迟理论上更容易被识别。但现场也达成一个共识UWB只是给安全增加了一层物理约束如果不做往返认证、不把测距结果纳入解锁判定条件最终结果依然是“看似安全实际裸奔”。1.3 三种数字钥匙通信路径的威胁面对比拿一张表整理现场讨论的威胁差异技术路径主要优势核心威胁安全实践思路NFC近场物理接触使用直觉强中继桥接、信号放大距离约束安全报文SE存储私钥BLE连接建立快功耗低中继攻击、重放攻击、嗅探双向认证、随机挑战值、频繁换临时密钥UWB物理层ToF测距精度高测距结果未参与判定、旁路攻击将ToF测距与业务状态机强绑定这张表基本框定了后面所有讨论的范围数字钥匙的安全实践不是在某个单点加一个加密算法而是要把每种通信路径下的威胁模型都梳理清楚再决定信任根放在哪、认证怎么做、密钥怎么管。2. PSA安全架构到底在讲什么它不是TrustZone的另一个名字2.1 一个很常见的误解PSA不等于TrustZone研讨会上有人问了个很典型的问题“我们已经用了带TrustZone的芯片是不是等于满足PSA要求了”答案是否定的。Arm PSAPlatform Security Architecture是一套从分析、设计、实现到认证的完整安全框架TrustZone只是它在某些芯片上的硬件隔离手段之一。PSA并不强求你用具体某一种硬件能力也没有规定必须跑MbedTLS还是TF-M。它的核心价值是让一个开发团队不再从零开始回答“什么算安全”“怎么做才算到位”这种模糊问题。换句话说TrustZone给了你一把“隔离手术刀”但PSA才告诉你手术该在哪些部位下刀、下刀后怎么验收。数字钥匙项目尤其需要这套方法论因为这个业务里“安全的定义”随时会跟用户体验打架既要让用户拿起手机就能解锁又要防止十几米外的攻击者转发信号把车开走。2.2 从Analyze到CertifyPSA四个阶段怎么落到数字钥匙上PSA把安全开发流程拆成四个阶段现场用数字钥匙场景逐个过了一遍Analyze分析做威胁建模明确资产、攻击者能力、攻击路径。对应数字钥匙就是分析手机丢失、系统被Root、云端凭证泄露、维修链被恶意替换等场景。Architect架构划分信任边界确定安全分区和信任根。对应数字钥匙就是决定私钥放SE还是TEE、车机验签逻辑跑在哪个安全世界、哪些代码可以被普通世界直接访问。Implement实现用具体的隔离机制和密码学库把架构落地。对应数字钥匙就是调用PSA Crypto API、实现安全启动、完成密钥导入与签名操作。Certify认证委托第三方实验室做评估验证“声称的安全等级”与“实际安全能力”一致。对应数字钥匙就是申请PSA Certified的不同级别认证。这四个阶段里前两个阶段最容易被跳过。很多团队拿到开发板就直接写业务代码等发现V2层密钥能被调试接口读出来时已经要改硬件设计了。2.3 PSA威胁模型文档的正确用法PSA官方发布过一组威胁模型文档Threat Model内容覆盖软件攻击、硬件攻击、生命周期攻击等。现场有人问文档怎么用原厂工程师的回答很直接不要把它当论文读把它当一个检查清单。比如针对数字钥匙拿到文档后可以对照这些问题逐项打勾是否存在未使用的调试接口JTAG/SWD没有被物理封堵密钥导入时是否依赖了一个可能被替换的“受信任环境”设备从生产到用户手里的供应链环节是否有可证明的信任锚OTA升级包被降级到旧版本时系统能不能感知并拒绝这些问题的答案如果都是“还没想过”那说明项目还停在“能用”阶段离“安全可用”还有距离。3. 把PSA映射到数字钥匙产品信任根、隔离边界和密钥生命周期3.1 钥匙凭证不是一串密钥而是“密钥状态机”的组合研讨会上有一位车联网架构师讲了个很有意思的观点数字钥匙的安全对象不能简单理解成“一段私钥”而应该理解成一个受保护的状态机。一段私钥只能回答“你是谁”但数字钥匙业务还需要回答另外几个问题这把钥匙当前的状态是已激活、已挂失、还是已过期这把钥匙允许在什么时间段使用允许开哪辆车是否已经被用过了如果只保护私钥、不保护状态攻击者可以通过回滚、重放等方式让系统回到“已激活且可用”的旧状态。所以PSA落到数字钥匙上时必须保护的不仅仅是密钥本身还有跟业务状态绑定的版本号、证书链和策略控制信息。最直观的办法是让状态机运行在安全边界内部普通世界只能通过定义好的安全服务接口查询和操作。3.2 SE与TEE的分工问题现场最有价值的讨论讨论到“密钥究竟放哪”时场面最激烈。结论值得单独列一下SE / eSE安全单元独立或半导体内嵌的安全芯片抗物理攻击能力强能通过EAL/CC这类高等级认证缺点是运算能力有限、写业务代码不方便、成本偏高。TEE可信执行环境与应用处理器同芯片基于TrustZone等隔离机制运算能力强、能运行相对复杂的逻辑但物理攻击抵抗力较弱攻击面比独立SE更大。混合方案把根密钥和关键证据放在SE里把需要频繁调用的签名算法和业务状态机放到TEE里应用层通过安全服务框架统一访问。现场那位车联网架构师的观点是数字钥匙这种高价值场景恰好是SE和TEE分层协作的典型舞台。SE负责“最终信任根”TEE负责“高频安全操作”两者通过安全通道通信。这样即使TEE被攻破攻击者也只能拿到会话级的数据没法直接把根密钥抽走。但如果成本压力极大、只能保留一套安全能力时优先保SE而不是保TEE。因为数字钥匙私钥一旦被提取攻击者可以离线复制造假凭证影响范围远大于一次在线攻击。3.3 密钥生命周期管理从签发、存储到吊销的完整路径把密钥看得越重越会发现“管理”比“生成”复杂得多。研讨会上画了一条比较完整的生命周期链路我记了下来签发OEM根证书或车厂根证书体系为每个设备签发设备证书绑定设备ID、信任根公钥、有效期。关键点是证书链要短到可验证又要短到不会因单点密钥泄露而全盘崩溃。下载云端用设备公钥加密会话密钥再用会话密钥加密钥匙数据到达手机安全存储后解密并落盘。整个过程保证传输层即使被劫持拿到的也只是密文。使用解锁时手机端安全侧用私钥完成签名车端验签后放行。验签时要绑定随机Challenge防止重放攻击。挂失与恢复手机丢失后云端吊销凭证同时允许用户在新设备上重新申请。这里有个难点既要让用户找回钥匙足够方便又要防止攻击者冒用“挂失”流程把合法密钥废掉。销毁用户注销或转让车辆时密钥必须能从SE/TEE中彻底删除并且证书状态要在云端同步更新。key management部分现场不少人提到“自己写一套密钥管理协议更灵活”原厂工程师给了一句忠告没有专业密码学团队优先复用经过验证的方案比如PSA Crypto API封装的密钥管理能力自己的协议往往是以后安全审计里最费劲的部分。4. 一套数字钥匙参考实现的落地拆解从编译环境到安全启动4.1 软硬件分层和信任链构建我根据现场分享和自己在嵌入式安全项目里的经验整理了一套比较典型的参考实现硬件侧主控MCU选择带TrustZone的Cortex-M33/M55外部或内部集成一块SE安全芯片车端通过UWB/BLE/NFC三种通道与手机交互。软件侧MCUboot做安全启动的引导加载TF-MTrusted Firmware-M提供安全运行时和PSA Crypto API业务侧在安全分区运行数字钥匙协议栈。信任链BootROM验证MCUbootMCUboot验证TF-M镜像安全分区再验证业务固件。每一级验证的签名公钥都烧在只读/一次性编程区域OTP里不允许被运行时代码修改。这个设计的好处是每一层都只信任上一层的签名结果任何一层被篡改都能在启动过程中被拦截下来。4.2 用PSA Crypto API把“开门”这件事安全化代码层面最核心的是密钥导入和签名操作。用PSA Crypto API写出来结构其实很清晰psa_key_attributes_t attr PSA_KEY_ATTRIBUTES_INIT; psa_set_key_usage_flags(attr, PSA_KEY_USAGE_SIGN_HASH); psa_set_key_algorithm(attr, PSA_ALG_ECDSA(PSA_ALG_SHA_256)); psa_set_key_type(attr, PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1)); psa_set_key_lifetime(attr, PSA_KEY_LIFETIME_PERSISTENT); psa_import_key(attr, key_der, key_der_len, key_id); uint8_t signature[64]; psa_export_public_key(key_id, pub_key, sizeof(pub_key), pub_key_len); psa_sign_hash(key_id, PSA_ALG_ECDSA(PSA_ALG_SHA_256), challenge_hash, sizeof(challenge_hash), signature, sizeof(signature), sig_len);注意这里的关键点不是“能不能签名”而是私钥从导入之后就没有出现在普通世界的内存里。PSA Crypto API强制通过handle引用密钥业务代码无法直接拿到私钥内容。为了让没接触过PSA的读者也能理解可以类比成普通世界手里拿的是一张“银行卡号”真正的取款密码封存在安全世界里每次支付由安全世界代为完成。车端验签流程则是对应Challenge-Response结构车端生成随机Challenge发送给手机手机安全侧用数字钥匙私钥对Challenge的哈希签名车端用数字钥匙证书链验签验签通过后再叠加UWB测距结果确认手机与车辆的距离在阈值内所有条件满足后执行解锁。4.3 遇到的问题反回滚、侧信道和功耗分享参考实现时原厂工程师提到了几个很实际的工程问题反回滚安全固件升级到新版后如果攻击者把固件降级到有漏洞的旧版本该怎么办。解决思路是把安全版本号保存在一次性编程区域或专用反回滚计数器里每次启动时检查固件版本号不能低于已记录的最低版本号。侧信道签名过程中如果分支条件依赖密钥值可能通过功耗曲线或电磁泄漏把信息泄露出去。应对方法是使用常量时间实现的库并避免在安全侧代码里根据私钥内容做分支跳转。低功耗车端不可能一直保持全功率监听状态。UWB测距需要非常精确的时间戳主控晶振频率的漂移会影响距离精度因此启动测距前需要先做时钟校准否则会出现“明明只有3米远测出来却有10米”的误判。这三点都是文档上不会写、但真机调试一定会撞上的事。尤其反回滚很多团队直到做OTA升级后测试才发现升级成功了可旧版本还能通过某条隐藏的恢复指令重新装回来。5. Arm平台开发里那些“看着熟悉但一跑就挂”的坑5.1 交叉编译工具链的选择armclang还是gcc-arm研讨会下半场聊到了开发环境。数字钥匙参考固件通常是跑在Arm核上的但绝大多数工程师的开发机是x86平台所以交叉编译是标配。现场不少人在用Arm Compiler 5的老工程一遇到新版TF-M就编不过。原因很简单Arm Compiler 5armcc已经停止适配新组件TrustedFirmware开源工程现在基本都要求AC6或GCC-Arm。如果你的项目还在沿用armcc 5.06 update 7这类老版本建议尽早规划切换不然后面想集成最新的PSA组件会寸步难行。比较稳妥的组合是用Arm Compiler 6armclang或者gcc-arm-none-eabi配合CMSIS软件包链接脚本直接用工程自带的分散加载文件不要自己“优化”我个人的经验是不要试图在x86机器上直接运行Arm的ELF文件。很多新人在模拟器里试跑Reference固件发现Segmentation Fault然后开始怀疑代码有问题。其实大概率是模拟器没完全模拟TrustZone的隔离行为。真机验证永远是最可靠的。5.2 .so从x86迁移到Arm的典型翻车场景有个提问挺有代表性“我们的数字钥匙业务模块原来是Linux x86上的.so能不能直接拷到Arm设备上跑”这个问题让现场几个人同时笑了。.so不是跨架构可执行文件x86编译出来的二进制和Arm是完全不同的指令集直接搬过去只有一种结果exec format error。而且就算用源码重新编译也要注意三类问题架构相关宏x86下默认小端Arm平台可能是小端也可能是大端需要统一。浮点调用约定确认目标设备是否支持硬件浮点编译参数要用对。依赖库版本Arm环境下openssl、mbedtls等动态库版本必须与开发机上一致否则加载时符号解析失败。迁移的正确姿势是拿到目标设备的完整交叉编译工具链在干净的sysroot上重新构建再放到目标设备上做全量回归。图省事直接拷文件只会把排查时间加倍还回去。5.3 链接脚本和启动文件里的小门槛开始移植TF-M这类安全固件时会发现它的镜像链接地址、加载地址、执行地址经常不是同一个值。比如代码段可能先放在外部Flash的0x10000000但运行时要拷贝到内部SRAM的0x30000000去执行。如果链接脚本里这几个地址没写对套路是安全启动验签通过跳转执行后立刻HardFault单步调试发现PC指针跳到了不可执行的内存区域。这类问题在QA文档里很难查到明确答案更实用的排查方式是对比官方开发板的linker script逐段检查FLASH地址、RAM地址、堆栈大小的配置。6. 现场问答里的争辩安全分级、成本与供应链6.1 “低端车机就做不了PSA”到底是不是真的圆桌讨论的最后一个环节有人抛出一个含金量很高的问题“我们的产品是低端车机主控MCU性能很弱难道也要完成PSA认证、做全套安全架构吗”原厂工程师给了一个很务实的回答PSA不等于最昂贵的方案它是一套分级体系。预算和算力有限的设备可以在PSA Certified的Level 1层面做好“安全设计流程合规”证明你有完整的威胁模型和架构文档中端车机做到Level 2通过实验室评估验证隔离方案有效只有门槛极高的车型或豪华品牌才需要冲Level 3的物理攻击抵抗评估。所以低端车机真正的问题不是“做不了PSA”而是“愿不愿意在最开始就把安全设计放进产品需求里”。很多团队是先定硬件成本再回来说安全要补做这才是博弈里最被动的情况。6.2 供应链风险大于攻击面风险讨论到安全投入重点时一位做安全评估的工程师说了句很真实的话“对大多数数字钥匙系统来说被远距离黑客0day击穿的概率远小于供应链里混进一块被替换的模组。”这话引发了共鸣。PSA把安全生命周期拉长之后供应链的所有环节——芯片出厂、模组贴片、整机装配、OEM写入初始终端密钥——每一步都必须有可追溯日志。否则一台出厂时就被植入后门的设备后面做再多安全启动、UWB测距、密钥吊销都是给一个失去安全根基的房子刷墙。现场给的建议非常落地锁定开源组件版本定期生成SBOM软件物料清单做审计芯片出厂密钥要写入由芯片原厂背书的证书仓库与设备ID严格绑定对代工厂的烧录环节做物理审计确保根密钥只在安全环境下写入。这几条不一定能在代码层面解决但它们决定了你整体安全方案的上限。写在最后我在这次研讨会之后调整了哪些做法整场研讨会听下来最触动我的不是某个高深的密码学算法而是“安全实践”这个四个字在真实项目里被拆开之后竟然有那么多零碎却又致命的小决策。会后我自己复盘调整了三个工作习惯一是每次新项目启动先把PSA的Analyze阶段产物威胁模型文档写出来哪怕只有两页纸也要把资产和攻击路径画清楚。这比一开始就盯着密钥算法更有价值。二是重新评估了密钥存储方案。以前为了省成本倾向于“TEE搞定一切”现在会更早跟硬件团队讨论SE的选型与连接方式宁愿把根密钥和业务状态机分开也不愿为了省一两块钱给后期安全审计埋雷。三是把交叉编译和开发环境配置当成正式工程任务来管理。很多安全固件的问题追到底其实只是工具链版本不一致或链接脚本配置错误。这部分虽然不性感但它决定了你整个安全架构能不能真正跑起来。后来跟一个同样做数字钥匙的产品经理聊起他说“安全不是做完一个功能就结束而是从启动到销毁一直存在的状态”。这句话虽然简单但确实是这场研讨会最浓缩的收获。