6 车主配对
6.1 概述
车主配对流程由设备上运行的数字钥匙框架操作。如图Figure 2-2所示，数字密钥框架使用第5节中描述的APDU命令来管理由SE保护的数字钥匙的配置。SE操作系统提供了信任的根源，这是第16.1节中定义的信任链的起点。车辆能够通过NFC发送AID选择数字钥匙小程序，并使用相应的AID选择数字钥匙框架。基于AID，NFC控制器可以被配置从SE到数字钥匙框架的通信路由，反之亦然。新的车主设备配对流程或车主设备更改并不意味着不配对，即，新的车主设备配对流程只是更改车主的密钥。已配对的现有共享/好友钥匙和车辆公钥不一定会受到影响。数字钥匙小程序实例应在车主配对执行之前在SE上可用。
理解说明：一个手机（设备）可以同时作为多个车辆的车主；一个车辆只可以有一个车主
6.2 钥匙和数据
本节定义了车主配对中使用的密钥和数据元素：
device.PK/device.SK(设备公钥/设备私钥): 设备在创建数字钥匙期间生成的长期密钥对。每个数字钥匙一个。
理解说明：配对成功，手机端创建数字钥匙时生成密钥对。一个设备对应一个车辆一个密钥对。
vehicle.PK/vehicle.SK: 车辆生成的钥匙对。一辆车只对应一个密钥对。该钥匙对的生命周期由车辆制造商定义和管理，不在本规范的范围内。
Pairing password(配对密码)：把SPAKE2+算法需要的配对密码输入设备；车辆制造商车主用户帐户提供UTF-8格式的八位数字（0–9）的配对密码，用于对车主进行身份验证。
Kenc：派生的对称密钥（由SPAKE2+共享密钥派生），用于加密机密命令和响应有效数据。
Kmac：派生的对称密钥（由SPAKE2+共享密钥派生），用于计算命令MAC。
Krmac：派生的对称密钥（由SPAKE2+共享密钥派生），用于计算响应MAC。
6.3 车主配对实现
本节介绍车主配对流程的各个阶段，包括：
阶段 0: 准备 (见第6.3.1节)
阶段 1：初始化车辆端和设备端的配对程序（见第6.3.2节）
阶段 2：与NFC阅读器的首次对话（见第6.3.3节）
阶段 3：与NFC阅读器的第二次会话（见第6.3.4节）
阶段 4：配对程序的最终确定（见第6.3.5节）
车主配对流程由两个会话组成：第一个会话（阶段2），使用数字钥匙框架执行，第二个会话（第3阶段）使用数字钥匙小程序执行，如图6-1所示。在车主配对阶段2中，车辆配置车主设备是否必须从车辆制造商服务器或从车辆在线读取防盗令牌。如果配置了在线检索，则在与NFC读取器的第二次会话中，车主防盗令牌不会被传输，而是在车主配对期间或之后，通过车主设备制造商服务器在车辆制造商服务器的钥匙跟踪请求/响应中传输。图6-1描述了车主配对过程，通过该过程可以从车辆中检索防盗令牌。
第一个会话由两个NFC交互组成。第一个交互是协商协议版本，执行SPAKE2+，并将所有密钥创建数据传输到设备。第二交互是，在设备中创建数字钥匙之后，向车辆提供创建证明和证书链。
Figure 6-1: Owner Pairing NFC Exchanges
6.3.1 阶段0： 准备
6.3.1.1 设备端准备
假设设备已经安装了数字钥匙小程序，并在车主配对操作之前为每个车辆制造商创建了CA实例。数字钥匙框架更新车辆制造商合作伙伴列表。
理解说明：即在手机的钱包->车钥匙里有对应的车辆制造商入口。需要和手机商合作
CA实例证书由数字钥匙框架获得。
理解说明：CA实例证书从手机制造商服务器获得
有关CA实例证书[E]的描述，请参见清单15-15。所有签名均按照第18.4.10节的规定生成。
6.3.1.2 车辆端提供
车主配对安全通道的创建基于SPAKE2+协议，如第18.4.1节所述。该协议将设备绑定到用户，并可抵御窃听和MITM攻击。有关协议的计算和安全方面的更多信息，请参阅[10]。在车主配对程序开始之前，车辆制造商服务器生成设备的配对密码和车辆的配对密码验证器，如清单18-1所示，并通过车辆制造商专有安全通道将配对密码验证器和salt参数发送到车辆端，如图6-2的步骤1所示。
理解说明：车辆制造商服务器生成配对密码、配对密码验证器和salt参数。车辆制造商服务器将配对密码发送给车主，将配对密码验证器和salt参数发送给车辆。
6.3.2 阶段1：初始化配对流程
在车辆方面，配对程序的启动由车辆制造商负责。需要满足适当的车主配对先决条件，例如存在遥控钥匙。
理解说明：配对前需要物理钥匙在车上。
Figure 6-2：Owner Pairing Flow - Phase 0/1: Preparation/Initiation
车辆被用户设置为配对模式，或者只要没有车主设备成功配对，车辆控制台NFC读卡器就尝试发送选择数字钥匙框架AID，设置为配对模式。为了启动车主配对模式（图6-2的第3步），设备通过用户输入、URL（参见第6.3.7节）或直接通过API从车辆制造商应用程序（如果已安装）接收配对密码。
设备端在配对程序开始后，应关闭NFC接口（图6-2的步骤3）。NFC链接应在用户输入配对密码后或者用户界面关闭后，再次开启。
注：由于设备或车辆受到外部影响，NFC接口的停用是为了停止额外的轮询。例如，在激活NFC接口的情况下，在等待用户输入（图6-2的步骤3）时，由于设备的移动，车辆可以再次重新启动轮询。这可能导致在第一个车主配对仍在运行时重新启动车主配对。
6.3.3 阶段2：第一次NFC会话
第一次NFC会话由两个不同的NFC交互组成。
第一个交互协商协议版本（见第6.3.3.8节），设备和车辆相互认证，使用SPAKE2+建立安全通道，并将所有密钥创建所需数据传输到设备，如图6-3所示。
Figure 6-3: : Owner Pairing Flow - Phase 2: First NFC Session
SPAKE2+创建一个对称会话密钥对，用于在车辆和设备之间建立安全通道。在第二次NFC交互开始之前，设备要创建设备密钥。
在第二次NFC交互中，车辆从设备读取密钥创建数据，对其进行验证，如果成功，则存储设备公钥。NFC重置过程在每次交互结束时执行。
在第一个NFC会话中发生以下步骤或事件序列：
6.3.3.1 步骤1：选择数字钥匙框架
当设备与车内控制台NFC读卡器通信时，车辆应通过SELECT命令使用AID选择数字钥匙框架。如果车辆在选择数字钥匙框架AID之前选择了数字钥匙小程序AID，则设备用状态字应6A82h响应SELECT Digital Key Applet AID。设备应通过SELECT命令响应将所有支持的SPAKE2+版本和所有数字钥匙小程序协议版本返回到车辆端。这决定了双方要使用的SPAKE2+版本（用于创建安全通道）和数字密钥小程序协议版本（用于密钥共享）。在按照第6.3.3.8.节所述继续操作之前，应在车辆端检查版本信息的兼容性。SELECT命令在第5.1.1节所述。
6.3.3.2 步骤2和2a: SPAKE2+交互
车辆应选择要使用的SPAKE2+协议版本以及所有支持的数字钥匙小程序协议版本列表并发送至设备（如第6.3.3.8节所述）。SPAKE2+交互如[10]所述。
Figure 6-4: SPAKE2+ Flow
SPAKE2+交互如图6-4所示。SPAKE2+交换为车辆和设备之间的数据交换建立了一个安全通道。该安全通道应在RF重置期间保持激活状态。
当发送指示成功的OP CONTROL FLOW命令时（图6-3的步骤17），当OP CONTROL FLOW命令指示错误时，或在流的任何其他中止之后，安全通道终止。APDU命令上的解密错误或MAC值错误也会终止安全通道。
当车辆未准备好进行车主配对时，应使用OP CONTROL FLOW中止并向用户指示中止条件，例如“未满足车主配对的先决条件”。
注意：只有具有适当类字节指示（位2=1）的命令才是安全通道的一部分。
6.3.3.3 步骤3~4：写入数据
车辆应使用多个写入数据命令通过安全通道向设备发送创建数字密钥所需的所有数据（见图6-5和图6-6）。设备成功接收后，应使用以下方法之一验证第6.3.3.10节中所述的车辆公钥证书[K]：
车辆制造商CA证书[J]（见图6-5）
设备制造商 CA[D]签署的车辆制造商 CA证书[M]（见图6-6）
在以SE为中心的小程序模型实现的情况下，数字钥匙框架可能会省略验证，因为它是由数字钥匙小程序在第15.3.2.4节所述的端点创建过程中进行的。
Figure 6-5: Key Creation Data Transfer to Device
Figure 6-6: Key Creation Data Transfer to Device
证书详细信息见第16节。
6.3.3.4 步骤5~6: OP CONTROL FLOW
OP CONTROL FLOW命令指示所有数据都已传输完成，没有错误。然后，设备端操作系统关闭设备卡模拟状态并创建数字钥匙，如第6.3.3.9节所述。
6.3.3.5 步骤9~12 读取数据
第二个会话继续使用生成的安全通道。在发送GET DATA命令之前，车辆应执行NFC轮询和链路设置程序，并使用SELECT命令重新选择设备操作系统框架AID。车辆应轮询设备及设备作出响应以判断钥匙创建是否失败。另请参见第6.3.3.12节。有关从NFC读卡器中断链设备或出现其他连接问题时的超时，请参阅第6.3.6节。
车辆应发送GET DATA命令，请求车辆制造商[F]签署的设备制造商 CA证书（见清单15-13）、设备制造商 CA[E]签署的CA实例证书（参见清单15-16）以及来自CA实例 [H] 签署的数字密钥证书（见列表15-5）。
车辆应验证第6.3.3.11节中所述的所有证书和相关数据元素。如果所有步骤都成功，车辆应将设备公钥存储为车主公钥。
GET DATA命令如第5.1.5节所述。
Figure 6-7: Key Creation Info Retrieval by Vehicle
证书详细信息见第16节。
6.3.3.6 步骤13~14 写入数据
如果所有验证都成功，车辆可以使用WRITE DATA命令向设备发送不透明的证明（见表5-12），以确认已提交给车辆的设备PK，该证明应在注册钥匙时发送给KTS。设备应以WRITE DATA响应进行响应。
如果任何验证失败，则车辆不会发送证明。车辆应向设备发送OP CONTROL FLOW命令以中止流程，并带有表15-27中定义的适当错误指示。
6.3.3.7 步骤15~18：OP CONTROL FLOW
如果车辆已无错误地收到所有钥匙证书，则应在步骤15中发送OP CONTROL FLOW（P1=10h，P2=02h）。否则，车辆应发送OP CONTROL FLOW（P1=12h，P2=原因），以因P2值指示的错误而中止车主配对。如果步骤15中的OP CONTROL FLOW为P1=10h，P2=02h，则车辆应在步骤17中发送OP CONTROL FLOW（P1=11h，P2=11h），以结束车主配对阶段2流程。
6.3.3.8 检查协议版本
设备和车辆可以支持不同版本的SPAKE2+和数字钥匙小程序协议。设备和车辆应支持较旧但不推荐使用的协议版本。车主设备应首先在SELECT响应中返回SPAKE2+和数字钥匙小程序协议的所有支持版本。车辆应返回选定的最高匹配的SPAKE2+协议和数字密钥小程序协议的版本，然后是支持的所有较低版本，从最高到最低排序。支持的数字钥匙小程序协议版本的列表以便车辆和车主设备在好友设备上找到不同但兼容的版本以进行密钥共享。下面给出了一个例子。
当没有匹配的版本时，车主配对程序应中止。在这种情况下，车辆应在其UI上指示这一点，并应使用OP CONTROL FLOW命令向设备发送一条错误消息，并指示“中止”。
支持的数字密钥小程序协议版本示例：
SPAKE2+REQUEST命令中包含的车辆支持的数字钥匙小程序协议版本（m个支持的数字密钥小程序协议版（ver.high|ver.low））由设备接收：
0104h
0103 h
0102 h
0101 h
0100 h
车辆接收到SELECT RESPONSE中包含的设备支持的数字钥匙小程序协议版本（m个支持的数字密钥小程序协议版（ver.high|ver.low））：
0103h
0102h
0101h
0100h
SELECT RESPONSE APDU将包含标签5Ch数据: 5C 08 0103010201010100.
SPAKE2+REQUEST命令将包含标签5Ch的数据: 5C 0A 01030104010201010100.
6.3.3.9 创建数字钥匙
数字钥匙框架使用CREATE ENDPOINT命令（见第15.3.2.4节）和以下参数在SE中创建数字钥匙：
vehicle identifier(车辆标识)：由车辆分配。建议用2字节的车辆品牌标识符（见[35]）和6字节的唯一标识符（在车辆制造商内）应用于车辆标识符。由于车辆标识符是在AUTH0命令中传输的，如果需要车辆隐私，当车主更改时（即，当车辆处于“未配对”状态时；有关配对状态的描述，请参见第2.7节），应更改车辆标识符。
endpoint identifier(端点标识)：相关证书中的通用名称。它用于识别数字钥匙。端点标识符对于小程序实例中的每个数字钥匙都是唯一的。格式见附录B.1。
Instance CA identifier(CA实例标识)：确定在创建钥匙后对数字钥匙证书进行签名的CA实例。该值应与要关联的CA实例的标识符中的名称完全匹配（请参见清单15-16）。格式见附录B。
Digital Key option group 1 and 2：应根据车辆制造商策略进行设置。
protocol version（协议版本）：商定的数字钥匙的数字钥匙小程序协议版本。
vehicle public key（车辆公钥）：车辆的公钥。出于隐私原因，当车主更换时（即，当车辆处于“未配对”状态时；参见第2.7节），钥匙可能会发生变化。
authorized.PK（授权）：此数组应包含车辆制造商CA PK。注意，一旦数字密钥创建后，授权公钥就不会更新。
confidential mailbox size（机密邮箱大小）：应根据车辆制造商定义的数字钥匙结构配置和要存储的防盗令牌数量进行设置。当不需要防盗令牌时，大小应设置为0。数字钥匙框架应计算机密邮箱的大小，如下所示：
confidential mailbox size = (SLOT_IDENTIFIERS_OFFSET – 33 SLOT_IDENTIFIER_BITMAP_OFFSET) × 8 × 34 IMMOBILIZER_TOKEN_LENGTH
private mailbox size（专用邮箱大小）：应根据车辆制造商定义的数字钥匙结构和证明的大小进行设置，并由车辆在WRITE DATA命令中提供（见第4.3.1节）。
slot identifier(槽标识符)：由车辆提供。如第13节所述，它用于数字钥匙识别和对已经删除的数字钥匙的防重放。在车主配对过程中，车辆应为车主提供槽标识符。根据车辆制造商的实施方式，用于共享（用于好友）的槽标识符可以由车主从车辆中获得，也可以由好友在线从车辆制造商服务器中获得。
counter limit（计算限制）：不推荐，不应提供。
在所有情况下，车主槽标识符（从车辆或在线检索的槽标识符）应由车辆在端点创建数据中提供。此处提供的值用于车主配对第3阶段的标准交换。
如果设备中已经存在与车辆标识符对应的数字钥匙，则数字钥匙框架应终止现有数字钥匙，并在创建新的数字密钥之前，将终止证明以及车辆制造商专有数据发送给KTS（如适用）。
6.3.3.10 验证车辆公钥证书链
在接受车辆公钥之前，设备应解析下面列出的证书链，并验证关键数据元素和签名：
Vehicle Public Key Certificate format [K]（车辆公钥证书格式）
Intermediate Certificate (optional)（中间证书（可选））
Vehicle OEM CA Certificate [J] or Device OEM CA signed Vehicle OEM CA Certificate [M]（车辆制造商证书[l]或设备制造商CA签署的车辆制造商CA证书[M]）
所有证书应采用X.509/ASN.1格式，并应采用DER编码。
理解说明：DER编码，证书后缀名为.cer、.crt、.der
主题标识符和颁发者标识符的格式在附录B.1.中定义。在成功验证车辆公钥证书链后，车主配对阶段2完成。
6.3.3.11 验证端点创建证明证书链
在接受设备公钥之前，车辆应解析下面列出的证书链，并按照第15节中定义的规则验证所有数据元素：
Device OEM CA Certificate (signed by Vehicle OEM) [F]：车辆制造商签名的设备制造商证书
Instance CA Certificate (signed by Device OEM) [E]：设备制造商签名的CA实例证书
Digital Key Certificate [H]：数字钥匙证书，由CA实例签名
所有证书应采用X.509/ASN.1格式，并应采用DER编码。
6.3.3.12 第一次NFC会话错误处理
以下错误可能出现在NFC配对流的第一会话中：
一般错误：
通信错误：
- RF通信错误
- 车主在协议流程结束之前删除设备，即在链路丢失之前未收到取消选择命令
在命令序列下没有收到正确的命令
接收到未知的命令
设备其他错误的状态字
实现错误导致超时
SELECT命令失败
设备上未激活车主配对
SPAKE2+协议错误
设备端输入密码错误
达到的最大配对尝试次数（由车辆强制执行）
协议版本不匹配
车辆发送带有错误指示的OP CONTROL FLOW命令
设备创建钥匙失败
验证Vehicle Public Key Certificate [K] 证书失败
创建数字钥匙需要的数据不一致
数字钥匙的配置不允许
在小程序中没有足够的空间创建数字钥匙
设备应强制车辆按照规定的顺序发送命令。如果命令顺序发送错误，设备应用错误代码“命令使用顺序错误”中止交互。
车辆和设备应允许第一次会话中最多七次重试（使用try_cnt、try计数器）。如果达到最大数量，车辆或设备应结束车主配对模式，并重新提供新的SPAKE2+验证器。
当车辆找不到SPAKE2+或数字钥匙交换协议的匹配协议版本时，应发送适当的OP CONTROL FLOW命令（即“中止”），并且不应发送SPAKE2+REQUEST命令。在这种情况下，设备不期望来收到来自车辆的其他命令。
在OP CONTROL FLOW命令之后，在新的或更新的设备准备好再次开始车主配对（第2阶段）的第一步之前，车辆应执行NFC链路拆除流程，然后执行NFC复位流程。
如果由于非接触式协议无法恢复的连接断开导致交换失败，车辆应执行NFC复位流程（如第3.2.4节所述），并启动NFC轮询和链路建立流程。
如果应用程序超时（非接触式协议级别），车辆应发送OP CONTROL FLOW命令，指示超时错误。
如果在钥匙创建前的第一次NFC会话期间发生任何错误，则不应在数字钥匙小程序中创建数字钥匙。
当发生通信错误时，数字钥匙框架不应删除数字钥匙，并应等待车辆重试流程。
如果设备发送下表中列出的错误SW（即SW不等于9000h或61XXh），则应发生所列行为。
Table 6-1：Error SW Condition List 1.
当发送未列出的错误SW时，应增加错误计数器，如果计数器尚未达到最大值，则应重试。
创建数字钥匙后，如果OP CONTROL FLOW命令中显示错误，且车辆端因数字钥匙证书数据验证失败而拒绝接受，则数字钥匙框架应删除已创建的数字钥匙。收到指示超时错误的OP CONTROL FLOW命令后，如果达到累积的最大数量，车辆端或设备端应结束配对模式。用户求重新启动车主配对流程，车辆制造商服务器必须重新提供新的SPAKE2+验证器和配对密码。
当设备没有提前接收OP CONTROL FLOW命令而检测到链路丢失或接收到意外命令时，交互应被视为失败，并应允许重复有限的次数（例如5次）。
当创建了数字钥匙，但车辆未要求数字钥匙证书[H]时，数字钥匙将不可用。
车辆方面的策略应将每套配对密码/车辆验证器的车主配对尝试失败次数限制在第5.1.2节所述的7次。当成功配对完成或达到最大配对失败次数时，车辆应立即删除验证器。如果车主配对成功，在车辆验证钥匙跟踪签名之前，不得更新验证器，除非该验证器因其他原因失效。
当车主配对流程永久中止时（例如，达到设备超时、达到最大重试次数等），设备应删除创建的数字钥匙。
在车主配对第2阶段期间，设备应防止车辆选择数字钥匙小程序，并应使用状态字（SW）=6A82响应SELECT Digital Key applet AID命令。
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
