Changes

Jump to navigation Jump to search
m
no edit summary
=Chapter 2 Public Key Infrastructure=
===== '''General''' =====
While until 1st of April 2024 most communications between energy market participants (roles) were relying on automatically processed email, this is changed to a machine-to-machine communication via webservices, using AS4 (<nowiki>https://en.wikipedia.org/wiki/AS4</nowiki> ) encrypted payloads. The requirements for the XML encryption / signing public key infrastructure (PKI) leans on Diffie-Hellman key exchange procedures. The keys algorithms themselves however can be based on anything commonly accepted like: RSA, Diffie-Hellman, DLIES or Elliptic-Curve (<nowiki>https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=9</nowiki> ).
===== '''Keygen and Distribution''' =====
In theory every market participant is obliged to create their own key-pair for each role in the EDI@Energy framework. Then the public key needs to be signed by an officially certified CA. Officially certified CAs in this case are IT service providers, registered with the National Energy Grid Agency (BNetzA) and do include like Arvato, Telesec and Deutsche Telekom. The signed public key must be made available in a central directory operated by the BDEW, an energy industry standardization organization. It turns out, the challenge to generate key pairs in a secure fashion is overwhelming most IT organizations in small and medium sized utilities companies. The challenges arising from installing and maintaining trust-centre grade “circle of trust” procedures including the necessary escrow mechanisms, keeping employees from stealing keys and passwords, are substantial. Some larger organizations are known to have the resources and procedures in place, most smaller companies seem to ignore the risks and have their admins generating X.509 keys with ssh-keygen on their Linux machines and some totally rely on the service offerings of the CAs. In the case of some IT-guy made the key pair, there is a substantial risk, this pair will sooner or later be compromised. Additionally relying on a CA service provider to generate, distribute and maintain thousands of key-pairs for smaller organizations creates a single target, which if compromised, will void the security of the whole PKI at least for a while.
===== '''Payload Encryption vs. Transport encryption''' =====
The National Institute for IT Security (BSI) emphasizes two alternative AS4 compatible approaches: PKI encrypted payloads with electronic signatures and transport based (TLS 1.2) encryption. It is not clear from the requirements specification which one should be used when. But the initial thinking probably was to go for the payload encryption in the first place and to fall back to TLS, when the procedures implemented proved unreliable for the market participants. As this is currently under implementation by a multitude of software vendors for energy market communication products at the point of this writing (March/2024), no statement can be made on the initial success and use of payload encryption.
113

edits

Navigation menu