CN117378169A - 一种密钥生成方法及装置 - Google Patents
一种密钥生成方法及装置 Download PDFInfo
- Publication number
- CN117378169A CN117378169A CN202180098495.4A CN202180098495A CN117378169A CN 117378169 A CN117378169 A CN 117378169A CN 202180098495 A CN202180098495 A CN 202180098495A CN 117378169 A CN117378169 A CN 117378169A
- Authority
- CN
- China
- Prior art keywords
- key
- vehicle
- message
- mounted device
- kms
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 217
- 230000004044 response Effects 0.000 claims abstract description 185
- 238000010276 construction Methods 0.000 claims description 250
- 238000012795 verification Methods 0.000 claims description 247
- 238000003860 storage Methods 0.000 claims description 57
- 238000004891 communication Methods 0.000 claims description 41
- 238000004590 computer program Methods 0.000 claims description 24
- 230000007774 longterm Effects 0.000 description 84
- 238000012545 processing Methods 0.000 description 54
- 230000008569 process Effects 0.000 description 51
- 230000006870 function Effects 0.000 description 35
- 238000003745 diagnosis Methods 0.000 description 30
- 230000000977 initiatory effect Effects 0.000 description 22
- 238000010586 diagram Methods 0.000 description 21
- 238000007726 management method Methods 0.000 description 20
- VIEYMVWPECAOCY-UHFFFAOYSA-N 7-amino-4-(chloromethyl)chromen-2-one Chemical compound ClCC1=CC(=O)OC2=CC(N)=CC=C21 VIEYMVWPECAOCY-UHFFFAOYSA-N 0.000 description 19
- 230000005540 biological transmission Effects 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 11
- 238000004519 manufacturing process Methods 0.000 description 11
- 241000208340 Araliaceae Species 0.000 description 10
- 235000005035 Panax pseudoginseng ssp. pseudoginseng Nutrition 0.000 description 10
- 235000003140 Panax quinquefolius Nutrition 0.000 description 10
- 238000011161 development Methods 0.000 description 10
- 235000008434 ginseng Nutrition 0.000 description 10
- 238000004364 calculation method Methods 0.000 description 9
- 239000003795 chemical substances by application Substances 0.000 description 9
- 230000004913 activation Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 5
- 230000001960 triggered effect Effects 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 238000013500 data storage Methods 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 3
- 238000009795 derivation Methods 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000002955 isolation Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 239000004973 liquid crystal related substance Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012827 research and development Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 206010063385 Intellectualisation Diseases 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000002405 diagnostic procedure Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 238000011282 treatment Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Lock And Its Accessories (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请公开了一种密钥生成方法及装置，应用于车辆，该方法包括：第一车载设备获得第一消息；第一消息用于指示第一车载设备构建第一密钥；根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
Description
本申请涉及智能网联车技术领域，尤其涉及一种密钥生成方法及装置。
当前在车载领域，车内设备间通信的基础密钥的管理，全部依赖车外在云端的车内密钥管理系统(key manager system in vehicle，KMS)对车内各设备的密钥进行管理。比如在产线上，通过工具将密钥灌装(即预置)到各部件的安全存储区中。车内各部件间需要的所有密钥都在车厂云端KMS进行管理。
随着车辆智能化的演进，新的业务逐渐增加，会逐步要求车内不同通信业务进行信息安全隔离，此时密钥将逐步增多，也就意味着车厂要为每辆车管理越来越多的密钥。管理难度增加，另外，从安全的角度来看，如果云端管理的车内设备间业务通信密钥发生密钥泄露，则可能会立即影响车辆的行驶安全。
发明内容
本申请提供一种密钥生成方法及装置，用于提高车辆密钥的管理性能，提供车辆密钥的安全性。
第一方面，本申请提供一种密钥生成方法，应用于车辆，包括：
第一车载设备获得第一消息；第一消息用于指示第一车载设备构建第一密钥；根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
通过上述方法，实现车辆的第一车载设备在车辆内部基于第一车载设备的第一安全硬件扩展单元为车辆中的车载设备的通信(例如，车辆中的车载设备之间的通信)构建第一密钥，并通过第一安全硬件扩展单元加密后生成的第一密钥信息返回给第一车载设备，使得第一车载设备可以安全的在车辆内部生成第一密钥，无需通过云端生成第一密钥并全程参与第一密钥的管理，降低了云端管理车辆密钥的难度和复杂度，同时降低了通过云端泄露车辆密钥的可能，提高了车辆内部第一密钥的安全性。
一种可能的实现方式，接收来自第一安全硬件扩展单元发送的第一响应消息。
通过上述方法，可以使得第一车载设备通过第一响应消息获得第一密钥信息，即通过第一响应消息获得加密后的第一密钥，保证第一密钥的安全，在车辆的车载设备对第一密钥进行灌装时，可以通过第一车载设备发送第一密钥信息的方式进行验证后，灌装第一密钥，实现了第一密钥在车辆的车载设备之间，例如，在车辆的第一车载设备和第二车载设备之间，进行传输的安全性及灌装的安全性。从而，保证了第一密钥从生成到灌装的安全性。
一种可能的实现方式，接收来自第一安全硬件扩展单元发送的第一密钥的第一参数；第一车载设备根据第一密钥的第一参数，生成第一密钥加载消息；第一车载设备向第二车载设备发送第一密钥加载消息；第一密钥加载消息用于第二车载设备对第一密钥加载消息 进行验证成功后，灌装第一密钥。
通过上述方法，由第一安全硬件扩展单元生成第一密钥的第一参数，该第一参数可以是用于第二车载设备对第一密钥进行安全性验证的参数，例如，第一密钥的第一参数可以为完整性验证的参数，还可以为基于车辆的安全验证密钥加密后的第一参数，从而，第二车载设备在接收都第一密钥加载消息后，可以对第一密钥信息的完整性验证的参数进行完整性验证，在完整性验证成功后，第二车载设备可以对第一密钥信息中基于安全验证密钥加密后的参数进行解密，获得第一密钥。从而，保证了第一密钥灌装的安全性。
一种可能的实现方式，第一车载设备获得第一消息之后，第一车载设备向第一安全硬件扩展单元发送状态更新消息；状态更新消息包括：车内密钥的构建状态；状态更新消息用于第一安全硬件扩展单元对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
通过上述方法，第一车载设备可以基于第一消息，确定车内密钥处于构建状态，因此，可以向第一安全硬件扩展单元发送状态更新消息，使得第一安全硬件扩展单元更新自身的车内密钥的构建状态。例如，车内密钥的构建状态包括：构建完成，未构建，构建中，构建失败等。状态更新消息可以用于将车内密钥的构建状态更新为构建中。此时，在接收到状态更新消息后，第一安全硬件扩展单元可以将车内密钥的构建状态更新为构建中。从而，在第一安全硬件扩展单元接收到第一请求消息时，可以基于第一安全硬件扩展单元自身的车内密钥的构建状态，对第一请求消息进行验证。
一种可能的实现方式，车内密钥的构建状态用于第一安全硬件扩展单元对第一请求消息进行验证。例如，在第一安全硬件扩展单元自身的车内密钥的构建状态为构建中时，接收到第一请求消息的，则第一请求消息可以根据其他方式验证第一请求消息中的完整性和安全性后，生成第一密钥。而在第一安全硬件扩展单元自身的车内密钥的构建状态不是构建中时，接收到第一请求消息的，则第一安全硬件扩展单元可以拒绝执行第一请求消息，以保证车辆构建第一密钥的安全性。
一种可能的实现方式，确定第一车载设备重启后，向第一安全硬件扩展单元发送第一查询请求；第一查询请求用于查询第一密钥的第二参数；接收第一安全硬件扩展单元发送的第一查询响应消息；第一查询响应消息为第一安全硬件扩展单元对第一查询请求进行验证后返回的；第一查询响应消息包括：第一密钥的第二参数；根据第一密钥的第二参数和第一消息，生成第一请求消息；第一密钥为第一车载设备重启前第一安全硬件扩展单元待生成的密钥。
通过上述方法，在第一车载设备重启后，第一车载设备可以向第一安全硬件扩展单元查询当前第一安全硬件扩展单元生成的第一密钥的状态，例如，第一密钥是否已生成成功，第一密钥的更新次数等。其中，为保证第一查询消息的安全性，第一车载设备可以对第一查询消息进行加密和完整性保护，从而，在第一安全硬件扩展单元接收到该第一查询消息后，可以对第一查询消息进行验证，例如，包括对第一查询消息进行解密和完整性验证，在验证成功后，将第一查询请求查询的第一密钥的第二参数通过第一查询响应消息返回给第一车载设备。第一车载设备可以对第一查询响应消息进行验证，在验证成功后，获得第一密钥的第二参数。通过上述方法，可以实现第一车载设备重启后，获得第一密钥的第二参数，以便后续继续执行第一密钥的构建过程，降低第一车载设备重启对第一密钥生成、加载过程的影响。其中，第一安全硬件扩展单元在对第一查询消息进行验证的过程中，还可以通过查询第一安全硬件扩展单元自身的车内密钥的构建状态，对第一查询消息进行验 证，保证第一查询消息的合法来源是在车内密钥的构建过程中的，以保证第一查询消息的安全性。
一种可能的实现方式，接收来自第一安全硬件扩展单元发送的临时密钥；临时密钥用于加密第一请求消息。
通过上述方法，第一安全硬件扩展单元可以为第一车载设备和第一安全硬件扩展单元之间进行消息的安全传输配置临时密钥，避免其他车载设备或其他车载设备的安全硬件扩展单元可能发起第一请求消息，考虑到临时密钥是限定在第一车载设备和第一安全硬件扩展单元之间进行消息的安全传输的，可以简化临时密钥的设置方式，降低第一车载设备和第一安全硬件扩展单元之间进行消息的传输，提高安全性的同时，降低第一车载设备和第一安全硬件扩展单元的开销和复杂度。
一种可能的实现方式，接收第二车载设备发送的第二消息；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
通过上述方法，在第二车载设备重启后，第二车载设备可以向第一车载设备发送第二消息，使得第二车载设备可以查询第一密钥的第二参数，还可以请求第一车载设备生成第一密钥，还可以通知第一车载设备第二车载设备重启，使得第一车载设备可以针对第二车载设备的重启，执行相应的操作，以降低第二车载设备重启对第一密钥的灌装带来的影响，例如，在第一车载设备确定第二车载设备重启之前，第一车载设备已发送了第一密钥的加载消息，此时，第一车载设备可以根据第二消息，确定第二车载设备未成功灌装第一密钥，因此，第一车载设备可以再次发送第一密钥的加载消息，实现对第二车载设备灌装第一密钥。降低由于第二车载设备的重启，导致第二车载设备可能的灌装第一密钥失败的可能，提高第二车载设备灌装第一密钥的成功率。
一种可能的实现方式，对第二消息进行验证后，向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
通过上述方法，第一车载设备可以对第二消息进行安全性验证后，例如，基于第二消息的安全验证密钥对第二消息进行完整性验证后，向第二车载设备发送第三消息，使得第二车载设备可以获得第一密钥的第二参数或第一密钥信息中的至少一项，使得第二车载设备在重启后，恢复到重启前的车内密钥的构建状态及第一密钥的灌装的状态。
一种可能的实现方式，根据以下任一项获得第一消息：
接收车内设备或车外设备发送的第一消息；
接收配置文件的初始化或更新信息后，获得第一消息；
接收车辆的固定密钥的初始化或更新信息后，获得第一消息；
接收车辆的车载设备之间的共享密钥的初始化或更新信息后，获得第一消息。
通过上述方法，可以灵活的触发第一密钥的生成，实现车辆的第一车载设备在多种场景下生成第一密钥的方式，提高车内密钥生成的适用性。
第二方面，本申请提供一种密钥生成方法，应用于车辆，包括：第一安全硬件扩展单元接收第一安全硬件扩展单元对应的第一车载设备发送的第一请求消息；第一请求消息为第一车载设备请求第一安全硬件扩展单元构建第一密钥生成的；对第一请求消息进行验证成功后，生成第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
通过上述方法，基于第一车载设备的第一安全硬件扩展单元为车辆中的车载设备的通 信构建第一密钥，并通过第一安全硬件扩展单元加密后生成的第一密钥信息返回给第一车载设备，使得第一车载设备可以安全的在车辆内部生成第一密钥，无需通过云端生成第一密钥并全程参与第一密钥的管理，降低了云端管理车辆密钥的难度和复杂度，同时避免了通过云端泄露车辆密钥的可能，提高了车辆内部第一密钥的安全性。
一种可能的实现方式，向第一车载设备发送第一响应消息；第一响应消息包括：第一密钥信息。
一种可能的实现方式，对第一请求消息进行验证成功后，生成第一密钥的第一参数；向第一车载设备发送第一密钥的第一参数；第一密钥的第一参数用于第二车载设备灌装第一密钥。
一种可能的实现方式，接收第一车载设备发送的状态更新消息；状态更新消息包括：车内密钥的构建状态；对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
一种可能的实现方式，在第一车载设备重启后，接收第一车载设备发送的第一查询请求；第一查询请求用于查询第一密钥的第二参数；对第一查询请求进行验证后，向第一车载设备发送第一查询响应消息；第一查询响应消息包括：第一密钥的第二参数；第一密钥的第二参数用于第一车载设备生成第一请求消息；第一密钥为重启前第一安全硬件扩展单元待生成的密钥。
一种可能的实现方式，对第一请求消息进行验证成功后，生成临时密钥；向第一车载设备发送临时密钥；临时密钥用于加密第一请求消息。
一种可能的实现方式，接收来自第一车载设备的第二消息的验证消息；第二消息为第一车载设备接收第二车载设备发送的；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
一种可能的实现方式，对第二消息进行验证后，向第一车载设备发送第二消息的验证响应消息；第二消息的响应消息用于第一车载设备向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
上述可能的实现方式，可以参见第一方面中的有益效果的描述，在此不再赘述。
第三方面，本申请提供一种密钥获取方法，应用于车辆，包括：第一车载设备接收车外设备发送的第一消息；第一消息用于请求第一车载设备获得第一密钥；根据第一消息和第一车载设备的验证信息，生成身份验证请求消息，身份验证请求消息用于服务器对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证；向服务器发送身份验证请求消息；接收服务器发送的身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
通过上述方法，可以使得车外设备触发第一车载设备安全的获得第一密钥，其中，车外设备发送第一消息后，第一车载设备可以基于第一消息及第一车载设备的验证信息，例如，第一车载设备获得第一密钥的权限，第一车载设备对应使用的用户获得第一密钥的权限等，生成向服务器发送的身份验证请求消息，从而，通过服务器对身份验证请求消息进行验证，在验证成功后，第一车载设备才可以获得第一密钥，提高了第一车载设备获得第一密钥的安全性。其中，第一消息可以是车外设备发送的个人识别码(personal identification number，PIN)码，第一车载设备可以根据策划为设备发送的PIN码进行加密后，携带在身份验证请求消息中，使得服务器对加密的PIN进行验证，提高验证的安全性。另外，第一车载设备还可以通过车外设备获得车外设备的证书，或者是第一车载设备自身生成的证 书，该证书可以是用于对第一车载设备的身份进行验证的，在验证成功后，服务器可以基于证书的验证结果，确定第一车载设备是否有权限获得第一密钥。
一种可能的实现方式，第一车载设备接收服务器发送的第一消息；第一消息用于指示第一车载设备生成第一密钥；第一车载设备根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
通过上述方法，在第一密钥可以是第一车载设备自身生成时，服务器可以向第一车载设备发送第一消息，此时，第一车载设备可以基于第一消息，生成第一请求消息，用于指示第一安全硬件扩展单元生成第一密钥。在该方式中，通过第一车载设备和第一安全硬件扩展单元，实现了安全的在车内生成第一密钥，并使得第一车载设备生成第一密钥的过程是经过通过服务器验证后执行的，提高了生成第一密钥的安全性。需要说明的是，在该方式中，具体第一车载设备生成的第一密钥的方式，可以参考第一方面中的密钥生成方法中的实施方式，在此不再赘述。第一密钥可以加载在第一车载设备，也可以加载在第二车载设备中，具体参见本申请实施例部分的详细描述。
一种可能的实现方式，第一车载设备接收服务器发送的第一密钥。
通过上述方法，可以使得第一车载设备安全的获得服务器中存储的第一密钥。提高获得服务器维护的第一密钥的安全性。
一种可能的实现方式，第一车载设备在身份验证请求消息的验证结果为验证成功时，向车外设备发送第一密钥。
通过上述方法，在第一车载设备自身存储第一密钥后，还可以基于身份验证请求消息的验证结果，向车外设备发送第一密钥。例如，在车外设备为车辆诊断设备时，为保证车辆的数据的安全性，在车辆诊断设备对车辆的数据进行采集和诊断时，可以通过第一密钥进行加密，因此，可以基于第二方面中的服务器验证的方式，验证第一车载设备合法获得第一密钥的同时，也可以验证车外设备通过第一车载设备获得第一密钥的合法性，从而，提高了车外设备获得第一密钥的安全性。可选的，第一密钥可以是第一车载设备基于第一请求消息为车外设备生成的，也可以是第一车载设备已存储的，用于与车外设备之间进行通信的密钥，本申请不做限定。可选的，在车外设备使用完该第一密钥，例如，车辆诊断设备完成车辆诊断过程后，可以通知第一车载设备删除第一密钥，车辆针对设备也可以删除第一密钥。在下一次诊断时，可以再重新生成第一密钥，用于当前的诊断过程。提高车辆数据的安全性。
第四方面，本申请提供一种密钥获取方法，应用于服务器，包括：
服务器接收第一车载设备发送的身份验证请求消息；身份验证请求消息为第一车载设备根据车外设备发送的第一消息和第一车载设备的验证信息生成的；服务器根据身份验证请求消息，对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证，生成身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。服务器向第一车载设备发送身份验证的响应消息。
通过上述方法，通过服务器对身份验证请求消息进行验证，在验证成功后，第一车载设备才可以获得第一密钥，并且，通过车外设备触发第一车载设备安全的获得第一密钥，使得服务器在对第一车载设备进行验证时，可以通过车外设备的第一消息进行验证，及对第一车载设备的验证信息，例如，第一车载设备获得第一密钥的权限，第一车载设备对应 使用的用户获得第一密钥的权限等进行验证，从而，提高了第一车载设备获得第一密钥的安全性。
一种可能的实现方式，服务器向第一车载设备发送第一消息；第一消息用于指示第一车载设备生成第一密钥。
一种可能的实现方式，服务器向第一车载设备发送第一密钥。
一种可能的实现方式，身份验证请求消息用于指示第一车载设备向车外设备发送第一密钥。
上述可能的实现方式，可以参见第三方面中的有益效果的描述，在此不再赘述。
第五方面，本申请提供一种密钥生成装置，该装置为车辆中的车载设备或KMS，该装置包括：
获得单元，用于获得第一消息；第一消息用于指示第一车载设备构建第一密钥；
处理单元，用于根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，接收单元，用于接收来自第一安全硬件扩展单元发送的第一响应消息。
一种可能的实现方式，接收单元，用于接收来自第一安全硬件扩展单元发送的第一密钥的第一参数；
处理单元，用于根据第一密钥的第一参数，生成第一密钥加载消息；
发送单元，用于向第二车载设备发送第一密钥加载消息；第一密钥加载消息用于第二车载设备对第一密钥加载消息进行验证成功后，灌装第一密钥。
一种可能的实现方式，获得单元获得第一消息之后，发送单元，还用于向第一安全硬件扩展单元发送状态更新消息；状态更新消息包括：车内密钥的构建状态；状态更新消息用于第一安全硬件扩展单元对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
一种可能的实现方式，车内密钥的构建状态用于第一安全硬件扩展单元对第一请求消息进行验证。
一种可能的实现方式，处理单元确定第一车载设备重启后，通过发送单元向第一安全硬件扩展单元发送第一查询请求；第一查询请求用于查询第一密钥的第二参数；通过接收单元接收第一安全硬件扩展单元发送的第一查询响应消息；第一查询响应消息为第一安全硬件扩展单元对第一查询请求进行验证后返回的；第一查询响应消息包括：第一密钥的第二参数；根据第一密钥的第二参数和第一消息，生成第一请求消息；第一密钥为第一车载设备重启前第一安全硬件扩展单元待生成的密钥。
一种可能的实现方式，接收单元，用于接收来自第一安全硬件扩展单元发送的临时密钥；临时密钥用于加密第一请求消息。
一种可能的实现方式，接收单元，用于接收第二车载设备发送的第二消息；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
一种可能的实现方式，处理单元对第二消息进行验证后，通过发送单元向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
一种可能的实现方式，根据以下任一项获得第一消息：
通过接收单元接收车内设备或车外设备发送的第一消息；
通过接收单元接收配置文件的初始化或更新信息后，获得第一消息；
通过接收单元接收车辆的固定密钥的初始化或更新信息后，获得第一消息；
通过接收单元接收车辆的车载设备之间的共享密钥的初始化或更新信息后，获得第一消息。
第六方面，本申请提供一种密钥生成装置，该装置为车辆中的安全硬件扩展单元，该装置包括：
接收单元，用于接收第一安全硬件扩展单元对应的第一车载设备发送的第一请求消息；第一请求消息为第一车载设备请求第一安全硬件扩展单元构建第一密钥生成的；
处理单元，用于对第一请求消息进行验证成功后，生成第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，密钥生成装置包括发送单元，发送单元，用于向第一车载设备发送第一响应消息；第一响应消息包括：第一密钥信息。
一种可能的实现方式，处理单元对第一请求消息进行验证成功后，生成第一密钥的第一参数；通过发送单元向第一车载设备发送第一密钥的第一参数；第一密钥的第一参数用于第二车载设备灌装第一密钥。
一种可能的实现方式，接收单元，还用于接收第一车载设备发送的状态更新消息；状态更新消息包括：车内密钥的构建状态；处理单元，还用于对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
一种可能的实现方式，接收单元，还用于在第一车载设备重启后，接收第一车载设备发送的第一查询请求；第一查询请求用于查询第一密钥的第二参数；
处理单元，用于对第一查询请求进行验证后，通过发送单元向第一车载设备发送第一查询响应消息；第一查询响应消息包括：第一密钥的第二参数；第一密钥的第二参数用于第一车载设备生成第一请求消息；第一密钥为重启前第一安全硬件扩展单元待生成的密钥。
一种可能的实现方式，处理单元，用于对第一请求消息进行验证成功后，生成临时密钥；通过发送单元向第一车载设备发送临时密钥；临时密钥用于加密第一请求消息。
一种可能的实现方式，接收单元，用于接收来自第一车载设备的第二消息的验证消息；第二消息为第一车载设备接收第二车载设备发送的；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
一种可能的实现方式，处理单元，用于对第二消息进行验证后，通过发送单元向第一车载设备发送第二消息的验证响应消息；第二消息的响应消息用于第一车载设备向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
第七方面，本申请提供一种密钥生成装置，该装置为车辆中的车载设备或KMS，该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第一方面中任一项的方法。
第八方面，本申请提供一种密钥生成装置，该装置为车辆中的安全硬件扩展单元，该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第二方面中任一项的方法。
第九方面，本申请提供一种车辆，包括如上述第五方面任意一项的密钥生成装置和第六方面任意一项的密钥生成装置。
第十方面，本申请提供一种密钥获取装置，该装置为车辆中的车载设备或KMS，该装置包括：
接收单元，用于接收车外设备发送的第一消息；第一消息用于请求第一车载设备获得第一密钥；接收服务器发送的身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
处理单元，用于根据第一消息和第一车载设备的验证信息，生成身份验证请求消息，身份验证请求消息用于服务器对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证。
发送单元，用于向服务器发送身份验证请求消息。
一种可能的实现方式，接收单元，还用于接收服务器发送的第一消息；第一消息用于指示第一车载设备生成第一密钥；处理单元，还用于根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，接收单元，还用于接收服务器发送的第一密钥。
一种可能的实现方式，处理单元还用于在身份验证请求消息的验证结果为验证成功时，通过发送单元向车外设备发送第一密钥。
第十一方面，本申请提供一种密钥获取装置，该装置为服务器，该装置包括：
接收单元，用于接收第一车载设备发送的身份验证请求消息；身份验证请求消息为第一车载设备根据车外设备发送的第一消息和第一车载设备的验证信息生成的；
处理单元，用于根据身份验证请求消息，对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证，生成身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
发送单元，用于向第一车载设备发送身份验证的响应消息。
一种可能的实现方式，发送单元，还用于向第一车载设备发送第一消息；第一消息用于指示第一车载设备生成第一密钥。
一种可能的实现方式，发送单元，还用于向第一车载设备发送第一密钥。
一种可能的实现方式，身份验证请求消息用于指示第一车载设备向车外设备发送第一密钥。
第十二方面，本申请提供一种密钥获取装置，该装置为服务器，该装置包括：该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第三方面中任一项的方法。
第十三方面，本申请提供一种密钥获取装置，该装置为服务器，该装置包括：该装置可以包括处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得装置执行如上述第四方面中任一项的方法。
第十四方面，本申请提供一种车辆，包括如上述第十方面或第十二方面任意的密钥获取装置。
第十五方面，本申请提供一种密钥生成系统，包括如上述第五方面任意一项的密钥生成装置和第六方面任意一项的密钥生成装置。可选的，还可以包括车外设备。
第十六方面，本申请提供一种密钥获取系统，包括如上述第十方面或第十二方面任意的密钥获取装置和第十一方面或第十三方面任意的密钥获取装置，可选的，还可以包括车 外设备。
第十七方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，当计算机程序被运行时，实现如上述第一方面中任一项的方法、或上述第二方面中任一项的方法、或实现如上述第三方面中任一项的方法、或实现如上述权利要求第四方面中任一项的方法。
第十八方面，本申请提供一种计算机程序产品，计算机程序产品包括计算机程序或指令，当计算机程序或指令被通信装置执行时，实现如上述第一方面中任一项的方法、或上述第二方面中任一项的方法、或实现如上述第三方面中任一项的方法、或实现如上述权利要求第四方面中任一项的方法。
第十九方面，本申请实施例提供了一种芯片，该芯片包括数据接口和处理器，其中，所述处理器用于执行第一方面或第一方面的任意可能实现方式中的方法、或上述第二方面中任一项的方法、或实现如上述第三方面中任一项的方法、或实现如上述权利要求第四方面中任一项的方法。例如，该芯片为车辆上安装有软件或固件的任意芯片。
第二十方面，本申请提供了一种芯片系统，该芯片系统包括至少一个处理器，用于支持实现上述第一方面或第一方面的任意可能实现方式中所涉及的功能，上述第一方面中任一项的方法、或上述第二方面中任一项的中所涉及的功能、或实现如上述第三方面中任一项的中所涉及的功能、或实现如上述权利要求第四方面中任一项的中所涉及的功能。例如，例如接收或处理上述方法中所涉及的数据和/或信息。
在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存程序指令和数据，存储器位于处理器之内或处理器之外。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
上述第五方面至第二十方面的有益效果，具体请参照上述第一方面至第四方面中相应设计可以达到的技术效果，这里不再重复赘述。
图1为本申请实施例适用的一种可能的系统架构示意图；
图2示例性示出本申请实施例提供的一种车内长期密钥的生命周期图；
图3-图7示例性示出本申请实施例提供的密钥生成方法对应的流程示意图；
图8为本申请实施例适用的一种可能的系统架构示意图；
图9示例性示出本申请实施例提供的一种密钥获取方法对应的流程示意图；
图10示例性示出本申请实施例提供的一种密钥生成装置对应的结构示意图；
图11示例性示出本申请实施例提供的一种密钥生成装置对应的结构示意图；
图12示例性示出本申请实施例提供的一种密钥获取装置对应的结构示意图；
图13示例性示出本申请实施例提供的一种密钥获取装置对应的结构示意图。
需要说明的是，本申请实施例中的方案可以应用于车联网，如车辆外联(vehicle to everything，V2X)、车间通信长期演进技术(long term evolution-vehicle，LTE-V)、车辆-车辆(vehicle to vehicle，V2V)等。例如可以应用于具有密钥生成、密钥认证功能的车辆， 或者车辆中具有密钥生成、密钥认证功能的其它装置。该其它装置包括但不限于：车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头等其他传感器，车辆可通过该车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头，实施本申请提供的密钥生成方法。当然，本申请实施例中的密钥生成方法还可以用于除了车辆之外的其它具有密钥生成功能的智能终端，或设置在除了车辆之外的其它具有密钥生成功能的服务器中，或设置于该智能终端或服务器的部件中。该智能终端可以为智能运输设备、智能家居设备、机器人等。例如包括但不限于智能终端或智能终端内的控制器、芯片、雷达或摄像头等其它传感器、以及其它部件等。
本申请实施例中涉及的服务器可以为本地服务器、也可以为云端服务器，服务器可通过多种方式进行部署，例如，服务器可以为单独的一台物理机，又如，服务器还可以为某台物理服务器上加载的某个虚拟机(virtual machine，VM)，再如，服务器还可以为某台物理服务器上加载的某个容器(docker)等等。如下实施例以服务器为云端服务器进行示例性说明，云端服务器也可以简称为云端。
在本申请实施例中，如图1所示，车辆可采用电子电气(electrical/electronic，E/E)架构，该架构包括三个层级，分别为网关电子控制单元(electronic control unit，ECU)、域控制器ECU和域内ECU。其中，根据功能不同，可划分为不同的域，每个域有一个域控制器ECU。域控制器ECU用于管理对应域内的域内ECU。网关ECU用于对域控制器ECU进行管理。例如，参照图1所示，根据功能不同，可划分4个域，分别为整车控制系统域、娱乐系统域、诊断系统域以及智能驾驶域。每个域对应于一个域控制器ECU。上述4个域，总共对应于4个域控制器ECU。网关ECU用于对4个域控制器ECU进行管理。
例如，在本申请实施例中，仍可参照图1，整个E/E架构中，包括4个控制器局域网络(controller area network，CAN)总线，分别为CAN总线1、CAN总线2、CAN总线3以及CAN总线4。可选的，图2中的4个CAN总线可与图1中的4个域存在对应关系。比如，图1中的CAN总线1可对应于整车控制系统域，CAN总线2可对应于娱乐系统域，CAN总线3可对应于诊断系统域，CAN总线4可对应于智能驾驶域等。
可以理解的是，图1所示架构，仅为示意性说明，并不作为对本申请实施例的限定。比如，本申请实施例所提供的方法，除可利用于上述图1所示的三层架构外，还可利用于其它两层或一层架构中等，不作限定。
下面基于图1所示意的系统架构，先对本申请所涉及到的部分术语进行介绍。
(1)电子控制单元(electronic control unit，ECU)。
本申请实施例中，车辆的内部可以配置有多个ECU，如图1所示意出的ECU 1、ECU 2、……、ECU N，N为正整数。其中，每个ECU都可以具有自己特定的功能，且还支持简单的传感器数据处理和复杂的逻辑计算。目前常见的ECU包括但不限于：车载传感器、车载摄像头、多域控制器(multi domain controller，MDC)、自动驾驶域控制单元(automated-driving control unit，ADCU)、前装智能网关(telematics box，T-Box)，也可以叫车载信息盒子、智能座舱域控制器(cockpit domain controller，CDC)、车载网关、整车控制单元(vehicle control unit，VCU)、电池管理系统(battery management system，BMS)、热管理系统(thermal management system，TMS)、配电单元(power distribution unit，PDU)等。
(2)网关(gateway)
网关是车辆架构中的核心部分，其作为整车网络的数据交互枢纽，可将CAN、本地互联网络(local interconnection network，LIN)、多媒体传输系统(media oriented systems transport，MOST)、FlexRay等网络数据在不同网络中进行路由。网关可对域控制设备和域内设备等进行管理。在本申请实施例中，网关内可包括网关ECU，网关与网关ECU不作相互区分。
(3)域控制设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内设有一个域控制设备，用于对该域内的域内设备进行管理。域控制设备也可称为域控制器。在本申请实施例中，域控制设备内包括域控制ECU，域控制设备与域控制设备ECU不作相互区分。
(4)域内设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内可包括一个域控制器和多个被控制设备，域内设备可具体指每个域内的被控制设备等。在本申请实施例中，域内设备中可包括域内ECU，域内设备与域内ECU不作相互区分。
其中，在图1所示的架构中，本申请实施例中，车辆中的各个ECU可以依赖于车辆出厂时所设置好的通信技术来交互消息。这些通信技术例如可以为LIN技术或CAN技术，还可以为其它实现消息交互的通信技术。当依赖于CAN技术来交互消息时，不同ECU之间可发送CAN消息。各个ECU可以连接在同一根CAN总线上，任一个ECU都可以自由地在该CAN总线上读取和发送CAN消息帧。CAN总线上的每个CAN消息帧中一般只具有消息标识，而不携带源地址或目的地址，连接到该CAN总线上的各个ECU可以通过消息标识来选择接收哪个消息帧。虽然基于CAN技术的消息交互方式具有较强的实时性和可靠性，但是CAN技术中并没有内置任何的安全功能。这种情况下，一旦攻击者破译了CAN总线，则攻击者注入的每个CAN消息帧都可能会被车辆中的ECU读取并认为是合法的CAN消息帧，这样，攻击者就能够完全控制车辆的功能，例如制动或加速，这对于用户使用车辆来说是非常不安全的。
因此，可以为车辆中的各个ECU配置各自对应的长期密钥。当某个ECU根据消息标识从CAN总线上获取到一个CAN消息帧时，该ECU还可以使用预先配置的长期密钥来解析该CAN消息帧。如果解析不成功，则说明该CAN消息帧大概率属于非法人员注入在CAN总线上的非法的控制命令，因此该ECU可以不执行对应的控制操作，以避免非法人员控制车辆。如果解析成功，则说明该CAN消息帧属于合法人员(例如车主)注入在CAN总线上的合法的控制命令，因此该ECU可以执行对应的控制操作。如此，通过在各个ECU中预设长期密钥来完成CAN消息帧的认证操作，有助于在真正执行控制之前先对控制命令进行认证，以提高车主的行车安全。
(5)KMS。
本申请实施例中，车辆的内部还可以配置有KMS。KMS在车辆中主要负责生成密钥、管理密钥和清除密钥等功能，该KMS还可以从云端服务器(例如，车厂密钥管理中心，或用户密钥管理中心)或用户的应用程序(application，APP)等车外设备获得密钥。基于KMS的功能或权限，可以分为KMS的服务端(Server)、KMS的代理(Agent)端和KMS 的客户端(Client)。
KMS的服务端可以部署在车内的域控制器上(比如VDC、CDC、MDC等)，也可以部署在网关、T-BOX、或一个独立的设备上。KMS的服务端上可以包括支持本申请的密钥生成方法的SHE，也可以包括支持密钥生成对应的密钥验证功能的硬件安全模块(hardware security module，HSM)等其他安全硬件机制。KMS的客户端可以是除KMS服务端之外的各传感器、ECU部件等设备。KMS的客户端可以包括SHE，可以支持本申请中的密钥生成过程，也可以用于支持密钥的安全存储功能。KMS客户端也可以包括HSM等其他安全硬件机制，用于支持密钥的安全存储功能。其中，KMS的代理(Agent)端可以是用于连接域控制器、网关、T-BOX与传感器设备、ECU部件的设备。KMS的代理端可以作为KMS子服务端(Sub Server)，用于管理与该代理端连接的KMS的客户端的密钥生成过程。代理端可以和与代理端连接的至少一个KMS的客户端之间组成代理域。
KMS的服务端、KMS的客户端之间可以预先灌装了用于相互之间进行安全通信的密钥，比如各设备可以提前灌装一车一密的固定密钥(比如，GLOBAL_FIX_KEY)。也可以是灌装了用于KMS的服务端和部分KMS的客户端之间的固定密钥，该固定密钥可以用于KMS的服务端和部分KMS的客户端之间进行安全通信的密钥，在此不做限定。
这些密钥包括上述介绍的长期密钥。不同于传统的信息与技术(information and communications technology，ICT)，车联网中的ECU大都遵循汽车网络安全(automotive,cyber security，EVITA)标准和安全硬件扩展(secure hardware extension，SHE)标准。示例性地，考虑到EVITA标准和SHE标准下设置密钥的性能和成本，KMS中的长期密钥可以设置为对称密钥。
图2示例性示出本申请实施例提供的一种车内长期密钥的生命周期图，如图2所示，车内长期密钥的整个生命周期内涉及到原设备制造商(original equipment manufacturer，OEM)侧、供应商侧和车辆售卖点侧三者的通信交互。其中，OEM侧具体可以包括OEM研发线和OEM产线。供应商侧具体可以包括芯片供应商和部件供应商，为了便于理解，无论是芯片供应商提供的芯片，还是部件供应商利用这些芯片组装的ECU或车辆部件，这里统称为ECU。供应商侧具体可以包括供应商研发线和供应商产线。如图2所示，车内长期密钥的整个生命周期可以包括如下几个阶段：
阶段201，OEM研发线根据业务需求和管理需求设计密钥层次结构，并生成业务需求所需的对称密钥1。其中，对称密钥1中可以包括一个或多个对称密钥，这一个或多个对称密钥作为密钥层次结构设计的初始密钥，用于派生得到其它对称密钥。
阶段202，OEM研发线将密钥层次结构和对称密钥1发送给供应商研发线。其中，该发送操作需要在安全保密的环境下进行，例如可以安排专人秘密派送，也可以通过加密的点对点(peer to peer，P2P)方式传输，还可以通过其它安全的通信方式发送，不作限定。
阶段203，供应商研发线基于对称密钥1和密钥层次结构派生出供应商侧自提供的对称密钥2。其中，对称密钥2中可以包括组装ECU所需的芯片的根密钥、组装车辆部件或车辆所需的ECU的根密钥、以及ECU组装成的车辆部件的根密钥。对称密钥2还可以配置为可更新，即对称密钥2可以根据不同的生产环境进行变更。
阶段204，供应商产线在组装ECU或车辆部件时，向供应商研发线申请密钥。
阶段205，供应商研发线将对称密钥1和对称密钥2返回给供应商产线。
阶段206，供应商产线调用HSM或SHE标准，将对称密钥1和对称密钥2封装在各 自对应的ECU或车辆部件中。
阶段207，供应商产线通知OEM产线进行整车组装。
阶段208，OEM产线基于封装了对称密钥1和对称密钥2的ECU或车辆部件组装整车，并在组装过程中向OEM研发线申请密钥。
阶段209，OEM研发线将对称密钥3返回给OEM产线。其中，对称密钥3中可以包括OEM侧预设的根密钥和工作密钥等。对称密钥3适用于车辆售后阶段，例如用于更换ECU或车辆部件，或者更新软件配置等。
阶段210，OEM产线将对称密钥3封装在车辆中，之后将车辆提供给车辆售卖点进行售卖。此时，车辆中同时封装有对称密钥1、对称密钥2和对称密钥3。
阶段211，车辆售出后，如果车辆中的ECU或车辆部件损坏，或者需要对车辆的软件配置进行更新，则车主还可以将车辆放置在车辆售卖点，由车辆售卖点基于对称密钥3向OEM侧申请售后。此外，车辆售出后，车主还可以根据提示在车辆中预置一些车主密钥，此时车辆中同时封装有对称密钥1、对称密钥2、对称密钥3和车主密钥。
应理解，上述各阶段中OEM研发线侧的全部操作均可以经由OEM侧设置的管理员和OEM侧的密钥管理系统来完成，供应商研发线侧的全部操作均可以经由供应商侧设置的管理员和供应商研发线侧的密钥管理系统来完成，本申请对此不作具体说明。
按照图2所示意的内容可知，在车内长期密钥的整个生命周期中，车内的KMS需要管理的长期密钥包括但不限于：OEM研发线按照业务需求预置的对称密钥1、供应商研发线根据对称密钥1派生得到的对称密钥2、OEM侧预设的对称密钥3和车主密钥等。这些长期密钥可以分别应用于不同的场景。例如，表1示例性示出一种KMS所管理的各个长期密钥的应用场景示意。
表1
如表1所示，而一辆车从生产组装完成，到交付给客户，以及车辆上路的过程中，可能涉及多个进行通信的数据管理者或使用者。比如车辆控制域(功能安全)中的数据的管理者为车厂，中间车辆运营公司也会有对车辆的数据管理的需要，例如，对车辆进行诊断时，也需要对车辆进行控制，以获得相应车辆的诊断数据。另外，车辆的信息娱乐域的管理者可能归属不同的驾驶员或车辆的使用用户。对于车内这些数据管理者或使用者，为实现不同业务之间的信息的安全隔离，在通过车辆的不同业务的ECU进行数据通信时，需 要使用不同的密钥保护各自业务在不同设备间的通信。另外，随着车辆智能化的演进，新的业务逐渐增加，针对不同的业务之间的信息安全，相应设置对应的密钥，可能导致密钥逐步增多，根据上述方案，车厂要为每辆车生成并管理越来越多的密钥，管理困难。
另外，从安全的角度来看，车内的KMS所管理的各个长期密钥不仅会应用于车内各个ECU之间的交互认证，还会应用于车内ECU和车外设备之间的交互认证。因此，长期密钥在车辆中起到至关重要的作用，如果云端管理的车内设备间业务通信密钥，发生密钥泄露，也可能导致用户的密钥泄露，可能会立即影响所有车辆的行驶安全(功能安全、信息安全)，还可能导致用户的隐私数据泄露的问题。
下面以具体的实施例来介绍本申请中的密钥生成方法。通过在车厂云端、用户侧仅维持少量的固定密钥，而车内设备间的业务通信密钥在车内自主构建，从而，减少云端管理密钥的数量；为不同用户的不同业务的通信需求构建独立的业务通信密钥，就可以实现不同业务间通信安全隔离，各方或攻击者就无法通过掌握的某一方的密钥非法监听其他用户的业务通信内容，只可能通过正式的授权服务来访问；最后即便云端密钥发生泄露，可能也难影响车辆行驶安全。
需要说明的是，本申请实施例中的术语“系统”和“网络”可被互换使用。“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。
以及，除非有特别说明，本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的优先级或者重要程度。例如，第一车载设备、第二车载设备，只是为了区分不同的车载设备，而并不是表示这两个车载设备的优先级或者重要程度等的不同。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。
本申请实施例提供一种密钥生成方法，应用于车辆，如图3所示，包括：
步骤301：第一车载设备获得第一消息。
其中，第一消息用于指示第一车载设备构建第一密钥；
在一些实施例中，第一车载设备可以是KMS的服务端或KMS的代理端。例如，在第一车载设备为服务端时，第一车载设备可以通过非KMS设备接收第一消息。在第一车载设备为代理端时，第一车载设备可以通过服务端接收非KMS设备发送的第一消息。具体实施方式可以参见下文中场景1～场景4的描述。
步骤302：第一车载设备根据第一消息，生成第一请求消息。
第一请求消息用于第一车载设备对应的第一SHE生成第一响应消息。
其中，第一SHE可以是设置与第一车载设备设置在同一ECU中的，也可以是单独设置的，在此不做限定。第一车载设备可以是用于管理该ECU中的密钥的KMS。
步骤303：第一车载设备向第一SHE发送第一请求消息。
步骤304：第一SHE根据第一请求消息，生成第一响应消息。
其中，第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
在一些实施例中，第一密钥信息可以是加密后的第一密钥。当然，第一密钥信息还可以包括第一密钥的其他信息，具体参见下文中的第一响应消息的介绍。
步骤305：第一SHE向第一车载设备发送第一响应消息。
本申请实施例中，一个车载设备的关键数据存储区可以包括以下内容：密钥名称(key name)、密钥地址(address或存储槽位memory slot)、存储区(memory area)，例如，如表2所示。
表2
其中，密钥名称可以标识在该存储区存储的密钥类型，例如，GLOBAL_FIX_KEY，可以用于存储一车一密的固定密钥PSKFix_Global，可以用于该ECU更新GLOBAL_FIX_KEY或更新该ECU的其他密钥。该密钥还可以是与该ECU的主密钥(例如， SHE协议中的MASTER_ECU_KEY)相同的密钥或不同的密钥。还可以是用于该ECU生成车内的长期密钥专用的固定密钥，本申请不做限定。KMS_CFG_MAC可以用于存储该ECU的配置文件更新的安全校验码，用于初始化或更新KMS的配置文件时进行安全校验。
MAC_FIX_KEY可以是SHE安全启动时，用于校验KMS的密钥生成的相关软件完整性的固定密钥。安全校验码BOOT_MAC可以是SHE安全启动时，用于校验KMS的密钥生成的相关软件完整性的校验码。其中，MAC_FIX_KEY还可以是用于校验车辆的其他KMS软件完整性的固定密钥，例如，SHE协议中的固定密钥BOOT_MAC_KEY。
KEY_1～KEY_20：可用于存储车内设备间通信的对称密钥(加密密钥、或者完整性密钥)。
在一车一密的固定密钥为非对称密钥时，KEY_1可以用于存储一车一密的固定密钥PSKFix_Global的密钥对(Pair)。例如，在支持在线更新时，即在通过云端服务器对一车一密的固定密钥进行更新时，可以根据一车一密的固定密钥PSKFix_Global的密钥对进行安全验证。KEY_2可以用于存储该ECU的固定密钥的安全验证密钥PSKGlobal，即可以是对该ECU上的固定密钥进行安全验证的密钥，以增强固定密钥的安全性。在安全验证密钥PSKGlobal为非对称密钥时，KEY_3可以用于存储该ECU的固定密钥的安全验证密钥PSKGlobal的密钥对(Pair)，用于与安全验证密钥配对使用，在使用安全验证密钥PSKGlobal进行加密或完整性验证时，可以根据该密钥进行安全性验证。其他位置可用于存储该车载设备规划的KMS所使用的长期密钥或固定密钥等。举例来说，在第一密钥为长期密钥时，第一密钥可以为第一车载设备专用的长期密钥，第一密钥可以为第二车载设备专用的长期密钥，第一密钥可以为第一车载设备和第二车载设备之间使用的长期密钥，第一密钥可以为用户1使用第一车载设备时对应的长期密钥，第一密钥可以为用户2使用第一车载设备和第二车载设备时对应的长期密钥。在一些实施例中，本申请中生成的车载设备的长期密钥可以是存储在密钥KEY_1～KEY_20中。相应的密钥地址可以用于表示密钥的标识和密钥的存储位置，例如，下文中的memory slot、KEY_ID的取值可以是该密钥地址的值。KEY_1～KEY_20的其他位置还可以用于存储不受KMS管理的其他密钥，比如本地文件加密存储用的加密密钥等。
可选的，ECU的关键数据存储区还可以包括其他参数，该参数可以包括：KMS角色信息，其中，KMS角色信息可以包括：密钥有效期(KMS_CFG_KeyLifetime)，KMS的配置文件版本号(KMS_CFG_Version)，KMS的角色(KMS_CFG_Role)。密钥有效期，可以支持存储区外部的读写，例如，所有长期密钥的有效期可以设置为相同，该密钥有效期的单位可以为分钟。KMS的配置文件版本号可以是针对密钥设置的版本号。例如，在第一次生成KMS的密钥体系中的密钥后的版本号为1.0。当然也可以增加版本号的长度，比如该配置文件的版本号是与KMS的软件版本号联合后的版本号。KMS的角色可以包括：无角色信息(角色信息的值可以为0)，KMS服务端(角色信息的值可以为1)，KMS代理端(角色信息的值可以为2)，KMS客户端(角色信息的值可以为3)，其他值为无效值。
ECU的关键数据存储区还可以包括：密钥体系的构建状态(KMS_KH_BuildStatus)，KMS密钥体系中的密钥构建成功的计数器(KMS_KH_BuildCounter)，KMS密钥体系构建成功完成的时间(KMS_KH_BuildDate)，KMS密钥体系的构建参数存储的完整性校验码(KMS_KH_BuildMac)和KMS密钥体系的构建采用的临时密钥KMS_KH_BuildKTemp。本申请中的密钥体系的构建可以表示为KMS构建的至少一个长期密钥(第一密钥)。密钥 体系的构建状态可以包括：未构建、构建中、构建成功、构建失败。例如，密钥体系的构建状态的取值可以为0～3，其中，0表示未构建，1表示构建中，2表示构建成功，3表示构建失败。KMS密钥体系中的密钥构建成功的计数器，可以用于表示当前构建成功的密钥的数量。KMS密钥体系构建成功完成的时间，在当前存在KMS密钥体系构建的过程时，KMS密钥体系构建成功完成的时间可以表示上一次KMS密钥体系构建成功完成的日期和时间。精度存储到分钟级，比如本次构建成功的时间为2020-9-29 10:20:25，将该时间从0000年0点0分计算，实际经过多少分钟，注意闰年等处理。当然也可以采用其他方式。需要说明的是，密钥体系的构建状态(KMS_KH_BuildStatus)，KMS密钥体系中的密钥构建成功的计数器(KMS_KH_BuildCounter)，KMS密钥体系构建成功完成的时间(KMS_KH_BuildDate)是用于该ECU在KMS的密钥体系构建过程中确定该ECU的密钥构建的相关信息的，因此，这些参数只能是该ECU进行写入，外部的设备没有写入的权限。
需要说明的是，在密钥体系构建过程中，生成的构建状态、密钥的生成状态等数据进行固化存储时，可以通过用于存储KMS密钥体系的构建参数的完整性校验码进行验证。该完整性校验码可以单独存储，也可以是存储在空闲的KEY_<n>中。
KMS密钥体系的构建采用的临时密钥KMS_KH_BuildKTemp，也可以单独存储，也可以是存储在空闲的KEY_<n>中，在密钥构建体系中的密钥构建完成后，该临时密钥可以删除。在该示例中，n小于或等于20。具体值可以根据实际的需要确定。
非易失性存储区(non-volatile)，用于存储固定密钥、长期密钥、或安全启动的安全校验码。易失性存储区(Volatile)，可以用于在灌装密钥时，SHE对灌装的密钥进行安全验证时进行临时存储的密钥，还可以用于临时存放非密钥数据、或临时数据。例如，ECU可以通过CMD_LOAD_KEY的命令，以密文方式发送给SHE，SHE会对该命令的入参进行完整性校验，然后解密，获得该命令携带的密钥，并向该位置存储密钥。
每个密钥在存储时，除密钥外，还可以会包含一些其他的信息，比如，写保护(write-protection)标识位、安全启动失败(secure boot failure)标识位、调试器激活(debugger activation)标识位、通配符唯一角色标识(wildcard unique identification item，wildcard UID)、密钥使用标识位(key-usage)、明文密钥标识位、密钥更新计数(counter)标识位、密钥构建状态标识位(buildstatus)、密钥索引(KeyID)等，一种可能的实现方式，可以如表3所示。
表3
其中，表3中的X表示在存储该行密钥或安全校验码时，必须包含有该列的内容。X/-表示在存储该行密钥或安全校验码时，可以根据产品或KMS业务的需要包含该项内容。空白表示在存储该行密钥或安全校验码时，可以不含该列的内容。
写保护(write-protection)标识位中，如果写保护标识位的值为1，则不允许该密钥的再次更新。如果写保护标识为的值为0，则表示该密钥允许更新。安全启动失败(secure boot failure)标识位和调试器激活(debugger activation)标识位表示SHE安全启动后的该密钥的状态。其中，安全启动失败标识位还可以是启动保护(boot-protection)标识位，调试器激活标识位可以是调试保护(debugger-protection)标识位。通配符UID(wildcard UID)标识位用于表示、密钥使用标识位(key-usage)用于标识、明文密钥标识位用于标识该密钥是否明文存储。密钥更新计数标识位用于标识密钥更新次数，该更新此时可以通过密钥更新计数器的取值确定。每个密钥可能的占用的比特位数的最大长度可以如表2中的全部数据(Overall data)指示位所示，约束了每个memory slot的块的大小不能小于最大值。
ECU的UID，可以是本ECU对应的UID，也可能是缺省标识(wildcard UID)。例如，UID取值为0时，UID可以作为缺省标识。其中，缺省标识用于确定是否允许使用任意UID来向对应存储区灌装(覆盖式更新)密钥。例如，wildcard UID为1时，允许使用任意UID来灌装该ECU的密钥，wildcard UID如果为0，则不允许使用任意UID来灌装该ECU的密钥。memory slot用于指示向第一密钥在ECU存储区中存储的密钥地址。UID可以是120 bits，也可以为128 bits。
密钥构建状态(BuildStatus)是针对一个密钥的构建状态，该密钥构建状态可以占用1bit。密钥构建状态的取值可以为0～3，其中，0表示未构建，1表示构建中，2表示构建成功，3表示构建失败。需要说明的是，该密钥的状态信息表示在该ECU中构建成功，并不涉及该密钥在其他设备上是否成功灌装。一种可能的实现方式，可以根据KMS的密钥体系的构建状态，确定该密钥涉及的所有相关设备是否都持有了该密钥。例如，在KMS的密钥体系的构建状态为构建成功时，确定该密钥涉及的所有相关设备都持有了该密钥。
密钥索引(KeyID)，可以是由KMS分配的、与安全存储硬件的密钥地址无关的密钥索引，也可以是与密钥地址相关联的值。例如，可以占用32 bits，与密钥一起安装。
本申请中，车辆的密钥体系可以包括：配置文件、固定密钥、长期密钥等。其中，固定密钥可以包括一车一密的固定密钥，还可以包括涉及至少一个车载设备的固定密钥。涉及至少一个车载设备的固定密钥可以是限定在涉及至少一个车载设备中使用。长期密钥也可以包括一车一密的长期密钥，还可以包括涉及至少一个车载设备的长期密钥。涉及至少一个车载设备的固定密钥可以是限定在涉及至少一个车载设备中使用。本申请中，固定密钥可以为从车外获取的密钥，长期密钥可以是车辆自身生成的密钥。在进行车辆的密钥体系构建过程中，为保证车辆内的车载设备对密钥体系的构建和管理的安全可信，车辆内的车载设备及对应的SHE在构建密钥传输的与密钥体系相关的消息，都需要采用安全验证密钥进行加密或完整性保护。
下面介绍触发车辆的密钥体系构建的多种场景，即触发第一车载设备获得第一消息的 场景可能有多种，以第一车载设备为服务端为例，该第一SHE可以用于生成第一密钥。在一些实施例中，服务端和SHE可以设置在一个ECU上，用于管理该ECU的密钥。在该ECU包括服务端和SHE时，服务端与SHE之间的操作，可以通过车外设备(例如，云端或管理固定密钥的终端(例如，管理固定密钥的APP)的固定密钥作为安全验证密钥、或车内的服务端自身提供的固定密钥或临时密钥作为安全验证密钥。下面以场景1～场景4举例说明。
场景1，通过非KMS设备向车辆的KMS服务端发起配置文件更新消息(例如，第一消息)，此时，可以通过非KMS设备的固定密钥对配置文件更新消息进行加密和完整性保护的安全验证。该配置文件更新消息可以包括以下至少一项：更新的配置文件、配置文件的安全验证码、KMS角色信息等。
在一些实施例中，非KMS设备可以是云端服务器或管理车辆密钥的终端，此时，云端服务器或管理车辆密钥的终端可以根据云端服务器的固定密钥对该第一消息进行加密和完整性保护的安全验证。在另一些实施例中，非KMS设备可以是车辆的CDC或中控屏，CDC或中控屏响应于用户的配置文件更新的确认操作，CDC或中控屏对应的SHE可以根据车辆的一车一密的固定密钥生成第一消息，即CDC或中控屏可以根据一车一密的固定密钥对该第一消息进行加密和完整性保护的安全验证。
可选的，在车辆的KMS服务端接收到配置文件初始化消息或更新消息后，可以经过验证成功后，对服务端对应的SHE中的配置文件的相关信息进行初始化或更新。另外，服务端还可以向代理端或客户端发送配置文件初始化消息或更新消息，使得代理端或客户端在对配置文件初始化消息或更新消息验证成功后，对代理端或客户端对应的SHE中的配置文件的相关信息进行初始化或更新。可选的，服务端也可以不向客户端转发该消息，通过代理端在对配置文件初始化消息或更新消息验证成功后，也可以向客户端发送配置文件初始化消息或更新消息，使得客户端在对配置文件初始化消息或更新消息验证成功后，对客户端对应的SHE中的配置文件的相关信息进行初始化或更新。
考虑到KMS中的服务端、代理端和客户端各自对应的SHE执行的功能不同。例如，服务端的SHE对应生成加密的第一密钥及生成安全验证密钥，及配合KMS服务端对车内密钥体系的构建进行管理。代理端的SHE用于配合KMS的服务端完成代理端的域内的各客户端的第一密钥的生成及灌装。因此，本申请中，可以为KMS中的不同车载设备配置不同的KMS角色，以使服务端或代理端可以更好的对各车载设备的密钥进行管理。
在一些实施例中，车辆的KMS服务端可以根据初始化或更新的配置文件，确定KMS角色信息的初始化或更新，及初始化或更新配置文件的安全验证码。并为各车载设备配置KMS角色信息和相应的配置文件的安全验证码。下面以具体的场景示例介绍配置文件初始化或更新时，生成KMS角色信息的配置消息的过程。
场景1.1，在初始化的KMS配置文件下发时，KMS可以为各车载设备(例如，车辆的KMS服务端、车辆的代理端和客户端)生成KMS角色信息的配置消息。KMS角色信息可以包括以下至少一项：KMS角色(KMS_CFG_Role)、配置文件版本号(KMS_CFG_Version)、KMS构建的长期密钥的有效期(KMS_CFG_KeyLifetime)等。
场景1.2，在KMS的配置文件更新时，尤其是通信安全域的定义发生变化时，需要重新对车辆的KMS角色信息更新，也可以向各车载设备发送KMS角色信息的配置消息，以更新车辆内的各车载设备的KMS角色信息。
在车辆的KMS服务端接收到该KMS角色信息的配置消息时，车辆的KMS服务端转发该消息至服务端对应的SHE，服务端的SHE可以基于车外的安全验证密钥，对该KMS角色信息的配置消息进行验证，验证成功后，存储相应的KMS角色信息到SHE中的相应位置上。可选的，在该KMS角色信息的配置消息携带配置文件的初始化或更新的安全验证码时，SHE还可以在验证成功后，存储更新的配置文件的安全验证码到SHE中的KMS_CFG_MAC的位置上。
在车辆的KMS服务端接收到该KMS角色信息的配置消息后，车辆的KMS服务端还可以转发该消息至代理端或客户端。
从而，在车辆的KMS代理端接收到该KMS角色信息的配置消息后，代理端向代理端对应的SHE转发该消息，代理端的SHE可以基于车外的安全验证密钥，对该KMS角色信息的配置消息进行验证，验证成功后，可以存储相应的KMS角色信息到SHE中的相应位置上。可选的，在该KMS角色信息的配置消息携带配置文件的初始化或更新的安全验证码时，SHE还可以在验证成功后，存储更新的配置文件的安全验证码到SHE中的KMS_CFG_MAC的位置上。
相应的，在车辆的KMS代理端接收到该KMS角色信息的配置消息后，代理端还可以将该消息转发给代理端管理的各客户端。
相应的，在车辆的KMS客户端可以通过服务端或代理端接收到该KMS角色信息的配置消息，此时，客户端向客户端对应的SHE转发该消息，客户端对应的SHE可以基于车外的安全验证密钥，对该KMS角色信息的配置消息进行验证，验证成功后，可以存储相应的KMS角色信息到SHE中的相应位置上。可选的，在该KMS角色信息的配置消息携带配置文件的初始化或更新的安全验证码时，SHE还可以在验证成功后，存储更新的配置文件的安全验证码到SHE中的KMS_CFG_MAC的位置上。
具体的，针对不同的场景，SHE验证KMS角色信息的配置消息方式也可以有多种，下面以方式1.3～方式1.4举例说明。
方式1.3，在密钥体系构建开始时，可以通过密钥体系构建启动消息(CMD_KMS_KH_BUILD_START)，指示SHE开启密钥体系中的密钥的构建，SHE可以通过对密钥体系构建启动消息进行验证，在验证成功后，将密钥体系构建状态(KMS_KH_BuildStatus)修改为构建中。在密钥体系构建状态为未构建时，可以通过的密钥体系构建启动消息携带KMS角色信息的配置消息中的信息，此时，SHE可以通过对密钥体系构建启动消息进行验证，在验证成功后，再对KMS角色信息的配置消息中的信息进行验证。具体验证方式可以参见下文中的CMD_KMS_SET_CFG_INFO命令的验证。
方式1.4，在密钥体系构建过程中，SHE中的KMS的任何参数的变更，SHE都可以根据密钥体系构建状态(KMS_KH_BuildStatus)是否为“构建中”，确定KMS的任何参数是否满足更新要求。当密钥体系构建状态是“构建成功”的状态时，对KMS角色信息的配置消息中的信息进行验证，具体验证方式可以参见下文中的CMD_KMS_SET_CFG_INFO命令的验证。当密钥体系构建状态不是“构建中”的状态时，确定KMS角色信息的配置消息验证失败。
另外，当密钥体系构建状态不是“构建成功”的状态时，受密钥体系构建状态影响的各密钥(例如，密钥体系构建涉及的至少一个第一密钥)将不可使用。例如，在车载设备请求使用第一密钥时，SHE针对该请求对第一密钥涉及的密钥体系构建状态进行验证， 在验证失败后，SHE可以返回“密钥状态错误，需重新构建KMS的密钥体系”的状态码，比如，ERC_KMS_KH_NEED_TO_REBUILD。
例如，KMS向车载设备发送加密的第一密钥的灌装消息时，KMS可以向车辆内的各车载设备发送KMS角色信息。车辆内的各车载设备接收到各车载设备对应的KMS角色信息的配置消息后，可以根据该车载设备对应的SHE对该KMS角色信息的配置消息进行安全验证，在验证成功后，将该KMS角色信息写入SHE中，并写入相应的安全验证码。
举例来说KMS角色信息的配置消息可以为CMD_KMS_SET_CFG_INFO命令。该命令的入参可以如表4所示。入参可以理解为传入的参数，入参可以用于在命令通过第一车载设备向第一SHE发送，请求第一SHE验证时携带入参，例如CMD_KMS_SET_CFG_INFO等命令。
表4
其中，入参M1满足：
M1＝KEY_ID|KMS Role|KMS_CFG_Version|KMS_CFG_KeyLifetime
其中“|”可以理解为拼接，例如M1可以为将KEY_ID、KMS Role、KMS_CFG_Version以及KMS_CFG_KeyLifetime的对应的字节拼接到一起。例如，当传输M1的过程中，可以依次传输KEY_ID、KMS Role、KMS_CFG_Version以及KMS_CFG_KeyLifetime等字节。
一种可能的场景中，在初始配置文件下发时，KEY_ID可以是车辆的固定密钥。另一种可能的场景中，在车辆的长期密钥的生成过程中，KMS服务端根据KMS的配置文件为自身配置KMS角色信息及相应的长期密钥时，考虑到第一车载设备已获得相应的SHE生成的临时密钥，因此，KEY_ID可以为临时密钥对应的密钥地址。
入参M2满足：M2＝CMAC(Key,M1)
即通过入参M2对M1进行加密和完整性保护，对M1进行加密的密钥可以是KEY_ID对应的密钥。从而，在第一车载设备向第一车载设备对应的第一SHE发送该命令时，SHE可以根据KEY_ID对该命令进行安全验证。即SHE可以根据SHE存储的KEY_ID对应的密钥对M1进行CMAC运算，获得M2’，在确定M2’与M2相等时，则确定该命令验证成功。
可选的，在配置文件更新后，车辆的KMS服务端可以确定是否需要更新车辆的固定密钥，即在车辆的KMS服务端确定根据更新后的配置文件确定需要更新车辆的固定密钥时，可以向非KMS设备发送提醒消息，提醒非KMS设备生成固定密钥，并发起固定密钥灌装的消息。
可选的，在KMS的配置文件初始化或更新后，根据更新后或初始化后的KMS角色信息，KMS还可以确定车内KMS的密钥体系中待生成的长期密钥，从而，触发待生成的长期密钥的生成过程。
场景2，通过非KMS设备向车辆的KMS服务端发起固定密钥灌装的消息，此时，可以通过非KMS设备的固定密钥对更新的固定密钥进行加密和完整性保护的安全验证。在车辆的KMS服务端接收到该固定密钥灌装的消息时，可以向服务端对应的SHE发送固定密钥灌装的消息，服务端对应SHE基于车外的安全验证密钥，对该固定密钥灌装的消息进 行验证，验证成功后，存储更新的固定密钥。例如，在该固定密钥为GLOBAL_FIX_KEY时，服务端对应SHE存储该固定密钥到GLOBAL_FIX_KEY的位置上，在该固定密钥为MAC_FIX_KEY时，SHE存储该固定密钥到MAC_FIX_KEY的位置上。在一些实施例中，可由车外设备，生成CMD_LOAD_KEY的入参，用于车辆灌装第一密钥。本申请中，该方式主要用于第一密钥为固定密钥的场景，也可以用于第一密钥为长期密钥的场景，在此不做限定。
一种可能的实现方式，外部设备通过向第一车载设备(例如，服务端)发送第一密钥加载消息，第一车载设备可以将第一密钥加载消息(例如，可以携带CMD_LOAD_KEY中的入参)发送给第一车载设备对应的SHE验证，在验证成功后，存储该第一密钥，并根据第一密钥加载消息，生成第一密钥加载的响应消息(例如，可以携带CMD_LOAD_KEY的出参)，通过第一密钥加载的响应消息反馈给车外设备，车外设备可以根据第一密钥加载的响应消息进行验证，确定第一车载设备的第一密钥加载是否成功。
另一种可能的实现方式，外部设备通过向第一车载设备(例如，服务端)发送第一密钥加载消息，服务端将第一密钥加载消息，转发给车内各第二车载设备，其中，第二车载设备可以为代理端或客户端。其中，一种可能的实现方式为服务端发送给代理端或客户端，或者，服务端通过密钥管理工具转发该第一密钥加载消息。出参可以理解为在接收到命令的SHE对该命令进行验证成功后，返回时传出的参数，出参可以用于将传出的参数传递给命令使用。
第二车载设备(KMS的代理端或客户端)将第一密钥加载消息(例如，可以携带CMD_LOAD_KEY中的入参)转发给第二SHE(第二车载设备对应的SHE，其中，第二SHE可以是第二车载设备对应的SHE。该SHE可以是设置在第二车载设备对应的ECU中，也可以是第二车载设备单独设置的，在此不做限定)验证，在验证成功后，在第二SHE中存储该第一密钥，并根据第一密钥加载消息，生成第一密钥加载的响应消息(例如，可以携带CMD_LOAD_KEY的出参)，并将第一密钥加载的响应消息反馈给代理端或服务端，从而，再转发给服务端，服务端将可以将该第一密钥加载的响应消息返回给车外设备，车外设备可以根据第一密钥加载的响应消息进行验证，确定第二车载设备(各代理端或客户端)的第一密钥加载是否成功。
在第二SHE存储第一密钥(例如，新的固定密钥)后，第二SHE可以设置该第一密钥对应的密钥构建状态。例如，将密钥构建状态BuildStatus设置为“1”，表示该第一密钥为构建成功的状态。
下面具体介绍CMD_LOAD_KEY命令，该命令可以向SHE中的密钥地址(例如，memory slot)指定的存储区安全存储第一密钥。如表5所示。
表5
| 参数Parameter | 参数方向Direction | 宽度Width(bit) |
| M1 | 入参(IN) | 128 |
| M2 | 入参(IN) | 256 |
| M3 | 入参(IN) | 128 |
| M4 | 出参(OUT) | 256 |
| M5 | 出参(OUT) | 128 |
车外设备要向第一车载设备或第二SHE中灌装第一密钥时，可以根据提前掌握的已有密钥，例如，SHE中GLOBAL_FIX_KEY的当前值或该位置上的原始密钥，派生出加密密钥K1和完整性密钥K2，来保护CMD_LOAD_KEY的入参，即构造的CMD_LOAD_KEY命令入参为基于保护的。或者，车外设备要向KEY_<n>位置灌装新密钥时，车外设备必须提前知道当前GLOBAL_FIX_KEY的位置上存储的密钥、或者KEY_<n>位置存储的密钥。例如，KEY_<n>表示KEY_1～KEY_10。向某个位置灌装密钥时，必须提前知道该位置存储的原始密钥，或者GLOBAL_FIX_KEY。例如，具体的待灌装密钥对应保护CMD_LOAD_KEY的入参的加密密钥，可以如表6所示。
表6
表6中，“X”表示在灌装该行上对应的密钥时，通过相应列上的至少一个密钥作为安全验证密钥进行安全验证。例如，第一密钥为GLOBAL_FIX_KEY时，应通过存储在SHE中的GLOBAL_FIX_KEY作为安全验证密钥构造CMD_LOAD_KEY的入参，实现第一密钥GLOBAL_FIX_KEY灌装的安全性验证。第一密钥为KEY<n>时，可以通过存储在SHE中的GLOBAL_FIX_KEY或KEY<n>作为安全验证密钥构造CMD_LOAD_KEY的入参，实现第一密钥KEY<n>灌装的安全性验证。第一密钥为RAM_KEY时，可以通过存储在SHE中的KEY<n>或SRCERET_KEY或明文(plaintext)作为安全验证密钥构造CMD_LOAD_KEY的入参，实现第一密钥RAM_KEY灌装的安全性验证。
在一种可选地实施方式中，SHE中还可以设置有消息认证码(message authentication code，MAC)生成器，消息认证码生成器用于按照预设的生成算法处理输入信息以得到消息认证码并输出。当预设的生成算法为CMAC时，第一密钥的ECU根据加密该命令的密钥生成该命令的消息认证码M3，一种可能的实现方式，该命令的消息认证码M3满足以下公式：
M3＝CMAC(K2,M1|M2)
其中，K2为使用KEY_ID对应的安全验证密钥派生出的完整性验证的密钥。KEY_ID对应的安全验证密钥可以是如表3中第一密钥对应使用的安全验证密钥的标识。该安全验证密钥还可以用于派生出对第一密钥进行加密的加密密钥K1。
参数M1满足：M1＝UID|memory slot|KEY_ID
其中，UID为第一车载设备的唯一角色标识(unique identification item)，可以是第一车载设备对应的UID，也可能是缺省标识(wildcard UID)。例如，UID取值为0时，UID可以作为缺省标识。其中，缺省标识用于确定是否允许使用任意UID来向对应存储区灌装(覆盖式更新)密钥。例如，wildcard UID为1时，允许使用任意UID来灌装该ECU的密钥，wildcard UID如果为0，则不允许使用任意UID来灌装该ECU的密钥。memory slot用于指示向第一密钥在ECU存储区中存储的密钥地址。
入参的参数M2满足：M2＝ENC
CBC,K1,IV＝0(Counter|Flags|“0…0”
95|Key
memory slot)
其中，加密函数ENC
CBC,K1,IV＝0，表示使用AES的CBC模式加密，初始化向量(initialization vector，IV)值为0，使用K1作为加密密钥。
Counter表示第一密钥对应的密钥更新计数，在第一密钥每更新一次后，即第一密钥加载成功后，Counter可以增加1，用于SHE验证该命令是否存在重放攻击。在使用AES_CBC_128加密时，块长度为128 bits，M2可以通过“0…0”
95进行补位，例如，填充95 bit的0。
Flags可以是根据第一密钥在SHE中存储的信息确定的，例如，Flags满足：
Flags＝write-protection|boot-protection|debugger-protection|key-usage|wildcard。
Flags中的参数详见表3中的取值。
Key
memory slot表示向memory slot位置存储的第一密钥。
以第二车载设备为例，第二SHE在接收到该CMD_LOAD_KEY命令后，该命令可以包括入参的3个参数。第二SHE可以将CMD_LOAD_KEY命令中的3个入参输入至消息认证码解析器，则消息认证码解析器根据该命令中的入参的M1和M2，及根据SHE自身存储的该CMD_LOAD_KEY命令对应的安全验证密钥，例如，第一密钥对应的安全验证密钥，生成K1和K2，并相应生成消息认证码M3’，在确定消息认证码M3’与M3相同时，确定验证成功。并将命令中携带的第一密钥存储到memory slot对应的位置。
相应的，第二SHE还可以根据CMD_LOAD_KEY命令中的3个入参，获得该命令的出参，即M4和完整性校验的消息认证码M5，消息认证码M5满足：M5＝CMAC(K4,M4)。
其中，K4是由memory slot存储的第一密钥派生得到的完整性验证使用的密钥。参数M4满足以下公式：M4＝M1|EncyptedValue。
其中，EncyptedValue＝ENC
CBC,K3,IV＝0(Counter|“1”
1|“0…0”
99)，“1”
1表示数值“1”占用1bit，“0…0”
99表示数值“0”占用99个比特位。Counter为SHE针对该第一密钥对应设置的更新计数器的值，可以为28 bits，用于对接收到的CMD_LOAD_KEY命令进行重放攻击的验证。在使用AES_CBC_128加密时，块长度为128 bits。K3是由memory slot中存储的第一密钥(即Key
memory slot)派生的加密密钥。
可选的，在固定密钥灌装完成后，车辆的KMS服务端，还可以根据固定密钥的使用范围，确定是否需要更新相应的长期密钥。例如，该固定密钥为车辆的一车一密的固定密钥，此时，车辆的KMS服务端可以确定基于该固定密钥生成的长期密钥更新。车辆的KMS服务端可以向非KMS设备发送长期密钥更新请求，非KMS设备接收到该长期密钥更新请求后，非KMS设备可以对该长期密钥更新请求进行验证，验证成功后，生成第一消息。非KMS设备生成第一消息的方式可以参见场景3。
场景3，第一密钥为长期密钥时，可以通过车辆的SHE生成第一密钥，在生成第一密钥的过程中，为保证车载设备与SHE之间的消息的安全性，及车载设备与车载设备之间的消息安全性，可以针对相应的消息进行安全性验证。例如，可以如表7所示，本申请在密钥体系构建过程中，可能涉及到的消息所对应使用的安全验证密钥。具体消息的示例下文中描述。
表7
X：表示可以使用该密钥作为安全验证密钥。例如，将临时密钥作为安全验证密钥的前提是构造消息时，在能获得该临时密钥时，使用临时密钥作为安全验证密钥。例如，第一车载设备根据临时密钥生成相应的消息，并通过第一SHE进行验证。第二车载设备根据临时密钥生成相应的消息，并通过第二SHE进行验证。Y：表示优先使用该密钥作为安全验证密钥。例如，在长期密钥作为安全验证密钥时，可以是第一车载设备和第二车载设备之间的消息采用的安全验证密钥，并通过各自对应的SHE进行验证。Z：表示仅当通过非KMS设备生成相应消息后发送给对应的第一车载设备或第二车载设备后，该密钥才可用作该消息发送给SHE的安全验证密钥。
需要说明的是，每个消息中的安全验证密钥KEY_ID是指该命令参数的完整性校验码MAC计算时所用密钥的密钥地址(memory slot)。
每个消息中安全验证密钥KEY_ID是指该命令参数的完整性校验码MAC计算时所用密钥的密钥地址(memory slot)。
每个消息对应的入参或出参数中，涉及CMAC计算时，参数的非128bits整数倍的部分，可以根据RFC4493进行填充处理。比如Mx是M1、M2组合后(Mx＝M1|M2)要进行CMAC计算的bit流，如果Mx的bit长度不是128 bit的整数倍，则需要按照RFC4493的定义进行填充处理，填充方式为Mx|"1"|"0...0"m，即Mx后跟1个bit的1，然后在填充最少bit的0，达到128 bit的整数倍。比如Mx为64bits，则需要填充63bit的0，即可 使Mx|"1"|"0...0"m达到128bits的整数倍。这种填充或者在SHE外填充，还可以是在SHE中填充。本申请中以在SHE内填充为例进行说明。
下面通过场景3.1～场景3.2，举例说明第一密钥为长期密钥时，通过车辆的SHE生成第一密钥的方式。
场景3.1，通过非KMS设备向车辆的KMS服务端发起第一消息。
在一些实施例中，非KMS设备可以是云端服务器或密钥管理工具或管理密钥的终端等。云端服务器可以根据云端服务器的固定密钥作为安全验证密钥对该第一消息进行加密和完整性保护的安全验证。在另一些实施例中，非KMS设备可以是车辆的CDC或中控屏，通过CDC或中控屏，接收到用户的确认操作，CDC或中控屏响应于用户的确认操作，CDC或中控屏对应的SHE可以根据车辆的一车一密的固定密钥生成第一消息，即CDC或中控屏可以根据一车一密的固定密钥对该第一消息进行加密和完整性保护的安全验证。
通过非KMS设备向车辆的KMS服务端发起第一消息，例如，在启动密钥体系的构建时，及当前的密钥体系的构建状态为未构建或构建完成中，可以由车外设备或非KMS设备生成第一消息，并向车辆的KMS服务端发送第一消息。例如，可以通过车辆的固定密钥对该第一消息进行加密和完整性保护的安全验证。其中，第一消息中可以指示车辆的KMS服务端生成的第一密钥是哪些密钥。例如，KEY_13用于存储全球导航卫星系统(global navigation satellite system，GNSS)模块对应的长期密钥。
例如，为防止CDC或中控屏被攻击，可以由CDC或中控屏接收用户的响应操作，确认“同意/拒绝：执行第一密钥的更新”，此时，在服务端通过场景1和场景2确定待生成的第一密钥后，可以向CDC或中控屏发送第一密钥生成请求消息，用户通过CDC或中控屏确认后，响应与用户的确认操作，CDC或中控屏通过该安全验证密钥返回给服务端长期密钥更新请求的响应消息，该响应消息可以使用一车一密的固定密钥进行加密和完整性保护，服务端将该响应消息发送给服务端的SHE进行验证。可选的，在服务端的SHE还可以根据第一密钥的有效期是否超时，确定是否主动向CDC或中控屏发送生成第一密钥生成请求消息。在接收到向CDC或中控屏发送的第一密钥生成请求的响应消息为同意时，该SHE执行对第一密钥的生成过程。
车辆的KMS服务端接收到非KMS设备发送的第一消息后，可以生成第一请求消息，该第一请求消息向服务端对应的SHE发送第一请求消息，其中，第一请求消息可以包括第一密钥的标识，第一请求消息可以是基于第一请求消息对应的安全验证密钥对该第一请求消息进行加密和完整性保护。
SHE基于第一请求消息对应的安全验证密钥，对该第一请求消息进行验证，验证成功后，触发生成加密的第一密钥。其中，加密的第一密钥可以是基于SHE存储的一车一密的固定密钥进行加密的，也可以是通过该KMS服务端存储的固定密钥进行加密的，该SHE在确定该第一密钥为KMS服务端使用的密钥时，可以存储该第一密钥。该SHE在确定该第一密钥为KMS服务端使用的密钥时，可以不存储该第一密钥。例如，在该第一密钥对应的KEYID为KEY_13时，SHE存储第一密钥到KEY_13的位置上。
服务端对应的SHE根据自身存储的第一请求消息对应的安全验证密钥验证第一请求消息，在验证成功后，生成加密的第一密钥。其中，加密的第一密钥可以是基于SHE存储的一车一密的固定密钥进行加密的，也可以是通过该KMS服务端存储的固定密钥进行加密的，该SHE在确定该第一密钥为KMS服务端使用的密钥时，可以存储该第一密钥。该 SHE在确定该第一密钥为KMS服务端使用的密钥时，可以不存储该第一密钥。例如，在该第一密钥为KEY_1时，SHE将该第一密钥存储到KEY_1的位置上。
下面以具体的示例举例介绍第一请求消息。第一请求消息CMD_BUILD_KEY涉及的参数可以如表8所示。
表8
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 256 |
| M2 | IN | 128 |
| M3 | OUT | 144 |
| M4 | OUT | 256 |
| M5 | OUT | 128 |
| M6 | OUT | 272 |
| M7 | OUT | 128 |
以第一车载设备向第一SHE发送第一请求消息为例，该第一请求消息中可以携带以下入参。
其中，入参M1满足：
M1＝UID|Flag|memory slot|KEY_ID|Counter[|KeyID]|“0…0”m
其中，UID的取值可以有多种，例如，在第一请求消息用于生成向第二车载设备发送的第一密钥的灌装消息(携带第一密钥的灌装对应的入参)时，该UID可以是第一车载设备或第二SHE的UID，也可以是0(即wildcard UID)。在第一请求消息用于生成向第一车载设备灌装的第一密钥的入参时，该UID可以是第一车载设备或第二SHE的UID。
Flag可以占用1字节，Flag满足：
Flag＝“0...0”
6|Hold
其中，Hold可以占用1 bit，表示第一SHE是否持有第一密钥，即是否在第一SHE中存储生成的第一密钥。例如，Hold为0时，表示不存储，Hold为1时，表示存储。如果是，则SHE在生成第一密钥后，先存储在本SHE中的memory slot位置，并设置该密钥相关内容，具体参见表3。其中，第一密钥的密钥构建状态可以设置为“1-构建成功”。如果不存储，则不可以在本SHE存储该第一密钥。
memory slot用于指示SHE第一密钥的密钥地址。
KEY_ID用于指示该第一请求消息的安全验证密钥。例如，结合场景3.1，通过非KMS设备生成的第一请求消息的入参(即携带在第一消息中)，可以通过固定密钥作为该安全验证密钥。结合场景3.2，在第一车载设备获得临时密钥后生成的第一请求消息，可以将临时密钥作为第一请求消息的安全验证密钥。Counter的取值与本SHE的KMS_KH_BuildCounter值相同，用于SHE验证重放攻击。
密钥索引KeyID：可以4字节，用于指明本次新生成的第一密钥的密钥索引。其中，“[]”表示可选的。例如，在不同硬件的安全存储机制涉及的车载设备之间对应的密钥索引可以是基于业务分配的，例如，可以基于KMS分配相应的密钥的索引。“0…0”m：表示数值“0”占用m bits，以便满足M1整体达到128 bits的整数倍。如果不含密钥索引KeyID，则填充76 bits的0。如果含有密钥索引KeyID，则填充44 bits的0。
入参M2满足：M2＝CMAC(Key,M1)
其中，Key是KEY_ID对应的安全验证密钥。
在第一SHE对第一请求消息的入参进行验证成功后，可以相应生成以下出参，并向第一车载设备返回第一响应消息，该第一响应消息可以包括第一密钥的第一参数，例如，可以携带以下出参M3～M7。
出参M3满足：M3＝UID|memory slot|KEY_ID
UID同入参M1中的UID，memory slot和KEY_ID同入参M1中的对应值。Counter为SHE存储的KMS_KH_BuildCounter值。
Flags＝write-protection|boot-protection|debugger-protection|key-usage|wildcard，也可以在入参Flag中携带Flags的信息。或者，SHE根据第一密钥的分类来决定携带的内容。
出参M4满足：
M4＝ENC
CBC,K1,IV＝0(Counter|KeyFlags[|KeyID]|“0…0”m|Key
memory slot)
KeyID同入参中的KeyID，如果入参携带了KeyID，则出参中也携带该KeyID。
Key
memory slot是第一SHE为memory slot生成的第一密钥的密钥值，由于第一密钥是要通过第一车载设备向第二SHE加密后分发的，第二车载设备不需要知道该第一密钥是如何生成的。因此，第一SHE在生成第一密钥时，可以有多种方案，举例来说，具体方案可有如下两种：方案一：使用SHE中的随机数功能生成一个随机数R1(128 bits)，然后利用一个SHE持有可用的安全的Key1，进行CMAC计算，得到Key
memory slot。例如，Key
memory slot＝CMAC(Key1,R1)。其中，Key1可以使用固定密钥，比如GLOBAL_FIX_KEY、MAC_FIX_KEY等第一SHE中的任意一个除临时密钥之外的密钥，保证外部不可读取。或者，key1可以是该第一请求消息的入参中增加的密钥地址memory slot1对应的密钥，该密钥可以由用户来指定。方案二：如果随机数足够安全，也可以直接使用生成的随机数生成第一密钥。
出参M5满足：
M5＝CMAC(K2,M3|M4)
出参M6满足：
M6＝UID|memory slot|KEY_ID|EncyptedValue
出参M7满足：
M7＝CMAC(K4,M6)
其中，第一响应消息携带的出参M3、M4、M5分别为第一密钥的灌装消息的入参M1、M2、M3。第一响应消息携带的出参M6、M7分别同第一密钥的灌装消息的出参M4、M5。即SHE通过第一请求消息，可以获得灌装第一密钥所需的入参，和验证第一密钥加载的出参。具体可以参见下文中的第一密钥的灌装消息中携带的入参和SHE执行第一密钥的灌装消息后的出参。
需要说明的是，出参M6和出参M7可以携带在第一响应消息中发送，也可以是存储在SHE的非易失性存储区中，例如，在SHE的非易失性存储区中预留专门用于KMS密钥体系构建过程中，临时存储服务端或代理端为第二车载设备之间共享密钥的存储位置，在第一车载设备(例如，服务端或代理端)接收到第二车载设备返回的第一密钥的灌装响应消息时，第一车载设备可以通过验证密钥消息，获得存储在SHE中的M6和M7。
场景3.2，在车内密钥体系构建过程中，例如，第一车载设备在确定当前密钥体系构 建状态为构建中时，例如，第一车载设备在确定密钥体系中待生成的第一密钥包括多个后，可以根据各个待生成的第一密钥，相应生成第一请求消息。举例来说，第一密钥可以为第一车载设备专用的长期密钥，第一密钥可以为第二车载设备专用的长期密钥，第一密钥可以为第一车载设备和第二车载设备之间使用的长期密钥，第一密钥可以为用户1使用第一车载设备时对应的长期密钥，第一密钥可以为用户2使用第一车载设备和第二车载设备时对应的长期密钥。在生成相应的长期密钥时，可以相应生成该长期密钥的第一请求消息。
第一车载设备(例如，服务端)除通过非KMS设备生成第一消息来携带第一请求消息的安全验证密钥之外，还可以通过第一车载设备与第一SHE之间共享一个临时密钥，作为第一请求消息的安全验证密钥。
该临时密钥可以用于构建过程中服务端与服务端对应的SHE之间的安全验证密钥。也可以是通过代理端与代理端对应的SHE之间共享一个临时密钥K
Temp，该临时密钥K
Temp可以用于构建过程中代理端与代理端对应的SHE之间的安全验证密钥。也可以是通过客户端与客户端对应的SHE之间共享一个临时密钥，该临时密钥可以用于构建过程中客户端与客户端对应的SHE之间的安全验证密钥。
该临时密钥可以是基于第一车载设备从非KMS设备接收到的第一消息(该第一消息通过非KMS设备与服务端之间可信的安全验证密钥进行加密的)，通过SHE对第一消息进行验证后生成的。
一种可能的实现方式，通过非KMS设备向车辆的KMS服务端发起长期密钥的生成消息(例如，第一消息)，非KMS设备可以通过非KMS设备的固定密钥对该第一消息进行加密和完整性保护的安全验证。其中，第一消息中可以指示车辆的KMS服务端启动长期密钥的生成过程。车辆的KMS服务端可以根据该第一消息，向服务端的SHE发送第一请求消息，该第一请求消息可以用于请求获得临时密钥。SHE生成临时密钥后，可以向第一车载设备发送第一消息的响应消息，在该响应消息中可以携带该临时密钥。此处临时密钥可以使用服务端与服务端对应的SHE共享的密钥进行完整性验证。例如，通过一车一密的固定密钥，或第一车载设备的固定密钥对该临时密钥生成消息校验码。从而，第一车载设备在对第一消息的响应消息进行验证成功后，可以获得该临时密钥。该临时密钥用于服务端验证SHE发送的第一响应消息。同时，车辆的服务端生成的第一请求消息还可以包括请求SHE生成加密的第一密钥。
考虑到在密钥体系构建过程中，很可能需要服务端多次生成第一密钥，或通过服务端或代理端对其他消息进行验证等操作，都可能涉及到使用临时密钥，此时，应在车载设备(服务端或代理端或客户端)相应的SHE执行第一密钥的生成等操作之前生成临时密钥，并使得车载设备获得该临时密钥。如果每次都生成或者向车载设备发送临时密钥，则会影响临时密钥的安全性(API接口监听等)。另外，针对密钥体系构建启动消息，应在车载设备相应的SHE执行第一密钥的生成等操作之前接收到，以便SHE更新密钥体系构建状态。
下面具体介绍生成临时密钥的一种可能的实现方式，即通过密钥体系构建启动消息触发该第一SHE生成临时密钥。服务端接收非KMS设备生成的密钥体系构建启动消息，并将该密钥体系构建启动消息的参数分发到代理端或客户端的车载设备，代理端也需要代理分发到其代理的各客户端，在车载设备接收到密钥体系构建启动消息后，转发给车载设备的SHE，SHE可以根据密钥体系构建启动消息，启动密钥体系的构建，例如，同步各车载设备的KMS_KH_BuildCounter值，以防止密钥体系构建启动消息的重放攻击，更新密钥 体系构建状态消息，并使得车载设备的SHE相应生成临时密钥，为后续第一密钥的生成等消息提供安全验证密钥。
下面通过以下方式1～方式2举例介绍密钥体系构建的启动消息中可能的方式。
方式1，在车外设备响应于用户“确认同意进行第一密钥更新”的操作后，车外设备构建密钥体系构建的启动消息。
方式2，在车内的CDC或中控屏响应于用户“确认同意进行第一密钥更新”操作后，由CDC或中控屏来构建密钥体系构建的启动消息。此时，为保证可安全的构建密钥体系构建的启动消息，可以通过以下方式实现：
方式2.1，在CDC或中控屏上，通过其他安全环境(不依赖SHE的安全环境)，比如部署有可信执行环境(Trusted execution environment,TEE)、或者HSM等的安全环境，使用长期密钥或固定密钥，来生成该消息。需要说明的是，在该安全环境中，同样存储该长期密钥，比如存储一车一密的长期密钥或一车一密的固定密钥等。
方式2.2，CDC或中控屏的SHE对服务端或代理端发送的启动密钥体系的构建的请求消息进行响应，返回启动密钥体系的构建的请求的响应消息，比如CMD_KMS_KH_PREPARE_START，使得CDC或中控屏的SHE生成并向服务端返回密钥体系的构建启动消息，服务端获得该密钥体系的构建启动消息，从而启动和管理第一密钥的更新。需要说明的是，启动密钥体系的构建的请求的响应消息(CMD_KMS_KH_PREPARE_START)无法提供密钥作为该消息的安全验证密钥。因此需要严格控制该消息的使用，比如通过身份识别与访问管理(identity and access management，IAM)、安全强化Linux(security enhanced linux，SELinux)、进程或容器安全隔离，并且强制检查在车辆停止等情况下，才允许使用。
下面举例说明密钥体系构建的启动消息的一种可能的实现方式，例如，如表9所示，为密钥体系构建的启动消息可能涉及的参数。其中，m和n为正整数。
表9
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | m |
| M2 | IN | 128 |
| M3 | OUT | n |
| M4 | OUT | 128 |
| M5 | OUT | 128 |
以第一车载设备向第一SHE发送密钥体系构建的启动消息为例，该密钥体系构建的启动消息可以携带下列入参。
其中，入参满足：
M1＝KEY_ID|KMS_KH_BuildCounter
M2＝CMAC(Key,M1)
其中，对于车外发起的密钥体系构建，必须是固定密钥对应的KEY_ID，对于内车CDC或中控屏确认后触发的长期密钥更新，可以是长期密钥对应的KEY_ID，比如是一车一密的长期密钥的KEY_ID。Key是KEY_ID对应的Key。KMS_KH_BuildCounter为密钥体系构建计数器的值，各车载设备的SHE在执行该密钥体系构建的启动消息时，该值必须大于、或等于本车载设备的SHE中KMS_KH_BuildCounter的值，以防止该密钥体系构建的启动 消息被重放使用。如果KMS_KH_BuildCounter值小于本设备SHE中的值，则忽略该命令，返回ERC_INVALID_PARAMETER。
在对密钥体系构建的启动消息验证成功后，SHE可以生成密钥体系构建的启动消息的出参，并向第一车载设备返回密钥体系构建的启动消息的响应消息，在该响应消息中携带出参。其中，出参满足：
M3＝KEY_ID|KMS_KH_BuildCounter1
M4＝CMAC(Key,M3)
M5＝KMS_KH_BuildKTemp
其中：KMS_KH_BuildCounter1是执行该命令后，SHE中KMS_KH_BuildCounter的最新值。实际应该是KMS_KH_BuildCounter1＝KMS_KH_BuildCounter+1。该命令执行后，SHE将KMS_KH_BuildStatus设置为“构建中”。
KMS_KH_BuildKTemp是该命令执行成功后，SHE生成的一个临时密钥KTemp，用于本车载设备直接操作SHE时的安全验证密钥。
为简化消息发送的复杂度，可以将密钥体系构建启动消息设计为两层命令，该消息中，还可以携带其他消息的参数，使得SHE接收到该密钥体系构建启动消息后，根据对密钥体系构建启动消息的验证，获得启动密钥体系构建的指示信息，并更新密钥体系构建状态。可选的，在服务端或代理端的SHE接收到该消息后，可以相应生成临时密钥。进一步的，根据密钥体系构建启动消息携带的其他消息的参数后，根据其他消息的参数，对该消息进行验证后执行相应的操作。
例如，其他消息为第一请求消息，此时，第一车载设备通过密钥体系构建启动消息携带第一请求消息。可以使得第一SHE通过对密钥体系构建启动消息进行验证后，确定密钥体系构建状态为构建中，并相应生成临时密钥。之后，根据通过密钥体系构建启动消息携带第一请求消息，对第一请求消息进行验证，在验证成功后，生成加密的第一密钥，并向第一车载设备返回加密的第一密钥和临时密钥。
下面举例说明密钥体系构建的启动消息的一种可能的实现方式，例如，如表10所示。其中，m和n为正整数。
表10
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | m |
| M2 | IN | 128 |
| M3 | OUT | n |
| M4 | OUT | 128 |
| M5 | OUT | 128 |
以第一车载设备向第一SHE发送密钥体系构建的启动消息为例，该密钥体系构建的启动消息可以携带下列入参，并嵌套其他消息对应的参数。
入参满足：
M1＝KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_IN_Parameters
M2＝CMAC(Key,M1)
其中，KEY_ID为用于对该消息进行安全验证的安全验证密钥。对于车外设备发起的密钥体系构建的启动消息，该安全验证密钥必须是固定密钥对应的KEY_ID；对于内车CDC 或中控屏确认后触发的长期密钥更新，可以是长期密钥对应的KEY_ID，比如是一车一密的长期密钥的KEY_ID。Key是KEY_ID对应的安全验证密钥。
在KMS_KH_BuildCounter值小于第一SHE中的KMS_KH_BuildCounter值时，确定密钥体系构建的启动消息验证失败，忽略该密钥体系构建的启动消息，返回错误消息ERC_INVALID_PARAMETER。
在KMS_KH_BuildCounter值大于第一SHE中的KMS_KH_BuildCounter值时，说明重放攻击验证成功，此时，可以对M2进行验证。
CMD_TYPE表示消息的消息类型，当CMD_KMS_KH_BUILD_START、CMD_KMS_KH_BUILD_CONTINUE不携带其他消息时，CMD_TYPE可以填充0。举例来说，本申请密钥体系构建的启动消息可携带的其他消息可以如表11所示。
表11
需要说明的是，该密钥体系构建启动消息含有的其他消息，可能只是发给特定的车载设备、或车辆内的部分车载设备的，其他车载设备不处理，此时，可以使用特定范围共享、 或特定车载设备持有的固定密钥对该含有的业务功能的消息进行安全验证。在构建该业务功能的消息时，可以通过KMS业务消息，向服务端、代理端发送该密钥体系构建启动消息、还可以向服务端、代理端发送该密钥体系构建启动消息是否需要分发、向哪些客户端分发、服务端、代理端是否需要处理等信息。
在一些实施例中，在第一SHE收到的消息含有无法处理的消息时，则该消息直接忽略，并返回错误消息ENC_CANNOT_PROCESS_INNER_CMD。
在一些实施例中，密钥体系构建的启动消息的安全验证密钥KEY_ID与携带在该消息中的其他消息中使用的安全验证密钥KEY_ID’可以一样，也可以不一样。其中，携带在该消息中的其他消息中使用的安全验证密钥KEY_ID’可以根据该消息的要求或实际需要选择KEY_ID’。
CMD_TYPE可以占用1字节，表示密钥体系构建的启动消息是否携带其他消息。CMD_TYPE_IN_Parameters：是CMD_TYPE对应其他消息的所有入参。此时，CMD_TYPE值不为0。
在对密钥体系构建的启动消息验证成功后，SHE可以生成密钥体系构建的启动消息的出参，并向第一车载设备返回密钥体系构建的启动消息的响应消息，在该响应消息中携带出参。其中，出参M3～M5可以满足：
M3＝KEY_ID|KMS_KH_BuildCounter1|CMD_TYPE|CMD_TYPE_OUT_Parameters
M4＝CMAC(Key,M3)
M5＝KMS_KH_BuildKTemp
其中，KMS_KH_BuildCounter1是对密钥体系构建的启动消息验证后，对SHE中KMS_KH_BuildCounter更新后的值。例如，KMS_KH_BuildCounter1满足：KMS_KH_BuildCounter1＝KMS_KH_BuildCounter+1。
CMD_TYPE_OUT_Parameters是CMD_TYPE对应的消息的所有出参。
KMS_KH_BuildKTemp是密钥体系构建的启动消息验证成功后，SHE生成的一个临时密钥KTemp，用于第一车载设备直接操作SHE时的安全验证密钥，但不用于向第二车载设备发送第一密钥加载消息的安全验证密钥。同时，SHE在对该消息验证成功后，可以将KMS_KH_BuildStatus设置为“构建中”。SHE将Counter设置为KMS_KH_BuildCounter的最新值。
在密钥体系构建的启动消息携带第一请求消息的场景，考虑第一车载设备生成第一请求消息的一些实施例中，即第一请求消息的参数可以通过服务端向SHE发送第一查询请求获取，比如，可以用第一查询消息CMD_KMS_KH_GET_BUILD_STATUS来查询KMS_KH_BuildCounter以及CMD_BUILD_KEY的入参等状态数据。该第一查询消息，可以通过临时密钥进行安全性验证。下面举例介绍第一查询消息(CMD_KMS_KH_GET_BUILD_STATUS)的一种可能的实现方式，第一查询消息的相关参数可以如表12所示。
表12
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 8 |
| M2 | IN | 128 |
| M3 | OUT | 208 |
| M4 | OUT | 128 |
该第一查询消息可以是车外设备发起的，也可以是车内的第一车载设备、第二车载设备等车载设备发起的。
在一些实施例中，可以是第一车载设备在启动时检查密钥体系的构建状态，以便第一车载设备根据当前的密钥体系的构建状态，确定下一步的操作，例如，当前的构建状态为已构建部分第一密钥，则第一车载设备可以向SHE发起其他待生成的第一密钥的第一请求消息。在当前的构建状态为已构建部分第一密钥，其中，包括构建成功的第一密钥1，构建失败的第一密钥2，则第一车载设备可以向SHE发起生成第一密钥2的第一请求消息。
在一些实施例中，可以是第一车载设备在确定第一密钥为待更新的密钥时，可以向第一SHE发送第一查询消息，用于查询KMS_KH_BuildCounter及相应消息的入参等信息，用于生成相应消息。例如，第一车载设备可以向第一SHE发送第一查询消息，从SHE中读取当前的密钥体系构建状态、构建计数、上一次构建成功的日期，以及构建状态数据的校验码MAC等。
以第一车载设备向第一SHE发送第一查询消息为例，该第一查询消息可以携带下列入参M1和M2。
入参M1满足：M1＝KEY_ID
其中，KEY_ID为用于该第一查询消息的安全验证密钥。因此，对于车外设备发起的第一查询消息，该KEY_ID为是固定密钥；在车内的非KMS设备，例如，CDC或中控屏，触发长期密钥更新时，例如，在发送第一消息之前，发起的查询，可以是长期密钥，也可以是固定密钥。在另一些实施例中，第一车载设备或第二车载设备发起的第一查询消息，可以使用相应的SHE生成的临时密钥作为该安全验证密钥。需要说明的是，KEY_ID可以为0。如果为0，表示无密钥查询，此时入参中的M1中不含MAC(即不含M2)。相应的，出参中不含M4。
入参M2满足：M2＝CMAC(Key,M1)
即通过入参M2作为安全校验码，Key是KEY_ID对应的安全验证密钥。
在SHE对第一查询消息中的入参进行验证成功后，可以相应生成出参，并返回第一查询响应消息。例如，以第一SHE为例，第一车载设备向第一SHE发送第一查询消息，则第一SHE对第一查询消息中的入参进行验证成功后，可以相应生成出参M3和M4，并向第一车载设备返回第一查询响应消息。
其中，出参M3满足：
M3＝KEY_ID|KMS_KH_BuildStatus|KMS_KH_BuildCounter|KMS_KH_BuildDate|KMS_KH_BuildMac
出参M4满足：
M4＝CMAC(Key,M3)
第一车载设备接收到第一查询响应消息后，可以对第一查询响应消息中的出参进行验证，在验证成功后，获得出参中的查询内容，例如，KMS_KH_BuildStatus，KMS_KH_BuildCounter，KMS_KH_BuildDate，KMS_KH_BuildMac。
在步骤304之后，第一车载设备接收到第一SHE的第一响应消息后，可以根据第一密钥对应灌装的车载设备，例如，可以是第二车载设备。其中，第二车载设备可以是第一车载设备，也可以是车辆内的其他车载设备。第二车载设备可以是服务端，也可以是代理端， 还可以是客户端，在此不做限定。
下面以第二车载设备为除第一车载设备之外的其他车载设备为例进行说明。如图4所示，包括以下步骤：
步骤401：第一车载设备接收来自第一SHE发送的第一密钥的第一参数。
其中，第一车载设备根据接收到的第一响应消息，获得第一密钥的第一参数。具体第一参数可以参见上述第一响应消息中的M3～M5，在此不再赘述。
步骤402：第一车载设备根据第一密钥的第一参数，生成第一密钥加载消息。
其中，第一密钥加载消息用于第二车载设备对第一密钥加载消息进行验证成功后，灌装第一密钥。
步骤403：第一车载设备向第二车载设备发送第一密钥加载消息。
举例来说，第一车载设备可以是KMS的服务端或KMS的代理端。第二车载设备可以是KMS的客户端或KMS的代理端。例如，在第一车载设备为服务端，第二车载设备为客户端时，第一车载设备可以向第二车载设备发送第一密钥加载消息，或者第一车载设备可以向代理端发送第一密钥加载消息，并由代理端向第二车载设备转发第一密钥加载消息。
再比如，在第一车载设备为服务端，第二车载设备为代理端时，第一车载设备可以向第二车载设备发送第一密钥加载消息。可选的，第二车载设备还可以向第二车载设备所管理的客户端下发第一密钥加载消息。
再比如，在第一车载设备为代理端时，第一车载设备可以接收服务端转发的第一密钥加载消息，还可以向第一车载设备所管理的第二车载设备下发第一密钥加载消息。再比如，在第一车载设备为代理端时，第一车载设备可以生成第一密钥加载消息，并向可以向第一车载设备所管理的第二车载设备下发第一密钥加载消息。
步骤404：第二车载设备根据接收到的第一密钥加载消息，向第二SHE发送该第一密钥加载消息。
步骤405：第二SHE对该第一密钥加载消息验证成功后，生成第一密钥加载的响应消息。
步骤406：第二SHE向第二车载设备发送第一密钥加载的响应消息，第二车载设备向第一车载设备转发第一密钥加载的响应消息。
步骤407：第一车载设备根据第一密钥加载的响应消息，生成第一密钥的灌装验证消息。
步骤408：第一车载设备向第一SHE发送第一密钥的灌装验证消息。
步骤409：第一SHE在对第一密钥加载验证消息验证成功后，向第一车载设备反馈验证结果。
步骤4010：第一车载设备根据第一SHE反馈的验证结果，更新第一密钥的状态信息，并相应生成状态数据的验证码。
步骤4011：第一车载设备向第一安全硬件扩展单元发送状态更新消息。
其中，状态更新消息包括：车内密钥的构建状态；状态更新消息用于第一安全硬件扩展单元对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
需要说明的是，车内密钥的构建状态可以为密钥体系的构建状态，也可以为第一密钥的构建状态，在此不做限定。
步骤4012：第一SHE对状态更新消息进行验证，在验证成功后，更新状态数据的安 全验证码。
下面具体介绍每个步骤中涉及的消息。
在步骤401中，第一车载设备接收的第一响应消息中，可以携带第一密钥加载消息的入参和出参，即第一响应消息中携带的出参包括M1～M7。其中，出参M3～M5为第一密钥的第一参数，即第一密钥加载消息对应的入参M1～M3。
其中，第一密钥加载消息对应的入参满足：
M1＝UID|memory slot|KEY_ID
M2＝ENC
CBC,K1,IV＝0(Counter|Flags[|KeyID]|“0…0”m|Key
memory slot)
M3＝CMAC(K2,M1|M2)
其中，UID在Memory Slot为8 bits时，UID可以为128 bits。当第一密钥加载消息用于向第一车载设备的SHE中存储该第一车载设备的专属密钥，比如GLOBAL_FIX_KEY，其他车载设备不获得该密钥时，则UID可以不为0，该UID为第一车载设备的专用标识。当第一密钥加载消息向第一SHE中存储时，且第一密钥还应灌装至第二车载设备时，则UID应该为0(即wildcard UID)。
Key
memory slot为第一密钥。memory slot用于指示第一密钥存储的密钥地址。KEY_ID用于指示该第一密钥加载消息的安全验证密钥，用于派生出K1、K2的密钥的密钥标识。K1、K2是由KEY_ID对应的密钥派生得到的加密密钥和完整性计算密钥，派生方法参考现有SHE规范，在此不再赘述。安全验证密钥的选择可以基于表7确定，例如，该第一密钥加载消息的入参M1～M3(即第一响应消息的出参M3～M5)为第一SHE生成的，则安全验证密钥可以是一车一密的固定密钥、一车一密的长期密钥或更新前的第一密钥等。Counter为第一密钥对应的密钥更新计数值，可以是28 bits。SHE处理时，可以先校验该值是否大于memory slot对应存储区的待更新的第一密钥的Counter值。如果当前处于KMS的密钥体系构建过程中时，即KMS_KH_BuildStatus值为“1-构建中”，还要校验该值与SHE中的KMS_KH_BuildCounter值是否相同。
可选的，还可以包括KeyID，用于表示memory slot对应密钥的密钥索引(不是Memory Slot)。如果含有该字段，不可为0。“0…0”m：填充0字段，用于块加密对齐。由于AES_CBC_128加密时，块长度为128 bits，如果不含KeyID，则“0…0”m需要填充94 bits的0。如果含有KeyID，则“0…0”m需要填充62 bits的0。
在步骤405中，第二SHE在对第一密钥加载消息携带的入参进行验证成功后，可以相应生成第一密钥加载的响应消息，该第一密钥加载的响应消息可以携带第一密钥加载消息的出参，其中，出参M4和出参M5满足：
M4＝UID|memory slot|KEY_ID|EncyptedValue
M5＝CMAC(K4,M4)
其中，M4中的UID同入参的说明，M4的值也与入参相同。相应的，memory slot和KEY_ID也与入参中的值相同。需要说明的是，该KEY_ID对应的密钥并不用于第一密钥加载的响应消息的出参的加密和/或完整性计算。出参可以是根据更新后的第一密钥进行加密和/或完整性计算的，见下面的说明。
EncyptedValue＝ENC
CBC,K3,IV＝0(Counter|“1”
1[|KeyID]|“0…0”n)。
其中，K3是由第一密钥派生的加密密钥。Counter同入参的Counter值。“1”
1表示数值“1”占用1bit，“0…0”n：表示数值“0”占用填充n个bit。KeyID为可选的，用于表 示第一密钥的密钥索引，如果入参中含有该字段，则此处必须包含。32 bits。AES_CBC_128加密时，块长度为128 bits，例如，在不含KeyID时，则填充99 bits的0。在含有KeyID时，则填充67bits的0。K4是第一密钥派生的完整性计算密钥。派生方法参考现有SHE规范的说明。在第一密钥加载消息验证成功后，第二SHE将第一密钥的构建状态BuildStatus设置为“1-构建成功”。
在步骤406中，第一密钥的灌装验证消息的参数可以如表13所示。
表13
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 272 |
| M2 | IN | 128 |
其中，第一密钥的灌装验证消息可以携带第一密钥的灌装响应消息的出参。即，入参满足：
M1＝UID|memory slot|KEY_ID|EncyptedValue
M2＝CMAC(K4,M1)
第一车载设备通过第一密钥的灌装验证消息，将来自第二车载设备的第一密钥的灌装响应消息的出参的M4、M5传给SHE进行验证，确认第二车载设备的第一密钥的灌装是否成功完成，并将验证结果返回给第一车载设备。
其中，第一密钥的灌装响应消息的安全验证密钥可以采用第一车载设备与第一SHE之间的临时密钥。
在步骤409中，第一车载设备根据第一SHE反馈的验证结果，更新第一密钥的状态信息，并相应生成状态数据的完整性验证码MAC。
在第一密钥的生成过程中，第一车载设备或第二车载设备需要不断将当前密钥体系构建过程中的状态数据，例如，第一密钥的状态数据，或密钥体系的状态数据，安全存储在非易失性存储区中。存储的第一密钥的状态数据可以包括：密钥的构建状态、构建类型、当前构建到第一密钥属于的通信安全域、构建的第一密钥对应的车载设备等。比如存储的状态数据可以包括：
构建状态的标记KMSBuildStatusFlag，用于标记密钥体系的构建状态，未构建、正在构建、已经完成。
构建类型的标记KMSBuildTypeFlag，用于标记当前是初始密钥体系构建、长期密钥更新、还是更换车载设备的密钥体系重构。该标记仅当KMSBuildStatusFlag是正在构建时才有用。
构建阶段的标记KMSBuildStageFlag，用于标记当前是正在进行一车一密的固定密钥灌装、一车一密的长期构建或更新、各通信安全域的构建阶段或更新阶段等；
当然，还可以附加一些信息，比如当前构建到哪个通信安全域的哪个车载设备等。
本申请中，为保证状态数据的安全性，可以对状态数据的完整性保护，加密保护是可选的，下面以在没有加密保护的状态数据，完整性密钥和完整性MAC可以存储在安全存储区的场景。
在KMS运行时，可以为上述更新后的状态数据生成的完整性校验码MAC，可以通过临时密钥验证后存储到SHE。
一种可能的实现方式，可以通过密钥体系构建的启动消息，由SHE生成一个临时密钥 KTemp，并返回给车载设备。在车载设备构建密钥体系的过程中，由KMS和SHE共同持有该临时密钥K
Temp。一种可能的实现方式，该临时密钥KTemp，可以采用对称密钥。可以避免运行过程中KMS(普通运行环境，如果是可信运行环境更好，比如隔离运行)密钥可能是SHE不信任，提高状态数据存储的安全性。或者，还可以采用非对称的签名算法，临时生成一对公私钥，临时公钥返回给KMS。考虑到该密钥可能被其他攻击者软件拿到，非对称算法并不会增强安全性，反而降低MAC的计算性能。
通过临时密钥进行完整性保护，可以使得SHE更新第一密钥的相关信息(例如，完整性MAC、状态数据等)时，可以通过临时密钥进行完整性保护，提高防篡改的性能。
临时密钥KTemp也可以存储在SHE的非易失性存储区中。比如密钥构建过程中，如果设备异常重启，车载设备重启继续密钥体系构建时，需要与SHE再次完成验证，此时SHE可将原分配的KTemp，返回给KMS。当然也可以分配新的临时密钥。即在一次密钥体系构建过程中，KTemp可以保持不变，也可以按需变化。如果变化，需要保证新老临时密钥(KTemp_New、KTemp_Old)的平滑切换——对每个使用老临时密钥KTemp_Old加密和完整性保护的内容，都需要先替换为新临时密钥KTemp_New后，才可删除老临时密钥KTemp_Old。
密钥体系构建过程中的状态数据的存储，可以是加密存储在普通存储区，例如，车内KMS的服务端或代理端Agent，在密钥体系构建过程中，每次构建状态变化时，利用KTemp派生出加密密钥和完整性密钥，对状态数据加密后，存储到普通存储区。基于加密后的数据生成新的MAC，再利用CMD_KMS_KH_UPDATE_BUILDSTATUS，存储到SHE的KMS_KH_BuildMac中。KMS密钥构建过程中的关键状态数据也可以直接安全存储在SHE内部。例如，在SHE中扩展预留好存储KMS的过程状态数据的存储区即可，比如预留100Bytes。状态数据的具体含义，SHE可以不感知。
在步骤409中，第一车载设备可以向第一SHE发送状态更新消息。
下面举例说明状态更新消息CMD_KMS_KH_UPDATE_BUILDSTATUS，可以涉及到的参数。如表14所示。
表14
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 168 |
| M2 | IN | 128 |
以该消息用于将构建状态信息的安全校验码MAC存储到SHE的KMS_KH_BuildMac中为例，该消息的入参满足：
M2＝CMAC(Key,M1)
Key是KEY_ID为状态更新消息的安全验证密钥，例如临时密钥。
其中，入参满足：
M1＝KEY_ID|KMS_KH_BuildCounter|MAC
其中，KEY_ID可以是临时密钥的密钥地址。MAC是利用临时密钥基于当前密钥体系构建状态数据生成的安全校验码。例如，状态数据为KMSBuildStatusData＝{KMSBuildStatusFlag|KMSBuildTypeFlag|KMSBuildStageFlag|…}，则安全校验码满足：
MAC＝CMAC(Key，KMSBuildStatusData)。KMS_KH_BuildCounter是SHE中的KMS_KH_BuildCounter值，防止该命令的重放攻击。例如，在KMS_KH_BuildCounter值 不等于第一SHE中的值，则忽略该状态更新消息，返回ERC_INVALID_PARAMETER。在MAC与SHE中KMS_KH_BuildMac当前保存的值相同，则表明状态数据无需更新，此时忽略该状态更新消息，并返回ENC_REPEAT_STORE_SAME_DATA。
场景4，在密钥体系构建过程中，第一车载设备或第二车载设备都可能出现异常重启的场景，第一车载设备或第二车载设备重启后，第一车载设备或第二车载设备可以重新经过SHE验证，获取临时密钥，该临时密钥可以是重启前生成的临时密钥，也可以是为该车载设备重新生成的临时密钥。在第一车载设备或第二车载设备与相应的SHE获得临时密钥后，可以验证存储的状态数据的完整性，之后继续密钥体系的构建，避免由于第一车载设备或第二车载设备的重启，导致重启密钥体系的构建，提高密钥体系构建的鲁棒性。
一种可能的实现方式，第一车载设备或第二车载设备异常重启后，也可以通过第一车载设备(例如，服务端或代理端)向第一SHE发送第一查询消息，通知SHE验证重启前存储关键状态数据的MAC，验证成功后，从SHE中安全读取重启前的密钥体系构建进度，即返回密钥体系构建的状态数据。在第一车载设备或第二车载设备获得临时密钥后，可以使用SHE为本次构建生成的临时密钥进行安全性验证。如果验证失败，在第一车载设备为代理端时，可以向服务端发送第一查询请求，以获得密钥体系的构建状态；在第一车载设备为服务端时，则确认密钥体系的构建失败，可以重启密钥体系的构建。第一查询消息的参数可以参见表12所示，在此不再赘述。
如图5所示，为本申请提供的一种重启场景下的密钥生成方法的流程示意图。以第一车载设备重启为例，包括如下步骤：
步骤501：第一车载设备确定重启后，向第一SHE发送第一查询请求；第一查询请求用于查询第一密钥的第二参数。
举例来说，第一车载设备可以是KMS的服务端或KMS的代理端。例如，在第一车载设备为服务端时，第一车载设备可以向第一SHE发送第一查询请求。此时，第一SHE为第一车载设备对应的SHE。
再比如，在第一车载设备为代理端时，第一车载设备可以向第一车载设备对应的SHE发送第一查询请求，通过第一车载设备对应的SHE对第一查询请求进行验证后，返回第一查询响应。或者，第一车载设备可以向服务端发送第一查询请求，通过服务端的SHE对第一查询请求进行验证后，返回第一查询响应。此时，第一SHE为服务端对应的SHE。
步骤502：第一SHE根据第一查询请求，生成第一查询响应消息；第一查询响应消息为第一安全硬件扩展单元对第一查询请求进行验证后返回的；第一查询响应消息包括：第一密钥的第二参数。
步骤503：第一SHE向第一车载设备发送第一查询响应消息。
场景4.1，第一车载设备的第一查询消息还可以用于获得临时密钥，即第一安全硬件扩展单元向第一车载设备发送临时密钥；其中，临时密钥用于加密第一请求消息。
第一SHE在验证该消息时，可以判断当前密钥体系的构建状态KMS_KH_BuildStatus是否为“构建中”。如果不是则拒绝。验证该重启消息和第一查询消息后，第一SHE可以返回密钥体系构建的重启响应消息，该密钥体系构建的重启响应消息携带第一查询响应消息。其中，该第一查询响应消息可以携带临时密钥。
场景4.2，第一车载设备根据第一查询响应，确定当前执行生成第一密钥的操作。
在一些实施例中，第一车载设备根据第一密钥的第二参数和第一消息，生成第一请求消息；第一密钥为重启前第一安全硬件扩展单元待生成的密钥。第一安全硬件扩展单元根据第一请求消息，生成加密的第一密钥。
在一种可能的实现方式中，确定第一车载设备重启后，第一车载设备可以向第一SHE通知第一车载设备的重启状态，并通知第一SHE继续重启前的密钥体系的构建，此时可以向第一SHE发送密钥体系构建的重启消息。用于第一车载设备重新获取安全验证密钥及密钥体系构建的状态。例如，针对服务端，重启消息可以使用固定密钥作为安全验证密钥，可以参见密钥体系构建的启动消息，在此不再赘述。针对代理端，重启消息可以使用固定密钥或当期使用的临时密钥作为安全验证密钥，该安全验证密钥可以来自服务端发送给代理端的密钥。针对代理端，重启消息可以使用固定密钥或当期使用的临时密钥作为安全验证密钥，该安全验证密钥可以来自服务端或代理端发送给客户端的密钥。
需要说明的是，第一查询请求可以是参考上文中的第一查询请求的方式发送的，还可以是通过密钥体系构建的重启消息携带第一查询请求的方式。
一种可能的实现方式，第一车载设备可以向第一SHE发送密钥体系构建的重启消息携带第一查询消息。第一SHE可以在第一查询响应中发送该临时密钥。一种可能的实现方式，第一车载设备可以向第一SHE发送密钥体系构建的重启消息携带第一请求消息。
下面具体介绍密钥体系构建的重启消息可能的实现方式。密钥体系构建的重启消息必须在密钥体系构建的启动消息之后、在密钥体系构建的结束消息之前执行。具体可以通过密钥体系构建的参数进行验证。如表15所示，密钥体系构建的重启消息可能涉及以下参数。
表15
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | m |
| M2 | IN | 128 |
| M3 | OUT | n |
| M4 | OUT | 128 |
| M5 | OUT | 128 |
以第一车载设备为例，第一车载设备可以通过车外设备触发密钥体系构建的重启消息，举例来说，可以由服务器、APP、CDC或中控屏生成密钥体系构建的重启消息所需参数，传递给服务端，服务端将该消息生成密钥体系构建的重启消息，发送给第一SHE，第一SHE对密钥体系构建的重启消息进行验证，在验证后，生成密钥体系构建的重启消息对应的出参，并相应生成密钥体系构建的重启响应消息，该响应消息携带密钥体系构建的重启消息对应的出参。
在一些实施例中，该重启消息可以携带其他消息，也可以不携带其他消息，具体方式可以参考
携带的其他消息可以参考表11，在此不再赘述。密钥体系构建的重启消息携带的参数可以包括M1和M2。
入参M1满足：
M1＝KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_IN_Parameters
入参M2满足：
M2＝CMAC(Key,M1)
其中，Key是安全验证密钥，即KEY_ID对应的密钥。在对于车外设备发起的密钥体系构建的启动消息，相应的，车外设备发起的密钥体系构建的重启消息，则KEY_ID是固定密钥对应的KEY_ID，对于内车CDC或中控屏确认后触发的长期密钥更新，可以是长期密钥对应的KEY_ID，比如是一车一密的长期密钥的KEY_ID。
CMD_TYPE表示密钥体系构建的重启消息是否携带其他消息。具体参见表11，即密钥体系构建的启动消息携带其他消息的示例。CMD_TYPE_IN_Parameters：是CMD_TYPE对应其他消息的所有入参，此时，CMD_TYPE值不可为0。
KMS_KH_BuildCounter为密钥体系构建计数的值。第一车载设备对应的第一SHE在执行该密钥体系构建的重启消息时，该密钥体系构建的重启消息中的KMS_KH_BuildCounter值必须等于第一SHE中KMS_KH_BuildCounter的值，且SHE中的KMS_KH_BuildStatus必须为“构建中”，确定第一车载设备对应的第一SHE对密钥体系构建的重启消息验证成功，否则，第一车载设备对应的第一SHE对密钥体系构建的重启消息验证失败。例如，在密钥体系构建的重启消息中的KMS_KH_BuildCounter值不等于第一SHE中的KMS_KH_BuildCounter值，则忽略密钥体系构建的重启消息，并返回ERC_INVALID_PARAMETER。具体可以参见密钥体系构建的启动消息的验证方式，在此不再赘述。
在第一车载设备对应的第一SHE对密钥体系构建的重启消息验证成功后，第一车载设备对应的第一SHE可以生成密钥体系构建的重启的响应消息，该响应消息可以携带以下出参M3～M5。
其中，出参M3满足：
M3＝KEY_ID|KMS_KH_BuildCounter|CMD_TYPE|CMD_TYPE_OUT_Parameters
出参M4满足：M4＝CMAC(Key,M3)
出参M5满足：M5＝KMS_KH_BuildKTemp
其中，CMD_TYPE_OUT_Parameters：是CMD_TYPE对应的所有出参。
KMS_KH_BuildKTemp可以是重启前，由密钥体系构建的启动消息生成的一个临时密钥KTemp，也可以是第一SHE针对密钥体系构建的重启消息生成的新的临时密钥。
需要说明的是，相比密钥体系构建的启动消息，在第一车载设备对应的第一SHE对密钥体系构建的重启消息验证成功后，SHE中KMS_KH_BuildCounter的值保持不变。
考虑到在每次执行密钥体系构建的启动消息，启动密钥体系构建时，相应的SHE将本地存储的KMS_KH_BuildCounter增1。在第一密钥构建完成(例如，执行第一请求消息、或第一密钥加载消息成功)后，第一密钥对应的Counter字段设置为KMS_KH_BuildCounter值。从而，在第一车载设备或第二车载设备重启后，可以通过获得密钥体系的状态数据，确定密钥生成的状态，尤其是对于重启前已生成但未完成加载的第一密钥。此时，服务端或代理端可以从相应的SHE中，获得第一密钥的第一参数，生成第一密钥加载消息，并继续向未获得该第一密钥的各客户端或代理端分发，而不必重新启动构建第一密钥的操作。
如图6所示，为本申请提供的一种重启场景下的密钥生成方法的流程示意图。以第二车载设备重启为例，包括如下步骤：
步骤601：第二车载设备向第一车载设备发送第二消息；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
在一些实施例中，第二车载设备可以是KMS的客户端或KMS的代理端。例如，在第一车载设备为服务端，第二车载设备为客户端时，第二车载设备可以向第一车载设备发送第二消息，或者第二车载设备可以向代理端发送第二消息，并由代理端向第一车载设备转发第二消息。
再比如，在第一车载设备为服务端，第二车载设备为代理端时，第二车载设备可以向第一车载设备发送第二消息。可选的，第二车载设备还可以接收来自第二车载设备所管理的客户端的第二消息。
步骤602：第一车载设备向第一SHE发送第二消息的验证消息。
其中，第一SHE为第一车载设备对应的SHE。
步骤603：第一SHE对第二消息的验证消息进行验证后，向第一车载设备返回第二消息的验证响应消息。
通过步骤602和步骤603实现第一车载设备对第二消息的验证。
步骤604：第一车载设备根据第二消息的验证响应消息，向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
举例来说，在第一车载设备为服务端，第二车载设备为客户端时，第一车载设备可以向第二车载设备发送第三消息，或者第一车载设备可以向代理端发送第三消息，并由代理端向第二车载设备转发第三消息。
再比如，在第一车载设备为服务端，第二车载设备为代理端时，第一车载设备可以向第二车载设备发送第三消息。可选的，第二车载设备还可以向第二车载设备所管理的客户端下发第三消息。
再比如，在第一车载设备为代理端时，第一车载设备可以接收服务端转发的第三消息，还可以向第一车载设备所管理的第二车载设备下发第三消息。再比如，在第一车载设备为代理端时，第一车载设备可以生成第三消息，并向可以向第一车载设备所管理的第二车载设备下发第三消息。
下面以场景5.1～5.2举例说明上述过程。
场景5.1，第二车载设备向第一车载设备发送的第二消息为第一查询消息。
对于第二车载设备的重启，重启后可以是在安全隧道建立成功后，由第一车载设备(例如，代理端、或服务端)根据第一查询消息的入参，生成向第一SHE发送的第一查询消息的验证消息，该第一查询消息的验证消息携带第一查询消息的入参，并通过第一SHE验证后，返回第一查询响应消息的出参(即第二消息的验证响应消息)。
需要说明的是，第一查询消息的安全验证密钥可以是第一车载设备和第二车载设备之间使用的密钥，第二消息的验证消息的安全验证密钥可以是第一车载设备与第一SHE之间使用的密钥。
相应的，第一车载设备可以根据第一查询响应消息的出参，生成向第二车载设备发送的第三消息，该第三消息携带第一查询响应消息的出参，并将第三消息发送给重启的第二车载设备，第二车载设备在验证该第三消息后，获得第一查询响应消息的出参。需要说明的是，第三消息的安全验证密钥可以是第一车载设备和第二车载设备之间使用的密钥，第二消息的验证响应消息的安全验证密钥可以是第一车载设备与第一SHE之间使用的密钥。具体第一查询响应消息的入参和出参可以参考上文中的第一查询响应消息。
场景5.2，第二车载设备向第一车载设备发送的第二消息为第一密钥的请求消息。
在第二车载设备为代理端时，重启的代理端可以向第一车载设备(服务端)发送第一查询消息，以触发服务端返回第一查询响应消息后，代理端可以向代理端管理的客户端下发第一查询响应消息，以便各客户端与客户端对应的SHE完成验证，获得相应的临时密钥或状态数据等，以继续密钥体系的构建。
相应的，第一车载设备根据第一密钥的请求消息，生成第一密钥加载消息。
考虑到第一密钥可能是在第二车载设备重启过程中已生成的，或者，是第二车载设备在重启后还未生成的，下面以场景5.2.1～场景5.2.2举例说明。
场景5.2.1，在一些实施例中，第一车载设备根据第一密钥的第二参数和第一消息，生成第一密钥加载消息；第一密钥为重启前第一安全硬件扩展单元已生成的密钥。从而，第一车载设备可以向第二车载设备发送第一密钥加载消息。一种可能的实现方式，第二车载设备可以在密钥体系构建的重启消息携带第一查询消息。
场景5.2.2，在一些实施例中，第一车载设备根据第一密钥的第二参数和第一消息，生成第一请求消息；并向第一SHE发送第一请求消息，在SHE验证第一请求消息后，生成第一响应消息，其中，第一响应消息携带第一密钥的第一参数。从而，第一车载设备接收到第一响应消息后，根据第一密钥的第一参数，生成第一密钥加载消息，并发送给第二车载设备，以使第二车载设备加载第一密钥。其中，第一请求消息可以携带在密钥体系构建的重启消息中发送。
在密钥体系构建场景下，例如，在密钥体系构建的启动消息执行后，第一车载设备执行第二查询消息查询密钥的状态数据，密钥的状态数据可以包括：密钥的密钥标记、查询密钥是否形成配对等信息。具体可以参见上述状态数据，在此不再赘述。为保证密钥的安全，第二查询消息无法查询密钥内容。
再比如，服务端可能无法知道第二车载设备是否完成加载或灌装，此时，可以由用户通过密钥管理工具触发密钥验证过程，例如，可以由车外设备触发服务端向服务端的SHE发送第二查询消息，以获得第一密钥的加载状态。
另一种可能的场景，在第一车载设备或第二车载设备启动时，第一车载设备或第二车载设备检查密钥的构建状态是否完成。比如，如果密钥的构建状态没有完成，上报告警，禁止车辆行驶等。在另一种可能的场景中，还可以是第一车载设备或第二车载设备重启后，通过第一车载设备或第二车载设备发送第二查询消息，以查询第一密钥的加载状态。
下面举例介绍第二查询消息中可以涉及的参数。例如，如表16所示。
表16
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 16 |
| M2 | IN | 128 |
| M3 | OUT | (13，或24)*8 |
| M4 | OUT | 128 |
以第一车载设备为例，第一车载设备可以生成第二查询消息的入参。其中，入参M1满足：
M1＝KEY_ID|memory slot1
入参M2满足：M2＝CMAC(Key,M1)
其中，memory slot1用于表示第二查询消息对应查询的密钥。
一种可能的场景，KEY_ID为第二查询消息的安全验证密钥，Key是KEY_ID对应的密钥。例如，在密钥体系构建的启动消息执行后，在密钥体系构建过程中，第一车载设备执行第二查询消息查询密钥信息时，则KEY_ID是临时密钥的密钥地址。如果KEY_ID为0，表示第二查询消息没有验证信息，忽略后面的M2、M4。
在第一SHE验证第二查询消息成功后，可以相应生成第二查询响应消息，其中，第二查询响应消息可以包括以下出参。其中，出参M3满足：
M3＝KEY_ID|memory slot1|Key1 Info
其中，Key1 Info为密钥地址为memory slot1对应的密钥信息，例如，Key1 Info满足：
Key1 Info＝KeyFlags|00|Counter(28 bits)|PairSlot|KeyID，
其中，KeyFlags可以满足：
KeyFlags＝WRITE-PROTECTION(1bit)|Secure boot failure(1bit)|Debugger activation(1bit)|Wildcard UID(1bit)|Key usage(1bit)|Plain key(1bit)|BuildStatus(1 bit)。
KeyFlags可以占用7bits，其中，00占用2 bits，KeyID占用32 bits。Counter占用28 bits。PairSlot用于标识查询的密钥Key1是否形成配对、或Slave，即后面是否含有“memory slot2”和“Key2Info”。例如，该PairSlot值为0，则不含；该PairSlot值为1含、且是Pair；值为2含、且是Slave。
出参M4满足：M4＝CMAC(Key,M3)
从而，第一车载设备解锁到第二查询响应消息后，可以对第二查询响应消息中的出参进行验证后，获得密钥的查询结果。
在密钥体系待构建的第一密钥全部构建成功后，可以有非KMS设备向第一车载设备发送密钥体系构建完成消息，并由第一SHE验证该消息。用于告知SHE本次KMS的密钥体系构建完成，其中密钥体系构建完成包括密钥体系的所有第一密钥成功生成、密钥体系的密钥加载验证成功等。需要说明的是，该消息可以不包括其他消息，可以含有一个加密和完整性保护的状态信息：KMS密钥体系构建完成，结果成功、或失败。
如图7所示，本申请实施例提供一种密钥生成方法，包括如下步骤：
步骤701：第一车载设备获得密钥体系构建完成消息。
一种可能的场景，在该次密钥体系构建过程中，密钥体系构建的启动消息可以是在车外设备生成并发送给第一车载设备(例如，服务端或代理端)的(比如由车外的服务器、密钥管理工具或APP发起的密钥体系构建启动消息)，则密钥体系构建的完成消息也由车外设备生成。
一种可能的场景，在该次密钥体系构建过程中，密钥体系构建的启动消息是在车内设备生成并发送给服务端的(比如由车内CDC或中控屏发起的长期密钥更新)，则密钥体系构建的完成消息也可以是在车内设备生成，也可以在车外设备生成，在此不做限定。
需要说明的是，密钥体系构建完成消息可以同密钥体系构建启动消息，选用相同的安全验证密钥，具体可以参见表11，在此不再赘述。
举例来说，第一车载设备可以是KMS的服务端或KMS的代理端。例如，在第一车载设备为服务端时，第一车载设备可以向客户端发送密钥体系构建完成消息，或者第一车载 设备可以向代理端发送密钥体系构建完成消息，并由代理端向客户端转发密钥体系构建完成消息。在第一车载设备为代理端时，第一车载设备可以接收服务端转发密钥体系构建完成消息，还可以向第一车载设备所管理的客户端下发密钥体系构建完成消息。
步骤702：第一车载设备根据密钥体系构建完成消息，向第一SHE发送密钥体系构建完成消息的验证消息。
其中，第一SHE为第一车载设备对应的SHE。第一SHE可以是设置与第一车载设备设置在同一ECU中的，也可以是单独设置的，在此不做限定。第一车载设备可以是用于管理该ECU中的密钥的KMS。
步骤703：第一SHE对密钥体系构建完成消息的验证消息进行验证，向第一车载设备发送验证结果。
步骤704：第一车载设备向第二车载设备发送密钥体系构建完成消息。
其中，第二车载设备可以是KMS的客户端或KMS的代理端。例如，在第二车载设备为客户端时，第二车载设备可以接收第一车载设备发送的密钥体系构建完成消息，也可以通过第二车载设备的代理端转发第一车载设备发送的密钥体系构建完成消息。在第二车载设备为代理端时，第二车载设备可以接收第一车载设备发送的密钥体系构建完成消息，还可以向第二车载设备所管理的客户端下发密钥体系构建完成消息。
步骤705：第二车载设备根据密钥体系构建完成消息，向第二SHE发送密钥体系构建完成消息的验证消息。
其中，第二SHE为第二车载设备对应的SHE。第二SHE可以是设置与第一车载设备设置在同一ECU中的，也可以是单独设置的，在此不做限定。第二车载设备可以是用于管理该ECU中的密钥的KMS。
步骤706：第二SHE对密钥体系构建完成消息的验证消息进行验证，向第二车载设备发送验证结果。
步骤707：第二车载设备向第一车载设备发送第二车载设备的验证结果。
下面举例说明密钥体系构建完成消息可能的方式，如表17所示，包括密钥体系构建完成消息可能涉及的参数。
表17
| 参数Parameter | Direction | Width(bits) |
| M1 | IN | 80 |
| M2 | IN | 128 |
一种可能的实现方式，密钥体系构建完成消息可以用于告知相应的SHE本次KMS的密钥体系构建完成，以及本次密钥体系构建完成的日期等。密钥体系构建完成消息可以包括以下入参。其中，入参M2满足：M2＝CMAC(Key,M1)
其中，Key是KEY_ID对应的密钥。KEY_ID为密钥体系构建完成消息对应的安全验证密钥的密钥地址。对于车外发起的密钥体系构建，则该值必须是固定密钥的KEY_ID(因为该命令消息的构造也必须是在车外完成)；对于车内CDC或中控屏发起的长期密钥更新，则可以是长期密钥对应的KEY_ID，比如是一车一密的长期密钥的KEY_ID。
入参M1可以满足：
M1＝KEY_ID|BuildStatus|BuildCounter|BuildDate
其中，密钥体系构建完成消息中的BuildStatus表示密钥体系的构建状态，例如，0—表示构建成功，其它值—表示构建失败。在SHE对密钥体系构建完成消息验证成功时，可以根据密钥体系构建完成消息中的BuildStatus更新SHE中的KMS_KH_BuildStatus值。
BuildCounter为本次密钥体系构建的构建计数的值。
在SHE对密钥体系构建完成消息进行验证时，密钥体系构建完成消息中的BuildCounter的值与SHE中KMS_KH_BuildCounter值一致时，继续其他的验证，否则忽略该密钥体系构建完成消息，并返回ERC_PARAMETER_INVALID。
在SHE对密钥体系构建完成消息进行验证时，SHE中的KMS_KH_BuildStatus必须是处在“1-构建中”，否则忽略该密钥体系构建完成消息，并返回错误消息ERC_KMS_KH_STATUS_INVALID。
在任何一个密钥、任何一项检查失败，SHE都不能更新KMS_KH_BuildStatus的值，并返回ERC_KMS_KH_NOT_FINISHED。
在SHE对密钥体系构建完成消息验证成功后，通过SHE检查受KMS_KH_BuildStatus影响的各第一密钥是否都完成构建。例如，包括每个密钥的BuildStatus、Counter的检查。仅当所有第一密钥的检查通过后，密钥体系构建完成消息返回验证结果ERC_NO_ERROR。否则返回验证结果ERC_KMS_KH_NOT_FINISHED。
在SHE对密钥体系构建完成消息验证成功后，此时SHE设置KMS_KH_BuildStatus为“2-构建成功”，以及刷新KMS_KH_BuildDate。即在每次密钥体系构建完成时，将密钥体系构建完成的日期和时间存储到SHE的KMS_KH_BuildDate。
在SHE确定BuildStatus表示构建成功(例如，BuildStatus的值为0)时，更新密钥体系构建的完成时间。BuildDate表示密钥体系构建完成消息的完成时间。能够从系统中读取系统时间时，可以忽略该参数，由SHE直接从系统中读取当前时间，作为密钥体系构建完成时间，并更新到KMS_KH_BuildDate。在SHE无法从系统中读取系统时间时，可以先校验该参数，例如，该参数BuildDate是否大于SHE中KMS_KH_BuildDate值。可选的，还可以参考KMS_CFG_KeyLifetime值，比如BuildDate大于或等于KMS_KH_BuildDate与KMS_CFG_KeyLifetime(或该值的二分之一等)的和时，则验证该参数合法，将该参数更新到KMS_KH_BuildDate。
如果BuildStatus值表示构建失败，则SHE设置KMS_KH_BuildStatus为“3-构建失败”，可以不刷新KMS_KH_BuildDate值。
通过步骤704～步骤707，保证第二车载设备都执行密钥体系构建完成消息。即服务端需要将密钥体系构建完成消息的参数分发到各代理端和客户端，代理端分发到其代理的各客户端，用于同步各第二车载设备的KMS_KH_BuildCounter值等状态数据。在车内密钥体系构建完成(成功/失败)后，第一车载设备和第二车载设备的要通知SHE将构建状态KMS_KH_BuildStatus设置为“构建成功”、或“构建失败”，并且刷新构建日期。
图8为本申请实施例适用的一种可能的系统架构示意图，如图8所示的系统架构包括车辆和诊断设备。其中，车辆可以是具有密钥认证功能的任意车辆。诊断设备可以是指诊断仪，也可以是指诊断服务器，还可以是指诊断服务器集群。应理解，本申请实施例对系统架构中车辆的数量和诊断设备的数量均不作限定，例如1台诊断设备可以只与1辆车辆进行信息交互，也可以与多辆车辆进行信息交互。且，本申请实施例所适用的系统架构中 除了包括车辆和诊断设备以外，还可以包括其它设备，如供应商设备、制造商设备、产线设备和销售设备等，对此本申请实施例也不作限定。以及，本申请实施例中的诊断设备可以将所有的功能集成在一个独立的物理设备上，也可以将功能分布在多个独立的物理设备上，对此本申请实施例也不作限定。
本申请实施例中，车辆诊断可以在有线方式下实现，也可以在无线方式下实现。示例来说，当基于有线方式实现车辆诊断时，诊断设备上通常带有诊断线，车辆上预设有诊断接口，诊断人员可以直接将诊断设备的诊断线一端插入车辆的诊断接口，之后在诊断设备上输入诊断命令，以使诊断命令通过诊断线发送给车辆。其中，诊断接口可以是指统一的诊断服务(unified diagnostic services，UDS)接口，也可以是指车载诊断(on board diagnostics，OBD)接口，还可以是指其它能够实现命令传输功能的接口，不作限定。当基于无线方式实现车辆诊断时，诊断设备和车辆可以具有蓝牙或无线局域网(wireless local area network，WLAN)等近场通讯功能，诊断人员可以先通过诊断设备和车辆的近场通讯功能连接诊断设备和车辆，再在诊断设备上输入诊断命令，以使诊断命令通过无线方式传输车辆。示例性地，诊断设备上还可以设置有液晶显示屏，在得到诊断结果后，诊断设备还可以将诊断结果同步显示在液晶显示屏上，以便于提醒诊断人员及时查看诊断结果，快速查明故障位置及故障原因。
如图9所示，本申请提供一种车内密钥获取方法，包括：
步骤901：车外设备向第一车载设备发送第一消息。
相应的，第一车载设备接收车外设备发送的第一消息；第一消息用于请求第一车载设备获得第一密钥。
一种可能的实现方式，第一密钥可以是触发第一车载设备生成的长期密钥，也可以是车辆预先存储的固定密钥，也可以是云端服务器存储的该车辆的固定密钥，在此不做限定。
例如，车外设备可以是诊断设备，诊断设备可以通过与车辆建立安全隧道，向第一车载设备发送第一消息，该第一消息可以包括诊断设备对应的证书、PIN码等。或者，针对设备还可以通过网关发送第一消息，在此不做限定。
步骤902：第一车载设备根据第一消息和第一车载设备的验证信息，生成角色验证请求消息，角色验证请求消息用于服务器对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证；
一种可能的实现方式，第一车载设备可以对PIN码进行加密后获得的加密的PIN码，并根据第一密钥的权限信息生成第一车载设备的验证信息，用于服务器对第一密钥进行验证，从而，第一车载设备可以通过诊断设备对应的证书、加密后的PIN码和加密后的第一密钥的权限信息，生成角色验证请求消息。
步骤903：第一车载设备向服务器发送角色验证请求消息。
一种可能的实现方式，第一车载设备可以通过加密的方式向服务器发送角色验证请求消息，具体加密方式本申请不做限定。
步骤904：服务器对角色验证请求消息进行验证，生成角色验证的响应消息。
其中，角色验证的响应消息包括：角色验证请求消息的验证结果。
一种可能的实现方式，服务器可以对加密的PIN码进行验证，对诊断设备对应的证书进行验证，还可以对第一密钥的权限信息进行验证。例如，在第一消息用于请求第一车载设备生成第一密钥时，可以对第一车载设备是否有生成第一密钥的权限和能力进行验证。 在第一消息用于请求服务器向第一车载设备发送第一密钥时，可以对第一车载设备是否有获得第一密钥的权限进行验证。在第一消息用于请求诊断设备获得第一车载设备上的第一密钥用于诊断时，可以对第一车载设备和诊断设备是否有获得第一密钥的权限进行验证。
步骤905：服务器向第一车载设备发送角色验证的响应消息。
相应的，第一车载设备接收服务器发送的角色验证的响应消息。
例如，角色验证的响应消息可以包括同意或拒绝第一车载设备获得第一密钥。可选的，角色验证的响应消息还可以包括其他信息。或者，这些信息还可以是服务器另外发送的，在此不做限定。
一种可能的实现方式，在步骤905之后，第一车载设备可以生成第一车载设备或第二车载设备的第一密钥。具体实现方式可以参见图3中的实现方式。例如，第一车载设备接收服务器发送的第一消息；第一消息用于指示第一车载设备生成第一密钥；第一车载设备根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
需要说明的是，第一车载设备确定生成第一车载设备或第二车载设备的第一密钥的方式可以是服务器发送的第一消息确定的，也可以是第一车载设备根据角色验证的响应消息确定的，此时，角色验证的响应消息可以包括第一消息中的内容。
一种可能的实现方式，在步骤905之后，服务器可以向第一车载设备发送加密的第一密钥。相应的，第一车载设备接收服务器发送的第一密钥。其中，服务器发送加密的第一密钥的方式可以参考上述实施例的场景2中，车外设备向第一车载设备发起发送第一密钥加载消息的方式，使得第一车载设备根据发送第一密钥加载消息，灌装第一密钥。
在另一些实施例中，服务器可以通过单独发送的消息向第一车载设备发送加密的第一密钥，也可以是角色验证的响应消息携带的，本申请不做限定。
一种可能的实现方式，在步骤905之后，第一车载设备在角色验证请求消息的验证结果为验证成功时，向车外设备发送第一密钥。
另一种可能的实现方式，服务器可以通过单独发送的消息向第一车载设备指示同意第一车载设备发送第一密钥，或者，也可以是角色验证的响应消息指示的，从而，第一车载设备可以确定向车外设备发送第一密钥。
第一车载设备向车外设备发送第一密钥的方式可以有多种。举例来说，第一车载设备向车外设备发送第一密钥的方式也可以是参考第一密钥加载消息的方式发送的，从而，车外设备可以根据接收到的第一密钥价值消息进行验证后，获得第一密钥。当然，还可以通过其他安全传输方式，向车外设备发送第一密钥。
图10为本申请实施例提供的一种密钥生成装置的结构示意图，如图10所示，该装置可以为第一车载设备或第一安全扩展单元，也可以为芯片或电路，比如可设置于第一车载设备中的芯片或电路，再比如可设置于第一安全扩展单元中的芯片或电路，再比如可设置于第一安全扩展单元中内的芯片或电路。
进一步的，该密钥生成装置1001还可以进一步包括总线系统，其中，处理器1002、存储器1004、收发器1003可以通过总线系统相连。
应理解，上述处理器1002可以是一个芯片。例如，该处理器1002可以是现场可编程 门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。
在实现过程中，上述方法的各步骤可以通过处理器1002中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器1002中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1004，处理器1002读取存储器1004中的信息，结合其硬件完成上述方法的步骤。
应注意，本申请实施例中的处理器1002可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器1004可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
该密钥生成装置1001对应上述方法中的第一车载设备的情况下，该密钥生成装置可以包括处理器1002、收发器1003和存储器1004。该存储器1004用于存储指令，该处理器1002用于执行该存储器1004存储的指令，以实现如上图1至图8中所示的任一项或任多项对应的方法中第一车载设备的相关方案。
当密钥生成装置1001为上述第一车载设备，密钥生成装置1001可以用于执行上述实施例中任一实施例中第一车载设备所执行的密钥生成方法。密钥生成装置1001为上述第 一车载设备时，收发器1003获得第一消息；第一消息用于指示第一车载设备构建第一密钥；处理器1002根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
当密钥生成装置1001为上述第一安全硬件扩展单元，密钥生成装置1001可以用于执行上述实施例中任一实施例中第一安全硬件扩展单元所执行的密钥生成方法。收发器1003用于接收第一安全硬件扩展单元对应的第一车载设备发送的第一请求消息；第一请求消息为第一车载设备请求第一安全硬件扩展单元构建第一密钥生成的；处理器1002对第一请求消息进行验证成功后，生成第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
基于以上实施例以及相同构思，图11为本申请实施例提供的密钥生成装置的示意图，如图11所示，该密钥生成装置1100可以为第一车载设备或第一安全硬件扩展单元，也可以为芯片或电路，比如可设置于第一车载设备或第一安全硬件扩展单元中的芯片或电路。
该密钥生成装置可以对应上述方法中的第一车载设备或第一安全硬件扩展单元。该密钥生成装置可以实现如上图1至图8中所示的任一项或任多项对应的方法中第一车载设备或第一安全硬件扩展单元所执行的步骤。该密钥生成装置可以包括获取单元1101和处理单元1102。可选的，还可以包括接收单元1103和发送单元1104。
当密钥生成装置1100为上述第一车载设备，且实现如上述图3中第一车载设备所执行的步骤时，获取单元1101用于获得第一消息；第一消息用于指示第一车载设备构建第一密钥；处理单元1102根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，接收单元1103，用于接收来自第一安全硬件扩展单元发送的第一响应消息。
一种可能的实现方式，接收单元1103，用于接收来自第一安全硬件扩展单元发送的第一密钥的第一参数；
处理单元1102，用于根据第一密钥的第一参数，生成第一密钥加载消息；
发送单元1104，用于向第二车载设备发送第一密钥加载消息；第一密钥加载消息用于第二车载设备对第一密钥加载消息进行验证成功后，灌装第一密钥。
一种可能的实现方式，获取单元1101获得单元获得第一消息之后，发送单元1104，还用于向第一安全硬件扩展单元发送状态更新消息；状态更新消息包括：车内密钥的构建状态；状态更新消息用于第一安全硬件扩展单元对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
一种可能的实现方式，车内密钥的构建状态用于第一安全硬件扩展单元对第一请求消息进行验证。
一种可能的实现方式，处理单元1102确定第一车载设备重启后，通过发送单元1104向第一安全硬件扩展单元发送第一查询请求；第一查询请求用于查询第一密钥的第二参数；通过接收单元1103接收第一安全硬件扩展单元发送的第一查询响应消息；第一查询响应消息为第一安全硬件扩展单元对第一查询请求进行验证后返回的；第一查询响应消息包括：第一密钥的第二参数；根据第一密钥的第二参数和第一消息，生成第一请求消息；第一密钥为第一车载设备重启前第一安全硬件扩展单元待生成的密钥。
一种可能的实现方式，接收单元1103，用于接收来自第一安全硬件扩展单元发送的临时密钥；临时密钥用于加密第一请求消息。
一种可能的实现方式，接收单元1103，用于接收第二车载设备发送的第二消息；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
一种可能的实现方式，处理单元1102对第二消息进行验证后，通过发送单元1104向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
一种可能的实现方式，根据以下任一项获得第一消息：
通过接收单元1103接收车内设备或车外设备发送的第一消息；
通过接收单元1103接收配置文件的初始化或更新信息后，获得第一消息；
通过接收单元1103接收车辆的固定密钥的初始化或更新信息后，获得第一消息；
通过接收单元1103接收车辆的车载设备之间的共享密钥的初始化或更新信息后，获得第一消息。
在另一些实施例中，密钥生成装置可以为车辆中的安全硬件扩展单元，该装置包括：
接收单元1103，用于接收第一安全硬件扩展单元对应的第一车载设备发送的第一请求消息；第一请求消息为第一车载设备请求第一安全硬件扩展单元构建第一密钥生成的；
处理单元1102，用于对第一请求消息进行验证成功后，生成第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，发送单元1104，用于向第一车载设备发送第一响应消息；第一响应消息包括：第一密钥信息。
一种可能的实现方式，处理单元1102对第一请求消息进行验证成功后，生成第一密钥的第一参数；通过发送单元1104向第一车载设备发送第一密钥的第一参数；第一密钥的第一参数用于第二车载设备灌装第一密钥。
一种可能的实现方式，接收单元1103，还用于接收第一车载设备发送的状态更新消息；状态更新消息包括：车内密钥的构建状态；处理单元1102，还用于对状态更新消息验证成功后，更新自身的车内密钥的构建状态。
一种可能的实现方式，接收单元1104，还用于在第一车载设备重启后，接收第一车载设备发送的第一查询请求；第一查询请求用于查询第一密钥的第二参数；
处理单元1102，用于对第一查询请求进行验证后，通过发送单元1104向第一车载设备发送第一查询响应消息；第一查询响应消息包括：第一密钥的第二参数；第一密钥的第二参数用于第一车载设备生成第一请求消息；第一密钥为重启前第一安全硬件扩展单元待生成的密钥。
一种可能的实现方式，处理单元1102，用于对第一请求消息进行验证成功后，生成临时密钥；通过发送单元1104向第一车载设备发送临时密钥；临时密钥用于加密第一请求消息。
一种可能的实现方式，接收单元1103，用于接收来自第一车载设备的第二消息的验证消息；第二消息为第一车载设备接收第二车载设备发送的；第二消息用于以下至少一项：查询第一密钥的第二参数、请求第一车载设备生成第一密钥或者指示第二车载设备重启。
一种可能的实现方式，处理单元1102，用于对第二消息进行验证后，通过发送单元向 第一车载设备发送第二消息的验证响应消息；第二消息的响应消息用于第一车载设备向第二车载设备发送第三消息；第三消息包括以下至少一项：第一密钥的第二参数、第一密钥信息。
发送单元1104和接收单元1103在发送信息时可以为发送单元或发射器，接收单元1103在接收信息时可以为接收单元或接收器，发送单元1104和接收单元1103可以为收发器，此收发器、发射器或接收器可以为射频电路，当密钥生成装置1100包含存储单元时，该存储单元用于存储计算机指令，处理单元1103与存储单元通信连接，处理单元1103执行存储单元存储的计算机指令，使密钥生成装置1100可以用于执行上述实施例中第一车载设备或第一安全硬件扩展单元所执行的方法。其中，处理单元1103可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(Application Specific Intergrated Circuit，ASIC)。
当密钥生成装置1100为芯片时，发送单元1104和接收单元1103可以是输入和/或输出接口、管脚或电路等。处理单元1103可执行存储单元存储的计算机执行指令，以使该密钥生成装置1100内的芯片执行实施例中任一实施例所执行的方法。可选地，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是密钥生成装置1100内的位于该芯片外部的存储单元，如只读存储器(Read Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)等。
该密钥生成装置1100所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
图12为本申请实施例提供的一种密钥获取装置的结构示意图，如图12所示，该装置可以为第一车载设备或服务器，也可以为芯片或电路，比如可设置于第一车载设备中的芯片或电路，再比如可设置于服务器中的芯片或电路，再比如可设置于服务器中内的芯片或电路。
进一步的，该密钥获取装置1201还可以进一步包括总线系统，其中，处理器1202、存储器1204、收发器1203可以通过总线系统相连。
应理解，上述处理器1202可以是一个芯片。例如，该处理器1202可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。
在实现过程中，上述方法的各步骤可以通过处理器1202中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器1202中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1204，处理器1202读取存储器1204中的信息，结合其硬件完成上述方法的步骤。
应注意，本申请实施例中的处理器1202可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者 晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器1204可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
该密钥获取装置1201对应上述方法中的第一车载设备的情况下，该密钥获取装置可以包括处理器1202、收发器1203和存储器1204。该存储器1204用于存储指令，该处理器1202用于执行该存储器1204存储的指令，以实现如上图9中所示的方法中第一车载设备的相关方案。
当密钥获取装置1201为上述第一车载设备，密钥获取装置1201可以用于执行上述实施例中第一车载设备所执行的方法。
密钥获取装置1201为上述第一车载设备，且执行图9的实施例时：
收发器1203用于接收车外设备发送的第一消息；向服务器发送身份验证请求消息。第一消息用于请求第一车载设备获得第一密钥；接收服务器发送的身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
处理器1202用于根据第一消息和第一车载设备的验证信息，生成身份验证请求消息，身份验证请求消息用于服务器对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证。
一种可能的实现方式，收发器1203还用于接收服务器发送的第一消息；第一消息用于指示第一车载设备生成第一密钥；处理器1202还用于根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，收发器1203还用于接收服务器发送的第一密钥。
一种可能的实现方式，处理器1202还用于在身份验证请求消息的验证结果为验证成功时，通过收发器1203向车外设备发送第一密钥。
该密钥获取装置1201对应上述方法中的服务器的情况下，该密钥获取装置可以包括 处理器1202、收发器1203和存储器1204。该存储器1204用于存储指令，该处理器1202用于执行该存储器1204存储的指令，以实现如上图9中所示的方法中服务器的相关方案。
当密钥获取装置1201为上述服务器，密钥获取装置1201可以用于执行上述实施例中第一车载设备所执行的方法。
密钥获取装置1201为上述服务器，且执行图9的实施例时：
收发器1203用于接收第一车载设备发送的身份验证请求消息；身份验证请求消息为第一车载设备根据车外设备发送的第一消息和第一车载设备的验证信息生成的；
处理器1202用于根据身份验证请求消息，对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证，生成身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
收发器1203用于向第一车载设备发送身份验证的响应消息。
一种可能的实现方式，收发器1203还用于向第一车载设备发送第一消息；第一消息用于指示第一车载设备生成第一密钥。
一种可能的实现方式，收发器1203还用于向第一车载设备发送第一密钥。
一种可能的实现方式，身份验证请求消息用于指示第一车载设备向车外设备发送第一密钥。
图13为本申请实施例提供的密钥获取装置的示意图，如图13所示，该密钥获取装置1300可以为第一车载设备或服务器，也可以为芯片或电路，比如可设置于第一车载设备或服务器中的芯片或电路。其中，第一车载设备可以为车辆中的任一ECU。
该密钥获取装置可以对应上述方法中的第一车载设备。该密钥获取装置可以实现如上图9中所示的任一项或任多项对应的方法中第一车载设备所执行的步骤。该密钥获取装置可以包括获取单元1301、处理单元1302、发送单元1303和接收单元1304。
当密钥获取装置1300为上述第一车载设备，且实现如上述图9中第一车载设备所执行的步骤时，
接收单元1304，用于接收车外设备发送的第一消息；第一消息用于请求第一车载设备获得第一密钥；接收服务器发送的身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
处理单元1302，用于根据第一消息和第一车载设备的验证信息，生成身份验证请求消息，身份验证请求消息用于服务器对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证。
发送单元1303，用于向服务器发送身份验证请求消息。
一种可能的实现方式，接收单元1304，还用于接收服务器发送的第一消息；第一消息用于指示第一车载设备生成第一密钥；处理单元1302，还用于根据第一消息，生成第一请求消息；第一请求消息用于第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；第一响应消息包括：第一密钥信息；第一密钥信息为对第一密钥加密后生成的。
一种可能的实现方式，接收单元1304，还用于接收服务器发送的第一密钥。
一种可能的实现方式，处理单元1302还用于在身份验证请求消息的验证结果为验证成功时，通过发送单元1303向车外设备发送第一密钥。
当密钥获取装置1300为上述服务器，且实现如上述图9中第一车载设备所执行的步骤时，
接收单元1304，用于接收第一车载设备发送的身份验证请求消息；身份验证请求消息为第一车载设备根据车外设备发送的第一消息和第一车载设备的验证信息生成的；
处理单元1302，用于根据身份验证请求消息，对第一车载设备获得第一密钥的权限和第一车载设备的验证信息进行验证，生成身份验证的响应消息；身份验证的响应消息包括：身份验证请求消息的验证结果。
发送单元1303，用于向第一车载设备发送身份验证的响应消息。
一种可能的实现方式，发送单元1303，还用于向第一车载设备发送第一消息；第一消息用于指示第一车载设备生成第一密钥。
一种可能的实现方式，发送单元1303，还用于向第一车载设备发送第一密钥。
一种可能的实现方式，身份验证请求消息用于指示第一车载设备向车外设备发送第一密钥。
发送单元1303在发送信息时可以为收发单元或发射器，接收单元1304在接收信息时可以为收发单元或接收器，发送单元1303和接收单元1304可以为收发器，此收发器、发射器或接收器可以为射频电路，当密钥获取装置1300包含存储单元时，该存储单元用于存储计算机指令，获取单元或处理单元可以分别与存储单元通信连接，获取单元或处理单元执行存储单元存储的计算机指令，使密钥获取装置可以用于执行上述实施例中任一实施例中第一车载设备或服务器所执行的方法。其中，获取单元或处理单元可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(Application Specific Intergrated Circuit，ASIC)。
当密钥获取装置1300为芯片时，发送单元1303和接收单元1304可以是输入和/或输出接口、管脚或电路等。获取单元或处理单元可执行存储单元存储的计算机执行指令，以使该密钥获取装置1300内的芯片执行实施例中第一车载设备或服务器所执行的方法。可选地，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是密钥获取装置1300内的位于该芯片外部的存储单元，如只读存储器(Read Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)等。
该密钥获取装置1300所涉及的与本申请实施例提供的技术方案相关的概念，解释和详细说明及其他步骤请参见前述方法或其他实施例中关于这些内容的描述，此处不做赘述。
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行图1至图9所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行图1至图9所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种密钥生成系统，其包括前述的第一车载设备、第一安全硬件扩展单元或服务器中的至少两项。
本申请实施例还提供一种车辆，车辆包括至少一个本申请上述实施例提到的待诊断单元，或者车辆包括至少一个本申请上述实施例提到的第一车载设备和第一安全硬件扩展单元。
本申请实施例还提供一种车辆，车辆包括至少一个本申请上述实施例提到的待诊断单 元，或者车辆包括至少一个本申请上述实施例提到的第一车载设备和服务器。
在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在两个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例 的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的保护范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
Claims (22)
- 一种密钥生成方法，其特征在于，应用于车辆，包括：第一车载设备获得第一消息；所述第一消息用于指示所述第一车载设备构建第一密钥；根据所述第一消息，生成第一请求消息；所述第一请求消息用于所述第一车载设备对应的第一安全硬件扩展单元生成第一响应消息；所述第一响应消息包括：第一密钥信息；所述第一密钥信息为对所述第一密钥加密后生成的。
- 如权利要求1所述的方法，其特征在于，所述方法还包括：接收来自所述第一安全硬件扩展单元发送的所述第一响应消息。
- 如权利要求1或2所述的方法，其特征在于，所述方法还包括：接收来自所述第一安全硬件扩展单元发送的所述第一密钥的第一参数；所述第一车载设备根据所述第一密钥的第一参数，生成第一密钥加载消息；所述第一车载设备向第二车载设备发送所述第一密钥加载消息；所述第一密钥加载消息用于所述第二车载设备对所述第一密钥加载消息进行验证成功后，灌装所述第一密钥。
- 如权利要求1-3任一项所述的方法，其特征在于，所述第一车载设备获得第一消息之后，还包括：所述第一车载设备向所述第一安全硬件扩展单元发送状态更新消息；所述状态更新消息包括：车内密钥的构建状态；所述状态更新消息用于所述第一安全硬件扩展单元对所述状态更新消息验证成功后，根据所述状态更新消息更新自身的车内密钥的构建状态。
- 如权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：确定所述第一车载设备重启后，向所述第一安全硬件扩展单元发送第一查询请求；所述第一查询请求用于查询所述第一密钥的第二参数；接收所述第一安全硬件扩展单元发送的第一查询响应消息；所述第一查询响应消息为所述第一安全硬件扩展单元对所述第一查询请求进行验证后返回的；所述第一查询响应消息包括：所述第一密钥的第二参数；根据所述第一消息，生成第一请求消息，包括：根据所述第一密钥的第二参数和所述第一消息，生成所述第一请求消息；所述第一密钥为重启前所述第一安全硬件扩展单元待生成的密钥。
- 如权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：接收来自所述第一安全硬件扩展单元发送的临时密钥；所述临时密钥用于加密所述第一请求消息。
- 如权利要求1-6任一项所述的方法，其特征在于，所述方法还包括：接收第二车载设备发送的第二消息；所述第二消息用于以下至少一项：查询所述第一密钥的第二参数、请求所述第一车载设备生成所述第一密钥或者指示所述第二车载设备重启。
- 如权利要求7所述的方法，其特征在于，所述方法还包括：对所述第二消息进行验证后，向所述第二车载设备发送第三消息；所述第三消息包括以下至少一项：所述第一密钥的第二参数、所述第一密钥信息。
- 一种密钥生成方法，其特征在于，应用于车辆，包括：第一安全硬件扩展单元接收所述第一安全硬件扩展单元对应的第一车载设备发送的第一请求消息；所述第一请求消息为所述第一车载设备用于请求所述第一安全硬件扩展单元构建第一密钥；对所述第一请求消息进行验证成功后，生成第一密钥信息；所述第一密钥信息为对所述第一密钥加密后生成的。
- 如权利要求9所述的方法，其特征在于，所述方法还包括：向所述第一车载设备发送所述第一响应消息；所述第一响应消息包括：第一密钥信息。
- 如权利要求9或10所述的方法，其特征在于，所述方法还包括：对所述第一请求消息进行验证成功后，生成第一密钥的第一参数；向所述第一车载设备发送所述第一密钥的第一参数；所述第一密钥的第一参数用于第二车载设备灌装所述第一密钥。
- 如权利要求9-11任一项所述的方法，其特征在于，所述方法还包括：接收所述第一车载设备发送的状态更新消息；所述状态更新消息包括：车内密钥的构建状态；对所述状态更新消息验证成功后，根据所述状态更新消息更新自身的车内密钥的构建状态。
- 如权利要求9-12任一项所述的方法，其特征在于，所述方法还包括：在所述第一车载设备重启后，接收所述第一车载设备发送的第一查询请求；所述第一查询请求用于查询所述第一密钥的第二参数；对所述第一查询请求进行验证后，向所述第一车载设备发送第一查询响应消息；所述第一查询响应消息包括：所述第一密钥的第二参数；所述第一密钥的第二参数用于所述第一车载设备生成所述第一请求消息；所述第一密钥为重启前所述第一安全硬件扩展单元待生成的密钥。
- 如权利要求9-13任一项所述的方法，其特征在于，所述方法还包括：对所述第一请求消息进行验证成功后，生成临时密钥；向所述第一车载设备发送所述临时密钥；所述临时密钥用于加密所述第一请求消息。
- 如权利要求9-14任一项所述的方法，其特征在于，所述方法还包括：接收来自所述第一车载设备的第二消息的验证消息；所述第二消息为所述第一车载设备接收第二车载设备发送的；所述第二消息用于以下至少一项：查询所述第一密钥的第二参数、请求所述第一车载设备生成所述第一密钥或者指示所述第二车载设备重启。
- 如权利要求15所述的方法，其特征在于，所述方法还包括：对所述第二消息进行验证后，向所述第一车载设备发送第二消息的验证响应消息；所述第二消息的响应消息用于所述第一车载设备向所述第二车载设备发送第三消息；所述第三消息包括以下至少一项：所述第一密钥的第二参数、所述第一密钥信息。
- 一种密钥生成装置，其特征在于，包括：处理器和通信接口，所述通信接口用于接收来自除所述密钥生成装置以外的其它通信装置的信号并传输至处理器或将来自处理器的信号发送给除所述密钥生成装置以外的其它通信装置；所述处理器通过逻辑电路或执行代码指令用于实现如上述权利要求1至8中任一项所述的方法。
- 一种密钥生成装置，其特征在于，包括：处理器和通信接口，所述通信接口用于接 收来自除所述密钥生成装置以外的其它通信装置的信号并传输至处理器或将来自处理器的信号发送给除所述密钥生成装置以外的其它通信装置；所述处理器通过逻辑电路或执行代码指令用于实现如上述权利要求9至16中任一项所述的方法。
- 一种车辆，其特征在于，所述车辆包括第一车载设备和第一安全硬件扩展单元，所述第一车载设备用于实现如权利要求1至8中任一项所述的方法，所述第一安全硬件扩展单元用于实现如权利要求9至16中任一项所述的方法。
- 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序被运行时，实现如上述权利要求1至8中任一项所述的方法、或实现如上述权利要求9至16中任一项所述的方法。
- 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序或指令，当所述计算机程序或指令被密钥生成装置执行时，实现如上述权利要求1至8中任一项所述的方法、或实现如上述权利要求9至16中任一项所述的方法。
- 一种芯片系统，其特征在于，包括：处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行所述存储器中的程序代码，以实现如上述权利要求1至8中任一项所述的方法、或实现如上述权利要求9至16中任一项所述的方法。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2021/095348 WO2022241799A1 (zh) | 2021-05-21 | 2021-05-21 | 一种密钥生成方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117378169A true CN117378169A (zh) | 2024-01-09 |
Family
ID=84140149
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202180098495.4A Pending CN117378169A (zh) | 2021-05-21 | 2021-05-21 | 一种密钥生成方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN117378169A (zh) |
| WO (1) | WO2022241799A1 (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107113167A (zh) * | 2014-12-12 | 2017-08-29 | Kddi株式会社 | 管理装置、密钥生成装置、车辆、维护工具、管理系统、管理方法以及计算机程序 |
| CN108496322A (zh) * | 2016-01-18 | 2018-09-04 | Kddi株式会社 | 车载计算机系统、车辆、密钥生成装置、管理方法、密钥生成方法以及计算机程序 |
| CN109428716A (zh) * | 2017-08-30 | 2019-03-05 | 福特全球技术公司 | 车内组的密钥分配 |
| CN112069502A (zh) * | 2020-07-22 | 2020-12-11 | 延锋伟世通电子科技（上海）有限公司 | 一种用于车载mcu的安全启动方法及装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018100789A1 (ja) * | 2016-11-30 | 2018-06-07 | Kddi株式会社 | 配信システム、鍵生成装置、車載コンピュータ、データ保安装置、配信方法、及びコンピュータプログラム |
| KR102450811B1 (ko) * | 2018-11-26 | 2022-10-05 | 한국전자통신연구원 | 차량 내부 네트워크의 키 관리 시스템 |
| CN111294771A (zh) * | 2018-12-10 | 2020-06-16 | 大陆汽车电子（连云港）有限公司 | 车载设备、用于实现车内通信的系统和相关方法 |
-
2021
- 2021-05-21 WO PCT/CN2021/095348 patent/WO2022241799A1/zh active Application Filing
- 2021-05-21 CN CN202180098495.4A patent/CN117378169A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107113167A (zh) * | 2014-12-12 | 2017-08-29 | Kddi株式会社 | 管理装置、密钥生成装置、车辆、维护工具、管理系统、管理方法以及计算机程序 |
| CN108496322A (zh) * | 2016-01-18 | 2018-09-04 | Kddi株式会社 | 车载计算机系统、车辆、密钥生成装置、管理方法、密钥生成方法以及计算机程序 |
| CN109428716A (zh) * | 2017-08-30 | 2019-03-05 | 福特全球技术公司 | 车内组的密钥分配 |
| CN112069502A (zh) * | 2020-07-22 | 2020-12-11 | 延锋伟世通电子科技（上海）有限公司 | 一种用于车载mcu的安全启动方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2022241799A1 (zh) | 2022-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112585905B (zh) | 一种设备升级方法及相关设备 | |
| Bernardini et al. | Security and privacy in vehicular communications: Challenges and opportunities | |
| EP3780481B1 (en) | Method for upgrading vehicle-mounted device, and related device | |
| EP3319266B1 (en) | Software distribution processing device, vehicle, software distribution processing method, and computer program | |
| CN109314639B (zh) | 管理系统、密钥生成装置、车载计算机、管理方法以及记录介质 | |
| US9577997B2 (en) | Authentication system and authentication method | |
| US9641329B2 (en) | In-vehicle system and communication method | |
| CN112543927B (zh) | 一种设备升级方法及相关设备 | |
| CN111279310A (zh) | 一种车载设备升级方法及相关设备 | |
| JP6178390B2 (ja) | 管理装置、管理システム、車両、管理方法、及びコンピュータプログラム | |
| KR102450811B1 (ko) | 차량 내부 네트워크의 키 관리 시스템 | |
| KR20150074414A (ko) | 펌웨어 업그레이드 방법 및 그 시스템 | |
| JP6190443B2 (ja) | 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム | |
| CN104429042A (zh) | 基于证书的控制单元遥控钥匙配对 | |
| CN113439425B (zh) | 报文传输方法及装置 | |
| CN112153646B (zh) | 认证方法、设备及系统 | |
| JP6192673B2 (ja) | 鍵管理システム、鍵管理方法およびコンピュータプログラム | |
| CN112740212B (zh) | 密钥写入方法及装置 | |
| WO2022160124A1 (zh) | 一种服务授权管理方法及装置 | |
| Ammar et al. | Securing the on-board diagnostics port (obd-ii) in vehicles | |
| US20230318823A1 (en) | Vehicle Diagnostic System, Method, and Apparatus | |
| CN114785532B (zh) | 一种基于双向签名认证的安全芯片通信方法及装置 | |
| WO2023000313A1 (zh) | 一种密钥验证方法及相关装置 | |
| WO2022241799A1 (zh) | 一种密钥生成方法及装置 | |
| WO2024036805A1 (zh) | 通信方法、装置和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |