ICCE 数字车钥匙介绍

0x01 概述

汽车数字钥匙（DK，数字钥匙、数字车钥匙）应该是智能卡问世50年以来的新应用。目前主流的数字钥匙规范除了国外的CCC联盟标准，国内主要是ICCE（智慧车联产业生态联盟，Intelligent Car Connectivity INdustry Ecosystem Alliance）的数字车钥匙规范，ICCOA（智慧车联开放联盟，Intelligent CarConnectivity Open Alliance）数字车钥匙规范和IFAA（互联网金融身份认证联盟，International Internet Finance Authentication Alliance）数字车钥匙规范。

CCC联盟的参与单位主要是国际上的汽车主机厂、零部件供应商、芯片厂商；ICCE联盟是国内主要主机厂、零部件供应商、加密芯片厂商；ICCOA联盟小米、OPPO、vivo三家手机厂商为发起单位后续有主机厂和汽车零部件供应商参与；IFAA联盟是由信通院、蚂蚁、华为、三星、阿里巴巴等厂家发起，主要做手机基于生物识别身份认证的技术联盟，在互联网金融认证领域非常有影响。

与智能卡最广泛的应用EMV卡支付规范，EMVCo将大部分支付规范都免费放在官网让全世界开发者下载。前述4个汽车数字钥匙的规范，需要先参加对应的联盟才能获得相关的技术规范。

国内的三个技术标准中，ICCE应该是目前国内影响最大的规范，下面从一个智能卡从业人员的角度，介绍一下ICCE数字车钥匙规范。

ICCE的数字钥匙是无需额外的实体钥匙，将车钥匙功能集成在移动终端设备中，基于SE，TEE等安全功能，使用NFC、蓝牙、UWB等技术连接手机和车，实现车辆开门、启动等功能。ICCE数字钥匙规范定义的，数字钥匙是在移动设备中的，但是因为规范支持手机NFC+SE的认证方案，所以如果主机厂采用卡片形式的数字钥匙，直接找个卡商开发符合规范的JavaCard Applet，直接发行卡片数字车钥匙，也是可行的，而且可能是最简单，成本最低的钥匙方案。

ICCE数字钥匙规范目前有以下几部分

规范名称	说明
第1部分 总体规范	主要介绍了车端和移动端的方案，Applet的APDU指令
第2部分 蓝牙系统规范	第1和2部分结合实现了蓝牙钥匙规范
第3部分 NFC系统规范	第1和3部分结合实现了NFC钥匙规范
第4部分 UWB系统规范	第1和4部分结合实现了UWB+蓝牙钥匙规范
第5部分 穿戴设备系统规范	-
第6部分 星闪系统规范	-

数字车钥匙规范适用以下场景：

• 车主自行开通
• 授权钥匙开通
• 更换移动终端后钥匙开通
• 移动终端远端使用车钥匙
• 无钥匙启动
• 无钥匙进入
• 远离自动闭锁
• 车主自授权车钥匙
• 授权钥匙撤销
• 远程撤销

系统框架

与CCC数字钥匙一样，ICCE数字车钥匙也定义了三个主要的实体，分别为：钥匙端、车端，后台服务，不同的是CCC数字钥匙的规范不定义车端部分，而ICCE的规范里定义了车端的实现，也可以看出来车端密钥管理是需要SE或者HSM的，而后续车端认证协议规范给出的推荐是智能卡的APDU指令，所以ICCE规范基本上明确了车端的密钥管理也是需要使用智能卡芯片的SE的。

钥匙端

钥匙端是数字钥匙的硬件实体，需要支持短距离通信（NFC、BLE、UWB、星闪至少一种）来实现数字车钥匙，在ICCE的规范中钥匙端被称作“移动终端”，但按照规范具体要求看，“移动终端”并不一定必须是手机、可穿戴设备或者实体钥匙这样的形态，所以一张符合ISO14443非接触通信协议的智能卡形态数字钥匙也是没问题的。ICCE数字车钥匙规范也支持钥匙端可以具备生物识别模块，用于实现车钥匙认证，所以如果纯卡片形态的带指纹模组的智能卡产品也是可以满足这个需求的。

Native App

手机出厂自带的App，一般负责提供SE全局密钥管理，提供查询的界面，负责和手机厂商的TSM平台对接，负责手机SE内JavaCard Applet的空中发卡。

业务App

负责提供钥匙管理，查询界面，与OEM后台交互，执行开通、更新、分享、撤销等业务，在钥匙开通阶段执行蓝牙/UWB/星闪配对，负责通过车钥匙系统框架层向SE内JavaCard Applet发送APDU指令。

车钥匙系统框架层

封装了SE管理接口、钥匙认证相关接口，上层各种应用与SE交互，统一由框架层实现。

SE

在手机和可穿戴设备上是SE形态的安全芯片，SE支持Global Platform规范，基本上就是GP和Java Card了。

车端

CCC的数字钥匙规范是不包含车端实现的，但是国内做数字钥匙似乎都是主要指车端。车端模块如系统框架中所示，车上的车端数字钥匙认证系统，通过UWB/BLE/星闪/NFC等短距离通信模块，与手机建立连接，并认证。鉴权控制模块可以通过TSP通信模块和OBD诊断模块与OEM的TSP平台建立连接。

云端服务

云端服务有主机厂的云平台、移动端厂商的云平台、移动服务提供商的云平台。基于手机或者可穿戴设备SE方案的数字钥匙，跟手机硬钱包开通交通一卡通，金融IC卡一样，需要通过TSM向SE芯片中空中发卡，需要跟移动端厂商合作，因此是需要能够对接到移动终端厂商的TSM服务器的；数字钥匙管理、控车、密钥管理等等则是主机厂自己的云服务；还可能会有移动服务提供商提供的车队管理服务、数据分析等服务。

0x02 功能要求

钥匙端

ICCE数字车钥匙规范中，对SE的要求为：具备安全存储、硬件加密、真随机数发生器等基本安全功能，SE还要支持Global Platform Card Specicification v2.2.1以上版本，这个基本市面上带SE的手机应该都支持吧。

而数字车钥匙的Applet，规范虽然没有明确指出是Java Card Applet，但是现实中又能找到其他更好的么？所以前面汽车钥匙Applet，我都写的是Java Card Applet。需要支持一个Applet实例，承载多个车钥匙的要求，遵循ICCE车钥匙的Applet实例应当使用统一的AID，数字钥匙的Applet应当保证不同厂商的钥匙数据相互隔离。

规范中提到了AID，并提到了一个RID，看上去ICCE联盟或者联盟的某个会员单位去ISO的SC17注册了一个新的RID，但并没有看到明确说用哪个AID，RID都公布了，AID为什么不写出来呢？总不至于联盟成员可以去ICCE注册自己的单独AID吧？将来某个钥匙Applet发行方使用AID1，支持3款汽车，另一个钥匙Applet发行方使用AID2，支5款汽车？

车端

汽车需要有蓝牙BLE，UWB，NFC，星闪等模块，具备可新环境（如TEE，SE或者其他安全芯片），按照规范整体理解，BLE/NFC/UWB/星闪这些汽车只要支持一个就可以实现完成的数字钥匙方案，目前应该比较推荐的是BLE+UWB方案的数字钥匙，NFC数字钥匙作为备份。
车端的密钥管理应当使用的SE，TEE按照目前国内商密产品检测认证的经验看，TEE的安全强度通常是被视为软件密码模块的，使用TEE并不会被认为是使用了硬件密码模块，再结合ICCE规范后面给出的车端认证的APDU指令，ICCE数字车钥匙车端认证是基于智能卡技术实现的，所以车端采用SE可能是目前车端密钥应用的最合规方案。

云端服务器

这个地方也是超出了规范的范围，基本上是两大部分，一个是主机厂云服务，主要是数字钥匙的激活/开通/撤销/分享/查询请求的处理；另一个是手机厂商的云服务器，主要是TMS服务，是手机上Applet的管理，包括下载/更新/禁用/清除等。

0x03 业务流程

数字钥匙的业务流程主要包括，钥匙的开通、使用、分享、删除。开通和删除，ICCE不如金融行业标准写的好，这部分不详细说了，下面主要说下使用和分享吧。

钥匙使用

上图是钥匙使用的通用流程，在无感认证、遥控认证、NFC认证时会有一些特殊的处理。

无感认证

无感认证是在钥匙端和车端协商出会话密钥后，在第3步会话维持之后，车端需要对移动端进行定位，车控指令为可选。

遥控认证

遥控钥匙与无感钥匙的区别是遥控钥匙需要用户的主动确认操作（以及身份认证），由于是用户主动发起，所以不需要考虑车主的位置，无需进行定位。用户在会话维持阶段，需要手动触发车控操作，车控操作指令需要使用会话密钥进行加密发送给车辆

NFC认证

NFC认证是，用户主动拿钥匙/手机靠近车辆，通过钥匙靠近不同区域的读卡器，触发不同的车控指令，比如在车门车窗触发车门解锁等，由于NFC通信方式是即时的，这里不需要进行会话维持操作，车端只需要对密钥认证通过，然后按照每个读卡器对应的不同的车控指令即可。

密钥认证过程

密钥认证的过程，就是最常见的对称密钥挑战应答方案，钥匙端和车端共享一个对称密钥，然后使用一个随机数作为挑战码，让对方使用共享的密钥计算应答，然后挑战一方使用共享的密钥验证应答值，做双向认证。按规范要求至少应该完成双向认证，也就是上图的第6步，后续读取二进制可选，根据需求来做。密钥认证的逻辑上NFC、无感认证、遥控认证流程是通用的。

钥匙分享

钥匙分享分为车主分享模式和借车人申请模式，总的流程都是借车人或者车主通过App提交申请，由主机厂后台审核后，生成数字钥匙并下发到车机和借车人手机。主要的业务流程还是需要结合具体的应用场景确定。

0x04 接口

规范中对接口的定义主要说的是Applet的COS接口，主要内容为APDU介绍。通过系统架构图可以看出来，数字钥匙方案里钥匙端有一个Applet，车端有一个Applet。看了以下这些指令基本和7816-4/EMV/PBOC/PK卡的指令类似，就不详细介绍了，简单说下功能。

钥匙端的Applet一般需要实现以下功能：Select/GetProcessData/Auth/ReadBinary/UpdateBinary/Encrypt/Decrypt。

车端的Applet一般要实现以下功能：Select/IntAuth/ExternalAuth/Decrypt。

0x05 商用密码要求

规范中并没有要求数字钥匙方案中使用的密码算法必须使用国产密码算法，标准只规定了分组密码算法需要使用不低于SM4/AES128的算法强度，加密模式推荐CBC/CTR/GCM模式；公钥密码算法应使用不地区SM2/ECC256/RSA2048/ECDSA256强度的算法；密钥协商算法强度不应低于SM2/ECDH
256;杂凑算法强度应当不低于SM3/SHA-256；TLS应使用不低于TLSv1.2以上版本。

随机数发生器，要求ECU所用的SE应满足GM/T 0005或者NIST SP800-22要求的随机数发生器，一般实践中会直接要硬件密码模块的商密检测认证中心或者FIPS的检测认证证书。

密钥生成需要使用获得安全认证的SE进行密钥生成/存储/调用。

密钥的的更新需要按照GP Card Specification进行安全更新。

车端的根密钥在生产阶段进行个人化时，应当保证密钥传输与写入的完整性与机密性。