-
-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible Non-Compliance with OCPP Specification Regarding Unique Message IDs #1305
Comments
I agree with this, i've faced a same issue |
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. |
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. |
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:
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. |
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: ***@***.***>
|
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:
|
Checklist
Specifications
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
CALL
messages using the same message ID.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.
The text was updated successfully, but these errors were encountered: