Federated detection of open charge point protocol 1.6 cyberattacks

1.1.1. FL for cybersecurity

Mothukuri et al.^[8] propose a privacy-focused FL approach for Internet of Things (IoT). Each IoT device trains a Gate Recurrent Unit (GRU) model using its local data, and sends the parameters to a central FL server that aggregates them and sends the updated weights to each IoT device. As a result, the accuracy of each model increases, while the data of each IoT device remains private. The authors evaluate the performance of their solution by using a public dataset based on Modbus TCP, which is processed by CICFlowMeter to extract the features that the AI models can use to classify the attacks. According to the evaluation results, the proposed FL approach achieves 90.2% accuracy, showcasing 4.1% improvement on accuracy compared to the non FL approach.

In ^[9], Rashid et al. introduce a dynamic weighted aggregation federated learning (DAFL), a new aggregation technique that implements dynamic filtering and weighting strategies for local models. The proposed method improves the performance of conventional FL-based IDS in terms of communication overhead, while maintaining high detection accuracy and preserving data privacy.

In ^[10], Idrissi et al. propose the Federated Anomaly-Based Network Intrusion Detection System (Fed-ANIDS), which employs auto-encoders and FL in a distributed manner. The proposed architecture further employs two aggregation methods, FedProx and FedAvg. The proposed system is evaluated using numerous public datasets, namely the $$ \texttt{USTC-TFC2016} $$, $$ \texttt{CIC-IDS2017} $$, and $$ \texttt{CSE-CIC-IDS2018} $$ datasets, which use an updated version of $$ \texttt{CICFlowMeter} $$ that improves the construction of network flows. The proposed solution is also compared with Generative Adversarial Network (GAN) models, and the results indicated a better detection performance, in terms of higher accuracy and fewer false alarms. In addition, the results showcased that FedProx delivered better results than FedAvg.

Karunamurthy et al.^[11] introduce a deep learning FL-based IDS for IoT environments. In the proposed architecture, the local models in the remote IoT environments leverage Convolutional Neural Networks (CNNs) with different parameter settings. Furthermore, an optimal feature selection model resides on the federated aggregation server, based on the Chimp optimization method. Inspired by the behavior of chimps in their natural environment, the feature selection model applies a fitness function to select the most optimal features, which are given as input to the deep learning classifier. The proposed model is evaluated on an MQTT protocol dataset, which includes five different attacks. The proposed method achieves 93.3% recall, 94% F1 score and 95.5% accuracy.

Finally, Radoglou-Grammatikis et al.^[12] present a multimodal FL-based IDS, called AI4FIDS, which is able to analyze four different data types, namely system logs, operational data, network flow statistics, and visual representations, in order to detect potential anomalies or indication of cyberattacks in the critical infrastructure. Combining the multiple detection methods, AI4FIDS includes a majority voting and a weighted majority method aggregate the predictions of the multiple underlying models in order to generate a single, combined prediction.

1.1.2. Detection of OCPP cyberattacks

Moreover, several works have been identified, which describe OCPP threats and try to address their detection. In more detail, Morosan et al.^[13] propose a Back-Propagation Neural Network (BPNN) that is able to classify EVCSs between the normal and faulted states, based on the OCPP 1.5-J traffic they generate. The three-layered neural network was able to determine a faulty EVCS based a) on the similarity of consecutive pairs of request-response, and b) the OCPP message type from the server. In a similar approach in ^[14], Kabir et al. propose a BPNN utilized by the EVCSMS to analyze the OCPP requests and detect potential malicious attempts of coordinated switching attacks, i.e., charging/discharging and back again within a very short time period.

Girdhar et al.^[15] aim to predict and mitigate cyberattacks against EVCSs; therefore, they propose a cybersecurity framework that predicts and mitigates potential cyberattacks. In particular, the authors employ the STRIDE thread modeling to predict potential vulnerabilities and attack vectors on EVCSs, then a weighted attack defense tree is developed to analyze the adversary's objectives and create attack scenarios. A Hidden Markov Model is proposed in order to predict the possible attack paths, while a Partially Observable Monte-Carlo Planning (POMCP) algorithm ensures that the attacker is directed toward the predicted paths, ensuring that mitigation actions are timely placed to reduce the impact of the attack. While the proposed method can predict the attacker's behavior in multi-step attack scenarios, the problem on how to classify the individual behavior as malicious is not addressed.

Elkashlan et al.^[16] utilize the $$ \texttt{IoT-23} $$ dataset in order to demonstrate the detection of cyberattacks against EVCSs. The authors employ various machine learning algorithms to detect malicious traffic that could be associated with threats against EVCSs, including Command and Control server communication, DDoS attacks, traces of the Okiru botnet, and samples of a horizontal port scan. The authors discussed the features of the dataset and removed those that presented weak correlation, hence choosing 14 out of 21 features. The authors get results in terms of Precision, Accuracy, Recall and F-1 scores, by comparing four classifiers: The Naive Bayes, the J48 classifier, the attribute-select classifier, and the filtered classifier. However, the proposed methodology did not address EVCS-specific attacks, while the authors highlight the necessity of building a dedicated dataset for EVCSs.

The $$ \texttt{DataTransfer} $$ operation of OCPP is utilized by some works in order to implement custom security logic, extending the capabilities of OCPP 1.6. In particular, Rubio et al.^[17] aim to ensure the confidentiality and integrity of the energy values exchanged during charging transactions, by using $$ \texttt{DataTransfer} $$ messages to enable the EVCSMS to exchange secrets with the EVCS. After exchanging secrets, different cryptographic mechanisms can be applied to securely exchange energy values through $$ \texttt{meterValue} $$ and $$ \texttt{meterStop} $$ messages. Kim et al.^[18] also utilize $$ \texttt{DataTransfer} $$ to provide security services, in particular, for implementing a rollback mechanism on the EVCSs, thus mitigating the impact of potential threats such as replay attacks, maliciously modified requests and unauthorized activities.

Benfarhat et al.^[19] leverage deep learning and propose a temporal convolutional network (TCN) in order to classify up to 17 different cyberattacks against the ISO-15118 and OCPP protocols, as they are introduced in the CICEVSE2024 dataset ^[20]. According to the authors, the proposed model provides benefits in terms of representing temporal dependencies and spatial characteristics, thus being able to detect complex patterns. The authors evaluate their solution by measuring accuracy, precision, recall and F1-score metrics, while comparing the results with CNN, DNN, RNN and LSTM models as well as a hybrid CNN-DNN-LSTM model. Three experiments are conducted, while considering two classes, five classes and 17 classes, respectively. In the binary and 5-class classification experiments, all metrics reach 100%. On the contrary, when considering 17 classes, the TCN achieves 93% in all metrics. Despite the large number of classes considered by the authors, it is noteworthy that the attacks considered exhibit common attack vectors of the network and transport layer, such as network scanning with the nmap tool and TCP/UDP flooding variants, which are already addressed by other solutions considering IoT-based DDoS attack detection ^[21].

Rahman et al.^[22] evaluate a hybrid architecture of CNN and LSTM networks to detect the attacks of the CICEVSE2024 dataset. To enhance the detection performance as well as to increase the understanding of the dataset and attack patterns, the authors apply the SHAP explainability method to obtain results on the features that contributed mostly on the detection outcomes. It is worth mentioning that the selected features are related solely to transport-layer characteristics, such as the average packet inter-arrival time in network flows. The evaluation results indicate high performance, achieving accuracy, precision, recall and F1 score at 97.5% and Area Under Curve (AUC) at 98.5%.

Finally, Purohit et al.^[23] propose an FL-based IDS for detecting cyberattacks against the EVCS infrastructure. Similar to ^[19] and ^[22], the authors utilize the CICEVSE2024 dataset in order to evaluate the performance of their solution, achieving an accuracy of around 97% and superior F1-score compared to centralized AI-based IDS that use the CICEVSE2024 dataset.

Summarizing, multiple works have been identified that aim to develop AI-based solutions for detecting attacks in IoT and EVCS setups. However, it is noteworthy that most of the existing work^{[16, 19, 20, 22, 23]} employs a similar methodology of detecting OCPP attacks by analyzing network flow features stemming from the network and transport layers of the TCP/IP stack, for example those generated by CICFlowMeter^[24] and NFStream². However, this approach is not sufficient for detecting threats that rely on application-layer characteristics, while the network and transport layers remain agnostic. Moreover, the threat model considered by the aforementioned works and the CICEVSE2024 dataset focus mostly on common IoT threats rather than on OCPP-specific attack scenarios.

²https://www.nfstream.org/

2.2.1. Charging profile manipulation

Normal operation: The $$ \texttt{SetChargingProfile.req} $$ message is an OCPP 1.6 operation that is used by the EVCSMS to install charging profiles to EVCSs. A charging profile describes the amount of power or current that an EVCS is allowed to deliver per time interval. According to the OCPP 1.6 specification, this operation can be issued either in the context of a charging transaction (i.e., at the start or during the transaction) or outside the context of a transaction, as a separate message ^[25]. The $$ \texttt{SetChargingProfile.req} $$ message includes a $$ \texttt{csChargingProfiles} $$ object, which defines the charging schedule. Multiple time intervals are defined as separate items inside the $$ \texttt{chargingSchedulePeriod} $$ list. The example provided in Figure 3 describes a $$ \texttt{SetChargingProfile.req} $$ that installs a charging profile, which instructs connector 1 of an EVCS to draw at most $$ 15A $$ on 2024-05-12, from 13:51:54 to 15:51:54.

Figure 3. Example of a SetChargingProfile.req message.

As a powerful and flexible operation, $$ \texttt{SetChargingProfile.req} $$ is used to implement smart charging scenarios and apply complex charging patterns to EVCSs. Moreover, it can also be leveraged by system operators (i.e., DSOs and TSOs), in combination with openADR ^[26], for ancillary services, e.g., to reduce peak demands or to avoid a predicted load surge ^[27].

Threat: Given its criticality for the above-mentioned reasons, an erroneous or maliciously altered charging profile could have significant cyber-physical impact to the power grid. For example, a CSO may have introduced charging profiles as a safety measure to avoid overloading and stressing of legacy electrical infrastructure, including old electric cables or unmaintained transformers. In that case, false charging profiles may lead to stressing of the electrical infrastructure and potential malfunctions. More sophisticated attacks are also possible, e.g., a coordinated oscillatory load attack that could manipulate the load following an on/off pattern, causing system frequency fluctuations that can threaten the grid stability ^[27].

Cyberattack: The Charging Profile Manipulation attack we consider in this work assumes that a cyberattacker performs MiTM, through ARP poisoning, followed by FDI that modifies the $$ \texttt{SetChargingProfile.req} $$ messages being transmitted from the EVCSMS to the EVCSs. For each incoming $$ \texttt{SetChargingProfile.req} $$ message, the attacker replaces the value of the limit attribute of all $$ \texttt{chargingSchedulePeriod} $$ objects with a higher number. As a result, the affected EVCS is able to draw more power than originally configured by the CSO.

Observation: The Charging Profile Manipulation FDI could be detected by inspecting the $$ \texttt{limit} $$ values of the transmitted charging profiles. Based on the characteristics of the EV charging infrastructure and the targeted EVCS, there are reasonable values that are expected to be set in this field. By profiling this attribute and getting the baseline from benign traffic, it would be possible for a CSO to detect an abnormal charging profile.

2.2.2. Denial of charge

Normal operation: Figure 4 describes the procedure to remotely start a transaction and the authorization process before starting a charging session. To start a charging transaction, the EV user through the mobile app will trigger EVCSMS to send a $$ \texttt{RemoteStartTransaction.req} $$ message. If the $$ \texttt{AuthorizeRemoteTxRequests} $$ configuration variable is activated on the EVCS, the EVCS will try to authorize the identity of the EV user ($$ \texttt{idTag} $$) via an $$ \texttt{Authorize.req} $$ message. Assuming that the presented identity is valid, the EVCS will receive a positive $$ \texttt{Authorize.conf} $$ response and will start the transaction procedure by sending a $$ \texttt{StartTransaction.req} $$ message. The EVCS will start providing power upon receiving a $$ \texttt{StartTransaction.conf} $$ with $$ \texttt{idTagInfo.status = Accepted} $$ from the EVCSMS. Similarly, the transaction can be stopped by the EV user by triggering a $$ \texttt{RemoteStopTransaction.req} $$ message ^[25].

Figure 4. The authorization of charging transactions in OCPP 1.6.

Threat: By observing the authorization procedure, a denial of service (in particular, a denial of charge) situation could happen if the authentication information, which is private information, is tampered with. In particular, if the $$ \texttt{idTag} $$ information is altered during transmission, this will lead to failure of authorization, thus preventing the EVCS from starting the charging transaction.

Cyberattack: We consider a denial of charge attack, in which a cyberattacker performs MiTM, through ARP poisoning, followed by FDI that replaces the $$ \texttt{idTag} $$ info included in any $$ \texttt{RemoteStartTransaction} $$ message with a random value. If $$ \texttt{AuthorizeRemoteTxRequests} $$ on the EVCS is enabled, the EVCS will send an $$ \texttt{Authorize.req} $$ message with the $$ \texttt{idTag} $$ injected by the attacker, leading to an $$ \texttt{Authorize.conf} $$ response with $$ \texttt{idTagInfo.status = Invalid} $$. If $$ \texttt{AuthorizeRemoteTxRequests} $$ is not enabled on the EVCS, the authorization will still fail, since the EVCSMS will send a $$ \texttt{StartTransaction.conf} $$ with $$ \texttt{idTagInfo.status = Invalid} $$.

Observation: Considering that the CSO prefers to minimize the messages transmitted from/to the EVCS, it is reasonable to assume that, normally, an EVCSMS will never send a $$ \texttt{RemoteStartTransaction.req} $$ with an invalid $$ \texttt{idTag} $$, since the EVCSMS has already the capacity to validate an $$ \texttt{idTag} $$ in the first place. Hence, observing a $$ \texttt{RemoteStartTransaction.req} $$ followed by a $$ \texttt{StartTransaction.conf} $$ or an $$ \texttt{Authorize.conf} $$ message with $$ \texttt{idTagInfo.status = Invalid} $$, would be an indication of a malformed $$ \texttt{RemoteStartTransaction.req} $$.

2.2.3. Heartbeat flood

Normal operation: Figure 5 depicts an overview of the procedure for establishing an OCPP 1.6 session over WebSocket (OCPP 1.6-J) between an EVCS and the EVCSMS ^[28]. The procedure is initiated by the CSO engineer, which configures the EVCS through an out-of-band management method, usually via Bluetooth and a dedicated mobile app provided by the EVCS manufacturer. The engineer specifies the Unique Resource Identifier (URL) that the EVCS must use to register to the EVCSMS. Upon applying this configuration, the EVCS sends a HyperText Transport Protocol (HTTP) GET request, incorporating the unique ID of the EVCS at the end of the URL as well as the appropriate HTTP headers that request session upgrade to WebSocket. If the EVCSMS accepts the EVCSMS, it will send an HTTP 101 Switching Protocols response, which signals the EVCS to immediately start sending OCPP 1.6-J messages, starting with the $$ \texttt{BootNotification.req} $$. Depending on the value of the $$ \texttt{HeartbeatInterval} $$ configuration variable of the EVCS and the $$ \texttt{interval} $$ parameter of the $$ \texttt{BootNotification.conf} $$ response of the EVCSMS (which can override the $$ \texttt{HeartbeatInterval} $$), the EVCS sends periodic $$ \texttt{Heartbeat.req} $$ messages to the EVCSMS in order to get the current date and time from the EVCSMS. Moreover, this message is useful for the EVCSMS to ensure that the EVCS is still online.

Figure 5. The establishment of an OCPP 1.6-J session over WebSocket.

Threat: While the Heartbeat interval can be indicated by the EVCSMS via the $$ \texttt{BootNotification.conf} $$ response, right after the OCPP 1.6-J session establishment, a malicious or misconfigured EVCS might not respect this interval, thus sending very frequent Heartbeat messages. Alternatively, in a MiTM situation, an attacker could modify the $$ \texttt{interval} $$ attribute of the $$ \texttt{BootNotification.conf} $$ messages, thus forcing the EVCSs to send very frequent Heartbeat messages. Regardless of the method, the high volume of Heartbeat messages may threaten the availability of the EVCSMS.

Cyberattack: In this attack scenario, we assume that the attacker deploys a botnet of multiple virtual EVCSs, which concurrently attempt to establish OCPP 1.6-J sessions with the targeted EVCSMS. Assuming that the EVCSMS is not configured to authorize each EVCS or that the bots use valid IDs, all connections are accepted. After this step, the bots flood the EVCSMS with $$ \texttt{Heartbeat.req} $$ messages, leading to resource exhaustion and service unavailability for the EVCSMS. For example, such flooding could lead to reaching maximum database connections internally in the EVCSMS, causing unavailability of other critical services provided by the EVCSMS. Moreover, the computing resources could be overutilized (including Central Processing Unit (CPU) cycles and network bandwidth), leading to overall system performance degradation.

Observation: In contrast to the FDI attacks, someone could notice the traces of this attack also at the Transmission Control Protocol (TCP) / Internet Protocol (IP) layer. In particular, an unusually high number of packets will be noticed per TCP session. Moreover, at the application layer, the CSO would notice an unusually high number of Heartbeat messages per EVCS.

2.2.4. Unauthorized access

Normal operation: As an alternative flow depicted in Figure 5, and according to the OCPP 1.6-J specification ^[28], if an EVCS session establishment attempt is not accepted, then the EVCSMS should reply with an "HTTP 404 - Not Found" response.

Threat: If the EVCSMS does not apply any throttling policy, an overwhelming amount of connection attempts may cause exhaustion of computing resources and degradation of system performance. Moreover, an attacker could perform an enumeration attack by trying to "guess" valid EVCS IDs.

Cyberattack: Similarly to the Heartbeat Flood attack, in this attack scenario we assume that the attacker deploys a botnet of multiple virtual EVCSs, which concurrently attempt to establish OCPP 1.6-J sessions with the targeted EVCSMS. However, in this variation of the attack, the targeted EVCSMS is appropriately configured in order to reject connection attempts from unknown EVCSs. Hence, the EVCS responds to each bot with an HTTP 404 message, leading to wastage of computing resources and possible performance degradation due to over-utilization of computing and network resources.

Observation: At the TCP/IP layer, this attack would generate an unusually high number of short-lived TCP sessions finished by TCP packets having the FIN flag activated. Moreover, at the application layer, this attack would generate an unusually high number of HTTP 404 messages, clearly indicating failed connection attempts from WebSocket clients.

2.3.1. Network traffic capturing module

First, the Network Traffic Capturing Module is responsible for capturing the network traffic data, using a Switched Port Analyzer (SPAN) (i.e., port mirroring) of the local network switch. SPAN allows the FL-based IDS to monitor and capture the traffic data passing through specific ports of the network switch, where the EVCSs are connected. In the context of SPAN, the monitoring source and destination ports should be defined. Next, all incoming and outgoing traffic data from the monitoring sources are copied/mirrored to the destination port. Next, the Network Traffic Capturing Module uses $$ \texttt{tcpdump} $$ in order to capture the mirrored network traffic data.

2.3.2. Network flow extraction module

The Network Flow Extraction Module is composed of a set of flow statistics/features generators that receive the network traffic data (i.e., PCAP file) from the previous module and produces bi-directional flow statistics/features. For this purpose, we use two flow generators, namely (a) the $$ \texttt{CICFlowMeter} $$^[24] tool; (b) the $$ \texttt{OCPPFlowMeter} $$.

$$ \mathbf{\texttt{OCPPFlowMeter}} $$: It is a custom tool, introduced in this work, that generates additional flow statistics focusing on the OCPP 1.6 protocol characteristics. The complete list of the $$ \texttt{OCPPFlowMeter} $$ features can be found in Table 1. Compared to $$ \texttt{CICFlowMeter} $$, which provides statistics only for the IP and TCP network layers, $$ \texttt{OCPPFlowMeter} $$ can effectively be used to detect both flooding and FDI attacks. Some of the features of the $$ \texttt{OCPPFlowMeter} $$ are influenced by the cyberattack observation described for each cyberattack in Section 2.2. Adopting the $$ \texttt{CICFlowMeter} $$ approach, the $$ \texttt{OCPPFlowMeter} $$ groups packets based on a pre-defined flow timeout of 120 seconds, and calculates statistics by parsing the payload of the OCPP 1.6 messages and the WebSocket and HTTP headers.

2.3.3. Local prediction engine

Upon completing the FL process, each participating client obtains a local copy of the final global model from the server, during the final FL round. This model is then independently deployed on the client's infrastructure (e.g., devices, on-premise servers, virtual machines, or cloud-based systems) to perform real-time inference. As such, the Local Prediction Engine consists of a set of federated detection models that are generated by the Training Module. As input, it receives the flow statistics/features from the previous module and applies the corresponding federated detection models. The Local Prediction Engine model is trained with TCP/IP flow statistics/features from $$ \texttt{CICFlowMeter} $$ and OCPP 1.6 statistics from the $$ \texttt{OCPPFlowMeter} $$. In case of a detected cyberattack, the Response Module generates the corresponding security event.

2.3.4. Response module

Based on the detection results, the Response Module is responsible for generating the corresponding security events. The security event is delivered to the configured SIEM using the $$ \texttt{rsyslog} $$ protocol.

2.3.5. Training module

The Training Module consists of two components: (a) Federated Server (Fed Server) and (b) Federated Client(s) (Fed Clients). On the one hand, the Federated Server is responsible for coordinating the FL process and managing the communication between the Federated Clients. It aggregates the locally trained models from the Federated Clients and updates the global model. It also handles the management of resources and data privacy. On the other hand, a Federated Client is responsible for training the AI models on the local data and communicating the trained models to the Federated Server. It also handles the pre-processing and post-processing of the data and the management of the local resources. It is placed on the EV charging hubs to enable the use of the local data for training the models and to ensure the privacy and security of the EV charging data. For the implementation of the Training Module, $$ \texttt{Flower} $$ and $$ \texttt{FedTree} $$ were utilized. Moreover, various aggregation techniques were investigated, such as FedAvg ^[29], FedProx ^[30], FedAdam ^[31], FedAdagrad ^[31], FedYogi ^[31] and FedTree ^[32]. Although detailed descriptions of these techniques are available in their respective references, we outline their main characteristics below. FedAvg is the standard FL aggregation strategy. It works by averaging the model weights from the clients after each local training round and updating the global model accordingly. FedProx extends FedAvg by adding a proximal term in the local objective to limit the deviation of local models from the global model. It is suitable for handling non-independent and identically distributed (non-iid) data among clients. Moreover, FedAdam applies adaptive learning rates by using first and second moment estimates of gradients, FedAdagrad adjusts learning rates based on historical information, and FedYogi maintains stable model updates by controlling the growth of second-moment estimates. These methods focus on providing training stability. Finally, FedTree is designed for decision tree-based models.