The use of this site and the content contained therein is governed by the Terms of Use. When you use this site you acknowledge that you have read the Terms of Use and that you accept and will be bound by the terms hereof and such terms as may be modified from time to time.
All text, graphics, audio, design and other works on the site are the copyrighted works of nasscom unless otherwise indicated. All rights reserved.
Content on the site is for personal use only and may be downloaded provided the material is kept intact and there is no violation of the copyrights, trademarks, and other proprietary rights. Any alteration of the material or use of the material contained in the site for any other purpose is a violation of the copyright of nasscom and / or its affiliates or associates or of its third-party information providers. This material cannot be copied, reproduced, republished, uploaded, posted, transmitted or distributed in any way for non-personal use without obtaining the prior permission from nasscom.
The nasscom Members login is for the reference of only registered nasscom Member Companies.
nasscom reserves the right to modify the terms of use of any service without any liability. nasscom reserves the right to take all measures necessary to prevent access to any service or termination of service if the terms of use are not complied with or are contravened or there is any violation of copyright, trademark or other proprietary right.
From time to time nasscom may supplement these terms of use with additional terms pertaining to specific content (additional terms). Such additional terms are hereby incorporated by reference into these Terms of Use.
Disclaimer
The Company information provided on the nasscom web site is as per data collected by companies. nasscom is not liable on the authenticity of such data.
nasscom has exercised due diligence in checking the correctness and authenticity of the information contained in the site, but nasscom or any of its affiliates or associates or employees shall not be in any way responsible for any loss or damage that may arise to any person from any inadvertent error in the information contained in this site. The information from or through this site is provided "as is" and all warranties express or implied of any kind, regarding any matter pertaining to any service or channel, including without limitation the implied warranties of merchantability, fitness for a particular purpose, and non-infringement are disclaimed. nasscom and its affiliates and associates shall not be liable, at any time, for any failure of performance, error, omission, interruption, deletion, defect, delay in operation or transmission, computer virus, communications line failure, theft or destruction or unauthorised access to, alteration of, or use of information contained on the site. No representations, warranties or guarantees whatsoever are made as to the accuracy, adequacy, reliability, completeness, suitability or applicability of the information to a particular situation.
nasscom or its affiliates or associates or its employees do not provide any judgments or warranty in respect of the authenticity or correctness of the content of other services or sites to which links are provided. A link to another service or site is not an endorsement of any products or services on such site or the site.
The content provided is for information purposes alone and does not substitute for specific advice whether investment, legal, taxation or otherwise. nasscom disclaims all liability for damages caused by use of content on the site.
All responsibility and liability for any damages caused by downloading of any data is disclaimed.
nasscom reserves the right to modify, suspend / cancel, or discontinue any or all sections, or service at any time without notice.
For any grievances under the Information Technology Act 2000, please get in touch with Grievance Officer, Mr. Anirban Mandal at data-query@nasscom.in.
One of the biggest challenges faced by OEMs today is automotive cybersecurity with the amount of hardware and software integrated into vehicles increasing significantly over the last few decades. There can be as many as 100 ECUs embedded in modern vehicles. That, along with increase in communication options, has greatly increased the number of vulnerabilities that hackers can exploit.
The need for automotive cybersecurity eventually led the International Organisation of Standardization (ISO) along with Society of Automotive Engineers (SAE) have come up with the ISO 21434 standard ‘Road vehicles – Cybersecurity Engineering’ in 2021.
In this blog, we will explore further the major security risks in an ECU and the measures that can be taken to prevent such threats in the following sections. We will also see in detail the different security concepts that can be used to prevent such threats strictly from an implementation point of view. However, we will not be discussing the cybersecurity processes in this blog.
What are the major threats for an ECU?
Listed below are a few of the major ways in which hackers can exploit ECUs:
Compromising In-vehicle communication – Communication in modern vehicles is handled by multiple interfaces like CAN, K-Line, Ethernet, etc. Hackers exploit such networks using various intrusion methods. For example, sniffing – which includes intercepting and logging data from a network. Another way in which hackers can exploit vehicle networks is by spoofing, i.e., by pretending to be another legitimate node in the network. These kinds of attacks can be of two types: masquerade attacks, where data is inserted that corrupt the network and replay attacks, where the “pretend” node replays data which was sent by another node in a previous iteration.
Gaining unauthorized access to vehicle – Modern vehicles all have on On-Board Diagnostics (OBD) and OBD ports that can communicate with the ECUs via CAN network and get diagnostic information regarding the faults in the vehicle and performance characteristics. Hackers can gain access to these ports and inject data & malicious code into the network.
Tampering ECU firmware & rogue updates – Attackers can modify ECU memory and change the security keys which are used for software authentication. They can reflash the ECU with their custom firmware and manipulate its state and perform unintended actions. They could also introduce malware and take control of the firmware.
Preventive Measures
For protecting against the above-mentioned threats, certain cryptographic algorithms need to be implemented to encrypt the data transmitted in vehicle networks, for securing access to vehicle diagnostics, authenticating the software flashed etc. There are basically two ways of implementing these cryptographic algorithms: traditional software-based implementation & implementation with usage of additional hardware components. We will see in the upcoming sections on how the two implementations can be done in an AUTOSAR ECU.
AUTOSAR provides the Crypto Stack for facilitating the traditional software-based implementation. Crypto Stack offers standardized access to cryptographic services like computation of hashes, asymmetrical signature verification, symmetric encryption of data etc.
The stack is divided into 3 layers – service layer, hardware abstraction layer and driver layer. The topmost layer, i.e., the service layer acts as an interface between Application & the lower layers of the stack. It is responsible for scheduling and queueing the received crypto service requests based on their priority. It forwards the requests to the lower layers for further operations.
The abstraction layer receives the crypto service requests from the service layer and forwards them to appropriate cryptographic operation in the driver layer. The lower most layer i.e., the crypto driver holds the actual cryptographic implementations and supports key configuration, key storage, etc. In traditional implementation, the driver layer is a cryptographic software library which supports various services including hash services & pseudo random number generator.
Fig 2: Data flow in AUTOSAR Crypto Stack
Let us consider a scenario where an application component inside a car must send a message to another software component but this message must be secured. In this case, the application component will pass on the message to the service layer. This service layer distributes the service request to the appropriate queue. Let’s assume that the message must be encrypted before sending to the next application component. The service layer will add the required information along with the message and will send it to the hardware abstraction layer. The hardware abstraction layer will identify to which driver it should be passed so that the required cryptographic action (viz. encryption here) can be performed. In our example, the message is encrypted using the appropriate encryption algorithm. After encryption, the message is sent back to the hardware abstraction layer which in turn sends it to the service layer from which it is sent to the required application component.
Hardware and Software Based Implementations
The cryptographic algorithms can be implemented with a combination of hardware and software as well. Hardware Security Module (HSM) and Secure Hardware Extensions (SHE) are examples of hardware components that can be used along with the AUTOSAR Crypto stack to facilitate cryptographic services.
Fig 3: The HSM Concept
The main advantage of using a hardware component like HSM compared to a purely software-based implementation is that it can provide a dedicated secure space for security applications like core, secure memory and hardware accelerators. The secure space can:
Provide security services to the application
Store keys and related security assets
Manage keys and certificates
Execute cryptographic algorithms using hardware/software implementations
There are stacks provided by third party vendors like Vector, ETAS, Elektrobit etc., for hardware components like HSM which are designed in a more modular and flexible way. This makes it easier to integrate the stack with the AUTOSAR environment. HSM provides many security services like storage of security assets and cryptographic algorithms. Let us see in detail how a hardware component like HSM can be used along with AUTOSAR Crypto Stack to implement cryptographic services.
HSM firmware consists of specific modules as well as standardized AUTOSAR modules. HSM firmware consists of Crypto modules which correspond to the AUTOSAR Crypto Stack, with service layer, hardware abstraction layer and driver layer. The HSM core uses inter processor communication interface (IPC) for communicating with the Host core which runs the application components and the AUTOSAR Crypto Stack.
Now let us consider the previous scenario where an application component inside a car must send a secured message to another software component.
Fig 4: Data & service flow of Crypto operations
At the Host side, as with the traditional implementation, the application component will pass on the message to the Crypto stack. The functionality of the Crypto stack remains the same as explained in the previous traditional software-based implementation. The major difference is that the information on the cryptographic algorithms that can be performed, the keys that should be used for encryption etc., is defined by HSM settings and this information is passed to the Host with the help of a specific HSM configuration file. So, the configurations in Host Crypto stack will correspond to this information. Additionally, information on IPC settings like version and number of channels are also passed to the Host with the help of the configuration file. Also in this implementation, the Crypto driver layer just acts as an interface to HSM and provides the IPC communication.
At the HSM side, the crypto service request (viz. encryption here) received from the IPC channel is forwarded to the Crypto hardware abstraction layer. It dispatches the request to the crypto driver which performs the cryptographic algorithm for encryption. Buffers are allocated for the driver in global RAM to store all the input and output data for the requested crypto operation. The access rights for this RAM section are configurable based on the security needs. When the crypto operation is finished, the host modules are notified via interrupt/polling mechanism. The output of the cryptographic algorithm is read back by the Host Crypto driver layer via IPC and is forwarded to the higher layers.
Conclusion
ECUs in modern vehicles present a wide range of vulnerabilities that hackers can exploit, potentially resulting in harm to drivers and pedestrians. Growing standardization in ECU components and software development undertaken by groups like AUTOSAR has increased the level of protection against such threats, but still much remains to be done to completely secure them against hacking. It is high time that the vehicle manufacturers consider cybersecurity with priority and make it a critical part of the safety infrastructure.
Cybersecurity is a key focus area for Ignitarium; our capabilities include security platform bring up, security stack integration, secure boot, secure diagnostics etc.
Look out for the next article in this blog series for understanding more about the usage of the Crypto software stack.
That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.
Introduction to functional safety
Functional safety is a vital discipline in engineering, focusing on ensuring system safety in areas impacting human safety or the environment. It aims to prevent or minimize the consequences of system failures,…
Self-driving or autonomous cars have been considered as the future of driving for a long time. Fully autonomous vehicles operating in mixed traffic will soon become a reality in the foreseeable future. According to Statista, in 2019, there were…
Need for Higher level of Validation
As design complexity is increasing, the goal of 100% functional coverage becomes harder to achieve even after using constrained random stimulus and directed scenarios, therefore there is a need to adopt new…
The evolving landscape of managed IT services is shaped by emerging technologies and trends that are redefining how businesses manage and optimize their IT operations. This blog explores the key trends in managed IT services and the strategic…
Localization is the process of determining a mobile robot’s location in relation to its surroundings. Let’s imagine that the area has been mapped out and that the robot has sensors to both monitor its surroundings and gauge its own mobility. Using…
On 04 July 2024, as part of the Nasscom Insights team, I had the privilege of visiting LTIMindtree's Mhape office in Mumbai to experience IgnAIte. The event was a dynamic gathering where LTIMindtrees’ subject matter experts showcased a range of…
