Inside Plug & Charge: The cryptographic architecture of seamless EV charging
A clear guide to TLS, symmetric vs asymmetric ciphers, key exchange, and digital signatures in EV charging that enable confidentiality, data integrity, and authenticity
Every Plug & Charge session relies on an intricate dance of encryption, a secure exchange of secret session keys to encrypt and decrypt data, digital signatures to ensure that messages haven’t been tampered with, and digital certificates to verify each participant’s authenticity – all happening within seconds between your EV, the charger, the charge point operator, and the mobility service provider. It’s the same level of security used in online banking, applied to the EV charging world to keep every byte of data – flowing through the charging cable and beyond – private and protected.
You may have heard these terms before, or even worked with some of them. But for most people, cryptography feels like a dense and abstract topic with little connection to daily life. So in this article, I’ll walk you through what actually happens under the hood and how ISO 15118 uses modern cryptography to make Plug & Charge both seamless and secure. If you happen to be a software engineer implementing this, or a test engineer trying to debug why a secure handshake keeps failing or Plug & Charge doesn’t work as expected, this will be especially useful.
My goal isn’t to turn you into a cryptographer, and I’ll spare you the level of depth I usually go into during my two-day advanced training sessions on this topic (part of CharIN’s Charging Communication with ISO 15118 program). Instead, I’ll explain just enough so you can see how Transport Layer Security (TLS), public and private keys, and digital certificates work together to prevent anyone from eavesdropping, tampering, or impersonating when data flows through the charging cable to control the flow of energy.
Let’s get started!
Let’s start by quickly revisiting the three basic principles that allow the EV and charger to ‘talk’ to each other in a secure way: confidentiality, data integrity and authenticity.
Confidentiality: When your EV exchanges information with a charging station (or wall box) it needs to make sure that no unauthorised third party can listen in on the conversation.
Data Integrity: The data that the EV and charging station exchange must be secure, and any malicious third-party attempts to manipulate the conversation
must be detected on both sides.
Authenticity: The EV must identify and be able to verify the charger to which it is physically connected as a trustworthy charger, and vice versa.
Data encryption ensures confidentiality, digital signatures and certificates are the tools to ensure data integrity and to verify the authenticity of the communicating counterpart. Managing these digital certificates securely requires an entire system of roles, policies, and procedures for issuing, validating, and revoking certificates. This system is known as a public key infrastructure, or PKI, which will be the focus of next week’s article.
So, let’s unpack this from the ground up.
Encrypting the conversation with TLS
The moment your ISO 15118-enabled EV and charger connect through the charging cable, they establish a communication link using the Transmission Control Protocol (TCP), the same reliable transport layer that keeps most of the internet running. TCP makes sure every message between the EV and the charger arrives intact, in the right order, and without loss, even if the physical connection isn’t perfect. It’s what guarantees that no data packets go missing or get scrambled while travelling through the cable. That’s important because ISO 15118 describes a strict sequence of messages to orchestrate a successful charging session. If one message is sent out of order or is not received in time, the session immediately terminates.
Once that reliable foundation is in place, Transport Layer Security (TLS) steps in to secure the conversation itself. While TCP ensures that the data arrives, TLS ensures that it arrives privately and unaltered. Before any sensitive information is exchanged – like authorisation data or charging schedules to influence the EV’s charging behaviour – the EV and the charger perform what’s called a TLS handshake: a rapid back-and-forth where they identify each other, agree on which cryptographic algorithms to use (the so-called cipher suite), and generate a shared secret key which then becomes the basis for the encryption key that will be used to encrypt everything that follows.
From that moment on, every message is wrapped in a layer of encryption that only the EV and charger can understand, creating the foundation for a secure Plug & Charge session.
Let’s decipher a TLS cipher suite
During that TLS handshake, the EV and charging station tell each other which set of cryptographic algorithms they support to enable confidentiality, data integrity, and authenticity. Together, these algorithms form what’s called a cipher suite. It’s essentially a recipe for secure communication, made up of four main components.
We’ll first look at the cryptographic algorithms used in ISO 15118-2, released back in 2014, and then briefly compare how they’ve evolved in ISO 15118-20, published in 2022. The shift reflects the industry’s natural move toward higher security and efficiency as both computing power and the sophistication of potential cyber attacks increase.
Key exchange algorithm: The big question is: how can the EV and the charger agree on a shared secret key (based off which the communication shall be encrypted) without anyone listening in, copying that key, and decrypting all their messages? That’s exactly what the Diffie–Hellman key agreement solves: it lets both sides start with their own private number (or digital private key), exchange only a derived public key, and then combine those keys in such a way that both end up with the same secret key, while an eavesdropper watching the exchange can’t reverse the math to uncover it.
In practice, ISO 15118 doesn’t use the original Diffie–Hellman method but a more efficient and modern variant called Elliptic Curve Diffie–Hellman (ECDH). It works on the same principle, but instead of using large prime numbers, it relies on the elegant mathematics of elliptic curves, a topic we’ll revisit further down to show why it’s especially well-suited for embedded systems like EVs and chargers.Authentication algorithm: The authentication algorithm ensures that both parties (the EV and the charger) can prove who they really are before exchanging any sensitive data. It prevents someone from impersonating a trusted device in the communication chain. In ISO 15118, this is done using the Elliptic Curve Digital Signature Algorithm (ECDSA), which allows each side to sign messages with its private key and verify them with the corresponding public key (embedded in a digital certificate), confirming authenticity without ever revealing the private key itself. I’ll walk you through a practical example of a digital signature in a minute.
Bulk encryption algorithm: Once the secure session is established, the bulk encryption algorithm takes over to keep the actual data exchange between the EV and the charger private. In ISO 15118-2, this is handled by AES-128-CBC (Advanced Encryption Standard, 128-bit, Cipher Block Chaining). The 128 indicates the length of the encryption key – long enough to make brute-force attacks practically impossible – while CBC describes how each block of data depends on the one before it, ensuring that even identical message blocks produce completely different encrypted outputs.
Message authentication algorithm: It makes sure that the EV and the charger can detect whether the data exchanged has been altered on its way – be it by accident or by someone trying to interfere. It works by creating a short, unique fingerprint of each message, called a message digest or hash, which the recipient can recalculate and compare to verify integrity. In ISO 15118-2, this is handled by SHA-256 (Secure Hash Algorithm, 256-bit), meaning each message is represented by a 256-bit hash value that changes completely even if a single bit of the original data is modified, making undetected tampering virtually impossible. Try it out yourself with this online hash generator. Hashes are used in digital signatures, I’ll explain this more further down in the article.
Why we need elliptic curve cryptography
For those electronic control units (little microchips and memory chips) embedded in EVs and charging stations, memory footprint and performance matter as much as security. That’s why ISO 15118 relies on elliptic curve cryptography (ECC), a modern variant of public key cryptography – which we’ll touch upon in a minute – that achieves top-tier security with much smaller keys and less computation as compared to e.g. the large prime numbers traditionally used in RSA.
ISO 15118-2 demands the use of a specific elliptic curve called secp256r1 (aka prime256v1) for the following well-established ECC algorithms:
Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol to generate the symmetric TLS session key during the TLS handshake
Elliptic Curve Digital Signature Algorithm (ECDSA) to generate digital signatures with the private key and verify digital signatures with the corresponding public key
Visual example of a TLS cipher suite in ISO 15118-2
In ISO 15118-2, there are only two cipher suites to choose from:
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
At first sight, they look almost identical. However, only the latter one facilitates Perfect Forward Secrecy (PFS), which is a desired characteristic in secure communications.
The ‘E’ in ECDHE stands for Ephemeral, meaning short-lived or temporary. It forces the EV and the charging station to create a new, unique private–public key pair for every charging session, and discard it once the TLS session ends. This way, even if an attacker somehow obtained the TLS session key used in a previous charging session, they couldn’t use it to decrypt any past or future communication. Each session has its own one-time key, ensuring that every conversation between car and charger stays secure on its own. That’s the essence of Perfect Forward Secrecy.
The cipher suite with ‘ECDH’ should have never made it into the ISO 15118-2 standard and is, hopefully and for good cyber security practice’s sake, not implemented in any EV or charging station these days1, even if the perceived risk may be low.
To summarise, each ISO 15118-2 communication session should only use the following cipher suite, which specifies the particular key agreement algorithm, signature and hashing algorithm, and encryption algorithm to use:
Increasing cybersecurity resilience in ISO 15118-20
ISO 15118-20 proposes a new set of cipher suites to enhance data security and be more resilient against cyberattacks. Whether these algorithms will stand the test when quantum computers become more widely available is still to be seen. But then again, commercially available quantum computers (not just prototypes) are likely still at least 10 years away.
The new cipher suites for ISO 15118-20, which demands the use of TLS 1.3, are:
TLS_AES_256_GCM_SHA384: Uses the same AES algorithm but with a 256-bit key for strong encryption, combined with GCM mode (Galois/Counter Mode) for speed and built-in integrity checks, and SHA-384 for hashing.
TLS_CHACHA20_POLY1305_SHA256: Offers a modern, lightweight alternative optimised for devices with limited hardware acceleration, using the ChaCha20 stream cipher for encryption, Poly1305 for message authentication, and SHA-256 for hashing.
In TLS 1.3, the handshake is quicker because the key exchange algorithm (ECDHE) is known from the start. That’s why it no longer appears in the beginning of the cipher suite name.
Beyond the updated cipher suites, ISO 15118-20 brings several notable cybersecurity enhancements, such as
a new default elliptic curve called secp512r1 (doubling the size of private and public keys),
a backup elliptic curve called Curve448 (for when the default curve gets hacked sometime in the future),
additional vehicle certificates to enable mutual TLS authentication, meaning that authentication now happens in both directions – the EV must also prove its identity to the charger, not just the other way around, and
a strong recommendation to use Trusted Platform Module (TPM 2.0) for storing private keys and certificates securely on tamper-resistant hardware.
Interoperability between ISO 15118-2 and -20 isn’t always straightforward. One common stumbling block is the EV and charger not supporting the same TLS version (TLS 1.2 vs TLS 1.3). If they don’t handle this gracefully, their attempt to “speak securely” can fail. When that happens, both sides may simply give up on Plug & Charge altogether and fall back to regular methods like an RFID card, an app, or a payment terminal. This is probably worth exploring further in a separate article. If that’s of interest to you, then let me know in the comments or drop me a message.
How do you secure the encryption key?
We’ve covered quite a bit about digital signatures, certificates (specifically in last week’s article), and the use of private and public keys, along with asymmetric (ECDHE, ECDSA) and symmetric (AES) cryptographic algorithms.
To keep things clear, let’s step back for a moment and untangle these terms so you can see the bigger picture and understand why we need both symmetric and asymmetric encryption in the first place.
Symmetric algorithms like the above mentioned block cipher AES use the same key – in our example: the TLS session key – to both encrypt and decrypt data (hence the term symmetric), making them fast and efficient for protecting large amounts of information once a secure connection is established.
But what if someone was tapping the communication channel (say, the charging cable between the EV and a hacked charging station) remotely during the TLS handshake? Wouldn’t that person then be able to intercept the symmetric TLS session key? If that’s the case, then the eavesdropper would be able to listen in on the communication, and the whole purpose of TLS would be rendered useless.
The eavesdropper could manipulate the communication by modifying the intercepted data for some malicious purpose like manipulating charging schedules (to induce a blackout) or authentication data (to charge on behalf of someone else’s account). How would the EV or charger know if they’re actually talking to a trustworthy party and not falling prey to this kind of man-in-the-middle attack?
That’s where public key cryptography, also known as asymmetric cryptography, comes to the rescue.
It’s called asymmetric cryptography because it uses two mathematically linked but distinct keys – a private key kept secret and a public key shared openly – which perform opposite functions, such as encrypting and decrypting or signing and verifying messages.
The private key must be kept secret at all times, otherwise the key pair is considered to be compromised. It’s a versatile tool that can be used for various cryptographic applications. In ISO 15118, we use asymmetric cryptography only for agreeing on the shared secret key needed for a TLS session key and for digital signatures.
Key Agreement: Back in 1974, two distinguished mathematicians, Whitfeld Diffie and Martin Hellman, invented the Diffie-Hellman key agreement protocol that uses public key cryptography. In this protocol, two parties can agree on a shared secret key without ever transmitting that secret key directly. Instead, they create a temporary private-public key pair, exchange their corresponding public keys, and use a mathematical function to generate the same shared secret key on both sides. This provides a secure way to establish a shared secret key that can be used for encryption and decryption of the following message flow.
Digital Signatures: A digital signature is a way to ensure the authenticity and integrity of a message. To create a digital signature, the EV, for example, uses the SHA-256 hash function to calculate a hash value (also known as the ‘message digest’) and encrypts the hash value with its private key. That encrypted hash value is then attached to the actual message it sends to the charger.
The charger can then verify the signature using the EV’s corresponding public key, which is embedded in a digital certificate to which the charger has access. To verify the message, the charging station basically follows these three steps:
Decrypt the encrypted hash value that the EV attached to its message, using the public key that matches the EV’s private key
Calculate the hash value of the received message
Compare the received (and decrypted) hash value with the calculated one.
If the hash values match, the signature is valid. This means that the charger can be sure that the message has not been tampered with by an unauthorised third party and that it was indeed sent by the EV, who is the only one in possession of that private key that fits to the public key to which the charger has access.
The same principle applies vice versa, of course, when the charger sends a digitally signed message to the EV.
How to create and verify digital signatures
Digital signatures, specifically the XML-based ones used in ISO 151182, can make your head spin and be a bit tricky to understand when you read about them the first time. Let me help you visualise the concept first with the diagram below, and then I’ll guide you through each step one by one.
In this example, we’re assuming that the EV is about to send a digitally signed AuthorizationReq (Req for Request) message to the charging station. This is one of the seven messages in ISO 15118 that need to be digitally signed. Here, the private key is the one that’s mathematically linked to the public key in the contract certificate. The EV has already shared that certificate – not the private key – with the charging station in a previous message called PaymentDetailsReq3:
EXI-encoding and hashing: The message body of an ISO 15118 message is converted into a compact, binary data stream using an EXI codec (see footnote 2 for a brief explanation on Efficient XML Interchange, or EXI). We need this binary representation as input for the SHA-256 hash function, which creates a 256 bit message digest. In the image above, those 256 bits are represented in 64 hexadecimal characters (1 hex character = 4 bits; 64 x 4 bits = 256 bits).
Store message digest in header: The resulting hash value is then stored in the
DigestValueelement of the message header’sSignature. ThisSignaturecontains the two fieldsSignedInfoandSignatureValue. TheSignedInfoelement includes several data fields, but for our purposes here, the key one to focus on isDigestValue.EXI encode SignedInfo: The
SignedInfodata field (which contains the message digest, or hash) is then also EXI encoded.Hash EXI-encoded SignedInfo: The binary, EXI-encoded
SignedInfois then also hashed using SHA-256, producing yet another hash value that represents theSignedInfodata field.Encrypt hashed and EXI-encoded SignedInfo: Using its private key, the EV will encrypt the hash value of the EXI-encoded
SignedInfodata field. This, my friend, is finally the digital signature.
Important note: Step 4 and 5 are both part of the Elliptic Curve Digital Signature Algorithm (ECDSA). DO NOT hash theSignedInfodata field before you apply ECDSA, as this would result in a double hashing operation and failed signature verification on the other side. I ran into this issue when I first implemented digital signatures in ISO 15118 many years ago. Took me a while until I understood why.Store digital signature in message header: The final step of creating the digital signature is to actually place this value into the
SignatureValuefield of the message header’sSignature.EXI encode signed ISO 15118 message: Now, before the EV sends the message across the wire to the charging station, the message needs to be transformed into a compact, digital data stream using the EXI codec once again.
Encrypt ISO 15118 message: The final step is to encrypt the now EXI-encoded and digitally signed
AuthorizationReqmessage with the symmetric block cipher AES-128-CBC, using the 128-bit TLS session key that the EV and charger agreed on during the TLS handshake (remember Elliptic Curve Diffie-Hellman?).
OK, so what does the charging station now do once it receives this message?
As the saying goes, images speak more than 1000 words. So let’s first summarise the actions visually before I walk you through each step.
Verifying a digital signature is actually a two-step process:
Part 1: Verify the digest value(s) of the message body (elements)4
Part 2: Verify the signature value
Let’s go through the steps of Part 1 first:
Decrypt EXI-encoded message: Upon receiving the
AuthorizationReqvia the charging cable, the charging station will first try to decrypt the message using the same, symmetric 128-bit TLS session key which the EV used for encryption.EXI decode the message: To be able to read the message header and body, the charger needs to use the EXI codec for decoding the
AuthorizationReq.EXI encode and hash message body: Then the charger does the same what the EV did previously: EXI encode and hash the message body. This is a step towards checking whether the message has been altered on its way to the charger.
Check if digest values match: The result from step 3 represents the message digest of the
AuthorizationReq. If that message digest is the same as the one stored in the message header’sDigestValuefield, then that’s already a good sign. But we’re not done yet. The charger still needs to check the authenticity of the received digest value (which we discuss in Part 2 below).
We’re almost there. The final steps of verifying a digital signature in ISO 15118 are:
EXI encode Signed Info: In order to verify the digital signature value, the charger needs to basically go through the same calculation steps as the EV did. Meaning: EXI encoding the
SignedInfoelement first before …Hash EXI-encoded Signed Info: … hashing the resulting binary data stream, resulting in (hopefully) the same value the EV calculated before it sent the message across.
Decrypt Signature Value: Now the charging station needs to use the public key that is linked to the contract certificate’s private key in order to decrypt the data field
SignatureValue, which is stored in theAuthorizationReq’s message header. Remember that the charger received the contract certificate (including the public key) from the EV in the previousPaymentDetailsReqmessage.Check if values match: The finale: if the decrypted
SignatureValuematches the calculated (EXI-encoded and hashed)SignedInfovalue, then the message is definitely authentic and can be trusted.
That was a lot to digest, I know.
But it’s the only way to truly understand how XML-based digital signatures work in ISO 15118. The good news? You’ve just worked through one of the toughest parts of Plug & Charge. If it all clicked – congratulations, that’s a real achievement. And if it didn’t fully land yet, grab a coffee, take a breather, and give it another read. It’ll make sense the second time around.
Symmetric vs asymmetric – the big picture
To summarise: asymmetric cryptography is ideal for the initial trust-building and key exchange (where confidentiality is critical but speed matters less), while symmetric cryptography takes over once the secure session is set up, efficiently encrypting and decrypting all the data that follows. Asymmetric ciphers require long key lengths compared to symmetric ciphers, which is computationally more expensive and requires a higher memory footprint. That’s the reason why symmetric ciphers (like AES) are used for encrypting the actual communication.
Below is a visual summary that captures the essence of what we discussed regarding symmetric and asymmetric ciphers.
Note that the shared secret key isn’t used directly as the symmetric TLS session key for encrypting and decrypting messages. Instead, there’s an intermediate step called a Key Derivation Function (KDF), which transforms the shared secret into a properly sized TLS session key. One reason for this is that ISO 15118-2 mandates the use of the elliptic curve secp256r1 (also known as prime256v1), which was considered state-of-the-art when the standard was published in 2014. This curve produces a 256-bit shared secret, while the symmetric cipher used in ISO 15118-2 – AES-128-CBC – operates on 128-bit keys. The KDF bridges this mismatch by deriving a 128-bit session key from the 256-bit shared secret.
ISO 15118-20 works in much the same way, but it uses larger key sizes and introduces additional signature algorithms in its cipher suites, as mentioned above.
Is your hardware ready for Plug & Charge?
Understanding the interplay of the various symmetric and asymmetric ciphers is essential to a) implement and b) debug Plug & Charge sessions in your test lab or later in the field when you introduced your (battle-tested) solutions to the market.
These days, we don’t need to reinvent the wheel when it comes to the various ciphers at play. OpenSSL is a mature, widely used open-source cryptographic library that already implements all the major symmetric and asymmetric algorithms needed – from AES and SHA-256 to ECDHE and ECDSA. It’s a solid foundation for handling TLS, digital signatures, and key exchange without having to build these components from scratch. However, it’s important to verify which OpenSSL version your system is using, as older releases may not yet support all the cipher suites required by ISO 15118-2 and especially ISO 15118-20 – which will become mandatory under AFIR in Europe by January 2027.
Also, keep in mind that there are mature, ready-to-use implementations that are battle-tested, certified, and have survived countless interoperability events. From open-source projects like Pionix’s EVerest to closed-source platforms such as EcoG OS (which, for those who remember, incorporates Switch’s former Josev stack) and Vector Informatik’s vSECClib for charging stations.
Also, make sure that you are sourcing the right crypto chips and hardware security modules (HSM). Ask yourself:
Are they compliant with the Trusted Platform Module (TPM 2.0) reference design?
Do they support TLS 1.2 and TLS 1.3?
Do they support all cipher suites required for ISO 15118-2 and -20?
What are the lead delivery times for those crypto chips?
What do you want to build in-house and what do you source from third-party vendors? (which can also have an effect on lead delivery times)
I’m by no means an expert in sourcing crypto chips, but I do know that companies like STMicroelectronics – and, I believe, Intel as well – offer hardware that meets the necessary security requirements. Take the ST33KTPM2I, for example. Just a couple of weeks ago, I spoke with both a charger manufacturer and a supplier of communication controllers, who mentioned that this particular chip currently (as of mid-November 2025) has a lead time of around 40 weeks. That’s quite a lead time…
It may be a good idea to source complete communication controllers and modules from solutions providers like Chargebyte, who already have these crypto chips integrated into their products.
If your company does provide the right kind of crypto chips, please do reach out to me by commenting on this article or sending me a message, and I’ll include your information in this section.
It’s a wrap!
Cryptography is one of those topics that can make even seasoned engineers’ heads spin. This was probably one of the more technical deep dives in this newsletter – so if you’ve made it this far, bravo. Seriously. That means you’ve either just wrapped your head around one of the toughest parts of Plug & Charge, or you’ve refreshed and deepened what you already knew.
I hope this breakdown helped make the moving parts of ISO 15118’s cryptography click — without drowning in jargon — and gave you a clearer sense of how all these algorithms work together under the hood.
If something didn’t quite click, feel free to let me know in the comments – or drop me a note via email or LinkedIn – so I can revise for more clarity. And if you did enjoy this one, I won’t say no to a bit of positive feedback either. 😉
Next week, we’ll build on this foundation and explore digital certificates and the public key infrastructure (PKI) that underpins Plug & Charge – from leaf certificates all the way up to the root trust anchors. We’ll also look at what CPOs, EV and charger manufacturers need to know about managing and updating their certificates.
See you next week.
When you start working on international standards, you quickly realise it’s not always the best technology or most elegant solution that makes it in. It’s the result of consensus. Standards represent the best common denominator that all participating companies and countries can agree on. I learned that early on when I began contributing to ISO 15118 back in 2010.
The structure of every message in ISO 15118 is defined using XML (Extensible Markup Language) schema files. How these messages are represented in code depends on the programming language being used. To ensure that the exchange of ISO 15118 messages is both efficient – meaning the data transmitted is as compact as possible – and easy to validate against the defined schemas on embedded controllers in the EV and charger, the Efficient XML Interchange (EXI) standard was adopted. An EXI codec (a software component that encodes and decodes messages) handles the conversion between human-readable XML and its compressed binary form for transmission.
I’m not going down the rabbit hole of going through the sequence of messages exchanged during an ISO 15118 session. But I wanted to mention that PaymentDetailsReq is actually a misnomer. It’s not payment details that are exchanged here, but identification details, namely the contract certificate installed on the EV.
With some ISO 15118 messages, the whole message body gets digitally signed. For other messages, only specific parts of the message body are digitally signed. This is why I am referring to the optional pural ‘s’ in “message body element(s)”.