Possible Non-Compliance with OCPP Specification Regarding Unique Message IDs

[Tano-Coppoletta]

Checklist

• I checked other issues already, but found no answer/solution
• I checked the documentation and wiki, but found no answer/solution
• I am running the latest version and the issue still occurs
• I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0
Operating system  : Ubuntu 22.04.1
JDK               : openjdk version "11.0.20.1"
Database          : version 1.0.3

Issue Description

According to the OCPP specification, each CALL message's ID must be unique and not reused within the same WebSocket connection. However, during testing, it was possible to send multiple messages using the same message ID without any rejection by the server.

Steps to Reproduce

1. Establish a WebSocket connection to the Steve OCPP server.
2. Send multiple OCPP CALL messages using the same message ID.
3. Observe that the server accepts and processes these messages without enforcing the uniqueness of message IDs.

Expected Behavior

The server should enforce the OCPP specification by checking the uniqueness of the message ID for each CALL message and reject any messages with a duplicate message ID.

Actual Behavior

The server processes messages with duplicate message IDs, which is against the OCPP specification and could lead to message tracking issues or misinterpretation of message responses.

Potential Impact

This behavior could cause confusion in message correlation, response handling, and could potentially impact the transactional integrity of the communication between charging stations and the central system.

Suggested Solution

Implement a check on the server to ensure message IDs are unique for each CALL message on the same WebSocket connection and reject any messages that violate this rule.

Compliance Reference

Please refer to section 4.1.4 of the OCPP JSON 1.6 documentation that states the requirement for message ID uniqueness.

[PratikVpel]

I agree with this, i've faced a same issue

[Tano-Coppoletta]

Hello,

I'm reaching out for an update regarding this issue.

We are in the process of submitting Common Vulnerabilities and Exposures (CVEs) related to this matter. However, we can wait if you are in the process of fixing it.

Additionally, we intend to publish our findings in an academic paper.

Your prompt response and attention to this matter would be greatly appreciated as it will greatly inform our next steps.

Thank you and looking forward to your response.

[goekay]

what is the practical issue or vuln this causes effectively? having this non-compliant behaviour has one major advantage: not keeping track of used IDs (memory or database). this is the reason for it missing.

implementing the check is easy. but, in order to do it, we need the history of used IDs for each connection. with a talkative station and really-long open connection, the number of IDs can grow to thousands and millions. and multiply this with the number of stations.

[Tano-Coppoletta]

Thank you for your prompt response to the issue reported. I understand your concern about the memory or database overhead associated with tracking unique message IDs for each WebSocket connection. However, I'd like to highlight the potential risks and implications of not enforcing unique message IDs as per the OCPP specification:

• Risk of Message Confusion: Without unique IDs, there's a potential for confusion in correlating requests and responses. This could lead to operational issues where a response might be incorrectly associated with a different request, potentially causing errors in transaction processing or charging station management.

• Security Implications: From a security standpoint, non-unique message IDs could be exploited in several ways. An attacker could potentially replay messages with the same ID to disrupt the communication flow or inject malicious messages that appear legitimate. This could be used to interfere with charging processes or extract sensitive information.

• Compliance and Interoperability Concerns: Adherence to the OCPP specification is crucial for ensuring interoperability between different systems and components in the EV charging infrastructure. Deviating from these specifications, especially in a protocol as fundamental as message identification, might lead to compatibility issues with other compliant systems or components.

• Potential Solution: To address the memory and database concerns, one potential approach could be implementing a time-based or session-based cleanup mechanism for the ID tracking system. This could involve purging the history of used IDs after a certain period or at the end of each session, thereby limiting the overhead.

I hope these points help clarify the potential issues associated with the current implementation. Ensuring compliance with the OCPP specification is essential for the robustness and reliability of EV charging systems. I look forward to your thoughts on addressing this issue.

[goRaspy]

Hello, Since you are considering the attacker is able to compromise messages from charger side. I suggest to take in priority attention about the registration of boot notification based on chargeboxid. As far I know OCA provided an ocpp errata about this specific point. To be honest it is not clear for me how attackers should be able to reply messages with malicious messages. Using wss probably partially limit this risk. @gaetono what is your point of view on this point ? Le dim. 3 déc. 2023, 19:24, Gaetano Coppoletta ***@***.***> a écrit :

…

Thank you for your prompt response to the issue reported. I understand your concern about the memory or database overhead associated with tracking unique message IDs for each WebSocket connection. However, I'd like to highlight the potential risks and implications of not enforcing unique message IDs as per the OCPP specification: - *Risk of Message Confusion*: Without unique IDs, there's a potential for confusion in correlating requests and responses. This could lead to operational issues where a response might be incorrectly associated with a different request, potentially causing errors in transaction processing or charging station management. - *Security Implications*: From a security standpoint, non-unique message IDs could be exploited in several ways. An attacker could potentially replay messages with the same ID to disrupt the communication flow or inject malicious messages that appear legitimate. This could be used to interfere with charging processes or extract sensitive information. - *Compliance and Interoperability Concerns:* Adherence to the OCPP specification is crucial for ensuring interoperability between different systems and components in the EV charging infrastructure. Deviating from these specifications, especially in a protocol as fundamental as message identification, might lead to compatibility issues with other compliant systems or components. - *Potential Solution*: To address the memory and database concerns, one potential approach could be implementing a time-based or session-based cleanup mechanism for the ID tracking system. This could involve purging the history of used IDs after a certain period or at the end of each session, thereby limiting the overhead. I hope these points help clarify the potential issues associated with the current implementation. Ensuring compliance with the OCPP specification is essential for the robustness and reliability of EV charging systems. I look forward to your thoughts on addressing this issue. — Reply to this email directly, view it on GitHub <#1305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACM5BTAMJM3C66KLZJOTA3LYHS7XLAVCNFSM6AAAAAA7QQ4PLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZXGU2TSNRQGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Tano-Coppoletta]

Thank you for your valuable input on the security aspects of OCPP communications, particularly regarding the registration of boot notifications based on the chargebox ID. I guess you are talking about this: "When a Central System receives CALL messages (other then BootNotification) from a Charge Point before the Charge Point is accepted, the Central System is RECOMMENDED to respond with and RPC CallError: SecurityError". You’re correct in noting the importance of this aspect, as highlighted by the OCA’s errata.

Regarding the potential for message replay and injection of malicious messages, there are a few points to consider:

• Message Replay and Injection: Even with secure WebSocket connections (WSS), the risk of message replay or injection remains if an attacker gains access to the communication channel. While WSS provides transport-level security, it doesn’t inherently prevent replay attacks or message forgery if message IDs are predictable or reused. Unique message IDs are a fundamental layer of security in ensuring that each message is distinctly identified and processed.

• Potential Attack Scenarios: An attacker could exploit non-unique message IDs in scenarios where they manage to intercept or simulate messages. For instance, if an attacker observes a pattern in message IDs or can predict them, they might forge requests or responses, leading to erroneous system behavior. Although this requires a higher level of sophistication, it’s a vulnerability that we need to acknowledge and mitigate.

• Mitigation Strategies: Implementing strict checks for unique message IDs as per the OCPP specification is a proactive step in strengthening the protocol's security. This, combined with secure WebSocket connections, creates a more robust defense against potential attacks.