Secrecy and Authenticity Properties of the Lightning Network Protocol
Hans H
¨
uttel
a
and Vilim Staroveski
Department of Computer Science, Aalborrg University, Denmark
Keywords:
Cryptographic Protocols, Protocol Verification, Blockchain.
Abstract:
The Lightning Network is a second layer protocol that sits on top of the Bitcoin cryptocurrency. It is a decen-
tralized network of payment channels first conceptualized in 2014 and its first implementation was released
in 2017. Being a fairly new technology, it may have security issues that we do not know of and the goal of
this report is to analyse the Lightning Network to further investigate its security properties. The focus of this
analysis is on answering whether the confidential data is kept secret and whether the user authenticity holds in
the protocol. In the analysis we use the process algebra to formally describe cryptographic protocols that form
the Lightning Network and an automatic cryptographic protocol analyser called ProVerif for their analysis.
1 INTRODUCTION
The Lightning Network is a decentralized network
of bidirectional payment channels that sits on top
of the Bitcoin blockchain. It was conceptualized in
2014 and a release candidate for version 1.0 of the
Lightning protocol was released in December 2017.
At the time of writing, the Lightning Network con-
sists of about 8000 nodes, with about 37000 payment
channels that altogether contain about 1000 bitcoins
(worth about 8 million US dollars with the current ex-
change rate).
Unfortunately there is still little work done on
analysing the security properties of the Lightning Net-
work. Kiayias et al. (Kiayias and Litos, 2019) have
studied the protocols from the point of view of com-
posable protocols, but some aspects of the protocol
have not been addressed, and the focus is on the prop-
erties of the cryptographic primitives involved.
One of the limitations of the Lightning Network
is that users needs to be online when receiving a pay-
ment. This could potentially expose their private keys,
which would give an attacker full access to user funds.
The secrecy of the user private key is therefore the
main security property of the Lightning Network. An-
other important security property that the Lightning
Network must satisfy is user authenticity. The proto-
col must be able to guarantee that if user A believes
that is interacting with user B, then this is the case.
In this paper we use the automatic protocol ver-
ifier ProVerif (Blanchet et al., 2018) to give a fully
a
https://orcid.org/0000-0002-4603-5407
automated analysis of these security properties of the
Lightning Network.
The Lightning Network is a collection of four
cryptographic protocols, and each of these has to be
described and analyzed separately.
The four subprotocols constituting the Lightning
Network are: The key agreement protocol that estab-
lishes a secure and authenticated connection to an-
other user, the channel opening protocol opening
a payment channel to another user, the onion rout-
ing protocol for making a payment to a user and the
channel closing protocol closing an existing payment
channel. In this paper we are analysing these proto-
cols with the exception of the channel closing proto-
col. Due to its simple behaviour (which simply is that
a channel can be closed independently from the other
participant), we omit its analysis in this paper.
The rest of our paper is organized as follows. In
Section 2 we describe the analysis methodology that
we follow, and in particular the Dolev-Yao attacker
model and the applied π-calculus that form the ba-
sis of ProVerif. Section 3 contains the specifications
of each of the subprotocols of the Lightning Network
and the results of our analysis.
2 THE SYMBOLIC APPROACH
TO SECURITY ANALYSIS
In this paper we use the symbolic approach to pro-
tocol analysis based on the Dolev-Yao assumptions
(Dolev and Yao, 1981).
Hüttel, H. and Staroveski, V.
Secrecy and Authenticity Properties of the Lightning Network Protocol.
DOI: 10.5220/0008974801190130
In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 119-130
ISBN: 978-989-758-399-5; ISSN: 2184-4356
Copyright
c
 2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
119

2.1 The Dolev-Yao Model
The underlying assumption of the symbolic approach
is that all messages exchanged in the protocol will be
sent through public channels. These are assumed to
be controlled by an attacker that can
• obtain any message passing through the network
• is a legitimate user of the network and can interact
with other users
• will have an opportunity to be a receiver to any
user
Moreover, an attacker will also be able to modify,
delete and inject messages as well as use the user
defined cryptographic functions for manipulating the
obtained data (e.g. accessing the ith element in a tu-
ple, constructing a tuple, decrypting a message, etc.).
However, the attacker we are considering will not be
able to perform any sort of cryptoanalysis or any op-
eration that would break the cryptography properties
of the defined cryptographic functions (e.g. finding
an inverse of an one-way hash function used in the
protocol).
2.2 The Applied π-calculus
We use the applied π-calculus for modelling the cryp-
tographic protocols. The choice of using a process
calculus lends itself well to a protocol analysis that
uses the Dolev-Yao-assumptions; as pointed out by
Abadi and Gordon (Abadi and Gordon, 1999), we can
then view any attacker as a process that interacts with
the protocol that is the protocol itself. Our version
of the applied π-calculus is that of (Blanchet, 2002),
which is used in the ProVerif protocol analyzer de-
scribed in Section 2.4.
We consider an infinite set of names (channels) N
and an infinitive set of variables X . We let a, b and
c range over N and x, y and z range over X . We will
use the letters M and N for terms and the letters P, Q
and R for processes.
The syntax of processes is given in Table 1. The
process 0 is the inactive process. The output process
ahNi.P outputs the term N on channel a and contin-
ues as P. The input process a(x).P allows a term to be
input on the channel a and binds the term to x within
the continuation P. The process P | Q denotes the par-
allel execution of processes P and Q. The replication
process !P denotes an infinite supply of copies of the
process P. The match process if M = N then P com-
pares the terms M and N.
A name n occurring in a process P is called free if
it is not bound by a restriction or an input. The set of
free names in P is denoted by fn(P).
Table 1: Formation rules for terms and processes in the ap-
plied π-calculus.
M,N ::= x, y, z | a, b,c | f (M
1
,...,M
n
)
P,Q ::= 0 | ahNi.P | a(x).P | P | Q |!P | (νa)P
| if M = N then P | let x = g(M
1
,..., M
n
) in P
Table 2: Structural congruence rules.
P ≡ P P | 0 ≡ P
P | Q ≡ Q | P P | (Q | R) ≡ (P | Q) | R
(νa)(νb)P ≡ (νb)(νa)P (νa)0 ≡ 0
(νa)(P | Q) ≡ P | (νa)Q if a /∈ fn(P)
P → Q
P ≡ Q
P ≡ Q
Q ≡ P
P ≡ Q Q ≡ R
P ≡ R
P ≡ Q
P | R ≡ Q | R
P ≡ Q
(νa)P ≡ (νa)Q
In the original π-calculus, the only terms that can
be transmitted along channels are names, but since
the applied π-calculus is used for describing crypto-
graphic protocols, we here allow a richer set of data
terms. Terms are now built from a signature, a finite
set of function symbols Σ that represent the crypto-
graphic primitives. Some function symbols are con-
structors that are used for building terms (e.g. in en-
cryption), while others are destructors used for taking
terms apart (e.g. in decryption).
In Table 1, f represents a constructor, while g
represents a destructor ( f ,g ∈ Σ). The evaluation of
data terms is defined by a collection of term reduction
rules that are specific to a given signature. We write
M → M
0
if the term M evaluates to M
0
and M 9 if the
term M cannot be evaluated.
The notion of structural congruence is used to
identify processes that are identical up to structure.
The rules defining the relation are presented in Table
2.
The semantics of the π-calculus is given by a re-
duction relation, → defined inductively by a collec-
tion of reduction rules on closed processes, presented
in Table 3. We write P →
∗
P
0
if either P = P
0
or P
reduces to P
0
in 1 or more reduction steps.
To the reduction rules for the π-calculus we add
the reduction rules in Table 4; they describe how
terms are evaluated by applying destructors in let-
expressions. If a term g(M
1
,. .. ,M
n
) evaluates to M
0
,
the process continues as P{
M
0
/
x
}, otherwise, it termi-
nates.
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
120

Table 3: Reduction rules of the π-calculus.
ahMi.P | a(x).Q → P | Q{M/x}
P → Q
P | R → Q | R
!P → P |! P
P ≡ P
0
P
0
→ Q
0
Q
0
≡ Q
P → Q
P → Q
(νa)P → (νa)Q
if M = M then P → P
Table 4: Reduction rules for let-expressions.
g(M
1
,. .. ,M
n
) → M
0
let x = g(M
1
,. .. ,M
n
) in P → P{M
0
/x}
g(M
1
,. .. ,M
n
) 9
let x = g(M
1
,. .. ,M
n
) in P → 0
2.3 Secrecy and Authenticity
In order to define security properties, we need to de-
fine an adversary present in the protocol. We are as-
suming an adversary that has Dolev-Yao capabilities
previously defined. An adversary is any process that
has a set of public names S in its initial knowledge
and does not contain correspondence assertions (de-
fined below).
Definition 1. Let S be a finite set of names. A closed
process Q is an S-adversary if and only if f n(Q) ⊆ S
and Q does not contain correspondence assertions or
executed correspondence assertions.
Informally, the secrecy of a term M is preserved in the
protocol, if M is never output to the public channels
and therefore obtained by the attacker.
Definition 2 ((Blanchet, 2002)). Let P be a closed
process and M be a message. We say that P outputs M
on c if and only if P →
∗
ahMi.R | R
0
for some process
R and R
0
and channel a. We say that P preserves the
secrecy of M from S if and only if P | Q does not
output M on c for any S-adversary Q and any c ∈ S .
We say that principal A is authentic to principal B,
if whenever B has completed a protocol run believ-
ing that A was the initiator, then this was indeed the
case. To express this, we use correspondence asser-
tions that are labelled with terms and are of the form
begin(M) and end(M). The intention is that in ev-
ery run of a protocol, if an end-expression end(M)
appears, a begin-expression begin(M) with the same
label M must have appeared earlier in the run. We
add correspondence assertions to the process calculus
syntax as shown in Table 5.
The reduction rules for correspondence asser-
tions are shown in Table 6; they tell us how as-
Table 5: Formation rules for correspondence assertions.
P ::= begin(M).P | end(M).P
| begin ex(M).P | end ex(M).P
Table 6: Reduction rules for correspondence assertions.
begin(M).P → begin ex(M) | P
end(M).P → end ex(M) | P
sertions evolve to executed correspondence asser-
tions: begin(M).P evolves to begin ex(M) | P and
end(M).P evolves to end ex(M) | P.
We distinguish between non-injective and injec-
tive agreement.
Definition 3. The closed starting process P satisfies
non-injective agreement with respect to S-adversaries
if and only if for any S-adversary Q, for any P
0
such
that P | Q →
∗
P
0
, for any M, if end ex(M) occurs
in P
0
, then begin ex(M) also occurs in P
0
. (In P
0
,
the restrictions are renamed such that they bind pair-
wise different names, and names different from free
names.)(Blanchet, 2002)
If we need to express that the event end(M) hap-
pened after the event begin(M) and at most as many
times as event begin(M), we use injective agreement.
Definition 4. The closed starting process P satisfies
injective agreement with respect to S-adversaries if
and only if for any S -adversary Q, for any P
0
such
that P | Q →
∗
P
0
, for any M, the number of oc-
currences of end ex(M) in P
0
is at most the num-
ber of occurrences of begin ex(M) in P. (In P
0
,
the restrictions are renamed such that they bind pair-
wise different names, and names different from free
names.)(Blanchet, 2002)
2.4 ProVerif
ProVerif is a tool for automatically analyzing the se-
curity of cryptographic protocols (Blanchet, 2014)
that is able to prove secrecy, authenticity and obser-
vational equivalence properties of cryptographic pro-
tocols. Its analysis considers a unbounded number
of sessions and unbounded message space and per-
formed on a symbolic model of a protocol (Blanchet,
2014). ProVerif automatically translates a protocol
described in the applied π-calculus into an abstract
model using Horn clauses and determines whether the
required security properties hold based on the resolu-
tion of these clauses.
Secrecy and Authenticity Properties of the Lightning Network Protocol
121

3 ANALYZING THE LIGHTNING
NETWORK PROTOCOLS IN
ProVerif
An important part of our work has been the descrip-
tion of each subprotocol in ProVerif.
3.1 Protocol Signature
For modeling the protocols will use the signature (S,
Σ), where S is a set of sorts and Σ is a set of function
symbols. S contains two sorts: S = {term,key}. The
sort term will be used for all hashes, encrypted data
and messages exchanged between the nodes, while
the sort key will be used for all types of keys used
(e.g. ephemeral and static keys, encryption keys, etc).
The function symbols are: Σ = {⊥, pk, hash, ECDH,
HKDF, senc, sdec, [ ], ith
i
} and their definitions are
given in Table 7 where:
• ⊥ represents an empty data
• ECDH(k
1
,k
2
) is an abstraction of the Elliptic
Curve Diffie-Hellman(Diffie and Hellman, 1976)
operation which combines two keys k
1
and k
2
and
produces a new key
• senc(d,k) encrypts data d with a symmetric key k
and produces a ciphertext
• sdec(d,k) decrypts encrypted data d with a sym-
metric key k and produces its plaintext version
• pk(k) is a function that generates a public key
from a private key k
• HKDF(k,x) represents a Hashed Message Au-
thentication Code (HMAC)-based key derivation
function (Krawczyk and Eronen, 2010), where a
key k and data x are combined to create a new
term; newly created term is actually a key which
is used to derive more additional keys
• hash(d) is a representation of a standard hash
function that takes a data d and returns its hash
value
• [x, y] is a tuple creation function in which we also
consider the short form [x
1
,x
2
,..., x
n−1
,x
n
] for the
expression [x
1
,[x
2
,[..., [x
n−1
,x
n
]]]]
• ith
i
(M) function that returns i-th element of a tu-
ple M
• getmess(s) returns the data that is being signed
with the signature s
• sign(d,k) signs a data d with a key k
• checksig(s,k) returns true, if the signature s was
made using a private key that corresponds to the
public key k
Table 7: Cryptographic primitives.
⊥ : → term
ECDH : key × key → key
senc : term × key → term
sdec : term × key → term
pk : key → key
HKDF : key ×term → term
hash : term → term
[ ] : term × term → term
ith
i
: term → term
getmess : term → term
sign : term × key → term
checksig : term × key → term
bk : key × key → key
HMAC : term × key → term
Table 8: Additional reduction rules.
sdec(senc(M,N), N) → M
ith
i
([M
1
,..., M
n
]) → M
i
getmess(sign(M,N),N) → M
checksig(sign(M, N), pk(N)) → true
• bk(k, b), creates a new key by combining a key k
with a blinding factor b, which can be considered
as another key
• HMAC(d, k) represents the keyed hash message
authentication code computed over the data d and
using the key k
We will also extend the applied π-calculus reduction
system with additional reduction rules for the destruc-
tors we will use. The rules are given in Table 8.
3.2 The Key Agreement Protocol
The first subprotocol of the Lightning Network that
we are going to analyse is the key agreement proto-
col. Its goals are to provide mutual authentication be-
tween two participants (i.e. nodes) and to create se-
cret session keys (asymmetric encryption key-pairs:
ek
I
, dk
I
for the protocol initiator, and ek
R
, dk
R
for the
responder). The keys will be used to encrypt all future
messages exchanged between the participants.
3.2.1 Properties
The protocol is expected to satisfy the following prop-
erties:
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
122

Table 9: The key agreement protocol message sequence.
node
R
→ node
I
: s pub
R
node
I
→ node
R
: [e pub
I
,senc(⊥, [k
1
,0, h
1
])]
node
R
→ node
I
: [e pub
R
,senc(⊥, [k
2
,0, h
2
])]
node
I
→ node
R
: [senc(s pub
I
,[k
2
,1, h
3
]),
senc(⊥,[k
3
,0, h
4
])]
• the initiating node must be authentic to the re-
sponding node - if the responding node reaches
the end of the protocol with a belief that it has
done so with the initiating node, then the initiat-
ing node has actually engaged a session with the
responding node
• the responding node must be authentic to the ini-
tiating node - similarly to the above
• the secrecy of the generated secret session keys
ek
I
and dk
I
must hold - if the initiating node has
reached the end of the protocol with the respond-
ing node, then the keys ek
I
and dk
I
, that the initiat-
ing node has generated, are secret and can be used
for encrypting and decrypting future communica-
tion with the responding node
• the secrecy of the generated secret session keys
ek
R
and dk
R
must hold - similarly to the above
3.2.2 Protocol Description
The key agreement protocol chosen for the Lightning
Network is Noise XK (Perrin, 2016), (lightningnet-
work, 2017b). Throughout the handshake process,
each side maintains the following variables:
• e: a freshly generated ephemeral key-pair
• s: a static key-pair
• ck: the chaining key (a key that is built iteratively
until the end of the protocol when it is used to
derive the encryption keys)
• h: the handshake hash (accumulated hash of all
handshake data sent and received; never transmit-
ted, but used as the Associated Data in the AEAD
messages)
• k
1
, k
2
, k
3
: the intermediate keys which are used
for encrypting messages during the handshake
(lightningnetwork, 2017b).
Key-pairs will have a private and public components
which we will differentiate by appending the word
priv for private and pub for public. In table 9 we can
see the message sequence of the protocol.
The protocol starts with the initalization phase,
where both parties initialize their handshake state,
namely, ck and h. The participants also acquire the
Table 10: The initiating node process.
node
I
(s priv
I
,s pub
R
,h
0
,ck
0
) =(1)
(νe priv
I
)c(s pub
X
).begin(s pub
X
).(2)
let k
1
= ith
0
(HKDF(ck
0
,es)) in(3)
let ck
1
= ith
1
(HKDF(ck
0
,es)) in(4)
ch[pk(e priv
I
),d
1
]i.c(m
2
).(5)
let e pub
R
= ith
0
(m
2
) in(6)
let k
2
= ith
0
(HKDF(ck
1
,ee)) in(7)
let ck
2
= ith
1
(HKDF(ck
1
,ee)) in(8)
let d
2
= ith
1
(m
2
) in(9)
let k
3
= ith
0
(HKDF(ck
2
,se)) in(10)
let ck
3
= ith
1
(HKDF(ck
2
,se)) in(11)
let dd
2
= sdec(d
2
,[k
2
,0, h
3
]) in(12)
if dd
2
= ⊥ then chm
3
i.(13)
if s pub
X
= s pub
R
then end(pk(s priv
I
))(14)
where



















































h
1
= hash([h
0
, pk(e priv
I
)])
es = ECDH(e priv
I
,s pub
X
)
d
1
= senc(⊥, [k
1
,0, h
1
])
h
2
= hash([h
1
,d
1
])
h
3
= hash([h
2
,e pub
R
])
ee = ECDH(e priv
I
,e pub
R
)
h
4
= hash([h
3
,d
2
])
d
3
= senc(pk(s priv
I
),[k
2
,1, h
4
])
h
5
= hash([h
4
,d
3
])
se = ECDH(s priv
I
,e pub
R
)
ek
I
= ith
0
(HKDF(ck
3
,⊥))
dk
I
= ith
1
(HKDF(ck
3
,⊥))
m
3
= [d
3
,d
4
]
static public key of the other party and hash it together
with some additional data known to both sides.
We first describe the actions of the initiating node.
In Table 10, we can see the applied π-calculus model
of the initiating node process.
The actions of the initiating node are
• Generate a new ephemeral key pair e (line 2)
• Compute the first intermediary key and update the
chaining key ck
I
using the outputs from HKDF
function (lines 3,4)
k
1
= ith
0
(HKDF(ck
I
,ECDH(e priv
I
,s pub
R
)))
ck
I
= ith
1
(HKDF(ck
I
,ECDH(e priv
I
,s pub
R
)))
• Encrypt an empty text (⊥) with k
1
and send it to-
gether with the ephemeral public key (e pub
I
)to
the responding node (line 5)
Secrecy and Authenticity Properties of the Lightning Network Protocol
123

• Receive a response from the responding node and
extract e pub
R
and the encrypted data from it (line
6)
• Compute a new intermediary key and update the
chaining key ck
I
using the outputs from HKDF
function (line 7):
k
2
= ith
0
(HKDF(ck
I
,ECDH(e pub
R
,e priv
I
)))
ck
I
= ith
1
(HKDF(ck
I
,ECDH(e pub
R
,e priv
I
)))
• Validate the encrypted data; if it fails, stop (line 8)
• Encrypt the static public key with k
2
(line 9)
• Compute a new intermediary key and update the
chaining key ck using the outputs from HKDF
function (lines 10,11)
k
3
= ith
0
(HKDF(ck
I
,ECDH(s priv
I
,e pub
R
)))
ck
I
= ith
1
(HKDF(ck
I
,ECDH(s priv
I
,e pub
R
)))
• Encrypt an empty text (⊥) with k
3
and send it to-
gether with encrypted static public key to the re-
sponding node (line 12)
• Derive the session keys from the chaining key us-
ing the HKDF function
In Table 11, we can see the applied π-calculus model
of the responding node process. The actions of the
responding node are
• Receive a message from the initiating node and
extract e pub
I
(line 16) and encrypted data from
it
• Compute the first intermediary key (line 17) and
update the chaining key ck
R
using the outputs
from the HKDF function (lines 18,19)
k
1
= ith
0
(HKDF(ck
R
,ECDH(e pub
I
,s priv
R
)))
ck
R
= ith
1
(HKDF(ck
R
,ECDH(e pub
I
,s priv
R
)))
• Validate the encrypted data (line 20); if it fails,
stop
• Generate a new ephemeral key pair e
• Compute a new intermediary key and update the
chaining key ck
R
using the outputs from HKDF
function (lines 21,22)
k
2
= ith
0
(HKDF(ck
R
,ECDH(e priv
R
,e pub
I
)))
ck
R
= ith
1
(HKDF(ck
R
,ECDH(e priv
R
,e pub
I
)))
• Encrypt an empty text (⊥) with k
2
and send it to-
gether with the ephemeral public key (e pub
R
)to
the initiating node (line 23)
• Receive a message from the initiating node and
decrypt s pub
I
from and save the additional en-
crypted data (line 24)
• Compute a new intermediary key and update the
chaining key ck
R
using the outputs from HKDF
function (lines 23,24)
k
3
= ith
0
(HKDF(ck
R
,ECDH(e priv
R
,s pub
I
)))
ck
R
= ith
1
(HKDF(ck
R
,ECDH(e priv
R
,s pub
I
)))
• Validate the encrypted data from the previous
message; if it fails, stop (line 30)
• Derive the session keys from the chaining key us-
ing the HKDF function (line 31)
We have omitted some of the steps in both of the de-
scriptions (e.g. updating the handshake hash h) but
they can be easily read from the corresponding mod-
els in Table 10 and Table 11.
Lastly, in Table 12, we can see the main process
that that will start the initiating and responding nodes
processes. Additionally, the participants static public
keys are outputted to the public channel to make sure
that the attacker receives them.
3.2.3 Analysing the Protocol in ProVerif
The representation of the protocol in ProVerif is a
straightforward translation of the specifications in Ta-
ble 10, 11 and 12.
To test the secrecy properties we use the queries
query attacker(secret ek I);
attacker(secret dk I);
attacker(secret ek R);
attacker(secret dk R).
The free names secret ek I, secret dk I, secret ek R
and secret dk R denote the secret keys that are en-
crypted using session keys ek
I
, dk
I
, ek
R
and dk
R
re-
spectively and output to the public channel. If the at-
tacker is able to obtain (decrypt) the encrypted form
of these names, then we know that it has obtained
some of the session keys.
To test for authenticity properties we use the
queries
query x:public key, y:public key;
inj−event(end I(x,y)) ==>
inj−event(begin I(x,y)).
query x:public key, y:public key;
inj−event(end R(x,y)) ==>
inj−event(begin R(x,y)).
These queries test for injective agreement and work as
described in Section 2.3. The first query tests if the re-
sponding node authentic to the initiating node, while
the second tests if the initiating node is authentic to
the responding node.
ProVerif outputs the results:
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
124

RESULT not attacker(secret ek I[]) is true.
RESULT not attacker(secret dk I[]) is true.
RESULT not attacker(secret ek R[]) is true.
RESULT not attacker(secret dk R[]) is true.
RESULT inj−event(end I(x 229,y 230)) ==>
inj−event(begin I(x 229,y 230)) is false.
RESULT inj−event(end R(x 231,y 232)) ==>
inj−event(begin R(x 231,y 232)) is true.
The secrecy of the session keys is proven to hold for
the protocol. Neither the keys owned by the initiat-
ing node and the ones owned by the responding node
were leaked to the attacker. However, while the ini-
Table 11: Responding node process.
node
R
(s priv
R
,s pub
I
,h
0
,ck
0
) =(15)
(νe priv
R
)c(m
1
).(16)
let e pub
X
= ith
0
(m
1
) in(17)
let d
1
= ith
1
(m
2
) in(18)
let k
1
= ith
0
(HKDF(ck
0
,se)) in(19)
let ck
1
= ith
1
(HKDF(ck
0
,se)) in(20)
let dd
1
= sdec(d
1
,[k
1
,0, h
1
]) in(21)
if dd
1
= ⊥ then(22)
let k
2
= ith
0
(HKDF(ck
1
,ee)) in(23)
let ck
2
= ith
1
(HKDF(ck
1
,ee)) in(24)
ch[pk(e priv
R
),d
2
]i.c(m
3
).(25)
let d
3
= ith
0
(m
3
) in(26)
let d
4
= ith
1
(m
3
) in(27)
let s
p
ub
X
= sdec(d
3
,[k
2
,1, h
4
]) in begin(s pub
X
).
(28)
let k
3
= ith
0
(HKDF(ck
2
,es)) in(29)
let ck
3
= ith
1
(HKDF(ck
2
,es)) in(30)
let dd
4
= sdec(d
4
,[k
3
,0, h
5
]) in(31)
if dd
4
= ⊥ then(32)
if s pub
X
= s pub
I
then end(pk(s priv
R
))(33)
where









































h
1
= hash([h
0
,e pub
X
])
se = ECDH(s priv
R
,e pub
X
)
h
2
= hash([h
1
,d
1
])
h
3
= hash([h
2
, pk(e priv
R
)])
ee = ECDH(e priv
R
,e pub
X
)
d
2
= senc(⊥, [k
2
,0, h
3
])
h
4
= hash([h
3
,d
2
])
h
5
= hash([h
4
,d
3
])
es = ECDH(e priv
R
,s pub
X
)
dk
R
= ith
0
(HKDF(ck
3
,⊥))
ek
R
= ith
1
(HKDF(ck
3
,⊥))
Table 12: The main process.
P = (νs priv
I
,s priv
R
,h
0
,ck
0
)
let s pub
I
= pk(s priv
I
) in chs pub
I
i.
let s pub
R
= pk(s priv
R
) in chs pub
R
i.
((!node
I
(s priv
I
,s pub
R
,h
0
,ck
0
))|
(!node
R
(s priv
R
,s pub
I
,h
0
,ck
0
)))
Table 13: Messages exchanged in the channel opening pro-
tocol (lightningnetwork, 2017a).
node
I
→ node
R
: open channel
node
R
→ node
I
: accept channel
node
I
→ node
R
: f unding created
node
R
→ node
I
: f unding signed
node
I
→ node
R
: f unding locked
node
R
→ node
I
: f unding
locked
tiating node is authentic to the responding node, the
responding node fails to be authentic to the initiat-
ing node. This means that the initiating node can be
tricked into thinking that it is running a protocol with
the responding node, when in fact it is running it with
the attacker.
3.3 The Channel Opening Protocol
After the users have completed the key agreement
protocol, they are able to open a channel between
them. To open a channel, users need to create a
funding transaction and two initial commitment trans-
actions. In the messages exchanged in the proto-
col, users will exchange the data needed for creating
the aformentioned transactions. The channel open-
ing protocol consists of several messages being ex-
changed and we can see them in table 13. Table 13
gives us a simplified overview of the protocol where
we see what messages are being exchanged. Mes-
sages exchanged in this protocol will be encrypted us-
ing the session keys that the users established in the
key agreement protocol.
3.3.1 Properties
The security of the protocol relies on the keys that
were established beforehand. The participants will
use the session keys for encrypting all of the data that
is being exchanged. The protocol must preserve the
session keys secrecy. Additionally, the participants
were authenticated in the key agreement protocol, so
the protocol must ensure that the participants authen-
ticity still holds. We can summarize the security prop-
erties as follows:
Secrecy and Authenticity Properties of the Lightning Network Protocol
125

• the encryption key used by the initiating node is
secret
• the encryption key used by the responding node is
secret
• the initiating node must be authentic to the re-
sponding node
• the responding node must be authentic to the ini-
tiating node
3.3.2 Protocol Description
To open a channel, we need to create three transac-
tions: one funding transaction and two initial com-
mitment transactions. At least one of the users need
to fund the newly created channel with the funding
transaction. The funding transaction sends funds to
a special 2-of-2 multisig bitcoin address. The funds
that are on this address can only be spent by using
both of the users private keys, so that one party can
not take the funds for itself. Another problem that
the users want to avoid is the other party disappearing
and forever locking the funds in the 2-of-2 multisig
address. The initial commitment transactions are the
mechanism that prevents this. They are transactions
that spend all of the funds from the multisig address
and dividing the funds according to how much each
party has initially put in the channel. In order to cre-
ate the aformentioned transactions, users will need to
communicate and exchange the needed data, such as
channel parameters and signatures for the initial com-
mitment transactions. The channel parameters will
not be very important for this model and they will be
presented as a single blob of data that needs to stay
confidential.
In this analysis we will simplify the contents of
the messages in compare to the actual specification.
The messages are listed and described as follows:
• open channel will contain the initiating node pub-
lic key (s pub
I
) and all other data will be repre-
sented as data I
• accept channel will contain the responding node
public key (s pub
R
) and all other data will be rep-
resented as data R
• f unding created will contain the initiating node
signature, created for signing a tuple containing
data I and data R, using the private key s priv
I
where s pub
I
= pk(s priv
I
)
• f unding signed will contain the responding node
signature, created for signing a tuple containing
data I and data R, using the private key s priv
R
where s pub
R
= pk(s priv
R
)
Table 14: The channel opening protocol message sequence
diagram.
node
I
→ node
R
: senc([s pub
I
,data I],ek
I
)
node
R
→ node
I
: senc([s pub
R
,data R],ek
R
)
node
I
→ node
R
: senc(sign([data I, data R],
s priv
I
),ek
I
)
node
R
→ node
I
: senc(sign([data I, data R],
s priv
R
),ek
R
)
node
I
→ node
R
: senc(⊥,ek
I
)
node
R
→ node
I
: senc(⊥,ek
R
)
• f unding locked will be an empty message, sent
as a information that the sender has reached the
end of the protocol
All messages will be encrypted using the encryption
keys (ek
I
, ek
R
) that the participants have established
in the key agreement protocol. The message sequence
diagram is present in table 14. The initiating node will
start the protocol with sending its public key and the
additional data encrypted using ek
I
to the responding
node. The responding node will decrypt the message
using dk
R
and answer with its public key and addi-
tional data also encrypted using ek
R
. The nodes will
then exchange signatures for the data exchanged in
the first messages, check the signatures and if they are
valid, continue with the protocol. The protocol will
end with the exchange of empty f unding locked mes-
sages. We have modeled the protocol in the applied
pi-calculus. The initiating node process can be seen
in Table 15 while the responding node process can be
seen in Table 16. Finally, the main process starts the
initiating and responding node processes and can be
seen in Table 17.
3.3.3 Analysing the Protocol in ProVerif
The ProVerif code used for the testing whether the
properties presented in 3.3.1, actually hold for the
subprotocol will be omited. The reason for this is be-
cause it looks very similar to the one used for the anal-
ysis of the key agreement protocol in section 3.2.3,
and we will only present the results of the analysis.
RESULT not attacker(secret ek I[]) is true.
RESULT not attacker(secret ek R[]) is true.
RESULT inj−event(end I(x 81)) ==>
inj−event(begin I(x 81)) is true.
RESULT inj−event(end
R(x 82)) ==>
inj−event(begin R(x 82)) is true.
We can see that both secrecy of the session keys and
the authenticity properties hold for the protocol.
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
126

Table 15: The initiating node process.
node
I
(s priv
I
,s pub
R
,ek
I
,dk
I
) =(34)
(νdata
I
)chenc m
1
i.(35)
c(enc m
2
).let m
2
= sdec(enc m
2
,dk
I
) in(36)
let s pub
X
= ith
0
(m
2
) in(37)
let data
X
= ith
1
(m
2
) in begin(s pub
X
).(38)
chenc m
3
i.c(enc m
4
).(39)
let sig X = sdec(enc m
4
,dk
I
) in(40)
let t = getmess(sig X) in(41)
let b
2
= checksig(sig X,s pub
X
) in(42)
if b = true then chenc m
5
i.(43)
if s pub
X
= s pub
R
then end(pk(s priv
I
))(44)
where

















enc
m
1
= senc([pk(s priv
I
),data
I
],ek
I
)
sig = sign([data
I
,data
X
],s
p
riv
I
)
enc m
3
= senc(sig,ek
I
)
b
1
= (t = (data I,data X ))
b = b
1
&&b
2
enc m
5
= senc(⊥, ek
I
)
Table 16: The responding node process.
node
R
(s priv
R
,s pub
I
,ek
R
,dk
R
) =(45)
(νdata
R
)c(enc m
1
).(46)
let m
1
= sdec(enc m
1
,dk
R
) in(47)
let s pub
X
= ith
0
(m
1
) in(48)
let data
X
= ith
1
(m
1
) in begin(s pub
X
).(49)
chenc m
2
i.c(enc m
3
).(50)
let sig X = sdec(enc m
3
,dk
R
) in(51)
let t = getmess(sig X) in(52)
let b
2
= checksig(sig X,s pub
X
) in(53)
if b = true then chenc m
4
i.(54)
c(enc m
5
).chenc m
6
i.(55)
if s pub
X
= s pub
I
then end(pk(s priv
R
))(56)
where

















enc m
2
= senc([pk(s priv
R
),data
R
],ek
R
)
b
1
= (t = [data I,data X ])
b = b
1
&&b
2
sig = sign([data
X
,data
R
],s priv
R
)
enc m
4
= senc(sig,ek
R
)
enc m
6
= senc(⊥, ek
R
)
3.4 The Onion Routing Protocol
Multi-hop payments enable users to pay to a recip-
ient they are not directly connected to (i.e. do not
Table 17: The main process.
P =(νs priv
I
,s priv
R
,ek
I
,ek
R
)
let s pub
I
= pk(s priv
I
) in chs pub
I
i.
let s pub
R
= pk(s priv
R
) in chs pub
R
i.
((!node
I
(s priv
I
,s pub
R
,ek
I
,ek
R
))|
(!node
R
(s priv
R
,s pub
I
,ek
R
,ek
I
)))
share an open channel with). The Lightning Network
uses onion routing to securely and privately route the
HTLCs (Hash-Time-Locked Contracts) through the
network (lightningnetwork, 2017c). The packets sent
through the network are obfuscated in layers of en-
cryption so that an attacker is not able to access their
content without the right key. Moreover, the nodes
that are a part of the payment route are only able to ac-
cess the information they need to forward the packet
to the next node in the route. Additionally, the pack-
ets are encrypted using the session keys established in
the key agreement protocol described earlier.
3.4.1 Properties
The security properties of the protocol can be anal-
ysed from two perspectives: the first one from the
point of view of a node being a part of the payment
route and the second one, from the point of view of
a node that is not a part of the route. We will anal-
yse both perspectives. The secrecy properties that the
protocol must hold are:
• secrecy of the session keys
• secrecy of the payment source private key
• secrecy of the payment intermediaries private
keys
• secrecy of the payment destination private key
• secrecy of the encrypted payload of every packet
In addition to the secrecy properties, the protocol
must also guarantee that the payment sender is au-
thentic to the payment receiver. Since the protocol is
based on a one-way communication (the packet is be-
ing sent from the source along the nodes in the route
to the receiver, without the receiver sending a reply
back) it is not possible to authenticate the payment
receiver. In other words, the payment receiver need to
know exactly who did send the packet with the pay-
ment information. If this property does not hold for
the protocol, the payment receiver might think that it
got the packet from the real payment sender, when
in fact it was the attacker that send it. The payment
sender authenticity property will therefore, be defined
as:
Secrecy and Authenticity Properties of the Lightning Network Protocol
127

Table 18: The onion routing protocol message sequence.
node
S
→ node
1
: senc([d
1
,senc(o
1
,k
2
)],k
1
)
node
1
→ node
2
: senc([d
2
,senc(o
2
,k
3
)],k
2
)
...
node
i−1
→ node
i
: senc([d
i
,senc(o
i
,k
i+1
)],k
i
)
...
node
19
→ node
D
: senc(d
D
,k
D
)
• authenticity of the payment sender to the payment
recipient: if the payment recipient reaches the end
of the protocol with a belief that it has done so
with the payment sender, then the payment sender
has actually initiated a session with the payment
recipient
3.4.2 Protocol Description
In this section, node
S
will be the node that is sending
a payment through the route of intermediaries called
”hops” to the recipient node we will call node
D
. The
Lightning Network uses source-routing and node
S
is
the one constructing the route. We skip the part of
the route creation and assume that node
S
has con-
structed a valid route (i.e. has selected the nodes
through which the payment will be sent). In table 18
we can see the onion routing message sequence di-
agram, where a node
i
possesses a key k
i
and node
D
possesses the key k
D
.
The onion packet contains the details for each
of the intermediary nodes specifying how much and
where they should send funds to. In return, they re-
ceive a fee, but only if the payment is successful. To
prevent the intermediary nodes of knowing the private
information about the payment, the packet is wrapped
in layers of encryption and every intermediary node
can decrypt only one layer. The encryption algorithm
used in the Lightning Network is ChaCha20 (Nir and
Langley, 2018) which uses a symmetric key for en-
crypting and decrypting the data. Additionally, the
authenticity and integrity of the data in the packet is
protected by the use of Keyed-Hash Message Authen-
tication Code (HMAC). If the packet was tampered
with by one of the intermediary nodes, the HMAC in-
cluded in the packet will not match the one computed
over the received data and therefore the packet should
be ignored and discarded. Additionally, every packet
has a fixed size of 1366 bytes, meaning that packets
that have to go through 1 hop and the ones that have
to go through 19 hops, will have the same size which
further increases the privacy of the payment.
We can describe the protocol on a simple one hop
scenario, which we will use for the analysis later on:
Table 19: node
S
process.
node
S
(s priv
S
,s pub
H
,ek
S
) =
(νe priv
H
,d
H
,d
D
)c
1
(s pub
X
).begin(s pub
X
).
c
1
hsenc([pk(e priv
H
),x
H
,HMAC(x
H
,ss
1
)],ek
S
)i
where

















b = hash([pk(e priv
H
),ss
1
])
e priv
D
= bk(e priv
H
,b)
x
H
= senc([d
H
,x
D
,HMAC(x
D
,ss
2
)],ss
1
)
x
D
= senc([d
D
,⊥], ss
2
)
ss
1
= ECDH(e priv
H
,s pub
H
)
ss
2
= ECDH(e priv
D
,s pub
X
)
Table 20: The node
H
process.
node
H
(s priv
H
,ek
H
,dk
H
) =
c
1
(enc m).let m = sdec(enc m, dk
H
) in
let e pub
H
= ith
0
(m) in
let x
H
= ith
1
(m) in
let h
prev
= ith
2
(m) in
if h = h
prev
then
let data = sdec(x
H
,ss
1
) in
let x
D
= ith
1
(data) in
let h
nxt
= ith
2
(data) in
c
2
hsenc([bk(e pub
H
,b), x
D
,h
nxt
],ek
H
)i
where





ss
1
= ECDH(s priv
H
,e pub
H
)
h = HMAC(x
H
,ss
1
)
b = hash(e pub
H
,ss
1
)
node
S
sends an onion packet over a hop node node
H
,
to the destination node
D
. node
H
is a common peer
from node
S
and node
D
(i.e. have an open channel in-
between both nodes). All of the node processes can
be see in Table 19, 20 and 21. The packets will be
sent along two public channels c
1
and c
2
, the first one
connecting node
S
and node
H
while the second one is
a connection between node
H
and node
D
. In short, the
packet is being encrypted using the asymmetric en-
cryption with a key set up between the nodes in the
route. The shared encryption keys are generated as
a result of a Elliptic Curve Diffie Hellman (ECDH)
(Diffie and Hellman, 1976) between the nodes. After
it reaches the next node in the route, it is partly de-
crypted (i.e. one part of the packet can be decrypted),
so the node knows where to forward it and then the
other part (i.e. the part that couldnt be decrypted), is
sent to the next node.
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
128

Table 21: The node
D
process.
node
D
(s priv
D
,dk
D
) =(57)
c
2
(enc m).let m = sdec(enc m, dk
D
) in(58)
let e pub
D
= ith
0
(m) in(59)
let x
D
= ith
1
(m) in(60)
let h
prev
= ith
2
(m) in(61)
if h = h
prev
then(62)
let data = sdec(x
D
,ss
2
) in(63)
let h
nxt
= ith
1
(data) in(64)
if h
nxt
= ⊥ then end(pk(s priv
D
))(65)
where
(
ss
2
= ECDH(s priv
D
,e pub
D
)
h = HMAC(x
D
,ss
2
)
3.4.3 Analysing the Protocol in ProVerif
The protocol analysis is divided into two scenarios;
the first one with the attacker being an outside ob-
server and the second one with the attacker being a
part of the route, i.e. controlling the intermediary
node.
The Outside Attacker. In the ProVerif code we
have tested the secrecy of the session keys and partic-
ipants private keys. Since we are sending the packet
in one way, we are just using the session key that
the payment sender has established with the hop node
(ek
S
) and the key that the hop node established with
the payment receiver (ek
H
). Furthermore we are test-
ing the secrecy of the payment information intended
for the hop and sender respectively as well as whether
the authenticity of the sender holds.
The results that ProVerif outputs are following:
RESULT not attacker(ek
S[]) is true.
RESULT not attacker(ek H[]) is true.
RESULT not attacker(s priv S[]) is true.
RESULT not attacker(s priv H[]) is true.
RESULT not attacker(s priv D[]) is true.
RESULT not attacker(hop data[]) is true.
RESULT not attacker(recipient data[]) is true.
RESULT inj−event(end(p)) ==>
inj−event(begin(p)) is true.
The Inside Attacker. The attacker control over the
intermediary node is modeled by introducing the ma-
licious intermediary node. We will omit its actual
process calculus model because we believe that the
reader can imagine the model presented in Table 20
outputting all the keys and data it receives into the
public channel. The ProVerif code used for analysing
the inside attack is similar to the one used in the out-
side attack, with the exception of testing out the se-
crecy of data that the intermediary node knows. The
results that ProVerif outputs are:
RESULT not attacker(ek S[]) is true.
RESULT not attacker(s priv S[]) is true.
RESULT not attacker(s priv D[]) is true.
RESULT not attacker(recipient data[]) is true.
RESULT inj−event(end(p)) ==>
inj−event(begin(p)) is true.
As we can see, the results are the same for both the in-
side and outside attack and therefore we can conclude
that the intermediary node knowledge is limited in the
sense that it does not allow the attacker to obtain the
confidential data that belongs to the other participants.
4 CONCLUSION
In this paper, we have given an analysis of the Light-
ning network using ProVerif. The analysis shows that
both the channel opening and the onion routing pro-
tocols satisfy all of the required properties. As for
the key agreement protocol, it does not satisfy the au-
thenticity property in one direction, namely that of
the authenticity of the protocol responder to the initia-
tor. This implies that in the key agreement protocol,
that should provide mutual authentication, the proto-
col initiator cannot be sure that it is running the pro-
tocol with the responder it has in mind.
While the protocols satisfy the desired secrecy
properties, other information leaks appear to be possi-
ble for the Lightning Network. Herrera-Joancomart
´
ı
et al. (Herrera-Joancomart
´
ı et al., 2019) have recently
presented an attack that is able to disclose the balance
of a channel in the Lightning Network. This attack is
based on carrying out multiple payments while ensur-
ing that none of them will be finalized.
An analysis of the anonymity properties of the
Lightning Network protocols is another topic for fur-
ther work. An attacker must be prevented from learn-
ing anything about the secrets (in this case the sum
of the secrets), and the support given by ProVerif for
proving indistinguishability is likely to be useful in
for analyzing both anonymity and the balance confi-
dentiality property mentioned above.
REFERENCES
Abadi, M. and Gordon, A. D. (1999). A calculus for crypto-
graphic protocols: The spi calculus. Information and
computation, 148(1):1–70.
Secrecy and Authenticity Properties of the Lightning Network Protocol
129

Blanchet, B. (2002). From secrecy to authenticity in secu-
rity protocols. In International Static Analysis Sympo-
sium, pages 342–359. Springer.
Blanchet, B. (2014). Automatic verification of security pro-
tocols in the symbolic model: the verifier ProVerif. In
Aldini, A., Lopez, J., and Martinelli, F., editors, Foun-
dations of Security Analysis and Design VII, FOSAD
Tutorial Lectures, volume 8604 of Lecture Notes on
Computer Science, pages 54–87. Springer Verlag.
Blanchet, B., Smyth, B., Cheval, V., and Sylvestre, M.
(2018). Proverif 2.00: Automatic cryptographic pro-
tocol verifier, user manual and tutorial.
Diffie, W. and Hellman, M. (1976). New directions in cryp-
tography. IEEE transactions on Information Theory,
22(6):644–654.
Dolev, D. and Yao, A. C. (1981). On the security of pub-
lic key protocols (extended abstract). In 22nd An-
nual Symposium on Foundations of Computer Sci-
ence, Nashville, Tennessee, USA, 28-30 October 1981,
pages 350–357.
Herrera-Joancomart
´
ı, J., Navarro-Arribas, G., Ranchal-
Pedrosa, A., P
´
erez-Sol
`
a, C., and Garcia-Alfaro, J.
(2019). On the difficulty of hiding the balance of light-
ning network channels. In Proceedings of the 2019
ACM Asia Conference on Computer and Communica-
tions Security, Asia CCS ’19, pages 602–612, New
York, NY, USA. ACM.
Kiayias, A. and Litos, O. S. T. (2019). A composable se-
curity treatment of the lightning network. IACR Cryp-
tology ePrint Archive, 2019:778.
Krawczyk, H. and Eronen, P. (2010). Hmac-based extract-
and-expand key derivation function (hkdf).
lightningnetwork (2017a). Github - lightning-rfc/02-peer-
protocol.md.
lightningnetwork (2017b). Github - lightningnetwork-
rfc/08-transport.md.
lightningnetwork (2017c). Github -
lightningnetwork/lightning-onion: Onion routed
mi- cropayments for the lightning network.
Nir, Y. and Langley, A. (2018). Chacha20 and poly1305 for
ietf protocols. Technical report.
Perrin, T. (2016). The noise protocol framework. Power-
Point Presentation.
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
130