OWNER PAIRING
本篇只介绍所有操作都成功执行的场景，中间如果出现异常，需要翻看规范决定接下来的操作
一些密钥
公私密钥对(Vehicle.PK&Vehicle.SK)
Endpoint.pk/sk：一个数字钥匙一对，在数字车钥匙创建期间产生
vehicle.pk/sk：由车辆产生。车辆的所有数字钥匙都相同。生命周期由oem管理，不由本规范定义
安全通道进行数据交互时所需的密钥：
kenc：对称秘钥，用于加密命令和回复payload
kmac：对称秘钥，用于计算命令macs
krmac：对称秘钥，用于计算回复macs
在标准交易和SPAKE2+之后，都会生成SCP03安全通道
配对分为5个阶段：准备、初始化、读卡器第一次会话、读卡器第二次会话、结束配对。
phase0：前置条件
手机：
确保已经安装Digital Key applet，创建InstanceCA
Instance CA Certificates are obtained by the Digital Key framework
See Listing 15-15 for the description of the Instance CA Certificate [E]. All signatures are
generated as described in Section 18.4.10.
车辆：
secure channel creation
generates the pairing password
the password verifier
sends the verifier and salt through a Vehicle OEM proprietary secure channel to the vehicle
phase1：手动操作
车辆：
into pairing mode by the user or select the framework AID on the console NFC reader in the vehicle
手机：
receives the password or through user input or a URL or through an API directly from the Vehicle OEM
phase2：第一次会话，Spake2+算法后，创建数字钥匙
consists of two distinct NFC transactions
first transaction negotiates the protocol versions、establishes a secure channel、transmits all key creation data to the device
In the second NFC transaction, the vehicle reads the key creation data from the device, verifies it and, if successful, stores the device public key
使用spake2+算法建立安全通道，使得创建digitalkey所需的数据，如Vehicle公钥证书、Authorized公钥等，能够被安全地送达至device。
step1：
使用AID选择DigitalKey framework
step2完成了对安全通道的创建，具体可以看
https://www.cnblogs.com/MiraculousB/p/16640377.html
phase3：第二次会话，标准交易后在MailBox写数据
The second NFC session is executed between vehicle and Digital Key applet
step1~2：
根据AID选择Instance
step3~6标准交易：
车辆端产生临时公私密钥对，交易标识符是发起标准交易请求时随机产生的，车辆标识符则是车辆的唯一编号，车辆端准备好这些参数数据后通过AUTH0命令发送至手机端。
手机端也产生自身的临时公私密钥对，在AUTH0命令反馈时给到车辆端，相当于车辆与手机完成了信息的交换
车辆发送的AUTH1 Command命令，此命令主要携带的参数是车辆的签名，主要使用车辆永久私钥对如下内容进行签名并发送至手机端:(vehicle_identifier | endpoint_ePK.x | vehicle_ePK.x | usage = 415D9569h )
手机端接收到车辆签名Veh.sig时进行验签
如果手机对车辆的验签通过则手机端也会用自身的永久私钥对如下内容进行签名得到终端签名endpoint.sig(vehicle_identifier | endpoint_ePK.x | vehicle_ePK.x | usage = 4E887B4Ch )并反馈至车辆端。
车辆接收到手机的签名也进行验签操作，如果验签成功则车辆与手机完成双向认证过程
ECDH算法可以在不事先存储密钥的情况下协商出一个共享密钥也就是对称密钥(Symmetric Key), DHKEY = [Vehicle.eSK * Endpoint.ePK | Transaction_identifier] = [Endpoint.eSK * Vehicle.ePK | Transaction_identifier] 通过这种方式，车辆和手机端在不经过密钥传输的情况下协商出一个对称密钥Kdh。
车辆和手机端可以利用对称密钥Kdh离散出建立安全通道所需要的密钥Kenc/Kmac/Krmac, 离散时需要的信息 info <- cod.vehicle_ePK.x || cod.endpoint_ePK.x || code.transaction_identifier || interface_byte || code.flag || "Volatile" || 5Ch||02h||code.current_protocol_version, 就是将 Kdh 与 info信息输入到SHA-256加密算法，派生出来的48bytes的密钥就可以分解成三个16字节的安全通道密钥。
类似于上一步步骤，此步骤车辆和手机端也是生成一个32字节的对称密钥Kpersistent就是将 Kdh 与 info信息输入到SHA-256加密算法，派生出来的32bytes的密钥就作为Kpersistent, Kpersistent是一个长期的对称密钥用于派生加密密钥和会话密钥，它存储在车辆和手机端的NVM中。Kpersisent在接下的安全通讯不会使用，它被存储起来，用于快速交易，所以必须经过标准交易后，才有可能进行快速交易。
生成了安全通道密钥和长期密钥Kpersistent之后，交易双方可以基于已经建立的安全通道，继续相关的应用操作，比如mailbox读写，然后结束当前交易。同时因为交易双方生成和保存了Kpersisent，所以下一次交易的时候交易双方可以采用快速交易的方式来建立安全通道，也就是在进行一次标准交易之后，后面可以利用Kpersistent进行快速的身份验证，这个有点类似于蓝牙配对之后生成的LTK有点类似。
step7~12：调用EXCHANGE指令，写各种东西到mailbox里。
opaque attestation、owner immobilizer token、slot identifier bitmap、Write the owner slot identifier into the slot identifier list in the private mailbox、Vehicle OEM proprietary data structure、immobilizer tokens for sharing、signaling bitmap to indicate the update of the above data structures
stop13~14：
发送控制流，表示所有数据已经成功地被写入到mailbox中。
step15：KTS交互
如果标准交易成功了，owner设备将发送同步信息给KTS注册数字钥匙。对于车辆来说，这个是个可选的选项。如果车辆也想注册，就可能会发生竞争关系。所以不推荐车辆来注册。
标准交易失败时，不发送信息给KTS。
发送的信息有：带E、H证书的请求、（私钥签名的端点加密key证明）、车辆公钥不透明证明、朋友名字？、设备隐私加密key（Device.Enc.PK）、设备隐私加密版本
返回的信息有：KTS签名、slot标识符、confidentialMailBox数据
phase4：收尾工作，与KTS交互
step2之前：
在手机的mailbox中保存kts签名
车辆读卡器执行标准交易检查签名是否在手机中，如果不存在，持续检查
如果是车辆接受到kts response，则停止对device的kts签名检查
如果都没有获得kts response，则发送失败控制流
step2~5：
根据谁获得了kts签名，决定从哪里读取receipt。
车辆验证kts签名
step6~9：
如果需要，通过exchange指令将防盗token写进confidential mailbox。
step10~13：删除一次性信息
车辆通过控制流，在private mailbox中删除已经验证完的key tarcking receipt。使用exchange命令，删除signaling bitmap、删除attestation package，使得车辆在下一次交易中不会检测到相同的attestation package。
step14~15：
发送控制流，表明配对结束。
