Click on the blue text above Talk Lab

to get more automotive cybersecurity news

This article discusses the CCC digital key protocol specification from the perspective of vehicle BLE, aiming to facilitate a better understanding of the CCC protocol. The content is relatively friendly for those with a basic understanding of BLE. Some knowledge of Bluetooth specifications may be involved; if unclear, please refer to the corresponding official Bluetooth documentation.

For BLE, the CCC protocol is divided into several phases: Phase 0, 1, 2, 3, and 4. This article categorizes the entire process into the following parts: Phase 0/1, Bluetooth connection, Phase 2, OOB pairing, UWB ranging, Phase 3, and Phase 4. The overall process is shown in the figure below.

Preparation phase, in which the mobile device, vehicle, and vehicle server need to prepare their respective items.

Initiation phase, where the mobile device accepts the password in the following ways to start the OP process.

1. Through user input.

2. By redirecting to the wallet via URL (see section 6.3.7).

3. Through an app developed by the vehicle OEM.

First, in the CCC protocol, broadcasting is divided into OP and PE, both of which use RPA addresses.

In the PE phase, the vehicle’s broadcast should be based on LE 1M PHY. The corresponding broadcast period should be 42.5ms. For this broadcast, ADV_IND should contain AdvA but not broadcast data (AdvData).

During the OP process, enabling OP broadcasting facilitates the mobile device to scan and initiate a connection. The OP broadcast format is shown in the figure below.

For the vehicle side, in addition to configuring this broadcast format, it also needs to configure the corresponding services. The service format is shown in the figure below.

The purpose of configuring this service is to determine the L2CAP layer’s SPSM during data exchange through the L2CAP layer.

The entire Bluetooth connection is divided into two parts, the first part is shown in the figure below. The vehicle side enables OP broadcasting, and the mobile device goes through phase 0 and 1 before entering the OP process. At this point, the mobile device scans the broadcast for CCC_DK_UUID to establish an LL layer connection with the vehicle.

The second part of the process is as follows: the mobile device detects the vehicle broadcast service and SPSM characteristic value to obtain specific values (in actual testing, the SPSM I used was 0x0083). The mobile device then initiates an L2CAP Connect Request. In this data packet, the SPSM is the previously read SPSM characteristic value from the service.

The figure shows the air data captured by Sniffer during the actual testing process.

In this data format, the LE Protocol/Service Multiplexer is the previously set SPSM. This value is specified in the BLUETOOTH SPECIFICATION Version 5.0, indicating that this parameter is divided into two ranges, as shown in the figure.

The first range is specified by Bluetooth SIG, ranging from 0 to 0x007F (as shown in the figure, with BLE using CID highlighted). The second range is dynamically changing, specifically designed in conjunction with services to complete the corresponding protocol. This is also why the SPSM was set to 0x0083 when configuring the broadcast service feature (you can try other values).

So far, for BLE, the LL layer connection and L2CAP layer connection have been established. The subsequent data exchanges in this phase are based on the L2CAP layer, using the selected 0x0083 channel for interaction. More knowledge about the L2CAP layer in Bluetooth will be introduced in subsequent articles. For the CCC protocol, the current reserves are sufficient.

After the Bluetooth connection process ends, the mobile device will send the Request_owner_pairing command. The air data is as follows.

After the mobile device sends the Request_owner_pairing command, it enters Phase 2. This phase is divided into two transactions, mainly for data exchange with the Digital Key Framework (The DK framework AID: A000000809434343444B467631h), including some data required for unlocking the vehicle from the mobile device. The specific process is as follows.

Since the CCC protocol does not provide a detailed flowchart for BLE, the flowchart for the Phase 2 process is introduced using NFC. In the figure, NFC will experience a field reset operation, and after resetting, it needs to select the AID again. For BLE, however, there is no need to reset and thus no need to select the AID again.

The figure shows the air data for Phase 2.

In the official Bluetooth specification, OOB generally refers to using out-of-band methods (non-BLE, such as NFC) to exchange pairing information. In the CCC protocol, it is specified that pairing information is exchanged through the data channel established in the previous L2CAP layer. Before starting OOB pairing in the CCC protocol, OOB preparation work is required to exchange the pairing parameters needed by both parties to pave the way for subsequent OOB pairing. The specific OOB preparation process is shown in the figure below.

The main interactive parameters are as follows:

BTAddrA/BTAddrB: Address of master/slave devices

ra/rb: Random numbers of master/slave devices

Ca/Cb: Encryption numbers calculated by the master/slave devices through Pka, ra and Pkb, rb respectively.

The above information is exchanged through First_Approach_RQ/First_Approach_RS events.

After the preparation work is completed, the normal pairing process can begin. The specific process is as follows.

This part is similar to the general BLE pairing process, with only minor details differing.

After the Phase 2 stage ends, the next step is to perform UWB ranging. The flowchart for this stage is as follows.

As shown, the first step requires a standard transaction process. After the standard transaction process is completed, URSK needs to be generated, and the pseudocode for URSK is as follows.

When generating URSK, a transaction_identifier data is also included.

After generating URSK, parameter interactions are needed to measure distance, mainly divided into three steps.

6.1 Capability Exchange (Ranging Capability Exchange)

The specific process is as follows.

The figure shows the data format interacted during capability exchange.

6.2 Ranging Session (Ranging Session)

The specific process is as follows.

The figure shows the data format interacted during the ranging session.

6.3 Ranging_Session_Setup (Ranging Session Setup)

The specific process is as follows.

Tips: The parameters in the red box are all necessary parameters for actual UWB ranging. Once UWB locates inside the vehicle, the next phase can be initiated.

Phase 3 is somewhat similar to Phase 2, requiring a standard transaction process. However, in Phase 3, data exchange mainly occurs with the Digital Key applet (The DK applet AID: A000000809434343444B417631h). The specific process is as follows.

All operations prior to (and including) this phase are in offline mode. Once Phase 3 ends, the vehicle card in the mobile wallet can also be unlocked. As for the subsequent Phase 4, it is online mode, requiring interaction with the OEM server.

Source: CSDN@Worker Reserve

Original link:

https://blog.csdn.net/weixin_46186672/article/details/143713331

New Power Vehicle Enterprises:

Tesla, Hozon Auto – Nezha, Li Auto, Zeekr, Xiaomi, Benz Automotive, Jiyue, Leap Motor, Avita Automotive, Zhiji Automotive, Xiaopeng, Lantu Automotive, NIO, Geely, Seres……

Foreign Traditional Mainstream Automakers:

Volkswagen China, Volkswagen Coolwing, Audi, BMW, Ford, Daimler-Benz, General Motors, Porsche, Volvo, Hyundai, Nissan, Jaguar Land Rover, Scania……

Domestic Traditional Mainstream Automakers:

Geely, SAIC Passenger Cars, Great Wall Motors, SAIC Volkswagen, Changan, Beijing Automotive, Dongfeng, GAC, BYD, FAW Group, FAW Liberation, Dongfeng Commercial, SAIC Commercial……

Global Leading Tier 1 Suppliers:

Bosch, Continental, Unic Automotive Electronics, Aptiv, ZF, KOSTAL, Schaeffler, Honeywell, DJI, Hitachi, Harman, Huawei, Baidu, Lenovo, MediaTek, Preh, Desay SV, Hella, Wuhan Guangting, Xingji Meizu, CRRC Group, Wintech, Weichai Group, Horizon, Unisoc, ByteDance,……

Tier 2 Suppliers (500+):

Upstream, ETAS, Synopsys, NXP, TUV, Shanghai Software Center, Deloitte, Qihoo 360, Cloud Chasing Future, Xinda Jiexin, Xinchangcheng, Zelu Security, New Creation Security, Fudan Microelectronics, Tianrongxin, Qihoo 360, China Automotive Center, China Automotive Research, Shanghai Automotive Inspection, Soft Security Technology, Zhejiang University……

More Articles

Don’t miss out, this could be the largest exclusive community in the automotive cybersecurity industry!

Lawyer’s statement regarding the alleged imitation of the AutoSec conference brand

One article to help you understand the onboard network communication security architecture of smart vehicles

Cybersecurity: TARA Methods, Tools, and Cases

Key Analysis of Automotive Data Security Compliance

Analysis of Automotive Chip Information Security and Secure Boot

Exploration of Automotive Onboard Communication Security Solutions in Domain-Centralized Architecture

System Security Architecture of Vehicle Network Security Architecture

Privacy Protection Issues in the Internet of Vehicles

Research on Cybersecurity Technologies for Smart Connected Vehicles

AUTOSAR Information Security Framework and Key Technology Analysis

What information security mechanisms does AUTOSAR have?

Underlying Mechanisms of Information Security

Automotive Cybersecurity

Use of AUTOSAR Hardware Security Module HSM

First release! Lei Jun from Xiaomi suggested at the two sessions regarding automotive data security: Suggestions on building a comprehensive automotive data security management system