# CheckOCPP: Automatic OCPP Packet Dissection and Compliance Check

Soumaya Boussaha, Victor Fresno Gómez, Thomas Barber, Daniele Antonioli

► To cite this version:

Soumaya Boussaha, Victor Fresno Gómez, Thomas Barber, Daniele Antonioli. CheckOCPP: Automatic OCPP Packet Dissection and Compliance Check. ACSW 2025, 4th Workshop on Automotive Cyber Security, in conjunction with IEEE EuroS&P 2025, IEEE, Jun 2025, Venice, Italy. hal-05157766

HAL Id: hal-05157766

https://hal.science/hal-05157766v1

Submitted on 11 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# CheckOCPP: Automatic OCPP Packet Dissection and Compliance Check

Soumaya Boussaha

SAP, EURECOM

Biot, France

soumaya.boussaha@sap.com

Thomas Barber

SAP

Baden-Wurtemberg, Germany

thomas.barber@sap.com

Victor Fresno Gómez

EURECOM, UPM

Madrid, Spain

victorfresno@live.com

Daniele Antonioli

EURECOM

Biot, France

daniele.antonioli@eurecom.fr

**Abstract**—As the adoption of electric vehicles (EVs) grows, ensuring compliance and security in EV charging infrastructure is critical. The Open Charge Point Protocol (OCPP) is the de facto standard for communication between EV charging stations and central management systems. However, verifying real-world implementations for protocol adherence and security remains challenging. We introduce CheckOCPP, an OCPP dissector integrated with Wireshark, designed to detect OCPP versions (1.6, 2.0, and 2.0.1), validate message structures against predefined compliant schemas, and flag non-compliant or malformed packets in real-time. CheckOCPP is built using Lua and leverages the Mobility House Python OCPP open-source library. As a dissector, CheckOCPP can be used for compliance verification and security analysis. Our evaluation demonstrates its effectiveness in dissecting and validating OCPP 1.6, 2.0, and 2.0.1 traffic, including detecting non-compliant behaviors against simulated malformed packets and EmonEVSE, an actual charging station.

## 1. Introduction

The Open Charge Point Protocol (OCPP) is the de facto standard for communication between electric vehicles (EVs), charging stations (CSs), often referred to as Charge Points (CPs), and central management systems (CSMSs) [18]. OCPP enables remote monitoring, session control, firmware updates, and billing integration. It allows operators to manage access to CPs, track energy consumption, and apply pricing models. Since its inception in 2009, OCPP has been updated with features and security mechanisms. Most notably, OCPP 1.6 and OCPP 2.0.1 accommodate smart charging and security profiles.

Despite OCPP's widespread adoption, practical challenges remain in achieving and verifying OCPP compliance. Inconsistent or incomplete implementations can lead to security vulnerabilities and unexpected behaviors. Researchers, security analysts, and compliance auditors struggle to pinpoint these issues, especially in production environments, due to the lack of dedicated tools. The existing OCPP Compliance Test Tool (OCTT) [19] is closed-source, accessible behind a cost barrier (€3,000–€18,000 per OCPP version), and requires conducting predefined

active tests against the CS or CSMS. This approach is not best suited for all use cases, including post-deployment audits.

Multiple studies have examined the security landscape of OCPP on production systems, uncovering various threats, including man-in-the-middle (MitM) attacks, replay attacks, message tampering, authentication flaws, and denial-of-service (DoS) [5], [11], [17], [20], [21]. However, no paper has provided dedicated tooling for OCPP traffic dissection, unlike similar protocols with dedicated dissectors (e.g., MQTT [24] and Modbus [23]). OCPP lacks a valuable tool for security assessments, allowing OCPP compliance checks. Ideally, the tool should be passive, i.e., observe OCPP packets flowing in the network or from a pcap and black-box, i.e., work without knowing the internals of the CS or CSMS under test.

To address these concerns, we propose CheckOCPP, an OCPP toolkit designed for dissection, compliance auditing, testing, and security analysis of OCPP implementations. Our tool works in a black-box manner without the need to access CP or CSMS implementations. By dissecting OCPP traffic, CheckOCPP automatically isolates the OCPP versions and packet components, including sensitive data, and evaluates their compliance against a schema.

We tested CheckOCPP against all OCPP versions and popular OCPP implementations. We evaluated a Mobility House [12] based simulation for OCPP 2.0 and 2.0.1. The Mobility House provides an open-source OCPP library for simulating charge point and central system behavior. We tested it against the EmonEVSE [4] CS for OCPP1.6, which is used in production systems. EmonEVSE is an open-source charge controller for electric vehicle supply equipment (EVSE) hardware.

CheckOCPP has proven to accurately dissect and analyze OCPP packets across versions 1.6, 2.0, and 2.0.1. It identified four key issues, including three non-compliant behaviors across different implementations. In the EmonEVSE device [4], a physical charging point used in production environments and implementing OCPP 1.6, CheckOCPP detected a violation where a GetConfiguration request containing a key exceeding the 50-character limit was improperly accepted.

In an OCPP 2.0 setup using a simulated charging
<figure><img src="image_2.png" /><figcaption>Figure 1. EV charging backend eco-system.</figcaption></figure>

station and the Mobility House library [12], it flagged a malformed `BootNotification` message with a 25-character CS model name, exceeding the specification's 20-character limit. A similar simulation environment for OCPP 2.0.1 revealed another compliance issue, where an undefined certificate type was included in an `InstallCertificate` request.

Beyond compliance testing, CheckOCPP also exposed a security concern by successfully extracting sensitive authentication data (`idToken`) in plaintext from a `ReserveNow` message, emphasizing the risks of deploying OCPP systems without TLS encryption.

We summarize our contributions as follows:

* We present CheckOCPP, a novel OCPP toolkit that integrates with Wireshark to dissect, parse, and analyze all OCPP versions.

* CheckOCPP checks message payloads against compliant schema definitions, automatically detecting noncompliant or malformed OCPP packets.

* We validated CheckOCPP in an evaluation against Mobility House (OCPP 2.0 & 2.0.1) [12] and EmonEVSE (OCPP 1.6) [4]. We open-source our tool at https://github.com/vfg27/CheckOCPP.

# 2. Background

This section presents background information about OCPP, Wireshark, OpenEVSE, and IPmininet.

## 2.1. OCPP

The Open Charge Point Protocol (OCPP) [1] is an open communication standard to ensure interoperability between CS and centralized management entities. Centralized management entities typically include charging station operators (CSOs), as in Figure 1, which oversee the deployment, maintenance, and operation of the charging infrastructure. Charging station management systems (CSMSs) provide the software platforms to monitor, control, and optimize charging station performance.

OCPP has three main versions: 1.6, 2.0, and 2.0.1, maintained by the Open Charge Alliance (OCA). OCPP 1.6. [1], [18], introduced in 2015, marked a milestone for OCPP by improving functionality and expanding its applicability across the electric vehicle charging ecosystem. Widely adopted by CS manufacturers and CSMSs, this release introduced key features such as SOAP and JSON support, intelligent charging capabilities for load balancing and profile management, enhanced status updates, and local list management.

In 2020, the whitepaper publication *Improved Security for OCPP 1.6-J* standardized the implementation of advanced security measures inspired by more modern versions of the OCPP. These enhancements include secure connection establishment, security event logging, and secure firmware updates, enabling developers to create robust and secure implementations of OCPP 1.6-J.

OCPP 2.0 [18], released in 2018, was the first in the 2.x series, developed with industry collaboration. For functional specification issues, it was quickly superseded by OCPP 2.0.1 [18], released in 2020. The latter resolves issues in OCPP 2.0, such as incompatible machine-readable schema definition files. Moreover, OCPP 2.0.1 introduces better device and transaction management and strengthened security measures. It also supports ISO 15118 [18], a vehicle-to-grid charging standard.

OCPP defines three security profiles to ensure secure communication [2], [7]. Security Profile 1 represents the basic level, which mandates client (CS) authentication using a password but does not require authenticating the server (CSMS) and encrypting the traffic [2], [7]. Security Profile 2 improves over the prior one by introducing Transport Layer Security (TLS) for channel encryption and server certificate validation for server authentication while using a password for client authentication over a TLS channel [2], [7].

Security Profile 3 employs TLS with client and server certificates to achieve mutual authentication [2], [7]. The CS and CSMS must use TLS v1.2 or higher. ECDHE key agreement is recommended over RSA because it provides forward secrecy. Deprecated or insecure cipher suites shall not be used. TLS compression methods are prohibited to prevent side-channel attacks.

OCPP is based on WebSocket [1], [18], an application layer protocol standardized by the IETF as RFC 6455 [8] in 2011. WebSocket enables full-duplex communication between clients and servers over a single TCP connection. Unlike traditional HTTP, which follows a request-response model, WebSocket allows for bidirectional interactions, facilitating real-time data exchange with reduced latency and overhead. This protocol is particularly beneficial for applications such as electric charging and billing where timely data transmission is crucial.

OCPP packets follow an array format with the following message fields:

* Type: message type (2=Request, 3=Response, 4=Error).

* ID: a unique identifier, typically a random UUID.

* Name: present only for requests.

* Payload: the message data.

## 2.2. Wireshark

Wireshark [9] is a popular open source network protocol analyzer. It enables real-time packet capture, dissection, and inspection. It supports several protocols, such as TCP, UDP, HTTP, and TLS, making it an essential tool for network security research and troubleshooting. By applying filters and analyzing traffic patterns, users can detect anomalies, manage problems, and examine encrypted communications if they have the necessary keys. Wireshark allows the integration of custom dissectors using Lua and currently does not have an OCPP dissector.
<figure><img src="image_3.png" /><figcaption>Figure 2. EmonEVSE WiFi Connected EV Charging Station.</figcaption></figure>

In network traffic analysis, *dissection* refers to systematically breaking down network packets and flows to extract meaningful insights regarding communication patterns, protocols, and potential security threats. A *dissector* is a tool or module to interpret and analyze network protocols, often integrated into traffic analysis frameworks such as Wireshark [23], [24]. These dissectors parse protocol headers, payloads, and metadata, facilitating deep packet inspection (DPI) and anomaly detection.

Wireshark supports dissectors written in Lua [16], a programming language and lightweight scripting engine designed to integrate into applications. Lua's core features include dynamic typing, first-class functions, and versatile table-based data structures. Lua dissectors are more adaptable than those written in C because they are interpreted (other than compiled) and have simpler semantics (comparable to Python).

## 2.3. OpenEVSE

OpenEVSE [4] is an open-source platform offering a CS and mobile application in Figure 2. Developed initially to generate the SAE J1772 pilot signal, it has become a widely used technology in charging stations worldwide, offering scalability and customization for hardware and software. Thanks to its open architecture, OpenEVSE allows manufacturers and developers to create custom charging solutions, from standard products (e.g., EmonEVSE [3]) to DIY kits. Its features include a WiFi module, which facilitates monitoring, control, and integration with home automation systems, HTTP, and MQTT.

## 2.4. IPmininet

IPMininet [22] is an extension of the Mininet [15] network emulator. IPMininet and Mininet are based on Linux containers and allow the emulation of complex (Internet-like) networks using a single Linux kernel. A virtual network includes hosts, switches, controllers, routers, and links. Mininet is compatible with IPv4, while IPMininet extends the compatibility to IPv6.

# 3. Design

In this section, we motivate our work and present the design of CheckOCPP.

## 3.1. Motivation

Several studies have explored the security landscape of OCPP, identifying Vulnerabilities and attacks (e.g., man-in-the-middle (MitM), replay attacks, message tampering, authentication weaknesses, and DoS) [5], [11], [17], [20], [21]. Despite the research on OCPP, there is no OCPP toolkit to dissect, parse, analyze, and check the compliance of OCPP packets.

A toolkit is needed because deployed OCPP versions (1.6, 2.0, and 2.0.1) introduce new packets, schemas, and security features, and they can even co-exist in the same network. Moreover, OCPP is fragmented as not all vendors upgrade their infrastructure uniformly. Vendors also customize OCPP deployment, e.g., by introducing proprietary authentication mechanisms [11], further increasing the presence of non-compliant and vulnerable OCPP deployments.

OCPP packet dissection would enhance security assessments by isolating sensitive information, such as authentication tokens, charging point passwords, and facilitating security testing. Furthermore, packet dissection is already used for other protocols like MQTT [24] and Modbus [23] and has been proven helpful for security and traffic analysis. Thus, adopting an OCPP dedicated dissector for each OCPP version would help tackle the challenges of validating OCPP implementations' compliance and testing their security robustness.

Despite OCPP's popularity, there are no open-source compliance checkers for OCPP. When it comes to verifying OCPP compliance, auditors have the choice of using the OCPP Compliance Test Tool (OCTT) [19], which requires active testing of a set of pre-defined scenarios against CPs and CSMS. However, OCTT is closed-source [19] and comes with a significant paywall of 3000-18000€ per single protocol version. Furthermore, it is unsuited for passive audits, where compliance is assessed without direct interaction with the system under test. A passive audit is beneficial in scenarios where interference with a system is undesirable, such as in production environments.

To address these gaps, we introduce CheckOCPP, a toolkit capable of dissecting OCPP packets regardless of their version, and checking OCPP compliance. The toolkit can work in passive and active modes and does not require prior knowledge of the tested OCPP clients (CSs) and servers (CSMSs).

## 3.2. CheckOCPP

CheckOCPP is an OCCP toolkit with dissection and compliance checking capabilities. The tool can sniff the traffic in a (production) OCPP network and analyze the OCPP packets as shown in Figure 3. To dissect OCPP packets when TLS is in place (security levels two or three [7]), the TLS key is needed first to decrypt the packets before parsing and compliance checking.

CheckOCPP supports the JSON implementation of OCPP, while SOAP support can be added with minimal engineering effort by integrating the XML-based SOAP packet schemas. This choice reflects the industry's preference for JSON, which offers better compatibility with modern frameworks than SOAP.
<figure><img src="image_4.png" /><figcaption>Figure 3. OCPP Communication and CheckOCPP traffic dissection.</figcaption></figure>

**Dissection.** The dissection process is the following: after capturing traffic, CheckOCPP looks first for WebSocket packets, then filters packets with the desired protocol (1.6, 2.0, or 2.0.1) in the WebSocket protocol information. CheckOCPP matches the observed data structure against OCPP-compliant schemas tables, each associated with an OCPP version. The dissector infers the specific OCPP version associated with each packet through this process. Furthermore, it organizes the packet content based on schema in an intuitively accessible way.

**Compliance Check.** CheckOCPP automatically validates the dissected packets against the OCPP specification. In cases where the payload does not align with the predefined schema definitions, CheckOCPP flags the message as non-compliant. It highlights the non-compliant packet and the error concerning the expected compliant schema. To verify compliance, CheckOCPP validates the dissected fields of the packet against the expected up-to-date compliant schema. The compliance verification through the Check-OCPP can be conducted in a passive setup, making it a suitable choice for use cases where no intervention in the traffic is desired.

**Security Analysis.** The tool can be used for active security analysis on the target OCPP network. Once the traffic is dissected, CheckOCPP can change a packet payload on the fly, facilitating attack scenarios such as man-in-the-middle, replay, or injection. This highlights its relevance as a diagnostic tool and a means to assess the impact of insecure deployments.

# 4. Implementation

Next, we describe how we implemented CheckOCPP’s parsing and compliance check logic.

## 4.1. Parsing

We implemented CheckOCPP using Lua [16] and Wireshark’s WebSocket dissector [9]. As shown in Figure 4, the tool loads the OCPP message schemas from the Mobility House library [12]. These schemas are used to check the structure of the dissected packages. The schemas are organized into three distinct tables, corresponding to OCPP versions 1.6, 2.0, and 2.0.1.

<figure><img src="image_5.png" /><figcaption>Figure 4. CheckOCPP diagram.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 5. CheckOCPP deployment for OCPP 1.6 evaluation against the EmonEVSE device.</figcaption></figure>

Since OCPP message payloads are formatted as JSON and Lua lacks native JSON support, the open-source cjson plugin [6] is used to parse the payloads into Lua tables. A Lua table is a structure that represents arrays or dictionaries. The parsed packets include their message type, identifier, message name (if applicable), and the OCPP payload.

## 4.2. Compliance check

CheckOCPP passes the tables containing the parsed OCPP packets to jsonschema [14], an open-source Lua plugin we use to generate OCPP validation functions stored in a separate table. The parsed OCPP payloads are passed through the corresponding validation function, which determines whether they adhere to the expected schema.

As shown in Figure 4, the validation function returns two outputs: Valid or Error. If the payload is Valid, the dissector adds the information to the Wireshark tree and marks the packet compliant. If there is an Error, the error is added to the tree, and the packet is flagged as non-compliant in red as malformed packets using the Expert information dialog [10], a Wireshark-compatible solution to highlight packets for errors and warnings.

# 5. Evaluation

This section presents the evaluation setup and results of CheckOCPP.

## 5.1. Setup

**OCPP 1.6.** We tested a EmonEVSE CS (client) based on OpenEVSE in a lab environment (Figure 5). The CSMS (server) was implemented using the Python-based Mobility House library for OCPP 1.6. This setup evaluated CheckOCPP’s ability to dissect OCPP 1.6 traffic and verify the compliance of the client and server implementations.
<figure><img src="image_7.png" /><figcaption>Figure 6. CheckOCPP deployment for OCPP 2.0.1 evaluation using Mobility House and IP-Mininet.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 7. Non-compliant OCPP 1.6 packet detected in EmonEVSE traffic.</figcaption></figure>

**OCPP 2.0, 2.0.1.** We developed an OCPP emulation scenario using IP-Mininet [22]. The virtual OCPP CSs and CSMSs use the OCPP 2.0 and 2.0.1 implementations from the Mobility House Python library [12] (Figure 6). This setup enabled controlled message exchanges and deliberate injection of malformed packets to test CheckOCPP's compliance-checking capabilities. It also validated the tool's ability to isolate security-sensitive OCPP data.

## 5.2. Results

CheckOCPP successfully identified three non-compliant messages, including an improperly formatted `GetConfiguration` response in OCPP 1.6 for the EmonEVSE device [4]. Next, we describe the experimental results in more detail.

**OCPP 1.6.** Using CheckOCPP, we identified non-compliant OCPP 1.6 behavior in the EmonEVSE charging point. For example, the `GetConfiguration` message, used to retrieve parameters from the CS, requires parameters to adhere to predefined length restrictions under OCPP 1.6. As shown in Figure 7, we queried an artificially crafted variable with an excessively long name exceeding 50 characters. A compliant CS should reject such requests, but the EmonEVSE responded to this invalid query. CheckOCPP captured this exchange and flagged the non-compliant packets.

**OCPP 2.0 and 2.0.1.** We also tested CheckOCPP with OCPP 2.0 traffic. As shown in Figure 8, CheckOCPP correctly identified and parsed OCPP 2.0 packets. We then evaluated CheckOCPP with OCPP 2.0.1, including mixed traffic containing both OCPP 2.0 and 2.0.1 packets (Figure 9). CheckOCPP accurately distinguished between the two protocol versions during analysis.

To test compliance checking, we injected a non-compliant `BootNotification` message with a 25-character CS model name (exceeding the 20-character

<figure><img src="image_9.png" /><figcaption>Figure 8. CheckOCPP analyzing OCPP 2.0 traffic.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9. Mixed OCPP 2.0/2.0.1 traffic analysis using CheckOCPP.</figcaption></figure>

limit). As shown in Figure 10, CheckOCPP flagged this violation by highlighting the packet in red and displaying an error message.

For OCPP 2.0.1, we tested certificate installation using an undefined certificate type. Figure 11 demonstrates CheckOCPP's ability to detect this non-compliance by flagging the malformed packet in red and displaying the error message.

Figure 12 showcases a dissected OCPP `ReserveNow` message sent when a user authenticates to start charging their EV. The figure highlights CheckOCPP's ability to examine and display all application-layer components of the OCPP packet, including sensitive data such as the `idToken` (highlighted in red). This token, often an RFID identifier or credit card number, is used by the CSMS to authorize charging sessions.

This last example highlights CheckOCPP's dissection capability that can facilitate detecting sensitive information in OCPP communication. Malicious authors can use the `idToken` to commit fraud by replicating it. The

<figure><img src="image_11.png" /><figcaption>Figure 10. CheckOCPP detecting non-compliant OCPP 2.0 `BootNotification` message.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>Figure 11. CheckOCPP identifying non-compliant certificate in OCPP 2.0.1 traffic.</figcaption></figure>
<figure><img src="image_13.png" /><figcaption>Figure 12. Isolating user authentication token using CheckOCPP.</figcaption></figure>

<figure><img src="image_14.png" /><figcaption>Figure 13. CheckOCPPiPV4 traffic distinction tested against EmonEVSE device.</figcaption></figure>

OCPP alliance recommends using no encryption for secure networks such as home deployment. However, related work [20] has highlighted that many production charging points do not implement TLS.

## 6. Discussion

Although OCPP does not mandate a specific IP version, IPv6 adoption is growing in the EV charging ecosystem due to its scalability and expanded address space [25]. For example, the IEC 61851-1 standard specifies IPv6-based protocols and power line communication (PLC) for advanced direct current (DC) charging features [25]. Similarly, the IETF documents IPv6 use cases for vehicular networking in Intelligent Transportation Systems (ITS) [13].

To address this trend, we added an IPv4/IPv6 differentiation feature to CheckOCPP. When enabled, IPv4 traffic is flagged in yellow (see Figure 13); this feature can be helpful for systems where IPv6 is required or recommended. Testing CheckOCPP on the OCPP 1.6 setup described in Section 5.2, we observed that the EmonEVSE device uses IPv4 for OCPP 1.6 communications, as shown by the marked packets.

## 7. Related Work

OCTT [19], provided by the OCA, is a cloud-based service designed to validate CS and CSMS against OCPP specifications. It supports predefined test scenarios for OCPP 1.6 and 2.0.1. However, OCTT requires direct interaction with the device under test (e.g., CS or CSMS) and is limited to predefined test sequences, making it unsuitable for real-world deployments. While OCTT ensures thorough protocol conformance testing, it is not designed for network monitoring or passive analysis. Consequently, it is primarily suited for pre-deployment quality assurance (QA) testing.

In contrast, CheckOCPP operates as a dissector for sniffed traffic between CS and CSMS, requiring no active interference with the tested systems. It flags non-compliant packets and enables passive audits. Another key distinction is that CheckOCPP supports all OCPP versions (at the time of writing) and is open-source, whereas OCTT is closed-source and costs between $3,000 to $18,000 per license for a single OCPP version [19]. While we do not claim CheckOCPP can fully substitute OCTT's complex test cases—developed by the OCPP protocol maintainers, we argue that CheckOCPP serves as a complementary solution for post-deployment analysis and security research.

Mobility House [12] is a Python library that enables developers to create advanced, customized charging systems. The library implements OCPP 1.6 (JSON), 2.0, and 2.0.1. Internal schema validation and typed request/response classes promote standards-compliant development and simplify the creation of custom charging applications. While the library performs internal checks for message consistency, it implements the protocol rather than a diagnostic or dissection tool for OCPP [12].

## 8. Conclusion

We present CheckOCPP, a new open-source OCPP toolkit compatible with Wireshark, providing dissection and compliance checking for OCPP and enabling passive real-time analysis of OCPP communications. CheckOCPP automates protocol version detection (OCPP 1.6, 2.0, and 2.0.1), validates message structures against schemas, and flags non-compliant packets. Built using Lua and Mobility House, CheckOCPP allows better OCPP traffic analysis, compliance validation, and security analysis. By open-sourcing CheckOCPP, we provide the community with a valuable tool for auditing OCPP deployments, complementing existing compliance frameworks, and enhancing security analysis.

Our evaluation against Mobility House and IP-Mininet (OCPP 2.0/2.0.1) and the production-grade EmonEVSE (OCPP 1.6) demonstrates CheckOCPP's ability to dissect traffic, detect malformed packets, and uncover compliance gaps in real-world implementations. For example, CheckOCPP identified that EmonEVSE accepts `GetConfiguration` requests with key names exceeding the 50-character limit, a deviation from the OCPP 1.6 specification that could be exploited to conduct an overflow attack.

## Acknoledgments

Work funded by the European Union under grant agreement no. 101070008 (ORSHIN project). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union. Neither the European Union nor the granting authority can be held responsible for them. Moreover, it has been partially supported by the French National Research Agency under the France 2030 label (NF-HiSec ANR-22-PEFT-0009) and the Apricot/ENCOPIA ANR MESRI-BMBF project (ANR-20-CYAL-0001).
## References

[1] What is OCPP?, 2024. ChargeLab.

[2] Ampeco. A Complete Guide to OCPP (Open Charge Point Protocol). https://www.ampeco.com/guides/complete-ocpp-guide/, 2025. Accessed: January 24, 2025.

[3] OpenEVSE authors. EmonEVSE WiFi Connected EV Charging Station (Type-2), 2024. OpenEnergyMonitor.

[4] OpenEVSE authors. OpenEVSE WiFi Kit, 2024. OpenEVSE.

[5] Alessandro Brighente, Mauro Conti, Denis Donadel, Radha Poovendran, Federico Turrin, and Jianying Zhou. Electric Vehicles Security and Privacy: Challenges, Solutions, and Future Needs. arXiv preprint arXiv:2301.04587, 2023.

[6] cjson developer. lua-cjson, 2023. LuaRocks.

[7] Wevo Energy. Open Charge Point Protocol (OCPP) Security Explained. https://wevo.energy/white-papers/open-charge-point-protocol-ocpp-security-explained/, 2025. Accessed: January 24, 2025.

[8] Ian Fette and Alexey Melnikov. The WSocket Protocol. RFC 6455, 2011.

[9] Wireshark Foundation. Wireshark Developer's Guide - Part II. Wireshark Development - Chapter 9. Packet Dissection, 2023. Wireshark.

[10] Wireshark Foundation. Wireshark Expert Information, 2025. Accessed: 2025-01-31.

[11] Zacharenia Garofalaki, Dimitrios Kosmanos, Sotiris Moschoyiannis, Dimitrios Kallergis, and Christos Douligeris. Electric vehicle charging: A survey on the security issues and challenges of the open charge point protocol (OCPP). IEEE Communications Surveys & Tutorials, 24(3):1504-1533, 2022.

[12] Mobility House. Python OCPP: The Mobility House Implementation. https://github.com/mobilityhouse/occpp, 2025. Accessed: Jan. 2025.

[13] Internet Engineering Task Force (IETF). Problem Statement and Use Cases of IPv6-based Vehicular Networking in Intelligent Transportation Systems. https://datatracker.ietf.org/doc/html/rfc c9365, 2025. Accessed: January 25, 2025.

[14] jsonschema developer. jsonschema, 2023. LuaRocks.

[15] Bob Lantz, Brandon Heller, and Nick McKeown. A Network in a Laptop: Rapid Prototyping for Software-Defined Networks. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, pages 1-6. ACM, 2010.

[16] Lua.org. Lua: Powerful, Fast, Lightweight, Embeddable Scripting Language. https://www.lua.org/, 2025. Accessed: January 24, 2025.

[17] Roberto Metere, Zoya Pourmirza, Sara Walker, and Myriam Neaimeh. An Overview of Cyber Security and Privacy on the Electric Vehicle Charging Infrastructure. arXiv preprint arXiv:2209.07842, 2022.

[18] OCA. Open charge point protocol, 2024. OCPP.

[19] Open Charge Alliance. OCPP Test Tools. https://openchargeallianc ce.org/test-tool/, 2025. Accessed: Jan. 2025.

[20] Khaled Sarieddine, Mohammad Ali Sayed, Sadegh Torabi, Ribal Atallah, Danial Jafarigiv, Chadi Assi, and Mourad Debbabi. Uncovering Covert Attacks on EV Charging Infrastructure: How OCPP Backend Vulnerabilities Could Compromise Your System. Preprint, 2024.

[21] Saiflow Research Team. Hijacking Charger's Identifier to Cause DoS, 2023.

[22] Olivier Tilmans et al. IPMininet: A Mininet Extension for Emulating Complex IP Networks. https://github.com/cnp3/ipmininet. Accessed: January 25, 2025.

[23] Wireshark. Modbus Dissector, 2023.

[24] Wireshark. MQTT Dissector, 2023.

[25] Wolfspeed. What's Under the Hood: EV Chargers - A Tale of Standards and Many Connectors. https://www.wolfspeed.com/knowledge-center/article/whats-under-the-hood-ev-chargers-a-tale-of- f-standards-and-many-connectors/, 2025. Accessed: January 25, 2025.

## Appendix

<table><caption>TABLE 1. CHECKOCPP OCPP MESSAGE COMPATIBILITY</caption><thead><tr><td>Message</td><td>Version</td></tr></thead><tbody><tr><td>Heartbeat</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>BootNotification</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td> Authorize</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>StatusNotification</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>TransactionEvent</td><td>2.0, 2.0.1</td></tr><tr><td>Reset</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td> MeterValues</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>CancelReservation</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>ReserveNow</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>ClearCache</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>ChangeAvailability</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>ClearChargingProfile</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>DataTransfer</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>SendLocalList</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>SetChargingProfile</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>TriggerMessage</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>UnlockConnector</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>UpdateFirmware</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>SignCertificate</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>InstallCertificate</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>CertificateSigned</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>DeleteCertificate</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>GetLog</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>LogStatusNotification</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>SecurityEventNotification</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>GetInstalledCertificateIds</td><td>1.6, 2.0, 2.0.1</td></tr><tr><td>ChangeConfiguration</td><td>1.6</td></tr><tr><td>GetConfiguration</td><td>1.6</td></tr><tr><td>GetDiagnostics</td><td>1.6</td></tr><tr><td>RemoteStartTransaction</td><td>1.6</td></tr><tr><td>RemoteStopTransaction</td><td>1.6</td></tr><tr><td>StartTransaction</td><td>1.6</td></tr><tr><td>StopTransaction</td><td>1.6</td></tr><tr><td>DiagnosticsStatusNotification</td><td>1.6</td></tr><tr><td>ExtendedTriggerMessage</td><td>1.6</td></tr><tr><td>SignedFirmwareStatusNotification</td><td>1.6</td></tr><tr><td>SignedUpdateFirmware</td><td>1.6</td></tr><tr><td>TransactionEvent</td><td>2.0, 2.0.1</td></tr><tr><td>RequestStartTransaction</td><td>2.0, 2.0.1</td></tr><tr><td>RequestStopTransaction</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyChargingLimit</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyEVChargingSchedule</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyEVChargingNeeds</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyDisplayMessages</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyCustomerInformation</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyMonitoringReport</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyReport</td><td>2.0, 2.0.1</td></tr><tr><td>SetVariables</td><td>2.0, 2.0.1</td></tr><tr><td>GetVariables</td><td>2.0, 2.0.1</td></tr><tr><td>SetNetworkProfile</td><td>2.0, 2.0.1</td></tr><tr><td>GetReport</td><td>2.0, 2.0.1</td></tr><tr><td>GetBaseReport</td><td>2.0, 2.0.1</td></tr><tr><td>GetMonitoringReport</td><td>2.0, 2.0.1</td></tr><tr><td>GetChargingProfiles</td><td>2.0, 2.0.1</td></tr><tr><td>ReportChargingProfiles</td><td>2.0, 2.0.1</td></tr><tr><td>PublishFirmware</td><td>2.0, 2.0.1</td></tr><tr><td>UnpublishFirmware</td><td>2.0, 2.0.1</td></tr><tr><td>CostUpdated</td><td>2.0, 2.0.1</td></tr><tr><td>GetCertificateStatus</td><td>2.0, 2.0.1</td></tr><tr><td>Get15118EVCertificate</td><td>2.0, 2.0.1</td></tr><tr><td>ClearDisplayMessage</td><td>2.0, 2.0.1</td></tr><tr><td>GetDisplayMessages</td><td>2.0, 2.0.1</td></tr><tr><td>SetMonitoringBase</td><td>2.0, 2.0.1</td></tr></tbody></table>
<table><tr><td>PublishFirmwareStatusNotification</td><td>2.0, 2.0.1</td></tr><tr><td>SetDisplayMessage</td><td>2.0, 2.0.1</td></tr><tr><td>SetMonitoringLevel</td><td>2.0, 2.0.1</td></tr><tr><td>SetVariableMonitoring</td><td>2.0, 2.0.1</td></tr><tr><td>ClearVariableMonitoring</td><td>2.0, 2.0.1</td></tr><tr><td>ClearedChargingLimit</td><td>2.0, 2.0.1</td></tr><tr><td>CustomerInformation</td><td>2.0, 2.0.1</td></tr><tr><td>NotifyEvent</td><td>2.0, 2.0.1</td></tr><tr><td>GetTransactionStatus</td><td>2.0, 2.0.1</td></tr></table>