Enhancing Anonymity for Electric Vehicles in the ISO 15118
Plug-and-Charge
Nethmi Hettiarachchi
a
, Kalikinkar Mandal
b
and Saqib Hakak
c
Canadian Institute for Cybersecurity, Faculty of Computer Science, University of New Brunswick, Fredericton, Canada
Keywords:
Electric Vehicle Charging, Plug and Charge, ISO15118, Anonymous Authentication, Authenticated Key
Agreement (AKA).
Abstract:
ISO 15118 is a standard protocol family that enables the plug-and-charge (PnC) functionality in the electric
vehicle (EV) charging architecture. To initiate a charging session, an EV must first authenticate to the charging
point (CP) by establishing a TLS connection using its X.509 certificate, followed by authorisation and billing
at the end of charging. In this work, we first analyse the privacy of EVs with respect to the information
exchanged during the ISO 15118 authentication, charging authorization and billing procedure. We discovered
a significant privacy leakage in the current standard, where the initial authentication phase and the billing
expose sensitive information that enables various attacks such as charging session linking, EV fingerprinting,
profiling and resumption attacks against EV. To address this privacy issue, we first propose an efficient mutual
authentication protocol for ISO 15118 PnC that protects the privacy of EVs, including identity and location,
against the CP. We analyse the security of our protocol using the Tamarin formal verification tool. The protocol
is implemented with various standardised cryptographic schemes and evaluated on different device platforms.
1 INTRODUCTION
Global EV adoption is rapidly increasing due to lower
costs, emerging technologies, and government incen-
tives. In 2023, 14 million new EVs were registered,
bringing the total to 40 million (International Energy
Agency, 2023). To support this growth, new charg-
ing strategies and protocols are being developed. ISO
15118 facilitates EV integration into the smart grid,
with Edition 1 being widely used and Edition 2 (ISO
15118-20) introducing enhancements. The protocol
automates authentication, authorisation, and billing
via PnC, eliminating the need for manual payment
methods. EVs authenticate using contract credentials
from e-Mobility Service Providers (eMSPs), with a
valid eMAID linked to a billing account. Despite its
convenience, ISO 15118 has privacy concerns. It re-
lies on a complex public key infrastructure (PKI) re-
quiring multiple entities and X.509 certificates. EVs
must share sensitive information, including provision-
ing certificates and personally identifiable informa-
tion (PII), with the CP and CPO for authorization.
a
https://orcid.org/0000-0002-0532-1263
b
https://orcid.org/0000-0002-8228-5016
c
https://orcid.org/0000-0002-8718-0336
The charge detail record (CDR) further exposes data,
enabling profiling and tracking (Regulation, 2016).
CPs can monitor EV charging habits and potentially
monetize this data. Any exposed information falls un-
der the EU’s GDPR and requires privacy-preserving
handling.
Our research focuses on three lacking privacy as-
pects in ISO 15118: (i) EV identity confidentiality,
(ii) location privacy, and (iii) EV untraceability. AKA
protocols in 3G, 4G, and 5G are crucial for address-
ing these concerns. They protect mobile subscribers’
identity and location confidentiality, ensuring that au-
thentication occurs without revealing sensitive infor-
mation to untrusted third parties. AKA enables mo-
bility services even outside regular provider coverage
by issuing temporary credentials, preserving user pri-
vacy during authentication. Thus we use an AKA
protocol-inspired approach to enhancing anonymity
for ISO 15118 PnC.
Our Contributions. Our contributions in this pa-
per are two-fold. First, we perform a privacy analy-
sis of the existing ISO 15118 PnC mechanism. Next,
to address such privacy leakage, we propose an ef-
ficient mutual authentication protocol, providing EV
anonymity, along with its security and implementa-
Hettiarachchi, N., Mandal, K. and Hakak, S.
Enhancing Anonymity for Electric Vehicles in the ISO 15118 Plug-and-Charge.
DOI: 10.5220/0013571700003979
In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 475-482
ISBN: 978-989-758-760-3; ISSN: 2184-7711
Copyright © 2025 by Paper published under CC license (CC BY-NC-ND 4.0)
475

tions in the ISO 15118 framework. We summarise
the key contributions below.
1. We conduct a comprehensive privacy analysis of
the ISO 15118 protocol and identify critical pri-
vacy leakages and potential attacks. Next, based
on the LINDDUN privacy model, we deduce the
essential privacy requirements for a secure and
privacy-preserving PnC session.
2. To mitigate the privacy leakage, we propose an
anonymous mutual authentication protocol that
establishes a secure session key for PnC charging.
3. We analyze the security of our protocol using the
Tamarin, providing a rigorous security proof to en-
sure its robustness against potential attacks.
4. We implement our protocol in the EcoG-io/ISO
15118 framework using a Raspberry Pi 4B de-
vice and a desktop. We benchmark our protocol
for a wide-variety of AKA algorithms Milenage
(AES-based) and TUAK (Keccak-based) and cryp-
tographic primitives.
2 RELATED WORK
(Yue et al., 2024) proposed the first anonymous
payment scheme for V2G networks, combining
blockchain with PBFT consensus, one-time signa-
tures (OTS) (Zaverucha and Stinson, 2010), and bi-
linear pairing to enable lightweight, anonymous, and
binding payments. Direct Anonymous Attestation
(DAA) enables privacy-preserving platform authen-
tication (Brickell et al., 2004), and recent PnC au-
thentication protocols (Zelle et al., 2018) and (Zhao
et al., 2015) use TPM-based DAA for EV authen-
tication. (Kern et al., 2022) also proposed a TPM-
based DAA scheme for EV authentication, but it has
several limitations. It requires EVs to be equipped
with TPMs, creating hardware dependencies and lim-
iting compatibility with current infrastructure. CPs
and CPOs must support DAA verification under high
session loads, introducing performance bottlenecks.
Additionally, the protocol replaces standard contract
certificates with DAA-based X.509 certificates, dis-
rupting the existing PKI model and requiring eMSPs
to issue new credentials. These constraints, includ-
ing a lack of standardisation and TPM requirements at
both EV and backend, raise scalability concerns and
limit practical deployment within ISO 15118 systems.
3 BACKGROUND
The transition to electrified transportation demands
a dedicated charging infrastructure that is efficient,
user-friendly, and interoperable. The e-mobility ar-
chitecture enables interoperability by allowing EVs
to charge with any provider through physical com-
patibility and standardized protocols like ISO 15118
for secure authentication, authorization, and billing.
Key entities include EVs, CPs, CPOs, eMSPs, Cer-
tificate Provisioning Services (CPS), and grid op-
erators, which communicate via standardized pro-
tocols to manage charging sessions (see Figure 1).
An EV contains an EVCC for communication,
while the SECC acts as the CP interface. EV-
CP communication occurs over a secure TLS chan-
nel using ISO 15118, with Edition 1 using TLS
1.2 and Edition 2 mandating TLS 1.3 for mu-
tual authentication via manufacturer-issued certifi-
cates. It recommends TLS_AES_256_GCM_SHA384
or TLS_CHACHA20_POLY1305_SHA256 cipher suites.
Backend communication with eMSP uses OCPI and
OCPP over TLS.
Provisioning Credential Certificate. During EV
production, the OEM generates provisioning creden-
tials, including a PCID (which uniquely identifys the
EV for billing and other purposes), a provisioning cer-
tificate (PC
cert
), and a key pair (PC
sk
, PC
pk
). PC
cert
contains the PCID and the EV’s public key and is
digitally signed by the OEM’s Certificate Authority
(OEM-CA) to ensure authenticity and integrity. This
certificate enables the EV to authenticate with charg-
ing stations and service providers during its initial
charging session and obtain the CC
cert
, the long-term
certificate for charging authorization.
Obtaining the Contract Certificate and Installa-
tion. To acquire PnC services, the EV must have a
valid charging contract with an eMSP. The EV owner
presents the PCID to the eMSP, which links it to a
billing account identified by an eMAID (Electric Mo-
bility Account Identifier) as specified in ISO15118.
The eMSP generates a key pair (CC
pk
, CC
sk
) and a
contract certificate (CC
cert
) containing the eMAID.
Figure 1 shows the process of obtaining and installing
the contract certificate. During the first charging ses-
sion, (CC
cert
) and keys (CC
pk
, CC
sk
) are installed into
the EV over a secure TLS channel. The EV sends
a credential installation request (containing PC
cert
signed with PC
sk
) to the CP, which forwards it to the
eMSP via CPS. The eMSP encrypts CC
sk
with PC
pk
from PC
cert
, and CPS signs the response after ver-
ifying the contract certificate chain. The EV, trust-
ing CPS, decrypts the response using PC
sk
to retrieve
CC
sk
and stores the credentials securely for future PnC
authentications.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
476

Provisioning
credentials (1)
Contract credential req. (2)
Contract credentials (4)
Contract credentials (5)
PnC authorization (6)
Contract credential req. (3)
Provisioning Certificate
Contract Certificate
[ ISO 15118 with TLS ] [ OCCP with TLS ]
CP's Certificate
eMSP's Certificate
CPO
Original
Equipment
Manufacturer
(OEM)
Electric
Vehicle
[EVCC]
Charge
Point
[
SECC]
Certificate
Provisioning
Services
(CPS)
e-Mobility
Service
Provider
(eMSP)
[Backend]
Figure 1: eMobility architecture.
Table 1: Summary of EV Privacy Attacks in ISO 15118 Charging Networks.
Attack Description and Impact
A1: Charging Ses-
sion Linking Attack
TLS 1.3 session resumption improves efficiency but exposes EV information through resumption
tickets. A passive adversary can perform linking EV sessions by correlating reused tokens, leading
to metadata exposure such as charging times and session frequency. CPs or adversaries can also
build behavioural profiles by profiling interaction history across networks (Arfaoui et al., 2019).
A2: EV Finger-
printing and Profil-
ing Attack
During the TLS handshake, EVs expose protocol parameters that allow adversaries to generate
unique fingerprints (e.g., JARM, JA3 (Althouse et al., 2017a), JA3S (Althouse et al., 2017b)). This
enables EV tracking and profiling across a chain of CPs (belongs to one company), even with
session resumption, and metadata exposure revealing the EV model, OS, and firmware version.
A3: Charging Point
Surveillance and
EV Profiling
Although TLS 1.3 encrypts certificates, CPs can still access EV certificates upon receiving. This
permits linking EV sessions across locations, metadata exposure of cryptographic configurations,
and monetizing EV data through sales to manufacturers or third parties. Additionally, tracking
movement can reveal sensitive locations such as home or workplace, and malicious CP attacks can
impersonate EVs or exploit their credentials.
Using the Contract Credentials. When an EV
plugs into the CP for charging, ISO15118 manages
the process without customer involvement. Before
communication, TLS 1.3 mutual authentication is
performed: the CP uses its SECC certificate, and the
EV uses its manufacturer-issued vehicle certificate.
Over the TLS channel, the EV sends its contract cre-
dentials (CC
sk
, eMAID) to the CP for authorization.
The CP validates the credentials, authorizes the EV,
and initiates charging. During the session, the EV
and CP periodically exchange signed charging status
and meter reading messages, with the EV signing us-
ing CC
sk
. A detailed description of ISO15118 crypto-
graphic operations follows in the next section.
ISO15118 PnC Charging Authorisation. The
ISO15118 communication protocol builds upon IEC
61851, which defines basic signalling and voltage lev-
els for EV charging. They operate together during
a session. When the EV plugs the charging cable
into the CP, the process initially follows IEC61851.
The control pilot line, a dedicated wire in the cable,
connects the EV and CP and transmits PWM sig-
nals. A PWM duty cycle of 5% signals both par-
ties to initiate ISO15118 communication. ISO15118
uses certificate-based mutual authentication. To en-
able plug-and-charge, the EV must have an installed
contract certificate. The EV submits its CC
cert
and the
eMSP certificate chain to the CP, which verifies the
eMSP chain against a locally installed root and val-
idates the CC
cert
. The CP then sends its CPID and a
challenge (fresh nonce) to the EV. To prove authentic-
ity, the EV signs and returns the eMAID (CPID and
nonce) and the challenge. The CP verifies the signa-
ture using CC
pk
from CC
cert
. Upon successful verifi-
cation, the EV is authorized and charging begins.
4 PRIVACY ASSESSMENT OF
THE ISO 15118 PnC PROTOCOL
Privacy Attacks on ISO 15118 PnC
Security and Privacy Requirements. To define
privacy and security requirements, we adopt the
LINDDUN framework (Deng et al., 2011), known for
its structured methodology and privacy threat trees
aligned with LINDDUN types (Sion et al., 2018).
This approach identifies risks and derives require-
ments in environments with honest but curious en-
tities; we model CCP and CPO as such. We also
consider an external attacker or passive eavesdropper
monitoring PnC traffic to infer EV locations, move-
Enhancing Anonymity for Electric Vehicles in the ISO 15118 Plug-and-Charge
477

Table 2: LINDDUN Privacy Requirements for ISO 15118.
Privacy Requirement Acron. LINDDUN Category
EV identity
confidentiality
P1 Identifiability,
Linkability
Prevention of unique
identification
P2 Identifiability,
Linkability, Detectability
Charging session
unlinkability
P3 Linkability, Disclosure
of Information
Charging data
aggregation prevention
P4 Linkability, Disclosure
of Information,
Non-repudiation
EV location privacy P5 Linkability, Disclosure
of Information
ment patterns, and session correlations, posing risks
like tracking EV owners or revealing home and work
locations. Based on these adversaries and LIND-
DUN threat modeling, privacy requirements are sum-
marized in Table 2.
5 OUR THREE-PARTY
AUTHENTICATION
PROTOCOL
Here, we present our protocol step by step with the
aid of detailed protocol diagrams. Each diagram illus-
trates both the cryptographic operations and the cor-
responding message flow within the ISO 15118 pro-
tocol. To enhance clarity, the ISO 15118 message
names are provided beneath the arrows in the dia-
grams, allowing readers to easily map each step to the
standard protocol sequence.
Cryptographic Credentials. Like ISO 15118, we
assume that each EV holds two pairs of certificates: 1)
PC
cert
for the digital signature key pair (PC
pk
, PC
sk
)
and an EV ID: PCID, received from OME; and an-
other certificate CC
cert
for (CC
sk
,CC
pk
) and eMAID
received from the eMSP for PnC. The CP also holds
CP
cert
for (CP
sk
,CP
pk
) and CPID. The eMSP has
a root certificate eMSP
root
and its own certificate
eMSP
cert
for the signature key (eMSP
pk
, eMSP
sk
)
and eMSPID. We also require the eMSP to have
a certificate for long-term/static public-private key
pair (PK
eMSP
, SK
eMSP
) for the public-key encryption
(PKE) used in the key-encapsulation mechanism.
EV Authenticating CP Messages (EV ⇒ CP): It
is a standard certificate-based challenge-response pro-
tocol. We present it in Figure 2 for completeness.
The EV randomly samples a number n
EV
and sends
it to the CP along with a certificate request. After re-
ceiving n
EV
, the CP signs n
EV
and its ID CPID with
the key CP
sk
and sends σ
CP
, CPID, and CP
cert
to the
EV. Upon receiving, the EV verifies σ
CP
by extract-
ing CP
pk
from the received CP
cert
. If the verification
is successful, the EV proceed to the next step, other-
wise, it aborts.
EV and eMSP Mutual Authentication Messages
(EV ⇔ eMSP): The communication between the
EV and eMSP is done via the CP. The key idea of our
protocol is that the EV sends a random challenge and
its certificate to the eMSP in the encrypted form so
that the CP does not have any information about the
EV’s identity and the EV and eMSP establish a shared
session key that is used for the authentication and key
establishment between the EV and CP. Figure 3 illus-
trates the three-party protocol for generating and veri-
fying authentication vectors. The eMSP authenticates
and establishes a shared key with the EV as follows:
(a) eMSP Authenticates EV and Computes a
Shared Key (eMSP ⇒ EV): The EV runs a key en-
capsulation using the eMSP’s public key PK
eMSP
to
obtain a key K
s
and ciphertext c. It saves K
s
for au-
thentication, signs c using CC
sk
to produce σ
EV
, and
encrypts CC
cert
and a challenge n
EV
with authenti-
cated encryption to get ciphertext and tag C. The
EV sends (c, σ
EV
,C) to the CP, who forwards it to
the eMSP via a secure channel (e.g., TLS). Upon re-
ceiving (c, σ
EV
,C), the eMSP decapsulates c using
SK
eMSP
to recover K
s
, decrypts C to retrieve D =
CC
cert
|n
EV
, and extracts CC
pk
from CC
cert
to verify
σ
EV
. If verification succeeds, K
s
is accepted. The EV
and eMSP then derive a shared secret K from K
s
, n
EV
,
n
eMSP
, eMAID, and eMSPID using a key derivation
function.
(b) eMSP Computes an Authentication Vector and
Keys: To enable CP authentication without reveal-
ing the EV’s identity or certificate, the eMSP gen-
erates an authentication vector from K
s
and a ran-
dom nonce R, following the 3GPP AKA protocol
(3rd Generation Partnership Project (3GPP), 2021).
Both EV and eMSP maintain counters, SQN
EV
and
SQN
eMSP
, to prevent replay attacks. Using one-way
keyed functions f
1
to f
5
(3rd Generation Partnership
Project (3GPP), 2024), the eMSP computes authen-
tication parameters: MAC = f
1
(SQN
eMSP
, R, K) and
xRES = f
2
(R, K). Sequence number protection is
ensured via an anonymity key AK = f
5
(R, K), and
the authentication vector is AUT H = (MAC,CONC)
with CONC = SQN
eMSP
⊕ AK and xRES. Encryp-
tion key CK and integrity key IK are derived using
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
478

EV CP
Keys: CC
cert
, (CC
sk
,CC
pk
), eMAID Keys: CP
cert
, (CP
sk
, CP
pk
), eMSP
root
1: n
EV
$
←− {0, 1}
∗
n
EV
−−−−−−−−−−−−−−−−−−−−→
«SupportedAppProtocolReq»
2: σ
CP
← Sign(CP
sk
, n
EV
∥CPID)
σ
CP
,CP
cert
,CPID
←−−−−−−−−−−−−−−−−−−−−
«SupportedAppProtocolRes»
3: a ← CertVerify(CP
cert
)
4: b ← Verify(CP
pk
, n
EV
∥CPID, σ
CP
)
5: If a = 1 ∧b = 1 then CP verified
and proceed.
Else abort.
Figure 2: EV authenticates the CP using a certificate.
EV CP eMSP
Keys: CC
cert
, (CC
sk
,CC
pk
), eMAID, SQN
EV
(CP
cert
,CP
sk
,eMSP
root
) (eMSP
sk
, eMSPpk)
1: n
EV
$
← {0, 1}
∗
2: (c, K
s
) ← KEM.Encaps(PK
eMSP
)
3: σ
EV
← Sign(CC
sk
, c)
4: D := CC
cert
∥n
EV
5: C ← AEAD.Enc(K, D)
c,C,σ
EV
−−−−−−−−−−−−−−−→
«PaymentDetailsReq»
1: K
s
← KEM.Decaps(SK
eMSP
, c)
2: D ← AEAD.Dec(K,C)
3: Parse D as CC
cert
∥n
EV
4: a ← CertVerify(CC
cert
)
5: b ← Verify(CC
pk
, c, σ)
6: If a = 1 ∧ b = 1 then proceed; Else abort.
7: n
eMSP
$
← {0, 1}
∗
8: K ← KDF(K
s
, n
EV
, n
eMSP
,CCID, eMSPID)
9: R
$
← {0, 1}
∗
10: σ
eMSP
← Sign(eMSP
sk
, n
eMSP
∥n
EV
∥R)
11: MAC ← f
1
(SQN
eMSP
∥R, K)
12: AK ← f
5
(R, K)
13: CONC ← SQN
eMSP
⊕ AK
14: AUT N ← (MAC,CONC)
15: xRES ← f
2
(R, K)
16: CK ← f
3
(R, K)
17: IK ← f
4
(R, K)
18: SQN
eMSP
← SQN
eMSP
+ 1
PID
EV
,n
eMSP
,R,σ
eMSP
,AU T N
←−−−−−−−−−−−−−−−−
«PaymentDetailsRes»
PID
EV
,n
eMSP
,R,σ
eMSP
,AU T N,xRE S,CK,IK
←−−−−−−−−−−−−−−−−−−−−−−−−
[OCCP]
6: eMSP
pk
ext
← eMSP
cert
7: a ← Verify(eMSP
pk
, n
eMSP
∥n
EV
∥R, σ
eMSP
)
8: If a = 1 then proceed; Else abort.
9: K ← KDF(K
s
, n
EV
, n
eMSP
,CCID, eMSPID)
10: PID
EV
$
← {0, 1}
∗
11: Parse AU T N as (xMAC, xCONC)
12: xSQN
eMSP
← CONC ⊕ f
5
(R, K)
13: MAC
EV
← f
1
(xSQN
eMSP
∥R, K)
14: If (SQN
EV
< xSQN
eMSP
< SQN
EV
+ ∆) ∧
(MAC
EV
= xMAC) then proceed; Else abort.
15: SQN
EV
← SQN
eMSP
16: RES ← f
2
(R, K)
17: xCK ← f
3
(R, K)
18: xIK ← f
4
(R, K)
RES
−−−−−−−−−−−−−−→
«AuthorizationReq»
1: If RES = xRES then auth
succeed and proceed; Else
abort.
RES
←−−−−−−−−−−−−−
«AuthorizationRes»
1: Use CK and IK to protect
communications with EV
or for authentication.
Figure 3: Three-party protocol for generating and verifying authentication vectors.
EV CP eMSP
Keys: CK, IK (CK, IK, CP
cert
,CP
sk
,eMSP
root
) (eMSP
sk
, eMSPpk)
1: D := PID
EV
∥M
read
2: C ← AEAD.Enc(CK, D)
C
−−−−−−−−−−−−−−−−→
«MeteringRecieptReq»
←−−−−−−−−−−−−−−−
«MeteringRecieptRes»
1: D ← AEAD.Dec(CK,C)
2: σ
CDR
← Sign(CP
sk
,CDR)
3: M
receipt
← PID
EV
∥CDR∥σ
CDR
M
receipt
−−−−−−−−−−−−−→
[OCCP]
1: a ← Verify(CP
pk
, σ
CDR
)
2: If a = 1 then proceed for billing on
eMAID
?
← PID
EV
Figure 4: Billing process involving EV, CP, and eMSP.
Enhancing Anonymity for Electric Vehicles in the ISO 15118 Plug-and-Charge
479

f
3
(R, K) and f
4
(R, K), respectively. The eMSP signs
n
eMSP
|n
EV
|R using eMSP
sk
to produce σ
eMSP
, then
sends n
eMSP
, R, σ
eMSP
, (AUT H, xRES) and (CK, IK)
to the CP via a secure channel. The CP stores xRES,
CK, and IK, and forwards n
eMSP
, R, σ
eMSP
, AUT H to
the EV.
(c) EV Authenticates eMSP and Computes an
Authentication Vector and Keys (EV ⇒ eMSP):
Upon receiving (n
eMSP
, R, σ
eMSP
, AUT H) from the
CP, the EV verifies n
eMSP
and R using σ
eMSP
and
eMSP
pk
. If successful, it computes the shared K using
the KDF. The EV extracts xCONC and xMAC from
AUT H and checks: (i) if xMAC matches the locally
computed MAC from K, R, and recovered SQN
eMSP
;
and (ii) if xSQN
eMSP
; satisfies xSQN
eMSP
> SQN
EV
;
and xSQN
eMSP
< SQN
EV
+∆, where ∆ is a threshold.
If both hold, the EV updates SQN
EV
; and derives
RES, xCK, and xIK using K and R.
(d) CP Authenticates EV for Charging (CP ⇒ EV):
When the CP sends an authentication request, denoted
by Auth_Req, the EV computes RES using f
2
on R
and K and sends it to the CP. After that, the CP checks
whether the received RES equals xRES received from
the eMSP. If they are equal, the CP successfully au-
thenticates the EV and authorizes the EV for charg-
ing. The rest of the communications such as the cur-
rent meter reading between the EV and CP are (confi-
dentiality and integrity) protected using the keys xCK
and xIK.
EV Sends Metering Data to eMSP for Billing
(EV ←→ CP): The EV prepares the metering data
by concatenating its pseudonymous ID (PID
EV
) with
the meter reading (M
read
). To ensure confidential-
ity and integrity, the EV encrypts this data using an
AEAD encryption scheme, producing the ciphertext
C. The encrypted metering data is then transmitted to
the CP. Upon receiving C, the CP decrypts it to re-
trieve the original metering information. The CP then
generates a Charging Data Record (CDR) and signs it
using its private key (CP
sk
) to ensure authenticity. The
signed CDR, along with the EV’s pseudonymous ID,
is compiled into a metering receipt (M
receipt
), which
is then forwarded to the eMSP. The eMSP verifies
the signature on the CDR using the CP’s public key
(CP
pk
). If the verification succeeds, the eMSP links
the session to the EV’s contract ID (eMAID) and
proceeds with the billing process on the correspond-
ing user. Figure 4 illustrates the secure transmission
of meter reading data to the eMSP for billing, en-
suring data confidentiality, integrity, and authenticity
throughout the process.
6 SECURITY ANALYSIS
Our study targets three objectives: EV confidential-
ity, location privacy, and EV unlinkability by the CP.
Using the LINDDUN framework, we derived pri-
vacy requirements (P1–P5) and verified them with the
Tamarin Prover (Meier et al., 2013). Lemma 1 proves
injective agreement between EV and CP to ensure au-
thentication uniqueness, while Lemma 2 confirms the
encrypted CCID (eMAID) is never exposed to the CP.
Data: All traces
For all EV, CP, ds, and #i:;
If Commit(EV, CP, ds) happens at step #i:;
There exists a step # j such that:;
Running(CP, EV, ds) happens at step
# j,;
# j < #i, and;
For all steps #i
2
, if
Commit(EV, CP, ds) happens at #i
2
,
then #i
2
= #i.;
Lemma 1: Injective Agreement Between EV and CP.
Data: All traces
For all EV, CP, C, and #i:;
If AEADEncryptionPerformed(EV, C)
happens at step #i and
CipherSentToCP(CP, C) happens at step #i:;
There exists a step # j such that:;
AEADDecryptionPerformed(eMSP, C)
happens at step # j.;
Lemma 2: CCID (eMAID) Not Shared with CP.
Privacy Properties:
• EV Identity Confidentiality (P1): Prevents CP and
CPO from learning the EV’s identity (eMAID)
during authentication; E ncrypted CCID Shared
with CP Only proves eMAID is AEAD-encrypted
and only the eMSP can decrypt it.
• Prevention of Unique Identification (P2): Injective
Agreement Between EV and CP and E ncrypted
CCID Shared with CP Only ensure session fresh-
ness and that CP cannot learn the eMAID or key
material, preventing tracking.
• Charging Session Unlinkability (P3): E ncrypted
CCID Shared with CP Only guarantees session in-
dependence by encrypting eMAID, preventing CP
from linking multiple sessions.
• Charging Data Aggregation Prevention (P4):
E ncrypted CCID Shared with CP Only ensures the
CPO cannot learn eMAID or aggregate data across
locations.
• EV Location Privacy (P5): E ncrypted CCID
Shared with CP Only prevents CPs from learning
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
480

B1 B2 B3
4
6
8
10
12
4.79
4.99
5.2
9.57
9.47
9.88
Billing Time (ms)
Figure 5: Total Billing Time Compari-
son on Desktop (blue) and Raspberry Pi
(red). B1: AES-GCM, B2: Ascon, B3:
ChaCha20-Poly1305.
S1 S2 S3 S4 S5 S6 S7 S8
S9
110
120
130
140
108.99
111.68
118.33
120.19
124.44
116.98
117.43
121
118.55
109.15
116.36
117.45
122.54
125.08
121.97
121.89
128.65
125.98
119.16
122.9
117.74
114.48
120.92
118.05
124.86
133.92
126.53
Time (ms)
Milenage TUAK TUAK-FIPS202
Figure 6: Comparing AKA protocol execution time on Desktop across S1–S9.
S1 S2 S3 S4 S5 S6 S7 S8
S9
900
1,000
1,100
1,200
1,085.09
1,184.65
1,062.75
1,074.59
1,166.87
1,018.78
1,027.41
1,115.64
1,064.85
1,098.5
1,062.22
1,055.01
1,018.29
1,091.8
987.4
1,118.24
1,127.89
1,024
1,043.86
1,070.93
1,010.29
994.6
1,086.61
1,012.83
1,099.76
1,130.18
1,114.3
Time (ms)
Figure 7: Comparing protocol execution time on Raspberry Pi across S1–S9.
eMAID, ensuring EV movements cannot be cor-
related by the CPO.
7 EXPERIMENTAL EVALUATION
Testbed Devices and Protocols. We implemented
our hybrid authentication protocol in the setup shown
in Figure 2 and Figure 3. The EV runs on a Rasp-
berry Pi 4 Model B (2 GB RAM, ARM Cortex-A72,
1.5 GHz), and the CP is deployed on a 64-bit desktop
with an Intel Core i7-9700 (3.0 GHz, 16 GB RAM,
8 cores with hyper-threading). To simulate plug-and-
charge, we connected the EV and CP via a direct net-
work cable. For simplicity, the eMSP runs in the same
environment as the CP, and uses the TLS-based OCPP
protocol, which is outside this work’s scope.
Security Implementation Details. The hybrid
authentication protocol was implemented in C as a
standalone cryptographic module, easily integrable
into the EcoG-io/ISO 15118 framework (EcoG.io,
2024) using C-type bindings for Python. The protocol
is optimized with mbedTLS (Limited, 2024) and
OpenSSL 3.0.5 (Project, 2024). It uses the NIST P-
256 curve for ECDSA digital signatures, and supports
authenticated encryption with ASCON AEAD, AES-
GCM, and ChaCha20-Poly1305. HKDF is employed
for key derivation, with SHA-256, SHA-3, and
ASCON hash as hashing options. For the AKA pro-
tocol, we implemented the Milenage set, TUAK set
(3rd Generation Partnership Project (3GPP), 2024),
and an enhanced TUAK variant using FIPS 202
(Bertoni et al., 2024). We experimented with various
combinations to identify efficient cipher suites, par-
ticularly targeting lightweight designs for constrained
environments. For further discussions, acronyms are
used to represent cipher suites. Our cipher suites are:
S1: AES_GCM_SHA2 S2: AES_GCM_SHA3
S3: AES_GCM_AsconAEAD
S4: AsconAEAD_SHA2 S5: AsconAEAD_SHA3
S6: AsconAEAD_AsconHash
S7: ChaCha20-Poly1305_SHA2
S8: ChaCha20-Poly1305_SHA3
S9: ChaCha20-Poly1305_AsconHash
7.1 Performance Results
This section presents our performance evaluation
across two aspects: 1) charging authentication and
2) billing. We conducted micro-benchmarking to
measure function-level execution times and macro-
benchmarking for overall protocol performance, en-
abling comparison against the ISO 15118-20 stan-
dard. Figure 6 and Figure 7 compares execution
times across cipher suites S-S9 on desktop and Rasp-
berry Pi, respectively. Figure 5 depicts the execu-
tion time comparison of the billing procedure. Our
results show that the Milenage-based AKA protocol
with AES_GCM_SHA2 achieves the best performance on
desktop, while the TUAK-based AKA protocol with
Ascon is optimal for Raspberry Pi. AES-GCM is the
best choice for billing on desktop, and Ascon AEAD
Enhancing Anonymity for Electric Vehicles in the ISO 15118 Plug-and-Charge
481

performs best for Raspberry Pi billing. All execu-
tion times are within acceptable limits and outperform
ISO15118 constraints (International Organization for
Standardization, 2022).
8 CONCLUSIONS
The current ISO-15118 PnC architecture lacks inher-
ent privacy protections. As a result, during authenti-
cation, charging authorization, and billing, the system
exposes a significant amount of personal information
about the EV to the CP and CPO. To address this,
we propose an anonymous authenticated key estab-
lishment protocol for ISO-15118 PnC charging, lever-
aging the KEM/DEM mechanism, inspired by 3GPP
AKA protocols. Our protocol ensures EV identity
confidentiality against CP and CPO, location privacy
and EV untraceability. It maintains fundamental se-
curity properties, is optimised through cross-platform
evaluations of computational and energy efficiency,
and is formally verified with the Tamarin Prover for
robustness. Overall, it provides a secure, scalable, and
privacy-preserving enhancement for ISO-15118 PnC.
ACKNOWLEDGEMENTS
The first and second authors are partially funded by
the NB Power cybersecurity research chair grant.
REFERENCES
3rd Generation Partnership Project (3GPP) (2021). 3gpp ts
33.535: Authentication and key management for ap-
plications (akma). Accessed: 2025-01-22.
3rd Generation Partnership Project (3GPP) (2024). 3g secu-
rity; security architecture. Technical Specification TS
33.102, 3rd Generation Partnership Project (3GPP).
Release 18, Accessed: 2024-11-30.
3rd Generation Partnership Project (3GPP) (2024). TUAK:
A New Set of 3GPP Authentication and Key Genera-
tion Algorithms.
Althouse, J., Atkinson, J., and Atkins, J. (2017a). JA3:
Fingerprinting TLS Clients. https://github.com/
salesforce/ja3. Accessed: 2024-12-14.
Althouse, J., Atkinson, J., and Atkins, J. (2017b). JA3S:
Server-Side TLS Fingerprinting. https://github.com/
salesforce/ja3. Accessed: 2024-12-14.
Arfaoui, G., Bultel, X., Fouque, P.-A., Nedelcu, A., and
Onete, C. (2019). The privacy of the tls 1.3 protocol.
Cryptology ePrint Archive.
Bertoni, G., Daemen, J., Peeters, M., and Assche, G. V.
(2024). The keccak reference - fips 202: Sha-3
standard: Permutation-based hash and extendable-
output functions. https://keccak.team/specifications.
html\#FIPS_202.
Brickell, E., Camenisch, J., and Chen, L. (2004). Direct
anonymous attestation. In Proceedings of the 11th
ACM conference on Computer and communications
security, pages 132–145.
Deng, M., Wuyts, K., Scandariato, R., Preneel, B., and
Joosen, W. (2011). A privacy threat analysis frame-
work: supporting the elicitation and fulfillment of
privacy requirements. Requirements Engineering,
16(1):3–32.
EcoG.io (2024). Iso 15118 framework. https://github.com/
EcoG-io/ISO15118.
International Energy Agency (2023). Global ev outlook
2023: Catching up with climate ambitions. Technical
report, International Energy Agency (IEA). Accessed:
2024-11-30.
International Organization for Standardization (2022). ISO
15118-20:2022 - Road vehicles – Vehicle to grid com-
munication interface – Part 20: 2nd generation net-
work layer and application layer requirements.
Kern, D., Lauser, T., and Krauß, C. (2022). Integrating
privacy into the electric vehicle charging architecture.
Proceedings on Privacy Enhancing Technologies.
Limited, A. (2024). mbedTLS: Open Source SSL/TLS Li-
brary. Version 3.2.1.
Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).
The tamarin prover for the symbolic analysis of secu-
rity protocols. In Computer Aided Verification: 25th
International Conference, CAV 2013, Saint Peters-
burg, Russia, July 13-19, 2013. Proceedings 25, pages
696–701. Springer.
Project, T. O. (2024). Openssl: The open source toolkit for
ssl/tls. https://www.openssl.org/. Version 3.0.5.
Regulation, P. (2016). Regulation (eu) 2016/679 of the eu-
ropean parliament and of the council. Regulation (eu),
679:2016.
Sion, L., Wuyts, K., Yskout, K., Van Landuyt, D., and
Joosen, W. (2018). Interaction-based privacy threat
elicitation. In 2018 IEEE European Symposium on
Security and Privacy Workshops (EuroS&PW), pages
79–86.
Yue, X., Bi, X., Yang, H., Bai, S., and He, Y. (2024). Pap: A
privacy-preserving authentication scheme with anony-
mous payment for v2g networks. IEEE Transactions
on Smart Grid.
Zaverucha, G. M. and Stinson, D. R. (2010). Short one-time
signatures. Cryptology ePrint Archive.
Zelle, D., Springer, M., Zhdanova, M., and Krauß, C.
(2018). Anonymous charging and billing of electric
vehicles. In Proceedings of the 13th International
Conference on Availability, Reliability and Security,
pages 1–10.
Zhao, T., Zhang, C., Wei, L., and Zhang, Y. (2015). A se-
cure and privacy-preserving payment system for elec-
tric vehicles. In 2015 IEEE International Conference
on Communications (ICC), pages 7280–7285. IEEE.
SECRYPT 2025 - 22nd International Conference on Security and Cryptography
482