After reviewing the SAFESealing code and documentation again - because someone told me, that this is now used in production - I have to admit that Version 2 reads less like a clean new cryptographic design and more like a security advisory for Version 1.
So... where is the actual security advisory for Version 1?
From a cryptographic engineering perspective, SAFE Sealing Version 1 appears to have an obvious structural problem: The payload is split into RSA-sized chunks, padded with the IIP structure, and then processed block by block using the sender’s RSA private key. For RSA-2048 this means roughly 251 bytes of useful payload per block. That raises the uncomfortable question whether Version 1 is vulnerable to splicing, reordering, substitution, or mix-and-match attacks against independently processed RSA blocks.
This is not a purely academic scenario. In the e-mobility use case, a malicious or compromised charging station operator could accumulate a very large library of sealed RSA blocks from the same energy meter over time. Such an operator is exactly the adversary German Eichrecht expects the system to mitigate. If valid blocks from earlier signed/sealed metering records can be reused, rearranged, or substituted under certain nonce/counter conditions, the system does not provide a robust end-to-end protection of the metering record. It only provides a fragile structural plausibility check.
The EV driver could theoretically collect sealed records as well and try to puzzle together alternative datasets. The only practical limitation might be that Version 1 requires many slow and expensive RSA private-key operations on the meter side, so the available amount of material may be limited in some deployments. But “too expensive to attack often” is not a security argument, especially not for legally relevant metering infrastructure.
Version 2, in contrast, looks like a large collection of mitigations for precisely these Version 1 design weaknesses. The additional AES-CBC layers, the multiple symmetric keys, the block reversal, and the reduction to a single RSA operation all look like attempts to create global diffusion and prevent local block manipulation. In other words: Version 2 appears to acknowledge that independently processed RSA blocks were not a sound design foundation.
But this creates a second problem. The entire SAFESealing idea appears to avoid the classical “hash the plaintext and sign the hash” model, apparently to work around the well-known patent situation around signed metering records. Yet Version 2 effectively reconstructs a different kind of message representative: a structured, reversible, AES-diffused representation of the plaintext that is finally bound to an RSA private-key operation. Formally it may not be a classical hash-based RSA signature. Functionally, however, it again creates a unique, verifiable representation of the plaintext — exactly the conceptual territory the design seems to have tried to avoid.
So the result is hard to defend from either side:
Version 1 appears fragile because it processes the message in independently reusable RSA blocks.
Version 2 appears to be a mitigation layer for those fragilities, but at the cost of becoming a proprietary, non-standard signature-like construction with message recovery.
The licensing situation makes this even more ironic. SAFE presented this repository as a contribution to the industry, but the repository is published under a Creative Commons NoDerivatives license. That is not a practical open-source software license for collaborative security engineering. In effect, the industry was not given a clean, free, maintainable alternative to the existing patented solution. Instead, it received another copyrighted, non-standard, partly fragile construction next to the still-existing patent problem.
For an infrastructure that is supposed to protect EV drivers against manipulation by operators, roaming chains, backends, and compromised charging infrastructure, this is not good enough. The industry should not rely on patent-driven cryptographic workarounds. It should use boring, standard, publicly reviewed digital signatures over canonical metering records, with a verifiable certificate chain from the meter key to the legally relevant device identity and calibration context.
Therefore, I would very much appreciate a clear public statement on the following points:
- Are splicing, reordering, substitution, or mix-and-match attacks against Version 1 RSA blocks known or considered possible?
- Was Version 2 designed as a mitigation for such Version 1 weaknesses?
- Is there a security analysis explaining why Version 1 is safe against block-level recombination attacks?
- Is there a security analysis explaining why Version 2 provides equivalent security to standard signature schemes?
- Why was the repository published under a NoDerivatives license if the stated goal was to help the entire industry?
- What migration advice exists for systems that still rely on Version 1 sealed metering records?
Without convincing answers to these questions, SAFESealing should be treated as an interesting historical experiment for computer science students, not as a trustworthy foundation for legally relevant EV charging transparency.
After reviewing the SAFESealing code and documentation again - because someone told me, that this is now used in production - I have to admit that Version 2 reads less like a clean new cryptographic design and more like a security advisory for Version 1.
So... where is the actual security advisory for Version 1?
From a cryptographic engineering perspective, SAFE Sealing Version 1 appears to have an obvious structural problem: The payload is split into RSA-sized chunks, padded with the IIP structure, and then processed block by block using the sender’s RSA private key. For RSA-2048 this means roughly 251 bytes of useful payload per block. That raises the uncomfortable question whether Version 1 is vulnerable to splicing, reordering, substitution, or mix-and-match attacks against independently processed RSA blocks.
This is not a purely academic scenario. In the e-mobility use case, a malicious or compromised charging station operator could accumulate a very large library of sealed RSA blocks from the same energy meter over time. Such an operator is exactly the adversary German Eichrecht expects the system to mitigate. If valid blocks from earlier signed/sealed metering records can be reused, rearranged, or substituted under certain nonce/counter conditions, the system does not provide a robust end-to-end protection of the metering record. It only provides a fragile structural plausibility check.
The EV driver could theoretically collect sealed records as well and try to puzzle together alternative datasets. The only practical limitation might be that Version 1 requires many slow and expensive RSA private-key operations on the meter side, so the available amount of material may be limited in some deployments. But “too expensive to attack often” is not a security argument, especially not for legally relevant metering infrastructure.
Version 2, in contrast, looks like a large collection of mitigations for precisely these Version 1 design weaknesses. The additional AES-CBC layers, the multiple symmetric keys, the block reversal, and the reduction to a single RSA operation all look like attempts to create global diffusion and prevent local block manipulation. In other words: Version 2 appears to acknowledge that independently processed RSA blocks were not a sound design foundation.
But this creates a second problem. The entire SAFESealing idea appears to avoid the classical “hash the plaintext and sign the hash” model, apparently to work around the well-known patent situation around signed metering records. Yet Version 2 effectively reconstructs a different kind of message representative: a structured, reversible, AES-diffused representation of the plaintext that is finally bound to an RSA private-key operation. Formally it may not be a classical hash-based RSA signature. Functionally, however, it again creates a unique, verifiable representation of the plaintext — exactly the conceptual territory the design seems to have tried to avoid.
So the result is hard to defend from either side:
Version 1 appears fragile because it processes the message in independently reusable RSA blocks.
Version 2 appears to be a mitigation layer for those fragilities, but at the cost of becoming a proprietary, non-standard signature-like construction with message recovery.
The licensing situation makes this even more ironic. SAFE presented this repository as a contribution to the industry, but the repository is published under a Creative Commons NoDerivatives license. That is not a practical open-source software license for collaborative security engineering. In effect, the industry was not given a clean, free, maintainable alternative to the existing patented solution. Instead, it received another copyrighted, non-standard, partly fragile construction next to the still-existing patent problem.
For an infrastructure that is supposed to protect EV drivers against manipulation by operators, roaming chains, backends, and compromised charging infrastructure, this is not good enough. The industry should not rely on patent-driven cryptographic workarounds. It should use boring, standard, publicly reviewed digital signatures over canonical metering records, with a verifiable certificate chain from the meter key to the legally relevant device identity and calibration context.
Therefore, I would very much appreciate a clear public statement on the following points:
Without convincing answers to these questions, SAFESealing should be treated as an interesting historical experiment for computer science students, not as a trustworthy foundation for legally relevant EV charging transparency.