Experimental Analysis of Key Exchange Protocols Using the JAKE Framework

Full text

Experimental Analysis of Key Exchange Protocols
Using the JAKE Framework
Octavian Catrina
Politehnica University of Bucharest
Bucharest, Romania
octavian.catrina@upb.ro
Radu Caius Lupu
Politehnica University of Bucharest
Bucharest, Romania
radu.lupu@upb.ro
Abstract—The paper presents JAKE, a lightweight Java frame-
work that supports the prototype implementation and experimen-
tal analysis of cryptographic protocols used to establish secure
communication channels. A first goal is to provide a common
platform for experiments with various key exchange protocol
constructions and cryptographic algorithm configurations, sim-
plifying their comparative performance analysis. Another goal
is to facilitate proof-of-concept implementations of attacks on
these protocols. The paper presents the system architecture
used for JAKE implementations and experiments, examples of
implemented protocols and performance measurements, as well
as examples of attacks on (vulnerable variants) of the protocols.
Index Terms—communication security, key exchange protocols,
cryptographic protocols, cryptography
I. INT ROD UC TI ON
Secure communication channels provide data authentication
and confidentiality in the presence of an adversary that controls
the communication network. These security properties are
achieved using various cryptographic algorithms. The data
transferred during the secure sessions is protected using fast
and efficient authenticated encryption algorithms based on
secret-key (symmetric) cryptography. However, the manage-
ment of the secure sessions is a more complex task: it involves
interactions that open a session, negotiate the cryptographic
techniques that will be used, authenticate the parties, establish
secret session keys, and more. Depending on the application
requirements and the deployment scenario, these tasks can be
achieved using secret-key cryptography, public-key (asymmet-
ric) cryptography, or (more generally) a combination of both.
The task of securing the communication sessions is usually
split into two sub-tasks achieved by different protocols: secure
data transfer (e.g., IPsec ESP and TLS Record protocols)
and secure session management (e.g., IPsec IKE and TLS
Handshake protocols [1], [2]). The latter are usually called
authenticated key exchange (AKE) protocols, since their main
goal is to establish secret session keys, ensuring entity authen-
tication, key secrecy and key authentication.
The design and analysis of AKE protocols has substantially
evolved during the last two decades and can be considered a
mature sub-field of cryptography. However, it remains an ac-
tive research subject, due to the evolution of the cryptographic
Part of this work was supported by POC72/1/2, nr.127454, ”SECREDAS
Support Project”, contract 7/1.1.3H/6.01.2020, associated to the Horizon 2020
ECSEL Joint Undertaking research project SECREDAS.
algorithms, the growing variety of application requirements,
and the gradual discovery of new attacks. For example, the
specification of TLS 1.3 required a substantial re-design of
TLS 1.2, to deal with many vulnerabilities and attacks discov-
ered during the previous two decades [3].
We introduce in this paper a lightweight Java framework,
JAKE, aimed at supporting the prototype implementation and
experimental analysis of AKE protocol constructions, attacks
on AKE protocols, and comparative performance analysis.
The paper is structured as follows. Section II presents the ar-
chitecture of the secure communication system used by JAKE
for the implementation and analysis of AKE protocols and
attacks. Section III provides examples of AKE protocols and
performance measurements and Section IV presents attacks
on vulnerable variants of these protocols, implemented using
JAKE. The main results are summarized in Section V.
II. OVE RVIEW OF THE JAKE FRA ME WO RK
The high level architecture of a secure communication
system developed using JAKE is shown in Fig. 1. The system
consists of application processes interconnected by a commu-
nication subsystem. JAKE uses a peer-to-peer (P2P) system
model that supports various system architectures, communica-
tion topologies, and attack scenarios (examples in Fig. 1).
An App class implements either the application run by an
honest user, or an attack carried out by the adversary. The
applications interact using a generic, message-based communi-
cation service, with message authentication and confidentiality.
An App instance can handle multiple concurrent communica-
tion sessions with one or more App instances.
ASession class creates a new secure session using an
AKE protocol and protects the data messages using authenti-
cated encryption (AED) and the session keys established by
the AKE protocol. These protocols are implemented using the
standard cryptographic libraries provided by the Java Cryp-
tography Architecture (JCA). An App instance selects and
configures the protocols and the cryptographic algorithms used
in its sessions. An adversary App uses a special Session
class to implement an attack on a protocol. The Session
instances are distinguished using unique session identifiers
chosen by the session initiator.
The Communicator class models a communication chan-
nel controlled by an active, man-in-the-middle (MITM) adver-
O. Catrina, R. C. Lupu. Experimental Analysis of Key Exchange Protocols Using the JAKE Framework. 14th International Conference on Communications
(COMM 2022), June 16-18, 2022, Bucharest, Romania, IEEE, 2022. https://doi.org/10.1109/COMM54429.2022.9817171.
978-1-6654-9485-4/22/$31.00 ©2022 IEEE

Fig. 1. Secure communication system implemented using the JAKE framework (Adv is the adversary).
Fig. 2. JAKE graphical user interface.
sary. App instances are distinguished by unique names. The
Communicator discovers the App instances and learns their
names when the system is initialized.
The message headers include the source name, the des-
tination name, the session identifier, and the message type
(Fig. 2). If the adversary is not present, the Communicator
delivers the messages to the destination indicated in the
header. Otherwise, the messages sent by the honest parties
are delivered to the adversary and the messages sent by the
adversary are delivered to the destination in the header. Thus,
the honest parties communicate via an adversary that can read,
modify, reorder, insert, and delete messages. The adversary can
send messages with any source name and initiate sessions with
any party, executing the attack implemented by its Session
class, rather than the actual protocol.
The system’s Communicator and App instances are exe-
cuted in different processes, on the same computer or on differ-
ent computers. The Coordinator classes create, configure
and start the system’s Communicator and App instances, for
different system architectures and communication topologies.
Each App process registers with the Communicator process
by establishing a TCP connection and specifying its name.
Then, the Coordinator starts the test scenario, while the
Communicator forwards the messages between the App
processes, as explained above.
The experiments are carried out using a graphical user
interface (GUI) or a command line interface (CLI). The GUI
(Fig. 2) simplifies and speeds up the selection and configura-
tion of the tests, the protocols, the cryptographic algorithms
and their parameters, and other features (execution traces,
performance measurements, message authentication attacks).
Both interfaces support the experimental analysis based on
traces of the protocol execution and running time measure-
ments. Real time traces show the protocols’ state, actions,
decisions, and exchanged messages, with configurable levels
of detail. The GUI is more convenient for functional analysis
with all processes running on the same computer, while
the CLI is mainly used for performance measurements with
processes running on different computers.
III. AUTH EN TI CATE D KEY EXCHANGE PROTOC OL S
We examine in the following several examples of protocols
implemented using JAKE, as well as their security and per-
formance. The AKE protocols combine cryptographic methods
for entity authentication, joint secret key generation, and data
authentication [4], [5]. Successful termination of the key ex-
change must guarantee both key secrecy and key authentication
even when the adversary controls the parties’ communication
channel. Essentially, a party that runs the protocol obtains
(unfalsifiable) evidence that it shares a session key only
with a certain other party. Some applications require mutual
authentication (MAKE). However, for many others, unilateral

Fig. 3. Generic AKE protocol messages.
authentication (UAKE) is sufficient. For example, TLS always
authenticates the server and optionally authenticates the client.
The AKE protocols usually support explicit authentication
and key confirmation. This means they provide evidence about
the identity of the party with whom the session key is shared
and that the party actually knows the key. Some AKE protocols
provide simpler implicit authentication. This ensures that only
a party identified in the protocol can learn the key, but without
evidence it actually executed the protocol and knows the key.
AKE protocols are also expected to provide session key in-
dependence and (usually) forward secrecy. Key independence
ensures that compromise of a session key does not affect
the security of any other (past or future) session. Forward
secrecy means that disclosure of the long-lived keys used in the
protocol does not compromise the confidentiality of previous
sessions (future sessions will inevitably be compromised).
The current version of JAKE focuses on the cryptographic
core of the protocols. However, the implementations can be
extended to provide additional functionality often found in the
protocols used in practice (like IKEv2 and TLS 1.3): negotiate
the protocol’s version and options, especially the cryptographic
algorithms and their parameters; hide the identities of the
parties; renew the session keys and set up multiple secure
channels; send data during the key exchange to reduce latency.
The message flows used to implement AKE protocols with
explicit authentication are shown in Fig. 3. InitAB and
InitBA exchange information used by the cryptographic
algorithms that authenticate the parties and generate the secret
session keys, such as random nonces and Diffie-Hellman (DH)
public keys. They can also negotiate the protocol options and
the cryptographic algorithms and their parameters. AuthAB
Fig. 4. AKE based on DH, SIG and PKC.
Fig. 5. AKE based on DH, MAC and PSK.
and AuthBA contain information used to verify the identities
of the parties and authenticate the contents of the previous
messages. This can be achieved using symmetric and/or asym-
metric data authentication: a Message Authentication Code
(MAC) and/or a digital signature (SIG), respectively. IKEv2
and TLS 1.3 support both variants: they can authenticate the
parties using either MAC and a pre-shared secret key (PSK),
or using SIG and a public-key certificate (PKC).
The protocols can order and combine these messages in
several ways, to satisfy specific application requirements and
reduce latency. For example, the variant MAKE 4M is similar
to IKEv2, while the variant MAKE 3M is similar to TLS 1.3.
These choices reflect slightly different objectives and priorities
in the design of IKEv2 and TLS 1.3.
Fig. 4 and Fig. 5 show examples of AKE protocols imple-
mented using JAKE. The UAKE protocols allow party Ato
authenticate party B. The MAKE protocols add a third mes-
sage that allows Bto authenticate A. The protocols in Fig. 4

authenticate the parties using asymmetric cryptography (SIG
and PKC), so they can establish secure connections between
arbitrary clients and servers over the Internet. However, if the
parties can pre-share secret keys, they can use the protocols in
Fig. 5, with authentication based on symmetric cryptography
(MAC and PSK), which is much more efficient.
Both constructions satisfy the core security requirements
discussed above. They achieve forward secrecy by using the
Diffie-Hellman (DH) key agreement. Session key confirmation
and identity hiding can be added as in [2] or [5]. The protocol
descriptions omit the session identifier; one can assume the
sessions are identified by the pair of nonces (NA|NB).
We take a closer look at the protocol MAKE-SIG-PKC-DH
(Fig. 4). The others are similar. The protocol is described for
generic DH with public parameters a finite cyclic group Gof
prime order qin which the Decisional Diffie-Hellman (DDH)
problem is hard and a generator g∈G[6].
Ainitiates a key exchange with B. She chooses a random
nonce NA∈ {0,1}tand a random x∈[1, q −1] (private DH
key) with uniform probability distribution and computes X=
gx(public DH key). Asends a message InitAB containing
its nonce NAand DH public key X. The bit-length tis chosen
such that the probability of reusing nonces during the lifetime
of the signature keys is negligible (e.g., t≥256 bits).
After receiving InitAB,Bchooses a random nonce NB∈
{0,1}tand a random y∈[1, q −1] (private DH key) and
computes Y=gy(public DH key) and the authenticator
RB=SI GskB(A|NB|NA|gy|gx)(’|’ denotes concatenation).
Then, Bsends the messages InitBA and AuthBA that con-
tain his nonce NB, DH public key Y, authenticator RB, and
certificate P KC (B, pkB). The certificate binds the signature
verification key pkBto the identity Band RBdemonstrates
knowledge of the matching private key skB.Bcomputes the
session key KS=P RFNA|NB(Xy), where PRF is a pseudo-
random function implemented using a MAC algorithm.
After receiving these messages, Averifies P KC (B, pkB)
(issuer’s signature, validity period, revocation status). If the
certificate is valid, Aconcludes that B’s signature verification
key is pkBand uses it to verify RB. If the verification suc-
ceeds, Aconcludes she is communicating with B. Otherwise
Aaborts the session. Then, Acomputes the authenticator
RA=SI GskA(B|NA|NB|gx|gy)) and sends the message
AuthAB containing RAand the certificate P KC (A, pkA).A
computes the session key KS=P RFNA|NB(Yx).
Breceives AuthAB and verifies A’s identity using the same
method as A. If the verification succeeds, Bconcludes he is
communicating with A. Otherwise Baborts the session.
Since Yx=Xy=gxy, the parties compute the same
session key. The received DH public keys must be validated
before session key computation. The JAKE implementations
use a key derivation function (KDF) based on the Extract-
then-Expand construction [7], rather than a simple PRF, and
generate different session keys for each data stream.
The security of these protocols relies on the standard
security properties of the DH key agreement and SIG (or
MAC) algorithms [6] and the random choice of nonces and DH
TABLE I
AKE PERFORMANCE MEASUREMENTS.
Protocol Algorithms Time [ms]
UAKE-MAC-PSK-DH ECDH (256), HMAC 4.44
UAKE-SIG-PKC-DH ECDH (256), ECDSA (256) 8.46
DH (3072), RSA (3072) 13.03
MAKE-MAC-PSK-DH ECDH (256), HMAC 4.50
MAKE-SIG-PKC-DH ECDH (256), ECDSA (256) 9.02
DH (3072), RSA (3072) 17.13
keys. The authenticators RAand RBare used to demonstrate
knowledge of the private key associated to the identity and
authenticate the exchanged nonces and DH public keys.
Table I shows the results of performance tests for 2 parties
that run the protocols in Fig. 4 and Fig. 5, interconnected as
shown in Fig. 1. The protocols were executed on PCs with
quad-core, 3.6 GHz CPU (Intel I7), running Linux 20.04 and
JDK 17, connected to a switch with 1 Gbps data rate. The
round-trip transfer delay of protocol messages was 1.1 ms.
The tests measured the duration of the key exchange at the
initiator for several algorithm selections and 128-bit security:
•U/MAKE-MAC-PSK-DH using ECDH with 256-bit keys
and HMAC with SHA256 and 128-bit keys.
•U/MAKE-SIG-PKC-DH using ECDH with 256-bit keys
or DH with 3072-bit keys and ECDSA with 256-bit keys
or RSA with 3072-bit keys, HMAC with 128-bit keys.
•256-bit random nonces and 128-bit session keys.
The protocols U/MAKE-MAC-PSK-DH, are simpler and
clearly faster than U/MAKE-SIG-PKC-DH, due to authentica-
tion based on symmetric cryptography, but their use is limited
to deployment scenarios in which the parties can pre-share
secret keys. The performance of U/MAKE-SIG-PKC-DH is
substantially improved by replacing finite-field DH and RSA
with the elliptic-curve algorithms ECDH and ECDSA.
IV. ATTAC KS O N AKE PROTOCOLS
A basic goal of JAKE is to support proof-of-concept imple-
mentations of attacks on AKE protocols. We’ll discuss in the
following examples of attacks on vulnerable variants of the
protocols described in Section III, implemented using JAKE.
Fig. 6 shows an interleaving attack on a variant of the UAKE
protocol in Fig. 4. The goal is to enable Ato authenticate B
and establish a secret session key known only to Aand B.
However, design flaws in this variant of the protocol allow
the adversary Eto convince Athat she shares a key with B,
although the key is actually shared with E.
The attack proceeds as follows. Astarts a session S1
with Bby sending a message InitAB that contains its
identity A, random nonce NAand DH public key gx.E
intercepts A’s message and starts a session S2with Bby
sending A’s InitAB (specifying Aas message source). B
replies with the messages InitBA and AuthBA that con-
tain a random nonce NB, DH public key gy, authenticator
RB=SI GskB(A|NA|gx), and P K C(B, pkB).

Fig. 6. Interleaving attack on vulnerable variant of UAKE-SIG-PKC-DH.
Fig. 7. Interleaving attack on vulnerable variant of MAKE-SIG-PKC-DH.
After receiving B’s messages, Ecancels the session S2and
continues S1.Egenerates a DH key pair z, gzand replies
to Ain the session S1by sending the messages InitBA
and AuthBA that contain the authenticator RBobtained
from B, a nonce NE, the DH public key gz, and B’s PKC
(specifying Bas message source). Ecomputes the session
key KS=P RFNA|NB(gxz). After receiving E’s messages,
Asuccessfully verifies that the identity of the responder is B
and computes the same session key as E.
The attack breaks both the key authentication property and
the key secrecy property by exploiting the following flaws:
•The authenticator is not properly bound to the current
session. This allows Eto obtain from Bthe authenticator
needed in session S1by executing in parallel the session
S2. To avoid this, the authenticator must depend on fresh
random values chosen by both parties and their identities.
•The protocol does not authenticate the nonce and the DH
public key sent by B. This allows Eto replace B’s DH
public key, gy, with its own DH public key, gz, without
invalidating the authenticator obtained in session S2. To
avoid this, both parties must authenticate all the values
used for session key derivation (as in Fig. 4).
Fig. 7 shows a variant of the MAKE protocol in Fig. 4
with similar flaws. The goal in this case is to enable Aand
Bto authenticate each-other and to establish a session key
known only to Aand B. At first glance, the protocol seems to
authenticate the parties using the challenge-response paradigm
and establish the session key using authenticated DH key
agreement. However, the adversary Ecan use the interleaving
attack shown in Fig. 7 to convince Bthat he shares the key
with A, while the key is actually shared with E.
The attack on the MAKE protocol (Fig. 7) exploits the same
flaws as the attack on the UAKE protocol (Fig. 6). Observe that
Ecan break the key secrecy and key authentication properties
of the MAKE protocol both as initiator and as responder. In
Fig. 7, Estarts a session with Band impersonates A. On
the other hand, if Astarts a session with B, then Ecan
impersonate Busing the attack in Fig. 6.
The interleaving attacks in Fig. 6 and Fig. 7 can be adapted
to break similarly flawed variants of the UAKE and MAKE
protocols based on MAC and PSK depicted in Fig. 5.
Fig. 8 shows another variant of the MAKE protocol in
Fig. 4 and a more subtle type of attack. This variant of the
protocol seems to avoid the design pitfalls discussed above,

Fig. 8. Identity misbinding attack on vulnerable variant of MAKE-SIG-PKC-DH.
since the authenticators sent by the parties cover both random
nonces and DH public keys. However, something is wrong: the
adversary Ecan use the attack in Fig. 8 to convince Bthat he
shares the key with E, while in fact Bshares the key with A.
This type of attack is called identity-misbinding or unknown
key-share attack (a similar attack is described in [5]).
The attack proceeds as follows. Astarts a session with B
by sending a message InitAB that contains her identity A,
random nonce NAand DH public key gx.Edelivers this
message to Bafter changing the source name from Ato E.
Breplies to Awith the messages InitBA and AuthBA
that contain his identity B, random nonce NB, DH public key
gy, authenticator RB=SI GskB(B|NB|NA|gy|gx), and cer-
tificate P KC (B, pkB).Edelivers them without modification.
After receiving B’s messages, Asuccessfully verifies B’s
identity and computes the session key KS=P RFN(gxy),
where N=NA|NB.Aterminates the protocol by sending to
Ba message AuthAB that contains her authenticator RA=
SI GskA(A|NA|NB|gx|gy)) and certificate P K C(A, pkA).A
is convinced that she has established a secure session with B.
Ereplaces A’s message with a message AuthAB that
contains E’s authenticator RE=SIGskE(E|NA|NB|gx|gy))
and certificate P KC (E, pkE). After receiving this message,
Bsuccessfully verifies that the initiator’s identity is Eand
computes the same session key as A.
Edoes not obtain any information about the session key
shared by Aand B, so the attack does not break the key
secrecy property. Nevertheless, it breaks the key authentication
property, since Bbelieves he shares a session key with E,
while the key is actually shared with A. This is sufficient
to break some applications. For instance, if Eattacks this
protocol when Asubmits to Bher answers to an online exam,
then Bis convinced that he has received the answers from E.
The protocol in Fig. 8 does not bind the authenticators to the
identities of both parties, Aand B. Thus, A’s authenticator can
be replaced with E’s authenticator. The authenticator is bound
to the claimant’s identity by the certificate and the private
key. To bind it to both identities, the input of the signature
generation algorithm must include the verifier’s identity, not
the claimant’s identity (as in Fig. 4).
V. CONCLUSIONS
The paper presents a lightweight Java framework, JAKE,
that simplifies the prototype implementation and experimental
analysis of cryptographic protocols used to create secure
channels for communication systems.
JAKE supports the implementation of various system archi-
tectures, protocol constructions and attacks, as well as perfor-
mance measurements. The attacks help to better understand
the design and implementation of these protocols, by showing
how subtle flaws can be exploited to break their security
properties. On the other hand, the comparative performance
analysis of various protocol constructions and cryptographic
algorithm configurations is substantially simplified by provid-
ing a common platform to implement and test them.
The development of JAKE is an ongoing project. It already
supports common protocol constructions and it is continuously
improved and extended, to include emerging cryptographic
algorithms and protocol designs.
REFERENCES
[1] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, “RFC 7296.
Internet Key Exchange Protocol Version 2 (IKEv2),” IETF, 2014.
[2] E. Rescorla, “RFC 8446. The Transport Layer Security (TLS) Protocol
Version 1.3,” IETF, 2018.
[3] Y. Sheffer, R. Holz, and P. Saint-Andre, “RFC 7457, Summarizing Known
Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS),”
IETF, 2015.
[4] C. Boyd, A. Mathuria, and D. Stebila, Protocols for authentication and
key establishment. Springer, 2020.
[5] H. Krawczyk, “SIGMA: The ’SIGn-and-MAc’ approach to authenticated
Diffie-Hellman and its use in the IKE protocols,” in Advances in Cryp-
tology - CRYPTO’03, ser. Lecture Notes in Computer Science, vol. 2729.
Springer, 2003, pp. 400–425.
[6] J. Katz and Y. Lindell, Introduction to modern cryptography. Chapman
& Hall/CRC, 2008.
[7] H. Krawczyk, “Cryptographic extraction and key derivation: The HKDF
scheme,” in Advances in Cryptology – CRYPTO 2010, ser. Lecture Notes
in Computer Science, vol. 6223. Springer, 2010, pp. 631–648.