Content uploaded by Imrana Abdullahi Yari
Author content
All content in this area was uploaded by Imrana Abdullahi Yari on Oct 15, 2020
Content may be subject to copyright.
Online at Will: A Novel Protocol for Mutual Authentication in Peer-to-Peer
Networks for Patient-Centered Health Care Information Systems
Imrana Abdullahi Yari
Friedrich-Alexander University
imrana.abdullahi.yari@fau.de
Tobias Dehling
Karlsruhe Institute of Technology
dehling@kit.edu
Felix Kluge
Friedrich-Alexander University
felix.kluge@fau.de
Bjoern Eskofier
Friedrich-Alexander University
bjoern.eskofier@fau.de
Ali Sunyaev
Karlsruhe Institute of Technology
sunyaev@kit.edu
Abstract
Patient-centered health care information systems
(PHSs) on peer-to-peer (P2P) networks promise decen-
tralization benefits. P2P PHSs, such as decentralized
personal health records or interoperable Covid-19
proximity trackers, can enhance data sovereignty and
resilience to single points of failure, but the openness of
P2P networks introduces new security issues. We pro-
pose a novel, simple, and secure mutual authentication
protocol that supports offline access, leverages inde-
pendent and stateless encryption services, and enables
patients and medical professionals to establish secure
connections when using P2P PHSs. Our protocol in-
cludes a virtual smart card (software-based) feature to
ease integration of authentication features of emerging
national health-IT infrastructures. The security evalua-
tion shows that our protocol resists most online and of-
fline threats while exhibiting performance comparable
to traditional, albeit less secure, password-based au-
thentication methods. Our protocol serves as foundation
for the design and implementation of P2P PHSs that will
make use of P2P PHSs more secure and trustworthy.
1. Introduction
Patient-centered health care information systems
(PHSs) are scalable information systems that leverage
information technology to support patients in managing
and taking an active role in their own health [1]. PHSs
are not intended to replace conventional electronic
health records (EHRs); they rather complement them by
providing ancillary functionality [1]. Among other fea-
tures, PHSs can enable patients to control release of
1
https://solidproject.org/
2
https://doc.ai/app-personalized-health-ai-companion
their data during interactions with other stakeholders
[2]. A US survey revealed that 80% of 800 patients are
willing to take ownership of their medical data because
they currently feel sidelined in the management of their
data [3]. In line with large-scale efforts to re-decentral-
ize the internet (eg, Tim Berners-Lee’s Solid project
1
),
peer-to-peer (P2P) designs are also becoming of interest
to PHS developers as an alternative to offline USB stor-
age, distributed ledger technologies, or centralized data-
bases [4]. P2P PHSs, for example, Doc.ai
2
or OnePa-
tient,
3
promise to be less rigid and flexible and store
health data locally (on any patient edge device) under
the sovereignty of individual device owners. Other ex-
amples for P2P PHS are Serenity,
4
which tracks mental
wellness, or decentralized systems for Bluetooth-based
SARS-CoV-2 (or Covid-19) contact tracking, which en-
sure that users’ data stays on owners’ devices and notify
people when they were near SARS-CoV-2 virus carri-
ers, such as Privacy-Preserving-Proximity-Tracing in
Europe [5] and Trace-Together in Singapore [6]. As en-
visioned by Alex Pentland et al., a paradigm shift with
a focus on decentralizing information systems, such as
P2P PHSs, is on the way to make information systems
more resilient, flexible, and transparent [7].
On the one hand, PHSs on P2P networks improve
data sovereignty because all data is technically and le-
gally governed by patients, disrupted internet connec-
tions will not stop data access, and P2P PHSs are more
resilient to single points of failure than centralized infra-
structures [8,9]; Moreover, P2P network characteristics
such as scalability, availability, self-configuration, and
extendability suit the provision of PHSs [9]. Further-
more, P2P PHSs simplify the technical and organiza-
tional challenges to implement data regulations such as
the General Data Protection Regulation (GDPR) of the
3
https://refinio.net/software.html
4
https://doc.ai/serenity-mental-wellness-companion-mood
This is pre-copyedited, author-produced PDF of a manuscript accepted for publication in the 54th Hawaii International Con-
ference on Systems Sciences (HICSS-54). The version of record "Online at Will: A Novel Protocol for Mutual Authentication in
Peer-to-Peer Networks for Patient-Centered Health Care Information Systems. Imrana Abdullahi Yari, Tobias Dehling, Felix
Kluge, Bjoern Eskofier, Ali Sunyaev. HICSS-54 January 5-8, 2021. Hawaii, USA" will be made available in the University of
Hawaii digital institution repository (ScholarSpace) at https://scholarspace.manoa.hawaii.edu/
European Union [10]. On the other hand, provision of
PHSs on P2P networks poses major security issues, such
as offline dictionary, sybil, impersonation, reflection,
replay, parallel session, or man-in-the-middle attacks
[11-14], which can impede attainment of PHS goals.
P2P networks are geographically dispersed, and peers
can freely join or leave the network [13]; this makes P2P
networks alluring targets for attackers to wreak havoc
while remaining undetected or untraceable [8]. Moreo-
ver, users need to manage information security largely
by themselves [8]; a task that challenges even qualified
professional administrators [8]. Additionally, the ab-
sence of a central entity to act as a trusted third party
makes it more challenging to establish confidentiality
and integrity [8]. From a behavioral perspective, P2P us-
ers tend to inadvertently release their sensitive infor-
mation due to the complicated design of some P2P sys-
tems, inattention to appropriate resource sharing, or the
set-and-forget nature of some P2P systems that run in
the background [13].
Due to the high sensitivity of medical data, which
is worth ten times more than credit card numbers on the
black market [15], P2P PHS security issues need to be
addressed to increase patient acceptance and lower the
risks of using them [16]. Effective authentication proto-
cols are highlighted as a priority among the security
measures that must be employed to address P2P security
issues and prevent data breaches and information loss
[11,16,18]. An authentication protocol involves the use
of cryptographic algorithms to validate a reported iden-
tity [12] and it assures legitimate access and authorized
use of information resources [18]. In this study, we fo-
cus on the development of an authentication protocol for
secure provision of P2P PHSs.
Some countries, for instance, Germany, planned
to provide user authentication through smart cards for
all insured persons and medical practitioners to ease se-
curity management for individual PHS providers [1,19].
However, implementation of national health-IT infra-
structures is often complicated, expensive, and pro-
tracted [1]. Hence, current PHS providers should con-
sider implementing more efficient security measures for
their systems. Although the advantages of a national
health-IT infrastructure for authentication could be
enormous, PHS providers should be able to freely
choose whether to certify their PHS based on national
specifications [19]. The design of a novel authentication
protocol can benefit PHS providers outside national
health-IT infrastructures, for instance, in countries with
less sophisticated IT infrastructures [20], and serves as
a medium-term security measure for PHS providers that
aim to integrate their systems with national health-IT in-
frastructures once they prove effective.
P2P authentication protocols that support mutual
(or user-to-user) authentication exist [11,21-23].
However, state-of-the-art protocols have disadvantages
that make them impractical for P2P PHSs: They rely on
additional card readers [23], which can be lost; use pass-
words to encrypt the cards [11], which are vulnerable to
offline attacks; incorporate remote cryptographic oper-
ations [24,25], which are unsuitable for P2P PHSs that
should mainly run on patient devices; apply steganogra-
phy for the authentication process [21], which can be
detected and blocked in the network; or are dependent
on biometric attributes for identification [26], which is
not universally applicable because some people are, for
instance, visually impaired. To address these chal-
lenges, this study proposes a novel, secure mutual au-
thentication protocol that enables patients to have of-
fline access and establish secure connections with other
authorized parties (eg, medical practitioners or research-
ers) in wireless multi-hop networks while ensuring pro-
tection against offline and online threats when using
P2P PHSs. Since PHSs are diverse, offered by multiple
parties, and can provide any functionality patients find
useful [1], our protocol design relies on a federated ar-
chitecture for various PHS providers. Furthermore, to
incorporate features of the proposed German national
health-IT infrastructure [1] into the design, we use a
software-based smart card (virtual card or vCard) fea-
ture in the authentication process. Since P2P PHSs
should predominantly run on patient’s edge devices,
they should not require resource-intensive operations;
hence, resource specifications of patient devices were a
paramount consideration in the design of the protocol.
The design of the proposed secure authentication
protocol for P2P PHSs was guided by formal methods
for developing authentication protocols [12] and pass-
word hardening techniques [27]. The protocol has low
computational cost due to symmetric encryption, has
stateless and independent data and vCard encryption
keys per user, and provides offline data access and mu-
tual authentication. As proof of concept, we imple-
mented the crucial parts of the protocol, password hard-
ening and encryption services, using an opensource net-
working and cryptographic library (Libsodium) and
demonstrated the feasibility of the protocol with a web
application. Password hardening is used to make pass-
words unsusceptible to offline attacks; the independent
and stateless symmetric keys are used for encrypting
PHS data and the vCard. The security evaluation shows
that the protocol can resist offline dictionary, man-in-
the-middle, Sybil, impersonation, and typical authenti-
cation protocol attacks, such as replay message, parallel
session, and reflection attacks [12,14].
2. Related research
In general, identity authentication can be done
based on the following factors [12,18]: what users are
(eg, behavior or biometrics), what users have (eg, smart
cards or credentials), and what users know (eg, personal
identification numbers (PINs) or passwords).
Traditional password-based authentication is
widely applied in client-server architectures [12] and
P2P systems—because it is convenient. Although Bill
Gates heralded the vulnerabilities of password-based
authentication already in 2004 at the RSA security sym-
posium [18], 65% of people still used the same password
for different accounts in 2018 [28] and compromised
passwords were responsible for 81% of data-related
breaches in 2018 [29]. Also, reused passwords contrib-
uted to 572 security incidents in 2019 in the US health
sector; 41 million patient records were affected [30]. Us-
ing strong passwords and storing them in a hashed
and/or an encrypted form are common methods that are
applied to tackle such security issues (Figure 1); how-
ever, such methods are arguably an ineffective solution
since they are susceptible to offline attacks [24,25,27].
Identity authentication protocols in wireless ad
hoc and P2P networks exist. However, low entropy of
used passwords makes them vulnerable to offline at-
tacks [11] and use of steganography in the authentica-
tion process can be detected and blocked in the network
[21]. Moreover, protocols that rely on public-key cryp-
tography [22] can be computationally too expensive for
P2P PHS. Recently, a user-centered identity manage-
ment system was presented [26] for virtual identity der-
ivation and biometrics, but it aims for user-host settings;
therefore, it does not focus on mutual authentication, en-
cryption services, or protection against offline attacks.
As a countermeasure to offline attacks and secu-
rity issues of traditional password-based authentication
protocols, password-hashing authentication leveraging
remote cryptographic operations to harden the password
and protect against offline attacks can be employed [24];
however, emerging services like P2P PHSs, which run
locally on patient devices, have a mismatch in their un-
derlying philosophy with remote cryptographic services
such as those offered by Facebook [24]. Encryption ser-
vices can be added to password hardening approaches
[25], but they are unsuitable for user-to-user authentica-
tion and impractical for P2P PHS due to third-party de-
pendencies. Moreover, some authentication protocols
use anonymous credential systems designed using zero-
knowledge proofs [25,26,31], which may be an undesir-
able feature for P2P PHS with respect to the patient-
practitioner relationship during off- or online treatment
where the identity of patients and other private infor-
mation needs to be explicitly exposed to practitioners.
Our approach extends the idea of leveraging al-
ready available resources in a web application to protect
secrets, such as passwords, against offline attacks [27].
Initially, we rely upon what users know to derive en-
cryption services and ensure that individual users can
Figure 1. Typical password-based authentication. A
user with a password P requests access to his stored
data. The host stores the data in an encrypted form
CT. When the hash (h) of P matches with the one
stored, the host decrypts CT using its private key HSK
and returns the raw data to the user.
benefit from self-sovereign authentication in accessing
their data offline without any support from PHS provid-
ers. Additionally, we leverage password hardening to
address the offline vulnerabilities and, in line with the
P2P spirit, our protocol does not depend on any central
external entity for the required computations. Moreover,
acknowledging the merits of emerging nationwide
health-IT infrastructures that plan to offer user authenti-
cation using smart cards, we incorporate cryptographic
chunks of user identity and other control information in
a vCard to ease integration of P2P PHS with future se-
curity infrastructures in the health care domain.
3. Authentication protocol development
We use Alice as a patient who owns her P2P PHS,
Bob as a practitioner who wants to mutually authenti-
cate with Alice to access her health records and Trent-1
(supporting personal health records and tracking mental
health), Trent-2 (supporting pregnancy due date calcu-
lation) and Trent-3 (supporting personal health records)
as independent PHS providers who host various PHSs.
Trent (1:n) are federated authorities that trust each other.
Arguably, national health agencies could serve as a con-
trol infrastructure to ratify various Trents in a manner
similar to current practices for ratifying X.509 certifica-
tion authorities [12].
3.1. Theoretical background
Key construction techniques for building identity
authentication protocols are data-origin authentication,
entity authentication, and authenticated key establish-
ment [12]. Data-origin authentication aims to establish
the integrity of the message using message age identifi-
cation and manipulation detection in such a way that old
messages may have valid data integrity but fail authen-
ticity checks. Entity authentication is a communication
process for establishing trust concerning a claimed iden-
tity. Authenticated key establishment is a process for
using cryptographic keys to establish further secure
communication at the application level.
In our protocol design, we used a cryptographic
nonce (‘number used once’) and cryptographic hash
functions for data-origin authentication. We avoided the
use of timestamps because time is not necessarily syn-
chronized between P2P nodes. For entity authentication,
we rely on a trusted network of Trents to run the authen-
tication and key establishment for their subset of users,
which is a standard architecture for establishing a key
agreement between Alice and Bob in wireless multi-hop
networks [12]. Long-term symmetric and independent
keys are used for establishing authenticated keys for
communication of Trents with Alice or Bob, short-term
keys are used for secure communication between Alice
and Bob in a multi-hop network.
3.2. Cryptographic techniques
Assuming that i & j
I are the respective identi-
ties of Alice and Bob, who share a secret symmetric key
K of size , that N is the nonce of Alice who is ini-
tiating the mutual authentication request, and that conv
refers to the protocol conversation history with all en-
countered and authenticated users, the execution of Al-
ice’ protocol oracle will yield the
chunk , where
m is a message to be sent out, is a decision, which can
be accept, reject, or undefined, of a principal (in this
case, according to Bob’s protocol) receiving the authen-
tication request. If the protocol accepts the run, a secure
short-term symmetric key KAB is issued for secure com-
munication between Alice and Bob.
Applying a generic one-way hash function on
sensitive information and encrypting it may not lead to
confidentiality and integrity since an attacker who com-
promised the database containing the sensitive infor-
mation can perform offline brute force attacks on the da-
tabase [12] and unveil users’ sensitive information to
wreak more havoc. Extant research employs sophisti-
cated cryptographic techniques such as key-homomor-
phic pseudorandom functions but relies on remote cryp-
tographic operations for password hardening [25]. De-
pendence on centralized third parties is undesirable for
P2P PHSs. Therefore, we rely on services available lo-
cally on patient devices which are located in a separate
repository within the PHS client software and use a
keyed-hash message authentication code (HMAC or
password hardening). Cryptographic hash functions are
usually keyless when applied to a secret (or password);
however, cryptographic hash functions can take a cryp-
tographic key and concatenate it with a message m to be
authenticated to create an HMAC. The key is not meant
for encrypting m, rather it allows a user in possession of
the correct key, the original m, and the hash function to
compute the same output (digest) to authenticate m. Ac-
cordingly, let represent a pair
where is a pseudo-random
HMAC which can be keyed with the hash of m for
higher integrity and protection against offline attacks.
4. Results
4.1. Overview of the protocol
The overview of the protocol is shown in Figure
2. Within the remainder of the manuscript, we refer to
any module that is local on a patient’s device that pro-
vides strong cryptography as crypto module. PHS pro-
viders (Trents-1:n) form a federated, structured P2P net-
work, where peers’ public identities (registered Alices’
and Bobs’) are securely maintained under the control of
distributed hash tables (DHT) [9]. The entire index is
equally distributed among participating Trents; each
Trent has to maintain it for lookup functionality. Net-
work communications between Trents can be handled
via an end-to-end-encrypted public-key infrastructure.
Our core scenario is that Alice wants to register
with Trent-1 while Bob is registered with Trent-3.
Trent-1 can issue and manage tokens that have a limited
validity to Alice after they personally verify that they
are eligible to use the PHS. In the case of Alice, token
issuance can be offline in offline processes such as val-
idation of health insurance. In the registration phase, Al-
ice supplies her password and a valid token to the PHS
client software from which the PHS locally HMACs the
password in the crypto module and derives a stateless
and independent data encryption key (DEK) along with
a vCard encryption key (VEK) from the password. Next,
the registration request is forwarded to Trent-1 and, af-
ter validation and verification, Trent-1 issues a vCard to
Alice, which is stored in her PHS client software. Bob
has to pass a similar registration process as Alice with
Trent-3. In the next run (ie, login phase), Alice and Bob
can access their respective PHS services offline without
involving any Trent. In the mutual authentication phase,
when Bob wants to access Alice’s PHS in a wireless
multi-hop network, he can search for Alice's public
identity online using the lookup functionality from
Trent-3 and then request a ticket to mutually authenti-
cate with Alice. This communication works when
Trent-1 and Trent-3 support the same PHS functionality.
The ticket with limited validity, containing a short-term
secure key, can be issued to Bob by Trent-3 and shared
with Alice via Trent-1 after validation and verification.
The mutual authentication focuses on wireless
multi-hop networks. At a single-hop network level (eg,
via Wi-Fi Direct or Bluetooth), when Alice and Bob are
both physically present in the same location (eg, in a
practice or hospital) and require faster PHS access, they
Figure 2. Authentication protocol overview
can mutually authenticate via a QR code feature on Al-
ice’s PHS client software. Bob can scan the QR code at
which time his self-signed public key is shared with Al-
ice's PHS. After establishing a network connection, Al-
ice can permit Bob to access her health records, which
allows the protocol to decrypt the records using her
DEK and Bob’s public key to temporarily encrypt the
data. This permission can be revoked by Alice or due to
network disconnection upon which the protocol re-
moves the access rights and re-encrypts the data using
Alice's DEK. This is a vital feature for P2P PHS to be
independent of Trents.
4.2. Registration phase
We assume that PHSs implement a setup algo-
rithm that activates whenever a PHS client software is
first downloaded by any user, in this case Alice. Alice’s
self-signed private-public key pairs [ASK, APK,], the
crypto module’s private-public key pairs [CSK, CPK,],
and the public key [TPK] of the respective Trent (here
Trent-1) are then made available to the PHS.
Initially, Alice supplies her token to, username
un, and password pw (flow (1): toi || uni || Alice || pwi )
to the PHS client software. The private key of the PHS
and the crypto module are concatenated, appended, and
processed with a cryptographic hash function h to
harden the password h(pwi)ASK || CSK. Random data saltx
and salty are generated and used individually with the
h(pwi) to generate the VEK and DEK, respectively.
Only the HMAC-passwords (HMAC-pw), saltx, and
salty are stored in the PHS database; h(ASK) is stored lo-
cally within the PHS in a secure repository, the actual
VEK and the DEK are stateless and only derived after
each successful login. To ensure confidentiality, the
VEK is used for encrypting the vCard while the DEK is
used for encrypting health information and other sensi-
tive information in the PHS. The registration request
(flow (2): [h(to) || Alice || uni || APK || h(VEK)]TPK),
which is encrypted using Trent’s public key is for-
warded to Trent-1. If Trent-1 successfully decrypts this
request message using his private key while the supplied
to is valid, Trent-1 generates a long-term secret session
key KAT for secure communication between him and Al-
ice (or KBT in case of Bob with Trent-3) and computes
XA = (h(uni || h(TPK)) + h(uni || h(VEK)) mod 2) and
vCard = [Alice ||uni || KAT || XA]h(VEK). Trent-1 does not
store the VEK of Alice. He only stores Alice’s public
identity which is maintained in the DHT and KAT. Fi-
nally, Trent-1 sends the vCard (flow (3): vCard, at the
provider side) to Alice and it is stored locally on Alice’s
PHS client software. From this point onwards, Alice can
access her data offline without any support from
Trent-1. This concept of storing private and identifica-
tion information locally on owners’ devices aligns well
with P2P PHS goals and mitigates risks for insider
threats while providing higher integrity.
4.3. Login phase
Alice’s input (flow (1): uni || pwi) to log in to her
PHS client software is used to retrieve the stored
HMAC-pw. Alice’s PHS uses its crypto module’s and
her private keys to recalculate the HMAC-pw with Al-
ice’s input of her password. Only if the derived hmac-
pw digest is equal to the stored digest (HMAC-pwi’ ==
h(pwi)ASK || CSK), login access is granted while the VEK
and the DEK are derived from the password. The DEK
is used to temporarily decrypt all other stored infor-
mation, the VEK is used to decrypt the vCard. In a wire-
less multi-hop network, Alice can activate her vCard
(flow (2): vCard, at the patient side) for her P2P public
identifier to be published online by Trent-1 via DHT so
that other peers, such as Bob, can find her. The PHS lo-
cally computes Alice's public P2P identifier (Apid = (XA
+ h(uni || h(VEK))) mod 2 || NA) and then forwards a
request to Trent-1 who sets her P2P identifier to online
(flow (3): Apid || Alice || h[NA]KAT). Without depending
on this request, Trent-1 computes Alice’s P2P identifier
using the information he already has (Apid’ = h(uni ||
h(TPK)) || NA). Only when the received P2P identifier is
the same as the derived one (Apid’ == Apid,) will Trent-1
set Alice online. Trent then computes a confirmation re-
sponse (flow (4):h[NA - 1]KAT) and sends it to Alice's
PHS client software while Alice's protocol can only ac-
cept this message if nonce NA is valid.
4.4. Mutual authentication phase
In this phase, it is expected that Bob and Alice
both logged in and activated their P2P identifiers. We
assume that Bob can acquire Alice's public identifier by
accessing the lookup service from Trent-3 since indexes
of all participating peers are maintained in the Trents’
supernode network; Bob can log the mutual authentica-
tion request (flow (1): [Bob || Alice || h[NB]]KBT) with
Trent-3 before connecting to Alice's health record(s).
After verification, Trent-3 can issue a ticket (flow (2):
ticketA || [{KAB}KBT || h[NB] || Alice || Bob || Apid ]KBT) to
Bob while parallelly notifying Alice (via the DHT and
Trent-1) with the ticket (flow (3): ticketA’ = [{KAB || Bpid
}KAT || T || Alice || Bob || Apid]KAT) about the request.
Both tickets have a secure short-term key KAB which has
a cryptographic association with their identities and
message age identifiers NA and NB. If the messages are
altered during transmission, changes can easily be de-
tected. Moreover, each ticket has a valid time T so that
an attacker that compromised Bob by replaying old ses-
sions from Alice and Bob can be detected by the proto-
col since the old session key may have valid data integ-
rity but fails authenticity. Next, Bob sends the ticket
(flow (4): ticketA) directly to Alice. She accepts this re-
quest only if the tickets received from Trent-1 and Bob
are the same and T is valid. Next, Alice sends an en-
crypted nonce (flow (5): h[NA]KAB) as a challenge to
Bob. To obtain NA, Bob decrypts the challenge using
KAB and then sends a response (flow (6): h[NA - 1]KAB)
to Alice. At this point, if message decryption is success-
ful by Alice and NA is valid, she will use KAB until it ex-
pires for secure communication over a wireless multi-
hop network with Bob. Finally, Alice can securely use
the PHS supported by Bob and improve her treatment.
5. Evaluation
5.1. Security
For the security evaluation of our protocol, we as-
sumed that the attacker is powerful enough and pos-
sesses all the necessary tools and techniques to eaves-
drop, intercept, change, and inject malicious content in
a wireless multi-hop network. Network-layer attacks re-
quire little effort. Techniques to mount such attacks lev-
erage, for instance, WI-FI Protected Access II (WPA2)
security protocol vulnerabilities [32] to conduct man-in-
the-middle attacks based on free and open-source tools
like Driftnet or Wireshark. The attacker focuses on the
unauthorized and undetected acquisition of crypto-
graphic credentials and not on breaking the
cryptographic algorithm [12]. PHS providers should de-
cide what cryptography to adopt (eg, AES) depending
on system requirements and other factors to strengthen
security. Moreover, we assume that each protocol prin-
cipal (Alice, Bob, or the federated network of Trents)
behaves honestly and does not expose any users’ shared
short-term or long-term session keys to unintended par-
ties. Although our protocol resists many attacks, such as
offline dictionary, replay, Sybil, impersonation, man-in-
the-middle, parallel session, reflection, or interleaving
attacks, we only present the interesting evaluations due
to page restrictions. The detailed evaluation report is
available from the authors upon request.
5.1.1. Offline dictionary attack
In a scenario in which an attacker compromised a
PHS database containing passwords and other sensitive
information, the attacker cannot successfully brute force
the password even when ASK is leaked since the other
key used for HMACing the password (CSK) is neither
stored in the PHS database nor in its source code accord-
ing to our protocol design and the defined assumptions.
Therefore, even a password with the lowest entropy, like
‘12345’, cannot be unveiled through offline attacks (due
to HMAC). On the contrary, traditional password hash-
ing functions like BCrypt, PBKDF2, or SCrypt [27] will
merely slow down the password cracking process [27].
However, even if an attacker compromised the crypto-
module’s private key, our protocol HMAC uses a
BLACK2 hash function, which is invulnerable to colli-
sions, immune to length extensions, and differential
enough for random oracles [33]. This serves as another
layer of protection that obstructs the cracking process.
Furthermore, other private information in the database,
encrypted using DEK or VEK, is strongly protected
since those keys are stateless and not stored anywhere—
they are only vulnerable to brute force attacks. Moreo-
ver, those keys are only derived when a correct pass-
word is provided to the PHS. Consequently, attackers
can only start tedious brute-force attacks on the DEK
and VEK once the first hurdle has been taken.
5.1.2. Parallel session attack
This is a form of an attack in which a disgruntled
insider concurrently orchestrates and executes more
than one run of the protocol while blocking and replac-
ing messages flowing from one user to the other [12].
We refer to this insider as Malice—a malicious and nor-
mal user (eg, a patient)—who also shares a secret sym-
metric key KMT with a Trent (1:n) in the network. Even
if Malice has a valid KMT and initiates a simultaneous
run, mutual authentication is not expected in the case of
our protocol since each ticket issued by a Trent contains
a secure short-term session key with a validity period
that does not allow more than one user to connect to an-
other user at the same time (this can be ensured via DHT
[9]). Again, each ticket contains the identities of the au-
thenticator and the user to be authenticated; therefore,
use of a ticket issued for communication between Bob
and Alice by Malice will be rejected. Although network
delay can open doors for eclipse or routing attacks [14],
Malice’s reuse of the nonce of one user to establish a
connection with another users (for example, reuse of
Bob’s nonce for Alice; flow (5) Mutual authentication
phase) will fail since nonces are cryptographically and
randomly generated; therefore, even if Malice can block
a user (eg, through eclipse or routing attacks), a parallel
session attack is impractical.
5.1.3. Impersonation attack
Assuming Malice intercepts Bob’s request to be
online on a P2P network and alters the message contents
by replacing her identifiable information with his fake
identity information (flow (3) in Login phase: Mpid ||
Malice || h[NB]KBT) with the intention of masquerading
as Bob (eg, to steal patient data) and then forwarding the
altered message to Trent-3 to set Bob’s identity online
before accepting Bob’s nonce NB, Trent-3’s verification
and validation of Bob’s P2P identifier will fail since
Bpid’ ≠ Bpid and Trent-3 will reject the request. Again,
Malice ≠ Bob and, consequently, identity verification
fails. This method of explicitly adding identities of the
participants in establishing the meaning of a message
also curtails other vulnerabilities such as attacks based
on name omissions [12]. Consequently, in combination
with our concept of token issuance and verification, the
protocol is also insusceptible to Sybil attacks.
5.2. Implementation and performance
As proof of concept, we implemented the crucial
parts of the protocol, password hardening and key deri-
vation, using a Libsodium cryptographic library. The
code is available from the authors upon request. We im-
plemented the protocol within the context of a PHS as a
web application developed using PHP/MySQL. We
hosted the PHS locally on an Apache web server in a
virtual workstation sharing resources from a host system
that uses 4-cores and 8-logical processors (AMD
Ryzen 7 2700U CPU). We leveraged the existing cryp-
tographic modssl module on Apache as crypto module
to provide most cryptographic operations of our proto-
col. Importantly, we directly used modssl to generate
CSK for the password hardening. Our selection of this
5
https://blake2.net/
6
https://password-hashing.net/#phc
key is different from the secret key used for transport
layer security [27]. Therefore, it is independent of any
external or remote service. Moreover, we used the
BLAKE2b
5
cryptographic hash function, which is faster
and more secure than MD5, SHA-2, SHA-3 for the
HMAC computation [33]. For key derivation, we use
the award-winning password hashing function
A2gon2id
6
due to its higher resistance to side-channel
and time-memory trade-off attacks.
We used the Apache Benchmarking tool
7
to cal-
culate the overhead per successful login attempt. We
used two cases for evaluation. First, we used a P2P PHS
with a password authentication without any hashing or
key derivations. Second, we used a P2P PHS with pass-
word hardening and key derivations. For each case, we
used 100 requests with 10 concurrent users and enabled
HTTP keep-alive and authentication features. The first
test completed in 9.337 milliseconds (ms) while the sec-
ond case completed in 9.913ms; therefore, the overhead
in terms of connection times per successful login at-
tempt for using an HMAC-pw and key derivation on the
P2P PHS is almost equal to using the default insecure
authentication methods. Therefore, despite the added se-
curity provided by the proposed authentication protocol
on P2P PHS, it has a similar performance with still de-
fault, albeit less secure (see evaluation steps above), au-
thentication methods. Furthermore, we compared our
proposed authentication protocol with protocols re-
viewed in the related research section with respect to
standard authentication construction requirements, se-
curity, and other requirements for P2P PHS authentica-
tion. The summary of the comparison is shown in Table
1 and discussed in the following section. Our protocol
does, not only, perform better in terms of security, but
also, outperforms the existing authentication protocols
in terms of their incompatibility with P2P PHSs.
6. Discussion
In the future, many health care information sys-
tems could reap the benefits of decentralization; P2P
PHS are a promising, possible future development that
comes with enormous advantages, such as improved pri-
vacy management, data sovereignty, and resilience to
single points of failure—a new paradigm shift as pic-
tured by Alex Pentland et al [7]. However, future P2P
PHSs will introduce new challenges, such as requiring
patients to manage information security for their PHSs.
P2P networks pose major new security issues while in-
heriting other security issues that any other networked
application running on the internet faces. The synergies
of P2P networks and wireless multi-hop networks are
7
https://httpd.apache.org/docs/2.4/programs/ab.html
Table 1. Comparisons of authentication protocols with
our protocol with respect to authentication requirements
and other features of P2P PHS1
Protocol
[11]
[25]
[22]
[26]
Our
Requirement
Data-origin
authentication
+
++
++
++
++
Entity authentica-
tion
++
++
+
++
++
Authenticated key
establishment
++
-
++
Protection against
Authentication
attacks2
+
+
+
++
Offline attacks3
-
++
+
+
Other
Mutual
authentication
+
-
+
-
+
Biometrics4
-
-
-
++
-
Anonymity
+
+
-
Encryption services
-
++
-
-
++
Virtual card feature
+
-
-
-
++
Offline data access
-
-
-
-
++
Dependent on re-
mote crypto-mod-
ule4
-
++
+
+
-
1requirement with '++' are fulfilled, '+' partially fulfilled, '-'
not fulfilled, and ‘ ’ could not be identified from the source.
2attacks evaluated in this study such as impersonation and
replay message, parallel session, and reflection.
3offline dictionary attacks on passwords or sensitive infor-
mation in a compromised database
4biometrics are problematic from a usability perspective
and such identifiers cannot be replaced once compromised
5reliance on remote cryptographic services in the pass-
word hardening computations
known [34] but pose new security risks for P2P-PHS
communications at the network level due to lack of a
centralized security infrastructures and the open nature
of wireless mediums [34]. Given these concerns and the
high sensitivity of medical data, our study investigates
the factors that could enhance the design of user authen-
tication as a security measure for P2P PHSs. To reduce
susceptibility to vulnerabilities due to abuse or offline
attacks in P2P PHS, our protocol design was designed
with encryption services that are stateless and independ-
ent per user. Independent encryption keys per user in a
PHS also provide integrity to patients from the perspec-
tive of a PHS provider while mitigating the impacts of
central attack profiles [12].
Additionally, for mutual authentication in wire-
less multi-hop networks, we used a federated and trusted
network of PHS providers to provide authentication and
key establishment in the registration phase. Subse-
quently, patients can access their data locally and mutu-
ally authenticate with other entities at a single-hop net-
work level using QR codes without requiring involve-
ment of any third party. Our protocol is interoperable
since it allows for P2P PHS users of different providers
while still allowing for mutual authentication; the public
identities are collaboratively and securely maintained
under DHT [9]. This feature can, for example, be useful
for interoperability between multiple national Covid-19
proximity trackers deployed in different geographical
regions. For example, when a user visits a foreign coun-
try, she can activate her Covid-19 tracker app to receive
exposure notifications of diagnosed Covid-19 patients
in that country while people of that country can get no-
tifications of visitors that are diagnosed with Covid-19.
Further, our protocol design is based on a decentralized
approach, which ensures no entity beyond a device
owner stores any personally identifiable information of
the user, which addresses the privacy concerns that cen-
tralized infrastructural approaches for Covid-19 trackers
are bound to cause (eg, the UK government has been
criticized for wanting to store individuals’ data for
twenty years for their NHSX Covid-19 contact-tracking
app [35]). This self-sovereign identity feature provides
data protection to both the infected, non-infected, and
other entities involved, increases trust, and prevents
abuse of data.
Our protocol works in a federated architecture
and enables mutual authentication of users of different
PHS provided by different parties supporting similar
PHS services. Basically, users’ public information is
maintained by a distributed network of supernodes
(PHS providers) but under the control of DHT to facili-
tate issuance of authentication keys and lookup func-
tionality. National health agencies could serve as a
trusted third party to ensure and ratify that all PHS pro-
viders can be trusted and misbehaving parties are black-
listed. Such considerations are required to establish a
P2P architecture suitable for PHS deployment, espe-
cially in the current situation, where countries like Ger-
many, France, and the UK [36] identified a need to link
their large health-IT infrastructures and their developing
SARS-Cov-2 (or Covid-19) proximity tracking systems,
although such plans may infringe user privacy [6].
Other authentication protocols for P2P systems
exist [11, 21-23]; however, they either tackle isolated
security concerns, are unsuitable for P2P PHSs, or do
not provide independent offline data access (Table 1). In
contrast to existing protocols, which assume users to be
anonymous at the application and network levels, health
care ecosystems can rely on established trust relation-
ships. We avoid the use of biometric features, which are
not universally applicable, in the design and focused on
the use of HMACed passwords to improve usability and
ensure that our authentication protocol can be adopted
in P2P PHSs and used by all patients and practitioners
on a global scale (Table 1). Additionally, we accounted
for emerging nation-wide health-IT infrastructures
[1,19]. Identifying opportunities how individual PHS
providers can leverage such national infrastructures for
user authentication is useful and can serve as a founda-
tion for the design of P2P PHSs. However, such infra-
structures are tedious to establish and restricted to geo-
graphic regions [1], therefore, we used a vCard (Table
1) in our protocol as a security feature in the authentica-
tion protocol design that is also useful for PHS providers
outside national health-IT infrastructures and serves as
a medium-term security measure for PHS providers that
plan to integrate their systems with large-scale health-
IT infrastructures. Such considerations serve as con-
cepts and foundations in both theory and practice for
PHS providers, PHS developers, and security service
providers in the domain of PHS and P2P systems.
Our study investigates state-of-the-art solutions
for mitigating security concerns of traditional authenti-
cation protocols in both P2P and user-host settings and
presents useful contributions for P2P PHSs as well as
the P2P network domain. Existing password hardening
techniques used to address offline security issues in
password authentication are unsuitable for P2P PHSs
because of their dependence on remote cryptographic
services (Table 1), which may affect patients’ flexibility
in accessing their data offline. Furthermore, state-of-
the-art soluations are computationally expensive when
adopted for P2P PHSs. For our protocol design, we lev-
eraged the available cryptographic services on patients'
devices to provide cryptographic operations and pass-
word hardening. We implemented the registration and
login phases of the protocol but focused on password
hardening and encryption services using an opensource
networking and a cryptographic library (Libsodium) and
demonstrated the feasibility of the protocol within the
context of a PHS as a web application. We used a ge-
neric hashing function, a keyed message authentication
code with a password at time of registration, and the pri-
vate keys of the PHS client software and the crypto-
module for the password hardening. Therefore, we sup-
plement established theories for authentication design
that provide integrity, confidentiality, and access control
services with a practical utility that enables less estab-
lished services like P2P PHSs to leverage already avail-
able services in such infrastructures to improve security.
Our study has limitations which offer opportuni-
ties for future research. First, our study is limited to the
perspective of authentication as a security contribution
for P2P PHSs. How other innovation characteristics
such as usability and deployability will affect adoption
by patients and health care providers is beyond the scope
of this study. This is an interesting opportunity for future
research investigating the behavior of P2P users and
systems concerning technological maturity, which will
also affect organizational decisions to adopt more se-
cure authentication protocols. Second, the proposed pro-
tocol design has flexibility features that could be im-
proved in many ways, for instance, by adding safety-
related requirements like emergency access or guardian
support. Additionally, a password change phase can be
directly added to the protocol to protect against online
threats such as guessing attacks. Limits for password
validation requests can as well be incorporated. Reliable
and patient-centered backup options to facilitate the re-
placement of a patient’s credentials in a situation where
patients lose access to their credentials (eg, a stolen lap-
top) can also be implemented.
7. Conclusions
P2P PHSs are an emerging phenomenon that will
become more relevant in the future. So far, dedicated
literature is sparse and requires research from many per-
spectives. With the evolving global outbreak of Covid-
19, proximity tracking P2P PHSs are emerging and of
growing interest for controlling the spread of the virus;
however, such developments come with complications
with respect to privacy risks resulting from security
threats. This study takes an authentication protocol ap-
proach as a security contribution to the emerging P2P
PHS landscape and is based on considerations of social
aspects in health care from the perspectives of patients,
practitioners, PHS providers, and large health-IT infra-
structures. A global pandemic requires global solutions
that go beyond national initiatives. Our protocol is in-
teroperable and can enable users of different national
implementations of proximity trackers (or other P2P
PHSs) to mutually authenticate with each other over sin-
gle or multi hop networks to share exposure notifica-
tions and enables health care practitioners to recom-
mend interventions such as testing or quarantine. By be-
ing borderless, our protocol can contribute to effectively
fight the Covid-19 pandemic. A secure authentication
protocol could mitigate the inherent security issues of
PHS deployment on P2P networks and boost the inten-
tion of patients and other stakeholders to use PHS.
We assert that our protocol is computationally se-
cure based on the security evaluation conducted since an
attacker with protocol oracle observation capabilities
(
) fails to convince a pa-
tient’s (or practitioner’s) protocol to accept his mali-
cious requests due to data-origin and entity verifications
[12]. Moreover, even with the added security provided
by the proposed authentication protocol for P2P PHS,
the evaluation shows that it has similar performance as
the extant insecure authentication methods. This study
can help PHS developers and providers to better under-
stand the concepts and processes required for instantiat-
ing authentication protocols that resists most offline and
online threats. Moreover, this study serves as an intro-
duction for security service providers to the emerging
landscape of P2P PHS and outlines the need for future
research to curtail other prevalent security issues.
8. References
[1] Dehling, T., and A. Sunyaev. Secure Provision of Pa-
tient-Centered Health Information Technology Ser-
vices in Public Networks—leveraging Security and Pri-
vacy Features Provided by the German Nationwide
Health Information Technology Infrastructure, Elec-
tronic Markets, 24, (2014), 89-99.
[2] Porsche-Consulting. The Digital Revolution of the
Healthcare Sector – Ecosystem, use Cases, Benefits,
Challenges and Recommendations for Action.
Healthcare of the Future, (2018).
[3] Spitzer, J. 63% of Americans Don'T Know Where their
Medical Data is Stored: 8 Survey Insights, (2018).
[4] Sunyaev, A. Internet Computing: Principles of Distrib-
uted Systems and Emerging Internet-Based Technolo-
gies, Springer International Publishing, (2020), 25-49.
[5] Troncoso, C., M. Payer, J. Hubaux, M. Salathé, J. La-
rus, E. Bugnion, W. Lueks, T. Stadler, A. Pyrgelis, and
D. Antonioli. Decentralized Privacy-Preserving Prox-
imity Tracing, Github DP-3T Documents, 12, (2020).
[6] Cho, H., D. Ippolito, and Y. W. Yu. Contact Tracing
Mobile Apps for COVID-19: Privacy Considerations
and Related Trade-Offs, arXiv:2003.11511, (2020).
[7] Hardjono, T., D. L. Shrier, and A. Pentland. Trusted
Data: A New Framework for Identity and Data Sharing,
MIT Press, (2019).
[8] Troncoso, C., M. Isaakidis, G. Danezis, and H. Halpin.
Systematizing Decentralization and Privacy: Lessons
from 15 Years of Research and Deployments, PoPETs,
(2017), 404-426.
[9] Vu, Q. H., M. Lupu, and B. C. Ooi. Architecture of
Peer-to-Peer Systems, P2P Computing, (2010), 11-37.
[10] Gassmann, H. P. OECD Guidelines Governing the Pro-
tection of Privacy and Transborder Flows of Personal
Data, Computer Networks (1976), 5, (1981), 127-141.
[11] Chen, G., H. Chen, L. Xie, G. Song, and T. Zhuang. An
Identity Authentication Scheme in Wireless Peer-to-
Peer Network, 12th IEE-ICCT, (2010), 473-476.
[12] Wenbo, M. Modern Cryptography: Theory and Prac-
tice, Publisher: Prentice Hall PTR, Copyright: Hewlett
Packard, (2004).
[13] Liu, Z. Control Engineering and Information Systems,
ICCEIS 2014, (2015).
[14] Kannengießer, N., S. Lins, T. Dehling, and A. Sunyaev.
Trade-Offs between Distributed Ledger Technology
Characteristics, ACM Computing Surveys, (2020).
[15] Caroline, H., and F. Jim. Your Medical Record is
Worth More to Hackers than Your Credit Card, Reu-
ters, (2014).
[16] Dehling, T., F. Gao, S. Schneider, and A. Sunyaev. Ex-
ploring the Far Side of Mobile Health: Information Se-
curity and Privacy of Mobile Health Apps on iOS and
An-droid, JMIR mHealth and uHealth, 3, (2015). e8.
[17] Gheorghe, G., R. Lo Cigno, and A. Montresor. Security
and Privacy Issues in P2P Streaming Systems: A Sur-
vey, Peer-to-Peer Networking and Applications, 4,
06/01, (2011), 75-91.
[18] Ghahramani, F., and J. Wang. Adoption of an Authen-
tication System: Is Security the Only Consideration?
ICIS 2017, (2017).
[19] Ariane, P. EHR and PHR: Digital Records in the Ger-
man Healthcare System, Healthcare Industry BW,
(2019).
[20] Muñoz, R. F. Using Evidence-Based Internet Interven-
tions to Reduce Health Disparities Worldwide, Journal
of Medical Internet Research, 12, (2010), e60.
[21] Xie, H., and J. Zhao. A Lightweight Identity Authenti-
cation Method by Exploiting Network Covert Channel,
Peer-to-Peer Networking and Applications, 8, (2015),
1038-1047.
[22] Chen, H., L. Ge, and L. Xie. A User Authentication
Scheme Based on Elliptic Curves Cryptography for
Wireless Ad Hoc Networks, Sensors, 15, (2015),
17057-17075.
[23] Zhao, Z., Y. Liu, H. Li, and Y. Yang. An Efficient
User-to-User Authentication Scheme in Peer-to-Peer
System, IEE-INIS, (2008), 263-266.
[24] Muffet, A. Facebook: Password Hashing & Authenti-
cation, Real World Crypto, (2015).
[25] Lai, R. W., C. Egger, M. Reinert, S. S. Chow, M. Maf-
fei, and D. Schröder. Simple Password-Hardened En-
cryption Services, 27th USENIX Security Symposium,
(2018), 1405-1421.
[26] Bernabe, J. B., M. David, R. T. Moreno, J. P. Cordero,
S. Bahloul, and A. Skarmeta. Aries: Evaluation of a Re-
liable and Privacy-Preserving European Identity Man-
agement Framework, Future Generation Computer
Systems, 102, (2020), 409-425.
[27] Diomedous, C., and E. Athanasopoulos. Practical Pass-
word Hardening Based on TLS, Dimva 2019, Interna-
tional Conference on Detection of Intrusions and Mal-
ware, and Vulnerability Assessment, 11543, (2019),
441-460.
[28] Google, and Harris-Poll. Google, in Partnership with
Harris Poll, Surveyed a Nationally Representative
Sample of 3,000 Adults (Ages 16-50+) Living in the
U.S. to Understand their Beliefs and Behaviors Around
Online Security. (2019).
[29] Verizon. 2018 Data Breach Investigations Report 11th
Edition, (2018).
[30] Protenus. 2020 Breach Barometer. how are Health Data
Breaches Affecting Your Organization? (2020).
[31] Shouqi, C., L. Wanrong, C. Liling, H. Xin, and J.
Zhiyong. An Improved Authentication Protocol using
Smart Cards for the Internet of Things, IEEE Access,
7, (2019), 157284-157292.
[32] Vanhoef, M., and F. Piessens. Release the Kraken: New
KRACKs in the 802.11 Standard, (2018), 299-314.
[33] Aumasson, J., S. Neves, Z. Wilcox-O’Hearn, and C.
Winnerlein. BLAKE2: Simpler, Smaller, Fast as MD5,
International Conference on Applied Cryptography and
Network Security, (2013), 119-135.
[34] Singh, M., C. Kumar, and P. Nath. Challenges and Pro-
tocols for P2P Applications in Multi-Hop Wireless
Networks, 2nd ICCMC, (2018), 310-316.
[35] Alex, H. Public Health England will keep personal
data of people with coronavirus for 20 years. The
Guardian, (2020).
[36] Natasha, L. Germany Ditches Centralized Approach to
App for COVID-19 Contacts Tracing, Techcrunch,
(2020).
