Testing cyber security functionality uniformly when outsourcing implementation

Cyber security threats are increasing rapidly as the Autotech industry becomes more connected and digitalized. To avoid unauthorized access to the ECUs (Electronic Control Unit) in a vehicle, advanced cyber security functionality is required. This includes e.g. authentication and encryption/decryption of data sent to and from the ECUs.

In the Autotech industry today much of the implementation of the software in the ECUs are outsourced to different Tier 1’s. As this technology tends to be increasingly advanced, it is important that there is no discrepancy in the interpretations of the specifications for the cyber security concepts to be implemented. As the functionality is implemented a vast amount of testing is required to ensure the correct behaviour from each ECU in the vehicle.

But how to ensure that the testing is correct?

As of today, a lot of different tools for testing ECUs are available. If the cyber security functionality is not implemented for a specific tool used by a Tier 1, it must be implemented by the Tier 1 itself. This means that the same faulty interpretations will be made both in the implementation of on-board software and in the test tool, which will later be found in the testing on the OEM side. As the implementation project approaches the end of its lifecycle, the cost of finding issues increases a lot![1]

Diadrom’s approach to this problem is to implement the functionality in a Dynamic-link library (DLL) which can be shared between different testing tools and different projects.

Example: Security Access

One functionality commonly implemented in the automotive industry is the UDS service Security Access, used to unlock protected functionality in an ECU. This functionality includes implementation of a seed-key algorithm, which differs from OEM to OEM.

To test the implementation of this, a DLL including the seed-key algorithm is provided for all test tools used in the development chain.

In the DLL, the following functions would be available:

• CreateSecurityAccessRequestSeedMessage()
• VerifyServerResponseSeed()
• CreateSecurityAccessSendKeyMessage()
• VerifyServerSendKey()

Conclusion

A lot of testing is required during software implementation projects in the Autotech industry. But even if the testing is conducted, it is equally important to test the correct behaviours. I think that the approach described in this article would minimize the risk of different interpretations of specifications during the implementation of software for ECU’s. This would ease the work of the developers and reduce the headaches and costly updates needed when finding out that the implementation was not done according to what was expected after it has been delivered to the end-customer.

Would you like to know more about how Diadrom’s solutions and software could help improve the software development? Please contact Jonas Hellberg, jonas.hellberg@diadrom.se or/and Viktor Eliasson, viktor.eliasson@diadrom.se 

Kind Regards

Author: Jonas Hellberg, Head of Product Development,+46 739 80 65 90, jonas.hellberg@diadrom.se

Co-author: Viktor Eliasson, VP Sales, +46733 31 11 15, viktor.eliasson@diadrom.se

[1] Brown, M et al. (2020) “A new management science for technology product delivery”, McKinsey.com, pp. 3 [accessed: 2020-06-02]