quinnwencn
commented
7 months ago This only solves the authentication problem. When to use this service and how to use it is still a todo.
Open quinnwencn opened 7 months ago
quinnwencn
commented
7 months ago This only solves the authentication problem. When to use this service and how to use it is still a todo.
Background
UDS(Unified Diagnostic Services) is an automotive protocol that enables the tester to communicate with the ECUs in the vehicle to diagnose faults, change configure, or even reprogram the ECUs. But unauthenticated access to the ECUs is extremely dangerous and can cause important information leakage or even worse.
According to the test results during 2022, the number of critical findings in UDS security implementation, is commonly high, mainly in the following UDS services: memory unauthorized access, DTC, and ECU reset.
In order to prevent Vehicle from unauthenticated access, access control to the vehicle diagnostic system is necessary.
Authentication method
UDS 29
UDS 29 service provides two means for the client to prove its identity, allowing it to access data or diagnostic services to the ECU.
UDS 29 APCE
There are two ways to authenticate the diagnostic session using APCE, “verifyCertificateUnidirectional” and “verifyCertificateBidirectional”. In the case of unidirectional authentication, only the tester’s certificate is verified. In the case of bidirectional authentication, certificates of the tester and ECU are verified.
Authentication process:
UDS 29 ACR
Authentication with the Challenge-Response process can be completed by symmetric cryptography or asymmetric cryptography, and the keys used in ACR should be filled on the production line.
In the case of using asymmetric cryptography, a client pair is required: the client private key shall be present in the client and the client public key shall be present in the server. In the case of Bidirectional authentication, which is strongly recommended, a server key pair is also required. The server private is present in the server, and the server public key is present in the client. The private keys MUST stored in HSM/SE/TEE, in case of private key leakage.
In the case of symmetric cryptography, a symmetric key is required to exist in both client and server.
Below is the process of authentication:
The POWN calculation and verification refers to IEC 9798-2.
UDS 27 Secure access
How to access Level 7
Key calculate algorithm: AES-128-CBC
Seed: 32 bytes random value(16 bytes)
After accessing level 7, we can enable the tester to execute commands in blacklists, but what if the tester request ECU reset, then the permissions to execute commands in blacklists will lose again. So we need to add a switch to remember the access granted action and keep the permissions until we end it. DID is used to solve this problem.
We use a DID or secure param as flag to indicate the permission of executing commands in blacklist. If the flag is disabled, then testers are not allowed to execute any command in blacklist. We use routine control to control the flag.
Routine control is not in the blacklist, we need to add an additional action to protect the specific routine from unauthenticated access.
When enable the flag, the time parameter indicates how long should the flag stands, which effects the time window of permission to the UDS commands in blacklist. For instance, the time could be set to 2 hours with an accuracy of 10 minutes.