整理了一下CCC組織的汽車數(shù)字鑰匙Release 3中關(guān)于車主配對Owner Paring馒胆，過程的APDU指令和數(shù)據(jù)說明卡儒√锇螅基本可以算是在車端的角度進(jìn)行車主配對操作鳍徽。里面的章節(jié)表格編號沿量，都按照CCC數(shù)字鑰匙Release 3文檔中的編號走傍衡，方便將來檢索對照词渤。

車主配對命令

5.1 車主配對的指令

表5-1：車主配對命令集

表5-2 基本狀態(tài)字

5.1.1 SELECT指令

汽車向鑰匙設(shè)備發(fā)送SELECT AID指令猫妙。Digital Key framework AID為 A000000809434343444B467631。

當(dāng)Digital Key framework被選中考蕾，設(shè)備應(yīng)當(dāng)按照表5-3返回?cái)?shù)據(jù)祸憋。

鑰匙設(shè)備應(yīng)當(dāng)向車輛指示當(dāng)前配對狀態(tài)，可能狀態(tài)有：

• 未配對
• 配對模式開始且配對口令已經(jīng)輸入

SELECT指令用來選擇Digital Key applet實(shí)例（使用實(shí)例AID）在15.3.2.1定義肖卧。

C-APDU: 00 A4 04 00 Lc [Digital_Key_Framework_AID] 00

R-APDU: [表 5-3]90 00

表 5-3 SELECT指令響應(yīng)

鑰匙設(shè)備應(yīng)當(dāng)返回所有支持的的SPAKE2+和支持的Digital Key applet協(xié)議版本蚯窥，每個版本使用2字節(jié)大端編碼的數(shù)據(jù)。

在CCC Release 3的規(guī)范里塞帐，鑰匙設(shè)備應(yīng)當(dāng)支持SPAKE2+協(xié)議版本1.0（編碼0100）和Digital Key applet協(xié)議1.0（編碼0100）拦赠。車輛應(yīng)當(dāng)依據(jù)6.3.3.8來匹配支持的版本。

鑰匙設(shè)備是否處于配對模式時會發(fā)出信號葵姥，如果鑰匙設(shè)備是“未配對”模式荷鼠，車輛只有在自己處于已配對模式時才能繼續(xù)（行駛）。

5.2.1 SPAKE2+REQUEST指令

在這個指令中榔幸，車輛應(yīng)當(dāng)發(fā)送所選擇的SPAKE2+版本允乐，所有支持的Digital Key applet協(xié)議版本和SPAKE2+的Scrypt參數(shù)。車輛應(yīng)當(dāng)在響應(yīng)中獲取SPAKE2+協(xié)議的曲線點(diǎn)X削咆。SPAKE2+REQUEST指令使用的參數(shù)見18節(jié)牍疏。

C-APDU：80 30 00 00 Lc [表 5-4] 00

R-APDU：[表 5-5] 90 00

表5-4 SPAKE2+REQUEST指令

Tag	長度(bytes)	描述	是否強(qiáng)制
5B	2	同意的SPAKE2+協(xié)議版本	強(qiáng)制
5C	2*m	m支持的Digital Key applet協(xié)議版本（ver.high|ver.low）	強(qiáng)制
7F50	32	Scrypt配置參數(shù)	強(qiáng)制
- C0	16	密碼鹽值 s	強(qiáng)制
- C1	4	Scrypt cost參數(shù)，	強(qiáng)制
- C2	2	塊大小參數(shù) r	強(qiáng)制
- C3	2	平行化參數(shù) p	強(qiáng)制
D6	2	車輛品牌（見表2-1）包含這個Tag拨齐，包括只支持NFC的的車輛	強(qiáng)制

表5-5 SPAKE2+REQUEST 響應(yīng)

在發(fā)送SPAKE2+REQUEST指令前，車輛應(yīng)當(dāng)先檢查SPAKE2+配對計(jì)數(shù)器瞻惋。如果計(jì)數(shù)器指示已經(jīng)配對7次厦滤，車輛應(yīng)當(dāng)不再發(fā)送配對指令。相反的歼狼，車輛應(yīng)當(dāng)發(fā)送一個OP CONTROL FLOW來中止（超過錯誤計(jì)數(shù)器次數(shù)掏导、需要新的配對口令或者沒有明確原因）。當(dāng)新的配對口令產(chǎn)生羽峰，計(jì)數(shù)器將被復(fù)位碘菜。

車輛應(yīng)當(dāng)發(fā)送所選的2字節(jié)的SPAKE2+協(xié)議版本。

車輛也應(yīng)當(dāng)發(fā)送支持的Digital Key applet 協(xié)議版本列表限寞，借此第一個被列出的版本應(yīng)當(dāng)被車主設(shè)備使用。整個Digital Key applet協(xié)議版本列表（Tag 5C）應(yīng)當(dāng)被包含在Key Creation Request（見11.8.1仰坦，DIGITAL_KEY_APPLET_PROTOCOL_VERSION）履植。這個允許在分享鑰匙到好友設(shè)備時選擇最好的版本使用。

SPAKE2+協(xié)議所有的曲線點(diǎn)的定義遵守X9.63標(biāo)準(zhǔn)悄晃，格式為 0x04||<x>||<y>的字節(jié)流玫霎，x和y為32字節(jié)的大端表示（見18.1）凿滤。

如果返回的X值在無窮遠(yuǎn)或者不是一個在橢圓曲線上定義的合法的點(diǎn)，車輛應(yīng)當(dāng)中止流程庶近，并發(fā)送OP CONTROL FLOW指令翁脆，按照5.1.7的描述P2值設(shè)置為0C。

Scrypt的迭代次數(shù)（cost參數(shù)）是一個4字節(jié)的無符號整數(shù)鼻种，用來配置Scrypt功能（見18.4）在主機(jī)廠服務(wù)器和鑰匙設(shè)備上來派生校驗(yàn)者的值反番。其他傳輸?shù)腟crypt參數(shù)還有塊大小和平行化參數(shù)（見18.1.2）。Scrypt cost參數(shù)叉钥、塊大小參數(shù)罢缸、平行化參數(shù)的TLV值部分都是編碼為大端格式。

如果車輛沒有找到雙方支持的SPAKE2+或者Digital Key applet協(xié)議版本投队，車輛應(yīng)當(dāng)發(fā)送一個OP_FLOW_CONTROL(Owner Paring
FLow Control)指令包含表5-24中定義的原因代碼枫疆，代替SPAKE2+REQUEST指令。

如果SPAKE2+REQUEST指令被成功處理敷鸦，車輛和鑰匙設(shè)備應(yīng)當(dāng)計(jì)算共享密鑰K息楔，分別為Listing 18-4和Listing 18-5。

表5-6 SPAKE2+REQUEST響應(yīng)錯誤狀態(tài)字

5.1.3 SPAKE2+VERIFY 指令

這個指令相互交換證據(jù)來證明雙方計(jì)算出來的共享密鑰是相同的扒披。

C-APDU: 80 32 00 00 Lc [表 5-7] 00

R-APDU: [表 5-8] 90 00

表5-7 SPAKE2+VERIFY指令

表5-8 SPAKE2+VERIFY響應(yīng)

在發(fā)送SPAKE2+VERIFY指令之前，汽車應(yīng)當(dāng)先給SPAKE2+配對嘗試計(jì)數(shù)器加1谎碍。

汽車應(yīng)當(dāng)計(jì)算證據(jù)M[1]（描述在Listing 18-7）并發(fā)送它給鑰匙設(shè)備鳞滨，一起發(fā)送的還有曲線點(diǎn)Y。

鑰匙設(shè)備應(yīng)當(dāng)驗(yàn)證下面的內(nèi)容：

• 1. 收到的曲線點(diǎn)Y是否是定義在橢圓曲線上的合法的點(diǎn)
• 2. 收到M[1]

如果都驗(yàn)證成功蟆淀，鑰匙設(shè)備應(yīng)當(dāng)計(jì)算證據(jù)M[2]（描述Listing 18-8）拯啦，并在SPAKE2+響應(yīng)中將M[2]給車輛返回。

只有車輛成功驗(yàn)證了收到的M[2]熔任，車輛才能繼續(xù)車主配對流程褒链。

如果上面任何驗(yàn)證失敗，比如鑰匙不能計(jì)算M[2]且不能返回M[2]或者返回其他除了狀態(tài)字之外的響應(yīng)疑苔。這種情況車輛應(yīng)當(dāng)發(fā)送一個OP_CONTROL_FLOW指令按照5.1.7中的描述將P2設(shè)置未09去中止車主配對.

表5-9 SPAKE2+VERIFY響應(yīng)狀態(tài)字

SPAKE2+VERIFY步驟引出用于建立鑰匙框架和車輛交換后續(xù)指令的SCP03通道的安全通道密鑰甫匹。建立SCP03通道的遵守Listing 18-10和Listing 18-11。創(chuàng)建安全通道的密鑰在下列情況應(yīng)當(dāng)被復(fù)位：

• 在成功配對之后
• 當(dāng)鑰匙設(shè)備響應(yīng)的狀態(tài)字不是9000或者6100時
• SPAKE2+REQUEST指令已經(jīng)發(fā)送
• 當(dāng)出現(xiàn)通信中斷時
• 車主配對沒有終止惦费，但時間超過最大允許的時間

車輛需要再重新開始SPAKE2+建立新密鑰兵迅。注意這種情況配對口令還是原來的。車輛應(yīng)當(dāng)在7次嘗試失敗后更換口令薪贫。

5.1.4 WRITE DATA指令

這個指令向鑰匙設(shè)備發(fā)送生成數(shù)字鑰匙所需要的所有數(shù)據(jù)恍箭。它也用于提供證明車輛的密鑰追蹤用途的設(shè)備公鑰。(好蹩腳瞧省，湊合看)

C-APDU: 84 D4 P1 00 Lc [command_data] [command_mac] 00
R-APDU: [response_mac] 90 00

除了發(fā)最后一次WRITE DATA指令時P1應(yīng)當(dāng)設(shè)置為80外扯夭，其他情況下參數(shù)P1和P2永遠(yuǎn)設(shè)置為0鳍贾。

這個指令只允許在安全通道內(nèi)發(fā)送。

表5-10 WRITE DATA響應(yīng)狀態(tài)字

一個或者多個WRITE DATA指令可以用來向鑰匙設(shè)備寫入請求的數(shù)據(jù)對象交洗。

表5-11 數(shù)字鑰匙創(chuàng)建數(shù)據(jù)對象

表5-12 設(shè)備數(shù)字鑰匙證書的對象

表5-11中所有要求的的對象應(yīng)當(dāng)按照表格順序被寫入設(shè)備。

一個或者多個TLV允許被寫在每個WRITE DATA指令中隐圾。

TLV 5F5F應(yīng)當(dāng)在最后被寫入標(biāo)記數(shù)據(jù)寫入結(jié)束伍掀。最后一個WRITE DATA指令應(yīng)當(dāng)通過設(shè)置P1=80指示包含TLV 5F5F。

當(dāng)車輛已經(jīng)接受了設(shè)備公鑰暇藏，表5-12中所有要求的對象應(yīng)當(dāng)被寫入鑰匙設(shè)備蜜笤。最后一個WRITE DATA指令應(yīng)當(dāng)通過設(shè)置P1=80來指示。

5F5F 應(yīng)當(dāng)為最后一個被寫入的TLV盐碱，標(biāo)記傳輸數(shù)據(jù)結(jié)束把兔。

Tag 7F4A應(yīng)當(dāng)包含表15-13中所有數(shù)據(jù)元素，除了下面的元素：

• 端點(diǎn)標(biāo)識符（設(shè)備定義）
• Instance CA標(biāo)識符 （設(shè)備定義）
• 計(jì)數(shù)器限制（棄用瓮顽，不使用）

如果車輛標(biāo)識符作為7F4A的一部分提供县好，設(shè)備應(yīng)當(dāng)比較它的值和車輛公鑰葉子證書K的值，如果檢查失敗車主配對應(yīng)當(dāng)中止暖混。

最大指令數(shù)據(jù)長度應(yīng)道為239字節(jié)：len=[command_data] + [padding] + [command_mac]

len = 239 + 1 + 8 <= 255(ok)

len = 240 + 16 + 8 255(not ok)

[command_data]+[padding]應(yīng)道是AES分組16字節(jié)的整數(shù)倍缕贡。填充方案描述在9.至少填充1字節(jié)的80。最大響應(yīng)數(shù)據(jù)長度應(yīng)當(dāng)為239字節(jié)拣播。

車輛公鑰應(yīng)當(dāng)以被主機(jī)廠CA簽發(fā)的一個X509證書形式提供晾咪，描述在Listing 5-3。

Listing 5-1 車輛證書擴(kuò)展方案

VehicleCertificateExtensionSchema ::= SEQUENCE
{
 extension_version INTEGER (1..255)
}

Listing 5-2 車輛證書擴(kuò)展數(shù)據(jù)

vehicle-cert-extension-data VehicleCertificateExtensionSchema ::=
{
 extension_version 1 --value shall be 1
}

車輛公鑰證書數(shù)據(jù)描述在Listing 5-3贮配。

Listing 5-3 車輛公鑰證書數(shù)據(jù)

vehicle-key-cert-data Certificate ::=
 {
 tbsCertificate
 {
 version v3, --shall be v3--
 serialNumber ..., --a random integer chosen by the certificate issuer,
 Signature
 {
 algorithm {1 2 840 10045 4 3 2} --OID for ecdsaWithSHA256 (ANSI X9.62 ECDSA algorithm with SHA-256)
 },
 issuer rdnSequence:
 {
 {
 {
 type {2 5 4 3}, --OID for CommonName
 value "..." --shall match the subject of the issuing certificate, shall use PrintableString or UTF8String format

 }
 }
 },
 validity
 {
 notBefore Time: "..." --shall use UTCTime or GeneralizedTime as defined in [3]
 notAfter Time: "..." --shall use UTCTime or GeneralizedTime as defined in [3]
 },
 subject rdnSequence:
 {
 {
 {
 type {2 5 4 3}, --OID for CommonName
 value "Vehicle OEM Identifier" --contains the subject of the certificate, as per Appendix B.2.6
 shall use PrintableString or UTF8String format
 }
 }
 },
 subjectPublicKeyInfo
 {
 algorithm
 {
 algorithm {1 2 840 10045 2 1} --OID for ecPublicKey (ANSI X9.62 public key type)
 parameters {1 2 840 10045 3 1 7} --OID for prime256v1(ANSI X9.62 named elliptic curve)
 },
 subjectPublicKey '04...'H --the public key pre-pended with 04 h to indicate uncompressed format
 },
 extensions
{
{
extnID {1.3.6.1.4.1.41577.5.1}, --OID for Vehicle Public Key Certificate (see Appendix B.2.2)
critical TRUE,
extnValue ‘…’H --DER encoding for VehicleCertificateExtensionSchema extension as per Listing 5-1
},
 {
 extnID {2 5 29 15}, --KeyUsage standard extension
 critical TRUE,
 extnValue '03020780'H --DER encoding for KeyUsage, digitalSignature only
 },
 {
 extnID {2 5 29 19}, --BasicConstraints standard extension
 critical TRUE,
 extnValue '3000'H -- DER encoding for cA=FALSE
 },
 {
 extnID {2 5 29 35}, --OID for AuthorityKeyIdentifier standard extension
 critical FALSE,
 extnValue '...'H- DER encoding of an AuthorityKeyIdentifier sequence, containing only a KeyIdentifier element.
 -- The KeyIdentifier is an OCTET STRING containing the 160-bit SHA-1 hash of the value of the BIT STRING
subjectPublicKey
 --from the issuer certificate (excluding the tag, length, and number of unused bits)
 },
 {
 extnID {2 5 29 14}, -- OID for SubjectKeyIdentifier standard extension
 critical FALSE,
 extnValue ‘…’H --160-bit SHA1 hash of the value of the BIT STRING subjectPublicKey
--(excluding the tag, length, and number of unused bits)
}
 }
 },
 signatureAlgorithm
 {
 algorithm {1 2 840 10045 4 3 2}
 },
 signatureValue '...'H --the certificate signature computed as per [3]
 --ECDSA signature
 }

5.1.5 GET DATA指令

這個指令應(yīng)當(dāng)繼續(xù)使用已經(jīng)建立的會話密鑰去檢索所有需要的所有數(shù)據(jù)谍倦，驗(yàn)證Digital Key framework創(chuàng)建在Digital Key applet 實(shí)例中的數(shù)字鑰匙。

C-APDU: 84 CA 00 00 Lc [encrypted_tag] [command_mac] 00

R-APDU: [response_payload] [response_mac] 90 00 or 61XX

每個GET DATA指令一次只能請求一個Tag 泪勒。---->這個地方跟EMV或者其他應(yīng)用一樣昼蛀。

X509證書不應(yīng)當(dāng)在封裝成TLV結(jié)構(gòu)

5.1.6 GET RESPONSE指令

跟ISO 14443規(guī)定的一個樣，這里就不寫了圆存。