系列文章目录

第五章 CCC3.0 SPAKE2+ Flow 流程说明

前言

随着科技不断发展，车钥匙经历了传统机械钥匙到高低频的电子钥匙再到目前的数字钥匙的转变，由于现在手机或者手环等成为人们生活中必不可少的随身携带的电子产品，于是人们开始寻思着用手机或手环来代替先前的车钥匙，而蓝牙作为数字车钥匙的一个重要部件，本文将介绍CCC3.0中关于蓝牙OOB配对的那部分内容，至于蓝牙模块之间的配对特性交换，认证以及密钥生成分发则不在讨论的范围内。

一、Vehicle OEM Server

1. CCC中车辆服务器的职责

1. 车主手机与车辆关联的账户管理。
2. 管理数字密钥服务订阅。
3. 对分享的数字密钥进行签名。
4. 提供必要的证书给到车辆，以便朋友设备在第一次靠近车辆时，分享的数字密钥能够被识别。
5. 当手机端的数字密钥被终止了，那个车辆服务器也需要把车辆上的数字密钥终止。
6. 管理与手机的安全通道，也就是车辆服务器与车辆之间建立SCP03安全通道。
7. 创建配对密码(Pairing password) 并提供至手机和车辆
8. 对车辆公钥进行签名
9. 提供必要的证书给到手机厂商
10. 提供车厂和手机厂公钥给到车辆用于车主配对 和密钥分享

2. 车辆服务器产生配对密码

1. 算法参数 Scrypt parameters
   Salt：16bytes 随机数，每次在进行配对的时候，服务器都需要产生一个随机的盐值 Salt。
   Cost parameter Nscrypt: 4096 or higher 是一个自行选择的常量
   Block size r: 8 算法常量固定为 8
   Parallelization parameter p:1 算法固定值
   Output length dkLen: 80 算法生成密钥的长度为 80bytes

2. 车辆服务器产生配对密码
   
   可以看到车辆服务器在产生配对密码的时候需要知道第一步所描述的算法参数，然后服务器产生一个随机的盐值Salt和随机的配对密码，然后经过一系列的离散，得到了W0/W1/L/s/pwd
   当密钥产生之后，服务器需要通过URL链接将此处的pwd发送给手机(稍后会提及)，然后将盐值Salt 和 verifier(W0 | L) 给到车辆端。

3. Pairing Password URL
   为了启动车主配对模式，手机应该通过一个URL 链接来获取到配对密码， vehicle OEM 应该使用URL格式将配对密码提供给手机，当用户点击手机上的这个URL链接的时候，手机会从这个URL链接提取配对密码并使用这个配对密码来开始车主配对，链接的示例如下:
   https://digitalkeypairing.org/v1/0001?technology=NFC,BLE&graphics=0001A0A1A2A3#pwd=12345678
   当用户在手机上点击这个链接的时候，手机里面的 Framework就获取这个pwd开始进入到车主配对的流程中，当整个配对进度完整之后，用户的手机就成为了一把数字钥匙。

二、车主配对相关密钥派生

1. Derivation of Z0，Z1 with Scrypt

D.1 Derivation of Z0，Z1 with Scrypt
这里的配对密码 pwd 在CCC3.0中要求的是13bytes长度，但是苹果手机要求的配对密码是4字节长度，所以在URL链接里面的密码长度为4字节的，这个还是的看具体手机厂商的要求来设定即可！
盐值 Salt 则是车厂服务器产生的16字节的随机数！
当拥有了 pwd 和 Salt 以后， Vehicle OEM Server 就可以使用算法计算SPAKE2+ 认证过程中的密钥了：
z0 = left 40 bytes of Scrypt(pwd，s， Nscrypt，r，p，dkLen)
z1 = right 40 bytes of Scrypt(pwd，s， Nscrypt，r，p，dkLen)

2. Computation of w0，w1

D.2 Computation of w0，w1
由配对码pwd + 盐值Salt 派生出z0/z1 然后再派生 w0/w1：
（pwd，s）—Scrypt --> (z0，z1) --Mod–> （w0，w1）

3. Computation of L

D.3 Computation of L
根据前面步骤得到的w1计算基点G 的标量倍乘的结果 L

4. Computation of X

D.4 Computation of X
手机端自身利用公式 X = xG + w0M 计算得到椭圆曲线上的三个点
xG(x,y) & w0M(x,y) & X(x,y)，手机把其中的一个点 X 给到车辆端
就是当车辆发送 SPAKE2+ Request 的时候，手机端在SPAKE2+ Response 反馈的时候返回的就是 X 的坐标点。

5. Computation of Y

D.5 Computation of Y
Y是由车辆端来计算的，Y = yG + w0N ，计算的Y 在 SPAKE2+ Verify 命令中发送给手机端去进行校验，同时手机端在 SPAKE2+ Response 反馈中的数据也是给到车辆端来校验手机的身份，通过两边的互相校验来最终确认双方的身份。

6. Computation of Z，V(by device)

D.6 Computation of Z，V(by device)
车辆在向手机发送 SPAKE2+ verify 命令时需要发送 Y 给到手机，手机端则可以据此计算出协商的共享密钥 Z 和 V。Z 和 V 后面和车辆端计算的 Z 和 V 是保持一致的，并不会在通讯过程中传递 Z 和 V, 所以称 Z / V 是协商对称密钥。

7. Computation of Z，V(by vehicle)

D.7 Computation of Z，V(by vehicle)
因为前面已经知道，手机传递 X 至车辆，而车辆传递 Y 至手机端，此处车辆利用手机端的 X 来计算协商对称密钥 Z 和 V 。

8. Derivation of K，CK，SK

D.8 Derivation of K，CK，SK
最后利用 X | Y | Z | V | w0 参与哈希256算法得到32bytes 密钥 K，所以 K 在车辆和手机端也是一样的，也是一个协商的对称密钥：
CK = left 16 bytes of K = SHA-256(X，Y ， Z ，V ，w0)
SK = right 16 bytes of K = SHA-256(X， Y ， Z ， V ，w0)

9. Derivation of Evidence Keys K1，K2

D.9 Derivation of Evidence Keys K1，K2
K1 和 K2 就是计算出来用于生成 M[1] 和 M[2] 的校验值。

10. Computation of Evidences M1 M2

D.10 Computation of Evidences M1 M2
车辆发送SPAKE2+ VERIFY Command 的时候携带的就是 Y 和 M[1] ，手机端在接收到数据 Y以后计算出一个 Endpoint_M[1] ，手机端将自身计算的 Endpoint_M[1] 与接收到的 M[1] 进行比对来完成对车辆的身份确认，如果对比确认通过则会返回一个 Device evidence M[2]
当车辆端接收到M[2]的时候，也会使用Y计算出一个 Vehicle_M[2]， 将Vehicle_M[2] 与手机反馈的 M[2]进行比对，以此来校验手机端的身份，当双方使用配对密码 pwd 完成了双向身份验证之后，后面的配对流程才得以继续，否则用户点击车主配对链接后直接失败！

11. Derivation of System Keys

D.11 Derivation of System Keys
利用SK 派生出系统密钥，主要离散出 SCP03安全通道密钥(Kenc/Kmac/Krmac)和长期密钥LONG_TERM_SHARED_SECRET

三、SPAKE2+ Flow流程说明

如果有了前面密钥的讲解过程后，下面的的 SPAKE2+ Flow 双端身份验证流程就只是车辆与手机端的两条应答指令就完成了认证的过程，验证通过后就可以进行后面的车主配对的过程了！
Vehicle --------------------SPAKE2+ Request Commad ------------------> Device
Vehicle <--------------------SPAKE2+ Response -------------------------------Device
Vehicle --------------------SPAKE2+ Verify Command---------------------->Device
Vehicle <--------------------SPAKE2+ Verify Response-----------------------Device
​​

总结

本文主要讲解了 SPAKE2+ Flow 的身份验证流程，以及车辆端和手机端如何利用配对密码 pwd 来生成最终的校验值 M[1] 和 M[2] 。