[DoCAN] Vehicle Diagnostic Communication Part 52 [UDS 13]

Click here for back issues.
https://www.simulationroom999.com/blog/diagnostic-communication-en-back-issue/

Introduction.
Concept of SecurityAccess service
SecurityAccess Service Buying Time
Conclusion

Introduction.

Explanation of ISO 14229, the UDS.
The concept of the SecurityAccess service will be explained in this article.

Concept of SecurityAccess service

In the last issue, I explained the message structure of the SecurityAccess service.
However, the message structure alone may not give you a clear picture of the service.
Therefore, in this article, I would like to explain the concept of the SecurityAccess service.

In fact, not only the SecurityAccess service, but also the DiagnosticSessionControl service I explained before it, are related to the SecurityAccess service.
ISO 14229-1 specifies that the SecurityAccess service is not supported in default sessions.
Therefore, it is necessary to at least transition to extendedDiagnosticSession.
(It’s supposed to be security-related, which makes it more work…)

It would seem that if it were defined by ISO, it would not be security.
Certainly, that would be true if security is interpreted as “completely preventing”.
However, it is impossible to “completely prevent” any security.

Therefore, the security concept of vehicle diagnostic communication becomes “security = making it troublesome to break through”.
Simply put, it is like reducing the number of attempts versus time.
In other words, either reduce the number of attempts or increase the time per attempt.

However, is it possible to increase the time by just one session transfer?
Session transfer alone does not make much difference.
The communication will increase, so against a brute force attack, the time will be doubled.

That means there is another way to buy time.

SecurityAccess Service Buying Time

In addition to session movement, there are two other time-buying tricks

SecurityAccess service is enabled n seconds after IGon.
If the SecurityAccess service makes a mistake in deactivation, the deactivation will not be accepted for m seconds.

How long is this n seconds or m seconds actually?

ISO14229-1 does not define a specific number.
The predecessor standard is ISO14230-3 (KWP2000), which defines that the time until the release becomes effective after IGon is turned on is 10 seconds.
Therefore, the 10-second period is often used in accordance with that time.
The pattern of the release miss is often that it does not return until the IGoff is turned off once.

The release miss should originally be a time rule, not an IGoff rule.
However, if a specification for recovery by time monitoring is included, design, implementation, and verification will increase by itself.
If that is the case, it would be easier to make the system unusable indefinitely once a mistake is made.
And it is more secure, too.
This is the reason why “no return until IGoff is done” is easily adopted.

In summary, the attacker will be subject to the following cycle.

(1) IGon
(2) Wait 10 seconds
(3) Transfer the session
(4) Security unlocking
(5) IGoff
(6) Return to (1).

From the attacker’s point of view, waiting for 10 seconds in (2) and IGoff in (5) are troublesome.

This troublesome process is the strength of security in vehicle diagnostic communication.
Well, it would be more secure to prevent unlocking after three mistakes, but since there is also the work involved in restoring the system, IGoff is probably a good place to start.

So, in this article, there was a lot of talk about the backstage of the automobile industry.

Conclusion

The SecurityAccess service is purposely troublesome procedure, which is the security strength.
- Must transition to non-defaultSession in advance.
- Must wait 10 seconds after IGon.
- If you make a mistake unlocking, you have to IGoff once.

Click here for back issues.