关于密码学:CCC-数字钥匙学习笔记-车主配对命令

51次阅读

共计 7171 个字符,预计需要花费 18 分钟才能阅读完成。

整顿了一下 CCC 组织的汽车数字钥匙 Release 3 中对于车主配对 Owner Paring,过程的 APDU 指令和数据阐明。根本能够算是在车端的角度进行车主配对操作。外面的章节表格编号,都依照 CCC 数字钥匙 Release 3 文档中的编号走,不便未来检索对照。

车主配对命令

5.1 车主配对的指令

表 5 -1:车主配对命令集

命令 Ins Byte(HEX) 实现方
SELECT A4 Digital Key Framework
SPAKE2+REQUEST 30 Digital Key Framework
SPAKE2+VERIFY 32 Digital Key Framework
WRITE DATA D4 Digital Key Framework
GET DATA CA Digital Key Framework
GET RESPONSE C0 Digital Key Framework
OP CONTROL FLOW 3C Digital Key Framework
参见表 15-1 5.3.2 Digital Key Applet

表 5 -2 根本状态字

SW1SW2 形容
6700 长度错
6A80 数据域的参数错
6A82 文件找不到
6B00 P1 P2 错
6C00 Le 错
6D00 INS 错
6E00 CLA 错
9000 胜利

5.1.1 SELECT 指令

汽车向钥匙设施发送 SELECT AID 指令。Digital Key framework AID 为 A000000809434343444B467631

当 Digital Key framework 被选中,设施该当依照表 5 - 3 返回数据。

钥匙设施该当向车辆批示以后配对状态,可能状态有:

  • 未配对
  • 配对模式开始且配对口令曾经输出

SELECT 指令用来抉择 Digital Key applet 实例(应用实例 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 指令响应

Tag 长度 (bytes) 形容 是否必须
5A 2*n n 反对 SPAKE2+ 协定版本(ver.high\ ver.low) 必须
5C 2*m m 反对的 Digital Key applet 协定版本(ver.high\ ver.low) 必须
D4 1 00 = 未配对 <br/>02 = 配对模式开始且配对口令曾经输出 必须

钥匙设施该当返回所有反对的的 SPAKE2+ 和反对的 Digital Key applet 协定版本,每个版本应用 2 字节大端编码的数据。

在 CCC Release 3 的标准里,钥匙设施该当反对 SPAKE2+ 协定版本 1.0(编码 0100)和 Digital Key applet 协定 1.0(编码 0100)。车辆该当根据 6.3.3.8 来匹配反对的版本。

钥匙设施是否处于配对模式时会发出信号,如果钥匙设施是“未配对”模式,车辆只有在本人处于已配对模式时能力持续(行驶)。

5.2.1 SPAKE2+REQUEST 指令

在这个指令中,车辆该当发送所抉择的 SPAKE2+ 版本,所有反对的 Digital Key applet 协定版本和 SPAKE2+ 的 Scrypt 参数。车辆该当在响应中获取 SPAKE2+ 协定的曲线点 X。SPAKE2+REQUEST 指令应用的参数见 18 节。

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

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

表 5 -4 SPAKE2+REQUEST 指令

Tag 长度 (bytes) 形容 是否强制
5B 2 批准的 SPAKE2+ 协定版本 强制
5C 2*m m 反对的 Digital Key applet 协定版本(ver.high\ ver.low) 强制
7F50 32 Scrypt 配置参数 强制
– C0 16 明码盐值 s 强制
– C1 4 Scrypt cost 参数,$N_{scrypt}$ 强制
– C2 2 块大小参数 r 强制
– C3 2 平行化参数 p 强制
D6 2 车辆品牌(见表 2 -1)蕴含这个 Tag,包含只反对 NFC 的的车辆 强制

表 5 -5 SPAKE2+REQUEST 响应

Tag 长度 (bytes) 形容 是否强制
50 65 SPAKE2+ 协定的曲线点 X,prepended with 04 h as per Listing 18-3 强制

在发送 SPAKE2+REQUEST 指令前,车辆该当先查看 SPAKE2+ 配对计数器。如果计数器批示曾经配对 7 次,车辆该当不再发送配对指令。相同的,车辆该当发送一个 OP CONTROL FLOW 来停止(超过谬误计数器次数、须要新的配对口令或者没有明确起因)。当新的配对口令产生,计数器将被复位。

车辆该当发送所选的 2 字节的 SPAKE2+ 协定版本。

车辆也该当发送反对的 Digital Key applet 协定版本列表,借此第一个被列出的版本该当被车主设施应用。整个 Digital Key applet 协定版本列表(Tag 5C)该当被蕴含在 Key Creation Request(见 11.8.1,DIGITAL_KEY_APPLET_PROTOCOL_VERSION)。这个容许在分享钥匙到好友设施时抉择最好的版本应用。

SPAKE2+ 协定所有的曲线点的定义恪守 X9.63 规范,格局为 0x04||\<x\>||\<y\> 的字节流,x 和 y 为 32 字节的大端示意(见 18.1)。

如果返回的 X 值在无穷远或者不是一个在椭圆曲线上定义的非法的点,车辆该当停止流程,并发送 OP CONTROL FLOW 指令,依照 5.1.7 的形容 P2 值设置为 0C。

Scrypt 的迭代次数(cost 参数)是一个 4 字节的无符号整数,用来配置 Scrypt 性能(见 18.4)在主机厂服务器和钥匙设施上来派生校验者的值。其余传输的 Scrypt 参数还有块大小和平行化参数(见 18.1.2)。Scrypt cost 参数、块大小参数、平行化参数的 TLV 值局部都是编码为大端格局。

如果车辆没有找到单方反对的 SPAKE2+ 或者 Digital Key applet 协定版本,车辆该当发送一个 OP_FLOW_CONTROL(Owner Paring
FLow Control) 指令蕴含表 5 -24 中定义的起因代码,代替 SPAKE2+REQUEST 指令。

如果 SPAKE2+REQUEST 指令被胜利解决,车辆和钥匙设施该当计算共享密钥 K,别离为 Listing 18- 4 和 Listing 18-5。

表 5 -6 SPAKE2+REQUEST 响应谬误状态字

SW1SW2 形容
6985 指令应用程序不对
6A88 收到的数据不非法或者为 0
9484 设施配对还未准备就绪

5.1.3 SPAKE2+VERIFY 指令

这个指令相互交换证据来证实单方计算出来的共享密钥是雷同的。

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

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

表 5 -7 SPAKE2+VERIFY 指令

Tag 长度 (bytes) 形容 是否强制
52 65 SPAKE2+ 协定的曲线点 Y,prepended with 04 h as per Listing 18-2 强制
57 16 车辆证据 M[1] 强制

表 5 -8 SPAKE2+VERIFY 响应

Tag 长度 (bytes) 形容 是否强制
58 16 钥匙设施证据 M[2] 强制

在发送 SPAKE2+VERIFY 指令之前,汽车该当先给 SPAKE2+ 配对尝试计数器加 1。

汽车该当计算证据 M[1](形容在 Listing 18-7)并发送它给钥匙设施,一起发送的还有曲线点 Y。

钥匙设施该当验证上面的内容:

    1. 收到的曲线点 Y 是否是定义在椭圆曲线上的非法的点
    1. 收到 M[1]

如果都验证胜利,钥匙设施该当计算证据 M[2](形容 Listing 18-8),并在 SPAKE2+ 响应中将 M[2] 给车辆返回。

只有车辆胜利验证了收到的 M[2],车辆能力持续车主配对流程。

如果下面任何验证失败,比方钥匙不能计算 M[2] 且不能返回 M[2] 或者返回其余除了状态字之外的响应。这种状况车辆该当发送一个 OP_CONTROL_FLOW 指令依照 5.1.7 中的形容将 P2 设置未 09 去停止车主配对.

表 5 -9 SPAKE2+VERIFY 响应状态字

SW1SW2 形容
6985 指令应用程序不对
6A88 验证证据失败

SPAKE2+VERIFY 步骤引出用于建设钥匙框架和车辆替换后续指令的 SCP03 通道的平安通道密钥。建设 SCP03 通道的恪守 Listing 18-10 和 Listing 18-11。创立平安通道的密钥在下列状况该当被复位:

  • 在胜利配对之后
  • 当钥匙设施响应的状态字不是 9000 或者 6100 时
  • SPAKE2+REQUEST 指令曾经发送
  • 当呈现通信中断时
  • 车主配对没有终止,但工夫超过最大容许的工夫

车辆须要再从新开始 SPAKE2+ 建设新密钥。留神这种状况配对口令还是原来的。车辆该当在 7 次尝试失败后更换口令。

5.1.4 WRITE DATA 指令

这个指令向钥匙设施发送生成数字钥匙所须要的所有数据。它也用于提供证实车辆的密钥追踪用处的设施公钥。(好糟糕,对付看)

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

除了发最初一次 WRITE DATA 指令时 P1 该当设置为 80 外,其余状况下参数 P1 和 P2 永远设置为 0。

这个指令只容许在平安通道内发送。

表 5 -10 WRITE DATA 响应状态字

SW1SW2 形容
6985 指令应用程序不对
6A84 内存不够

一个或者多个 WRITE DATA 指令能够用来向钥匙设施写入申请的数据对象。

表 5 -11 数字钥匙创立数据对象

Tag 长度 (bytes) 数据内容 是否强制
7F4A var 端点创立数据,元素来自表 15-13 强制
7F4B var 车辆公钥证书 K,Der 编码 X509 证书,Listing 15-3 强制
7F4C var 两头证书,Der 编码的 X509 证书 可选
7F4D var 邮箱映射 表 5 -13 强制
7F4E var 设施配置 表 5 -14 强制
5F5F 0 数字钥匙数据发送实现 强制

表 5 -12 设施数字钥匙证书的对象

Tag 长度 (bytes) 数据内容 是否强制
5F5A var 车辆对设施的认证公钥(不通明) 可选
5F5F 0 数字钥匙证书发送实现 强制

表 5 -11 中所有要求的的对象该当依照表格程序被写入设施。

一个或者多个 TLV 容许被写在每个 WRITE DATA 指令中。

TLV 5F5F 该当在最初被写入标记数据写入完结。最初一个 WRITE DATA 指令该当通过设置 P1=80 批示蕴含 TLV 5F5F。

当车辆曾经承受了设施公钥,表 5 -12 中所有要求的对象该当被写入钥匙设施。最初一个 WRITE DATA 指令该当通过设置 P1=80 来批示。

5F5F 该当为最初一个被写入的 TLV,标记传输数据完结。

Tag 7F4A 该当蕴含表 15-13 中所有数据元素,除了上面的元素:

  • 端点标识符(设施定义)
  • Instance CA 标识符(设施定义)
  • 计数器限度(弃用,不应用)

如果车辆标识符作为 7F4A 的一部分提供,设施该当比拟它的值和车辆公钥叶子证书 K 的值,如果查看失败车主配对该当停止。

最大指令数据长度应道为 239 字节:len=[command_data] + [padding] + [command_mac]

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

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

[command_data]+[padding] 应道是 AES 分组 16 字节的整数倍。填充计划形容在 9. 至多填充 1 字节的 80。最大响应数据长度该当为 239 字节。

车辆公钥该当以被主机厂 CA 签发的一个 X509 证书模式提供,形容在 Listing 5-3。

Listing 5-1 车辆证书扩大计划

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

Listing 5-2 车辆证书扩大数据

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

车辆公钥证书数据形容在 Listing 5-3。

Listing 5-3 车辆公钥证书数据

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 指令

这个指令该当持续应用曾经建设的会话密钥去检索所有须要的所有数据,验证 Digital Key framework 创立在 Digital Key applet 实例中的数字钥匙。

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 或者其余利用一样。

X509 证书不该当在封装成 TLV 构造

5.1.6 GET RESPONSE 指令

跟 ISO 14443 规定的一个样,这里就不写了。

正文完
 0