CCC SPAKE2+流程解析
1、SPAKE2+流程及SCP03通道介绍
SPAKE2+流程发生在CCC车主配对过程中的Phase2。
SPAKE2+流程为车辆和手机之间的数据交换建立了一个安全通道SCP03。
那这个SCP03通道是干啥的？
我们可以先简单的理解为：建立安全通道前，车辆和手机之间交互的APDU数据是明文，建立安全通道后，车辆和手机之间交互的APDU数据是密文。具体详细可参考文档《GPC_2.3_D_SCP03_v1.2_PublicRelease.pdf》，本文不展开详细描述。
该安全通道在整个RF复位期间保持为激活状态。即，虽然在车主配对过程中的某些步骤，NFC会关闭/重启，但该安全通道一直保持在激活状态。
那哪些情况下，这个安全通道会被关闭?
发生如下任意一种情况时，则该安全通道会被关闭：
1) 当发送成功的OP CONTROL FLOW命令(如Figure6-3中的步骤17)，
2) 或，当发送错误的OP CONTROL FLOW命令，
3) 或，当SPAKE2+流程（Figure6-4）由于任何异常导致的终止，
4) 或，当APDU命令解密错误
5) 或，当APDU命令中的MAC值是错误的。
当车辆尚未准备好进行车主配对时，应使用OP CONTROL FLOW中止并向用户提示情况，如preconditions for owner pairing not fulfilled （未满足车主配对的前提条件）。
2、CCC SPAKE2+流程
CCC标准中关于SPAKE2+流程如下图，下面详细讲解下这个SPAKE2+流程，主要讲解流程，对相关算法暂不做深入解析。
2.1、SPAKE2+流程详细解析
根据自己的理解，我将上面CCC的SPAKE2+流程，梳理成下图，接下来展开各部分的解析。
2.1.1 步骤1
步骤#1解析如下：
1) 车辆OEM服务器产生Salt, password；
2) 车辆OEM服务器计算L, w0；
3) 把password发送给手机（可通过网页或车辆OEM的App）
4) 发送Salt, L, w0给到车辆（通过车辆OEM专有链路）；
具体可参考下图Listing18-1:
2.1.2 步骤2
步骤#2解析如下：
1) 车辆产生随机数y；
2) 车辆计算Y = y * G +w0 * N；
3) 车辆通过SPAKE2+ Request Command发送salt，Y等参数给手机；
4) 手机产生随机数x；
5) 手机计算X =x × G + w0 × M；
6) 手机通过SPAKE2 Response发送X等参数给车辆；
该步骤中的1->3步骤，对应下图Listing 18-2
该步骤中的4->6步骤，对应下图Listing 18-3
2.1.3 步骤3
步骤#3解析如下：
1) 车辆计算Z，V，K，CK，SK，如下图Listing 18-4；
a) Z = y×(X-w0×M)
b) V = y×L
c) K = SHA-256(len(X) || X || len(Y) || Y || len(Z) || Z || len(V) || V || len(w0) || w0)
d) CK = [0:128]
e) SK = [128:128]
2) 手机计算Z，V，K，CK，SK，如下图Listing 18-5；
a) Z = x×(Y-w0×N)
b) V = w1×(Y-w0×N)
c) K = SHA-256(len(X) || X || len(Y) || Y || len(Z) || Z || len(V) || V || len(w0) || w0)
d) CK = [0:128]
e) SK = [128:128]
2.1.4 步骤4
步骤#4解析如下：
1) 车辆和手机分别计算各自的K1，K2，M1，M2；
a) K1=HKDF(CK, “ConfirmationKeys” || TLV 5Bh || TLV 5Ch, [0:128])
b) K2=HKDF(CK, “ConfirmationKeys” || TLV 5Bh || TLV 5Ch, [128:128])
c) M[1] = CMAC(K1, X)
d) M[2] = CMAC(K2, X)
2) 车辆通过SPAKE2+ Verify Command，将M[1]发送给手机；
3) 手机确认发送过来的M[1]是否与自身计算的M[1]相同，若相同则流程继续，否则异常退出；
4) 手机通过SPAKE2+ Verify Response，将M[2]发送给车辆；
5) 车辆确认发送过来的M[2]是否与自身计算的M[2]相同，若相同则流程继续，否则异常退出；
关于K1，K2的计算，详见下图Listing 18-6：
关于M1的计算，详见下图Listing 18-7：
关于M2的计算，详见下图Listing 18-8：
2.1.5 步骤5
步骤#5解析如下：
1) 车辆和手机分别计算各自的Kenc, Kmac, Krmac, LONG_TERM_SHARED_SECRET；
2) 若Flag_Kble_intro_Kble_oob_master_support==TRUE，则需额外输出 Kble_intro和Kble_oob_master ；
具体可参考下图Listing 18-9：
2.1.6 步骤6
步骤#6解析如下：
1) 前5个步骤完成后，则SPAKE2+流程已经完成，手机和车辆已完成SCP03通道的建立；
2) 之后手机和车辆交互的APDU则为密文交互；
3) 即，发送方会根据Kenc, Kmac, Krmac密钥，而接收方收到数据后再进行解密。
加密计算过程如下图Listing18-10和Listing18-11
3、总结
1) SPAKE2+流程发生在CCC车主配对过程中的Phase2。
2) SPAKE2+流程为车辆和手机之间的数据交换建立了一个安全通道SCP03。
3) 建立SCP03安全通道前，车辆和手机之间交互的APDU数据是明文，建立安全通道后，车辆和手机之间交互的APDU数据是密文。
4) SPAKE2+流程可拆解为如下步骤：
a) 在车主配对流程中的Phase0，车辆OEM服务器发送Salt, L, w0给到车辆，把password发送给手机；
b) 手机&车辆双方通过SPAKE2+ Request Command和SPAKE2+ Response交互Salt，Y，X等信息
c) 手机&车辆双方各自计算Z,V,K,CK,SK等共享密钥信息
d) 手机&车辆双方各自计算K1,K2,M1,M2等信息，通过SPAKE2+ Verify Command和SPAKE2+ Verify Response交互M[1], M[2]，并验证各自收到的信息是否正确
e) 手机&车辆双方各自生成Syetem Keys，主要包含Kenc, Kmac, Krmac等信息。
f) 至此完成SPAKE2+流程，建立SCP03安全通道，之后的APDU交互则为密文交互。即发送方会根据Kenc, Kmac, Krmac密钥, 对数据进行加密，然后发送；接收方收到数据后，再进行解密。