steve-community
Add support for SignedUpdateFirmware
1.6 whitepaper mandates the new SignedUpdateFirmware request, and it is required not to support the old UpdateFirmware. Thus, for a CS supporting the signed version, Steve cannot be used to update firmware.
In other words, it would be good if we could add support for SignedUpdateFirmware.
i assume you are referencing OCPP 1.6 Security Whitepaper (3rd edition). none of the enhancements/adjustments mentioned there are implemented in steve.
so, i agree, but not only that. we should aim to implement all the ideas by the whitepaper.
The whitepaper link has changed, you can find it through this link OCPP-1.6-security-whitepaper-edition-3-2.zip or this page INFO & WHITEPAPERS.
... and it is required not to support the old UpdateFirmware.
It's strange that they mention this in the white-paper indeed, as in OCTT, the official tool for certification, they require you, as a charge point, to support it and there are tests cases for it, so I doubt any CP will disable it, since it's part of CORE.
@razvanphp They are indeed:
Which OCTT test case are you referring to exactly?
https://openchargealliance.org/wp-content/uploads/2025/09/CompliancyTestTool-TestCaseDocument.pdf
... and it is required not to support the old UpdateFirmware.
It's strange that they mention this in the white-paper indeed, as in OCTT, the official tool for certification, they require you, as a charge point, to support it and there are tests cases for it, so I doubt any CP will disable it, since it's part of CORE.
This has been discussed on the OCPP mailing list, which is unfortunately only available to members. If I remember it correctly, they don't consider this as a conflict. For example, it is possible to use different firmware or configuration for CS in order to pass both set of test cases.
With one product that I have worked with, we have implemented a "one way" parameter: It is possible to activate this parameter to enforce signed firmware update, but once activated, you cannot go back.
Also note that since 2025-08-01, for products in EU which falls under the RED directive, signed firmware update is also required thus the old UpdateFirmware must be disabled. Unfortunately many CSMS systems still don't support signed firmware update 🙄
Which OCTT test case are you referring to exactly? https://openchargealliance.org/wp-content/uploads/2025/09/CompliancyTestTool-TestCaseDocument.pdf
I mean those:
@razvanphp It makes sense that the 1.6 core test cases validate the initial command only. The challenge comes when you aim to validate both specifications, but so far I haven’t found any certification scheme addressing the security whitepaper. As @astrand pointed out, it is possible to validate a particular firmware version or enforce a specific configuration to manage behaviour expectations.
Also note that since 2025-08-01, for products in EU which falls under the RED directive, signed firmware update is also required thus the old UpdateFirmware must be disabled. Unfortunately many CSMS systems still don't support signed firmware update 🙄
@astrand thanks for raising that point. I wasn’t aware of it, and from what I hear, manufacturers aren’t proactively mentioning it either, even though many reference ISO 15118‑20. Do you have any links or resources that could help me dig deeper into the implications of RED for EV charging equipment?
I thought that for RED they are checking only RF signals, so WiFi and NFC. Interesting, we are going through the RED certification for one charger in November, so will update here if something about this comes up.
PS: the OCPP 1.6J certification now has an optional certification for security whitepaper, called "Advanced Security", namely those:
Good catch. I hadn’t reviewed the file in enough details.
BTW, I don’t see any test case in the list that appears to cover the L01.FR.20 rule.
Wrt RED, basically the upcoming Cyber Resilience Act has been introduced in advance for internet connected radio equipment. EU DR 2022/30 "activates" clause 3.3 in the earlier RED directive. In practice, this means that you must consider EN 18031 -1 -2 -3. The first one of these requires a software update mechanism which "shall only install software whose integrity and authenticity are valid at the time of the installation".
hey folks, i just wanted to ping that this operation is now implemented in the respective PR. also see the WIP updates.
i saw L01.FR.20 and decided to leave this control to CP. steve will offer both variants, UpdateFirmware and SignedUpdateFirmware, and the user can decide.
hey folks, would like to get your input regarding the following:
do you know from your field experience how existing central system implementations deal with the decision of which security profile they use? the spec says "... Central System SHALL only use one security profile at a time".
why can the backend not be flexible (and not use any security profile, but support all of them) and the final decision happens dynamically based on the configuration of station?
if a station is running with profile 2, do what is necessary for 2 and validate respective requirements.
if a station is running with profile 3, do what is necessary for 3 and validate respective requirements.
my concern is the following: lets say that steve is configured to run at profile 3. it will NOT be able to work with stations at profile 2, right? why exclude them?
or am i misunderstanding something? sorry for hijacking this thread.
EDIT: there is also the following
which is kind of a relief, but a different address or port is not necessarily needed and would require configuration changes (regarding the backend url) in/at station.
@goekay For cases like this, suggestion is to check what is written in 2.0.1 and 2.1, since OCPP 1.6 has been evolving a lot over time. Some parts of the Improved Security whitepaper are confusing or conflicting. For example, the forbidden "lowering of security profile" is also strange.
However, I just checked 2.1 and the idea seems to be that you should use different ports if you should support both profile 2 and 3.