Over the years, due to rising need to curb greenhouse gas emissions, countries across the world have developed regulations, standards, and infrastructure for Electric vehicles (EV) as an alternative to conventional vehicles. The vehicle-to-grid (V2G) technology has been evolving rapidly owing to demands for reduced emissions and clean energy. The V2G communication involves communication between the electric vehicle (EV), the supply equipment (SE) or charging station and the grid. It also involves the process of billing for the amount of energy supplied by the SE to the EV. This demands two-way communication for the exchange of information from EV to charging station and vice versa. Therefore, there is a growing concern over the security involved in the process of charging of an EV.
In V2G systems, exchange of information between EV and SE is essential in order to meet the charging requirements of the EV. The communication between the two needs to be protected against cyber-attacks. Confidentiality of the data communication between EV and SE needs to be maintained and identities of SE and EV must be assured during the communication. If SE wrongly identifies EV or if SE receives incorrect charging information from a malicious source, then the charging requirements of the EV may not be met. Utmost care should be taken for maintaining integrity of data between EV and SE. Data communication is a crucial part of V2G system. Therefore, its availability must be ensured.
The above-mentioned security requirements have been taken care of in various standards for V2G communication. However, no system is fully secure and must be constantly tested for vulnerabilities. Adopting security checks during the development cycle reduces risk of cyber-attacks.
Figure 1 : Figure 1 : Automotive cybersecurity V model
It is very important to incorporate cybersecurity checks and processes at every phase of a development cycle. The figure above depicts the V model for the same. Development process always begins with analysis of requirements and architectures and is followed by the design phase. During these phases the process of security analysis should be performed. The advantage of performing security assessment at these phases is that all the security requirements in terms of hardware, software and resources will be known at the beginning of the process, thus, minimizing the cost of rework in future. During implementation and integration phase, all the security requirement suggested in security assessment phase shall be implemented. Fuzz testing should be performed to find out unknown vulnerabilities. Penetration testing can be carried out post implementation and integration phase in order to validate security assessment results.
In this article we would like to introduce and demonstrate two major types of attacks- denial of service (DoS) attack and the man in the middle (MITM) sniffing attack on a V2G set-up. Following are the assumptions made:
Assumptions
Set-up to perform attack
For this experiment, an open source V2G stack was deployed and 2 microcontrollers-one to simulate an EV and the other to simulate an SE, were selected. The two microcontrollers are connected to a router via Ethernet cable. Next, we selected a suitable network traffic monitoring- and a python-based tool, capable of manipulating network traffic and made appropriate configurations on the attacker node for performing attacks. Afterwards the attacker node was brought onto the same network as the EV and SE.
Penetration test build-up
The V2G communication in our set up is based on Ethernet and the communication between EV and SE is IP-based. Therefore, we focused on the IPv6 and ICMP protocols to identify protocol level vulnerabilities to build up MITM sniffing attack and DOS attack.
Man–in-the-middle sniffing attack:
A man-in-the-middle attack is a form of eavesdropping, where communication between two users is monitored and/or modified by an unauthorized party. In the process, the two authorized parties appear to communicate normally. The transmitter does not recognize that the receiver is an attacker or an unauthorized party, trying to access or modify message before retransmitting to the receiver. We have performed a man-in-the- middle sniffing attack, where the traffic between the EV and the charging station was captured.
The attacker node sends a neighbor solicitation packet to the electric vehicle, pretending to be charging station by using the IP address of the charging station as shown in Figure 2
Figure 2 : Attacker sends a unicast neighbor advertisement to EVCC
The EV sees the solicitation message coming from the charging station (which is actually coming from attacker node). The attacker sends its own MAC address in the source link-layer in a neighbor solicitation message to the EV. This makes the EV think that it is the MAC address of the charging station and therefore EV will update this MAC to its cache.
Due to this, traffic from EV to the charging station will go through the attacker node as shown in Figure 3 . On the attacker node, we observe the traffic on a network monitoring tool. These messages were monitored to find a suitable message/stage in the communication that can be exploited for further attack.
Figure 3 : IPv6 traffic flow- Man in the middle sniffing
Denial of service attack:
A denial-of-service attack is a security event, in which an attacker prevents a legitimate user from using services. The DoS attack performed by us has deprived the customer of charging the EV.
For performing the DoS attack, an invalid MAC address (not used in the network) in the neighbor solicitation message as shown in Figure 4 , was sent. (add reference to the figure)
Figure 4 : Attacker sends a unicast neighbour advertisement to EVCC
Due to this, the message has an invalid destination or no destination within the network and as a result, messages from EV will not reach the charging station. Figure 5 shows the effect of DOS attack on the communication flow during charging process.
Figure 5 : IPv6 traffic flow- Man in the middle sniffing
Detailed security assessment and penetration testing can prevent these types of attacks. If all the security checks were performed on the experimental set-up above, the vulnerability can be identified at the earlier stages by performing security assessment in the design phase (in this case experimental set-up) and can be validated in the penetration testing phase. We at KPIT have a complete process set up for incorporating various security checks at various stages of automotive system development. These security measures include security assessment, penetration testing, fuzz testing and HSM based security services into the development cycle of automotive systems and vehicular communication including V2V, V2I and V2G.
SME – Automotive Cybersecurity
KPIT Technologies
Software Engineer – Automotive Cybersecurity
KPIT Technologies
Likes
Likes
Bleiben Sie mit uns in Verbindung
KPIT Technologies is a global partner to the automotive and Mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 13000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and Mobility and is present where the ecosystem is transforming.
Grundstück Nummer-17,
Rajiv Gandhi Infotech Park,
MIDC-SEZ, Phase-III,
Hinjawadi, Pune – 411057
Telefon: +91 20 6770 6000
Frankfurter Ring 105b,80807
München, Deutschland
Telefon: +49 89 3229 9660
Telefax: +49 89 3229 9669 99
KPIT und das KPIT-Logo sind eingetragene Warenzeichen | © Copyright KPIT for 2018-2024
CIN: L74999PN2018PLC174192
Plätzchen | Dauer | Beschreibung |
---|---|---|
cookielawinfo-checkbox-analytics | 11 Monate | Dieses Cookie wird vom GDPR Cookie Consent Plugin gesetzt. Das Cookie wird verwendet, um die Benutzereinwilligung für die Cookies in der Kategorie "Analytics" zu speichern. |
cookielawinfo-checkbox-funktional | 11 Monate | Das Cookie wird von GDPR Cookie Consent gesetzt, um die Benutzereinwilligung für die Cookies in der Kategorie "Funktional" aufzuzeichnen. |
cookielawinfo-checkbox-andere | 11 Monate | Dieses Cookie wird vom GDPR Cookie Consent Plugin gesetzt. Das Cookie wird verwendet, um die Benutzereinwilligung für die Cookies in der Kategorie „Sonstiges“ zu speichern. |
cookielawinfo-checkbox-erforderlich | 11 Monate | Dieses Cookie wird vom GDPR Cookie Consent Plugin gesetzt. Die Cookies werden verwendet, um die Benutzereinwilligung für die Cookies in der Kategorie „Notwendig“ zu speichern. |
cookielawinfo-checkbox-performance | 11 Monate | Dieses Cookie wird vom GDPR Cookie Consent Plugin gesetzt. Das Cookie wird verwendet, um die Benutzereinwilligung für die Cookies in der Kategorie "Performance" zu speichern. |
angesehene_cookie_richtlinie | 11 Monate | Das Cookie wird vom GDPR Cookie Consent Plugin gesetzt und wird verwendet, um zu speichern, ob der Benutzer der Verwendung von Cookies zugestimmt hat oder nicht. Es speichert keine personenbezogenen Daten. |
Schreibe einen Kommentar