10610
13, JULY 1, 2022
A New Approach to Constructing Decentralized
Identifier for Secure and Flexible Key Rotation
Chang-Seop Park , Member, IEEE, and Hye-Min Nam
Abstract—Owing to the introduction of blockchain (BC) tech-
nology, a decentralized identity (DID) model has been proposed to
replace conventional identity models based on centralized author-
ities. The BC platform operated by various participants provides
a new root-of-trust functionality for entity identification and
access control. Each entity generates and registers its own iden-
tifier and credential (public key) to the BC such that any entity
can obtain the other entity’s public key. When the corresponding
private key is compromised, the key rotation to generate and reg-
ister a new key pair should be performed. However, the current
approach for cryptographically binding a decentralized identi-
fier with a public key induces a serious security problem that
results in both identity-stealing attacks and multiple identifiers
for a single entity. A new DID to address the security problem
above is proposed herein, which is based on a newly proposed
cryptographic primitive (infinite one-way hash chain), as well as
its security analysis and performance evaluation on Hyperledger
Fabric and Contiki Cooja simulator. To demonstrate the appli-
cability of the proposed DID to various security protocols, an
authenticated key exchange protocol is also designed.
Index Terms—Blockchain (BC), decentralized identity (DID),
hyperledger fabric, identity-stealing attack, infinite one-way hash
chain, key rotation, root-of-trust.
I. I NTRODUCTION
DENTITY management models, such as the silo, feder-
I ated identity, and user-centric identity models, have evolved
over the last three decades to reduce the number of identities
maintained by each entity for multiple service providers and
to return identity control to the entity. In particular, the iden-
tity management of the Internet of Things (IoT) has gained
increasing significance as it includes not only the user identi-
fication for controlling access to various devices and services
but also user–device/device–device interactions.
Recently, the concept of decentralized identity (DID) or
self-sovereign identity (SSI) based on blockchain (BC) tech-
nology has been introduced as the next-generation iden-
tity model [1], [2] replacing conventional identity models.
Several startups and academic research groups have proposed
various identity management systems based on the DID
Manuscript received May 12, 2021; revised July 17, 2021; accepted
October 18, 2021. Date of publication October 21, 2021; date of current
version June 23, 2022. This work was supported by the Basic Science
Research Program through the National Research Foundation of Korea (NRF)
funded by the Ministry of Education, Science and Technology under Grant
NRF-2021R1A2C100327611. (Corresponding author: Chang-Seop Park.)
Chang-Seop Park is with the Department of Software Science, Dankook
University, Yongin 16890, Republic of Korea (e-mail: csp0@dankook.ac.kr).
Hye-Min Nam is with the Department of Computer Science, Dankook
University, Yongin 16890, Republic of Korea (e-mail: nhm9410@naver.com).
Digital Object Identifier 10.1109/JIOT.2021.3121722
2327-4662 
c 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO.
model [3]–[7], including device management systems in IoT
applications [8]–[10]. Each entity (person, thing, or collective)
generates its own DID comprising a decentralized identi-
fier (dID) and the associated attributes without relying on
any trusted third parties (TTPs), such as certificate author-
ities (CAs) or service/identity providers. The attributes of
the DID include security credentials (sCRs) based on the
public- and private-key pairs for entity identification and
access control, as well as the entity description for mapping
it to a real-world entity [e.g., a user’s e-mail address or the
medium access control (MAC) address of an IoT device]. Self-
sovereignty over identity is achieved when each entity can
control its identity, as well as when central authorities (TTPs)
have no authority over them [11].
As the BC is a framework for DID management, four oper-
ations are applied to the DID—creation, registration, update,
and deletion of the DID—all of which should be initiated
entirely by the entity (DID owner) and validated using the
chaincode (or smart contract) of the BC. Three security-related
issues are associated with DID management–key recovery, ID
squatting, and key rotation.
A key recovery mechanism should be provided when
the private key of the entity is lost. Without the key
recovery mechanism, the dID associated with it no longer
belongs to the original entity. Recently, a key recovery
mechanism [12] known as “key sharding” based on Shamir’s
secret sharing [13] has been proposed, where the private key
is segregated into N shards, and each of them is distributed to
N trusted entities. During a loss, the original entity requests
K (< N) shards of the key from N trusted entities, where K is
the number of distinct shards required for the recovery. Upon
receiving K shards, the key is successfully recovered.
The second issue is the ID-squatting problem. Because the
same dID cannot be assigned more than once, registering
unused dIDs to the BC repeatedly through adversaries might
create a problem even though the dID derived based on the
cryptographic hash is less sensitive to ID squatting than the
human-readable ID. For instance, Namecoin [14] employed a
first-come–first-serve logic to assign name–value pairs. In a
recent study pertaining to Namecoin, only 28 of 120 000 regis-
tered domain names were not squatted [15]. Hence, depending
on the application scenario, a suitable mechanism to suppress
ID squatting is required.
The third issue is the key rotation replacing a current key
pair (SK, PK) with a new key pair (SK + , PK + ), where a new
public key (PK + ) is posted to the BC together with the sig-
nature using the current private key (SK) [16]. If an adversary
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
obtains the current private key of a certain entity, the adversary
can mount various security attacks using the compromised pri-
vate key. Because the moment at which the private key is
compromised cannot be predicted accurately, the only defense
is to update the key pair regularly such that the vulnerability
window resulting from the compromised private key can be
reduced. Hence, the purpose of the key rotation for the DID
system is the same as that for the PKI system.
Among the three security issues related to DID manage-
ment, the key rotation issue is the main theme of this study.
In this study, the relationship between a dID and its associated
credentials was investigated in addition to its security implica-
tions. We observed that the current approach of key rotation for
DID management exhibits security and usability issues, which
will be discussed more comprehensively in Section II. Once
the private key is compromised, the control of the victim’s
dID is completely relinquished to the adversary, such that the
victim entity loses its own dID indefinitely (we name this the
“ID-stealing attack”), which differs significantly from the PKI
system. In the PKI system, even if the private key is compro-
mised and a new certificate is issued to the victim entity, its
original identifier can be maintained.
Motivated by the fact that the compromised private key
induces an ID-stealing attack as well as various security
attacks against the security protocols (e.g., entity authentica-
tion and access control), a new DID resilient to such security
attacks is designed by embedding additional security function-
ality into the DID. Whereas the sCR of the conventional DID
comprises a key pair, our DID’s sCR is augmented with one-
time password (OTP) based on the hash chain. Therefore, the
adversary should obtain the next OTP value together with the
private key to mount such security attacks including the ID-
stealing attack. The proposed OTP serves as both a nonce
for the security protocol based on the proposed DID and
a second-factor authenticator for the key rotation in DID
management.
The major contributions of this study are as follows.
1) A new cryptographic primitive known as “infinite one-
way hash chain” is designed, which is an extension of
Lamport’s one-way hash chain [17], whose main weak-
ness is the finite length of the hash chain. Without a
preshared secret between two entities, each hash value of
the hash chain can be used for various security purposes
once the root of the hash chain is registered. Meanwhile,
Lamport’s hash chain requires a new root registration
when the current hash chain is exhausted, and the infinite
hash chain requires only one registration.
2) A new DID is constructed based on the proposed “infi-
nite one-way hash chain,” where the PK of the entity
is embedded in each value of the infinite one-way hash
chain. The main reason for constructing a DID with such
an infinite hash chain is to create an immutable dID with
flexible key-rotation functionality.
3) An authenticated key exchange protocol between two
entities is designed to demonstrate the applicability
of the proposed DID to various security protocols.
Additionally, it can be adapted for a new security mode
for TLS/DTLS handshake.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10611
4) The proposed DID based on the infinite one-way hash
chain is implemented using Hyperledger Fabric [18] and
Contiki Cooja simulator, and its performance is evalu-
ated and compared with those of conventional DIDs.
The remainder of this article is organized as follows.
Following the problem statements provided in Section II,
the backgrounds of the DID and one-way hash chain are
introduced in addition to previous related studies, since our
proposed DID evolves from them. In Section IV, a new dID
denoted as “BC-cID-L” for limited key rotations, which is
an intermediate step for the design of “BC-cID-F,” is intro-
duced. Subsequently, flexible key rotations are discussed in
Section V. Security analysis and performance evaluations are
provided in Sections VI and VII, respectively, and finally, the
concluding remarks are presented in Section VIII.
II. P ROBLEM S TATEMENT
After the DID is generated by the entity, it should be reg-
istered on the BC by the entity or the agent delegated to the
entity. Hence, the uniqueness of the dID on the BC should
be guaranteed, and its corresponding sCRs should be asso-
ciated with the dID. Currently, two approaches can be used
to link the dID to its sCRs: self-signed certificates and self-
certifying identifiers, both of which are derived from a PK and
SK pair. Given a key pair generated by the entity, the DID is
composed of (dID, PK, Sig(SK)), where dID is the dID, and
Sig(.) is a signature on both the dID and PK using the SK
in the self-signed certificate approach. Meanwhile, the DID is
composed of (cryptographic identifier (cID), PK) in the self-
certifying identifier approach, where cID is the cryptographic
identifier (cID), which is a special case of the dID and is
derived from the PK using a cryptographic hash function h(.),
where cID = h(PK). If the uniqueness of the dID derived from
either of the approaches is not verified by the chaincode (or
smart contract) of the BC, then the entity should repeat the
registration process after generating a new key pair.
If the key pair (SK, PK) associated with dID must be
rotated (updated) because SK is compromised, then the entity
generates a new key pair (SK+ , PK+ ) and derives a new
self-signed certificate (dID, PK+ , Sig(SK)) in the self-signed
certificate approach. When the new self-signed certificate is
posted to the BC to update the current certificate (dID, PK,
Sig(SK)), the chaincode (or smart contract) verifies whether
Sig(SK) in the new certificate is valid using the current public
key PK. In this case, (dID, PK+ , Sig(SK)) is posted instead
of (dID, PK+ , Sig(SK+ )) because the chaincode recognizes
(dID, PK+ , Sig(SK+ )) as a new DID to register by another
entity and refuses its registration. However, this is a severe
security weakness, in that the adversary accessing the compro-
mised SK can steal the DID belonging to the original entity.
Meanwhile, when the current key pair (SK, PK) associated
with the cID in the self-certifying approach is updated to a new
key pair (SK+ , PK+ ), then the current cID should be changed
to cID+ = h(PK+ ), where cID+ = cID because of the crypto-
graphic property of h(.). That is, when the key pair is rotated,
the current dID is changed, which is undesirable and unac-
ceptable in most digital ID applications. Suppose the cID is
10612
the identifier of a vehicle. Even if more than one identifier can
be assigned to a single vehicle, it is reasonable and efficient to
identify each vehicle with a single identifier administratively.
A current approach to mitigate the risk due to a compro-
mised private key is to proactively perform the key rotation
to reduce the vulnerability window. However, once the pri-
vate key is exposed to the adversary, the ID-stealing attack
can be easily mounted. Hence, a new DID that is robust to
ID-stealing attacks should be designed. Furthermore, it should
demonstrate immutability, in that the dID (or cID) must not
change even when the key rotation is performed.
III. BACKGROUND AND R ELATED W ORK
In this section, two cryptographic primitives (dID and one-
way hash chain) are introduced as our proposed security
framework evolves from them. Each of them is proposed
as a building block to construct various security protocols
and mechanisms, and several of their variants have been also
proposed to enhance their security and efficiency.
A. Decentralized Identifier and PKI
A globally unique identifier generated by an entity has
become a necessity since the 1980s. The universally unique
identifier (UUID) [19], [20] and IPv6 address for secure neigh-
bor discovery [21] are two examples of early versions of dIDs
that are generated in a semidecentralized manner. A 122-bit
UUID is generated by a device based on a device-specific
MAC address allocated by the device manufacturer. Similarly,
the 128-bit IPv6 address comprising both a subnet prefix
and an interface identifier can be generated by the entity
(host/router). However, the subnet prefix is allocated by the
Internet service provider (ISP), even though the IPv6 interface
identifier is selected by the entity and its uniqueness is tested
within the subnet. Hence, a type of TTP, such as the device
manufacturer and the ISP, is involved in the generation of
globally unique identifiers.
Owing to the introduction of BC technology, each entity can
generate its own identifier without relying on the TTPs, such
as CAs and service/identity providers. Because conventional
TTPs are operated centrally, a single point of failure [22], [23]
of CAs and multiple identifiers for an entity from multiple
service/identity providers are yielded. Meanwhile, the BC plat-
form can be considered as a decentralized TTP that is operated
by various participants for several application domains such
that each participating entity can control its own identity.
Recently, the concept of DID (or SSI) has been introduced
as the next-generation identity model based on BC technology.
Several startups and academic research groups have proposed
BC (Bitcoin, Ethereum)-based identity management systems,
such as Sovrin [3] and Uport [4]. In particular, Certcoin [5],
Authcoin [6], and Blockstack [7], all of which are based on
Namecoin [14] (forked from Bitcoin), have been proposed as
a decentralized PKI platform. A DID comprises a dID and the
associated attributes, where dID is also known as BC-dID as it
is based on the BC platform and the attributes include the sCR
for the entity identification. Even though the attributes of the
DID include the entity description for mapping the dID to the
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
Construction 1 BC-dID
On input SKx ∈R {0, 1}l and dIDx ∈R {0, 1}l
• PKx ← pkGen(SKx ), where pkGen(.) is a public-key
generation function;
• (dIDx , PKx , Sig(SKx )) is generated as a self-signed
certificate;
• If dIDx is unique and Sig(SKx ) is valid, it is registered at
the BC;
real-world entity, it is assumed in this study that DID = (dID,
sCR) to focus on the security issues of the DID. Each dID
should be unique on each BC platform and be tightly bound
to the sCR. As the sCR is stored in the BC, it cannot be a
password or a secret key, but a PK.
Two approaches can be used to bind the dID cryptographi-
cally with the sCR—self-signed certificate and self-certifying
identifier—both of which are candidates seeking the W3C
standard [16]. The first approach is discussed in this section,
whereas the second approach in Section III-B. An entity x
(person, thing, or collective) generates a pair of private key
(SKx ) and public key (PKx ) and then constructs a self-signed
certificate to bind dIDx cryptographically with PKx . Hence,
DIDx = (dIDx , PKx , Sig(SKx )), where Sig(SKx ) is a self-
signed signature on both dIDx and PKx using SKx , as in
Construction 1.
As any entity can access a specific entity’s PK through the
BC platform, any two entities can perform various security
protocols based on each other’s PK. However, when the key
pair (SKx , PKx ) associated with dIDx is compromised, the
adversary generates a new key pair (SK+ +
x , PKx ) and posts
+
(dIDx , PKx , Sig(SKx )) to the BC; therefore, the ID-stealing
attack can be mounted as mentioned in Section II.
B. Cryptographic Identifier as Decentralized Identifier
A cID is an identifier into which a cryptographic prop-
erty is embedded, and for a pair of private and public keys,
a simplified cID is derived from the public key. The con-
cept of the cID first appeared in the design of a secure
file system [24], where each file name (identifier) is derived
from a cryptographic key. Furthermore, it has been employed
to construct an IPv6 address and is known as a crypto-
graphically generated address (CGA) [25], which is useful
for securing the IPv6 neighbor discovery protocol [21] and
the mobile IPv6 binding update protocol [26]. Meanwhile,
an address-based key (ABK) is based on identity-based
cryptography [27], where any IPv6 address can be used as
a PK. However, it requires a trusted party to generate and
distribute private keys. Because the CGA does not require a
trusted and centrally controlled party, it is superior to both the
ABK and PKI-based certificates.
When the cID is operated on the BC platform, it can be
another form of dID. A typical BC-based cID (BC-cID) is an
account holder’s address in cryptocurrency systems, such as
Bitcoin and Ethereum. The BC-cID is a self-certifying identi-
fier, in that for a PK and cID, no proof is required to confirm
that the PK belongs to the cID’s owner (entity). The BC-cID
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
Construction 2 BC-cID
On input SKx ∈R {0, 1}l
• PKx ← pkGen(SKx ) ;
• cIDx ← h(PKx ), where h(.) is a cryptographic hash
function such that h: {0, 1}* → {0, 1}l ;
• If cIDx is unique and valid, (cIDx , PKx ) is registered at
the BC;
Construction 3 One-Way Hash Chain
On input Kx ∈R {0, 1}k
• hcx = {xj | xj = h(xj+1 ) for j ∈ [0, n−1] and xn = h(Kx ||
“chain seed”)}, where ‘||’ is concatenation;
of an entity x is derived as in Construction 2. When the current
key pair (SKx , PKx ) associated with cIDx is updated to a new
key pair (SK+ +
x , PKx ), the current cIDx should be changed to
+
cIDx = h(PKx ). +
C. One-Way Hash Chain
A one-way hash chain proposed by Lamport was first
employed to design an OTP system [17] without a shared
secret between the prover and verifier. It is generated by
applying consecutive cryptographic hash functions to a ran-
dom number (seed); subsequently, the hash values of the hash
chain are used in the reverse order as OTPs. Because the ver-
ifier maintains the last hash value sent from the prover, it is
not feasible for an adversary (insider or outsider) to derive
the next hash value because of the preimage resistance of the
cryptographic hash function. For a random seed Kx ∈R {0, 1}k ,
a one-way hash chain, hcx of length n is generated as shown
in Construction 3.
After generating hcx , the prover must register a root value
x0 in advance at the verifier. For a previous hash value (a
commitment value) xj , the next hash value (a new commitment
value) xj+1 satisfying xj = h(xj+1 ) can be generated only by
the entity who knows the seed. An authenticated channel with
the verifier’s authentication should be provided between them
to prevent man-in-the middle attacks. Lamport’s one-way hash
chain is disadvantageous in terms of practical implementation,
i.e., a new hash chain must be generated, and a new root value
must be registered when all hash values of a current hash chain
are used.
Various schemes for converting Lamport’s finite hash chain
into an infinite hash chain have been proposed, and they can
be categorized into two schemes: 1) Lamport-like [28] and
2) non-Lamport-like scheme [29], [37], [38]. The former is
based on the cryptographic hash function only, whereas the
latter employs additional cryptographic primitives such as sig-
nature or PK encryption, in addition to the cryptographic hash
function. Hence, the Lamport-like scheme is more favorable
as it provides simplicity and higher implementation efficiency.
In Section V, another Lamport-like infinite hash chain is
proposed. A more detailed comparison among the schemes
can be found in Appendix A.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10613
Construction 4 BC-cID-L
On input Kx ∈R {0, 1}k
• xn ← h(Kx ||“chain seed”);
• for j = n, n−1, ... , 2, 1 {
. SKx (j) ← kdf (Kx , “key seed”||j), where
kdf (.) is a key-derivation function;
. PKx (j) ← pkGen(SKx (j) );
. xj−1 ← h(xj || PKx (j) );
}
• cIDx ← h(x0 || PKx (0) );
Fig. 1. Generation of BC-cID-L for limited key rotation.
IV. D ESIGN OF C RYPTOGRAPHIC ID FOR
L IMITED K EY ROTATIONS
A main drawback of the BC-cID in Construction 2 is that
the BC-cID should be changed on each key rotation. However,
if the BC-cID is fixed as an identifier of an entity, the usage
of the cID is limited. In this section, a new BC-cID named
“BC-cID-L” is designed to embed the limited key-rotation
functionality, as a middle stage of designing “BC-cID-F” with
the full and flexible key-rotation functionality, which will be
discussed in Section V. To embed the key-rotation functional-
ity into the BC-cID, BC-cID of Construction 2 is integrated
with the one-way hash chain. Let E = {x, y, z, . . .} be a set
of entities. Therefore, cID (cIDx ) of entity x can be generated
as in Construction 4. Fig. 1 shows the BC-cID-L generated
based on Construction 4.
When an initial entry (cIDx , x0 , PKx (0) ) for entity x is sent
to the BC for registration, the chaincode (or smart contract) of
the BC verifies if cIDx is unique on the BC and cIDx = h(x0 ||
PKx (0) ). If the verification is successful, then the initial entry
for entity x is registered at the BC. By querying the BC,
another entity (i.e., entity y) can obtain entity x’s current PK
and authenticate entity x by verifying the signature, Sig(SKx (0) )
on the challenge sent from entity y.
If the key rotation is required, entity x can perform it directly
on the BC. Namely, to update the public key from PKx (0) to
PKx (1) , entity x sends (cIDx , x1 , PKx (1) ) to the BC, and the
chaincode (or smart contract) verifies if x0 = h(x1 ||PKx (1) ). If
the verification is successful, a new entry (cIDx , x1 , PKx (1) )
for entity x can be appended to the BC, and PKx (1) will be the
current public key of cIDx . Although the number of possible
key rotations is limited to n−1 as the length of the one-way
hash chain is n, the BC-cID-L is secure against the ID-stealing
attack.
10614
Fig. 2. Infinite hash chain and BC-cID-F for flexible key rotation.
Proposition 1: BC-cID-L is secure against the ID-stealing
attack.
Proof: Suppose the BC stores (cIDx , xj−1 , PKx (j−1) ) for
entity x and SKx (j−1) is exposed to an adversary, where j ∈
[1, n]. Then, the adversary generates its own key pair (SKAdv ,
PKAdv ) such that PKAdv = pkGen(SKAdv ) together with xAdv ,
and sends (cIDx , xAdv , PKAdv ) to the BC. In order for the ID-
stealing attack to be successful, xj−1 = h(xAdv || PKAdv ) should
be met. However, due to the second-preimage resistance prop-
erty of h(.), it is not feasible to find (xAdv , PKAdv ) such that
xj−1 = h(xAdv ||PKAdv ) = h(xj ||PKx (j) ).
V. D ESIGN OF C RYPTOGRAPHIC ID FOR
F LEXIBLE K EY ROTATIONS
The compromised private key in the DID model can be abused
via impersonation and ID-stealing attacks. Both the BC-dID
and BC-cID are subject to two types of attacks, whereas the
BC-cID-L is robust to the ID-stealing attack, as discussed in
Section IV. However, the BC-cID-L presents two security weak-
nesses. First, the number of secure key rotations for suppressing
the ID-stealing attack is limited. Second, a compromised pri-
vate key can still induce illegitimate authentication. In this
study, an infinite one-way hash chain and the associated OTP
were designed, based on which a security-enhanced BC-cID,
denoted as BC-cID-F (flexible key rotation), was designed to
address the security weaknesses of the BC-cID-L. In particu-
lar, it is shown in Sections V-E and VI-C that the BC-cID-F
remains secure under the impersonation attack induced by the
private key compromise.
A. Design of Infinite Hash Chain and OTP
We begin with the one-way hash chain used for the
OTP in Section III-C. As shown in Fig. 2-(A), the origi-
nal hash chain of Construction 3 is denoted hcx (1) ={x0 (1) ,
x1 (1) , x2 (1) , x3 (1) , . . . , xn (1) }. When the verifier maintains
xj−1 (1) as a commitment value and receives xj (1) for j ≥
1 as the next commitment value from entity x, the verifier
checks if xj−1 (1) = h(xj (1) ). Our approach in constructing
an infinite (one-way) hash chain is to generate multiple
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
Construction 5 Multiple Hash Chains, hc(Kx , i)
On input Kx ∈R {0, 1}k and i ≥ 1
hcx (i) = {xj (i) | xj (i) = h(xj+1 (i) ) for j ∈ [0, n−1] and
xn (i) = h(Kx || “chain seed”||i)};
Construction 6 Infinite Hash Chain
On input Kx ∈R {0, 1}k
• call hc(Kx , 1) to generate hcx (1) = {x0 (1) , x1 (1) , . . . ,
xn (1) };
• x0 (1) is a root of infinite hash chain;
• for i = 1, 2, 3, . . . . {
. call hc(Kx , i+1) to generate hcx (i+1) = {x0 (i+1) ,
x1 (i+1) ,. . . , xn (i+1) };
. for j = 1, 2, 3, . . . , n−1 {
generate a 3-tuple (xj (i) , x0 (i+1) , h(j+1)(i) );
}
. generate a 3-tuple (xn (i) , x0 (i+1) , h(1)(i+1) ));
}
hash chains, hcx (i) for i ≥ 1, each of which is of length
n, as in Construction 5; and binds them seamlessly, as in
Construction 6, as if they are parts of an infinite hash chain.
To bind multiple hash chains seamlessly, the root value x0 (2)
of the second hash chain hcx (2) = {x0 (2) , x1 (2) , x2 (2) , . . . ,
xn (2) } is sent in advance when the prover (entity x) sends xj (1)
to the verifier for j ≥ 1. A reason to send x0 (2) proactively is to
register it as a new root value for the second hash chain before
the first hash chain is exhausted. From the security viewpoint,
the integrity of the root value (i.e., x0 (2) , x0 (3) , x0 (4) , . . .) to
be registered for the next hash chain should be guaranteed.
Otherwise, an adversary can modify the root value into another
one and control the subsequent sessions after the current hash
chain is exhausted. To address the problem, the root value of
the next hash chain should be integrity protected by the next
hash value of the current hash chain.
For example, when {xj (1) , x0 (2) } is sent, xj+1 (1) is used to
compute h(xj+1 (1) || x0 (2) ) = h(j+1)(1) such that (xj (1) , x0 (2) ,
h(j+1)1 ) is sent, where h(j+1)(1) is a type of message-integrity
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
Construction 7 Modified Hash Chains, mhc(Kx , i)
On input Kx ∈R {0, 1}k and i ≥ 1
• SKx (i) ← kdf (Kx , “key seed”||i);
• PKx (i) ← pkGen(SKx (i) );
• mhcx (i) = {xj (i) | xj (i) = h(xj+1 (i) ||PKx (i) ) for j ∈ [0, n−1]
and xn (i) = h(Kx || “chain seed”||i)};
code (MIC) for x0 (2) using xj+1 (1) . Hence, the infinite
hash chain comprises three-tuples sequentially generated from
Construction 6, as in the shaded box shown in Fig. 2-(B).
When the infinite hash chain is employed for the OTP authen-
tication, each three tuple is a OTP. For a root x0 (1) of the
infinite hash chain, a series of three tuples can be generated:
(x1 (1) , x0 (2) , h21 ) for the first OTP, (x2 (1) , x0 (2) , h31 ) for the
second OTP, (x3 (1) , x0 (2) , h41 ) for the third OTP, etc.
Suppose the prover registers (C = x0 (1) , D = __, E = __ )
at the verifier, where “__” denotes a null value. When receiv-
ing (x1 (1) , x0 (2) , h21 = h(x2 (1) || x0 (2) )), the verifier checks
if x0 (1) = h(x1 (1) ). Upon a successful verification, the ver-
ifier changes the commitment value from x0 (1) to x1 (1) and
stores (x0 (2) , h21 ) such that the prover’s entry at the verifier
is updated to (C = x1 (1) , D = x0 (2) , E = h21 ). Upon the
next successful verification on x1 (1) = h(x2 (1) ) after (x2 (1) ,
x0 (2) , h31 ) is received from the prover, x0 (2) can be confirmed
as a valid root of the next hash chain if h21 = h21 , where
h21  is a value computed by the verifier. Hence, the confirma-
tion on E = h21 is delayed until the next OTP is processed.
Subsequently, the prover’s entry at the verifier is updated to
(C = x2 (1) , D = x0 (2) , E = 1), where E = 1 means that
D = (x0 (2) ) has been confirmed valid.
Once the root of the next hash chain is confirmed valid, the
subsequent OTPs do not necessarily contain an identical x0 (2)
together with a MIC until the end of the current hash chain.
This is the case when a reliable transport of each OTP consist-
ing of three tuple is guaranteed. However, some three tuples
might not be delivered to or processed by the verifier when an
unreliable transport such as the UDP is employed for the IoT
application using the OTPs. Suppose an IoT device (prover)
transmits each OTP to another IoT device (verifier) regularly
(i.e., every 10 s) to prove that it is active. Because it is bur-
densome for resource-constrained IoT devices to establish or
maintain the TCP connection with each other, the UDP is
typically employed for the IoT applications allowing for ran-
dom packet loss. Hence, the periodic and iterated OTPs for
the liveness test can be transmitted without requiring acknowl-
edgements from the verifier since the intermittent packet losses
do not deteriorate the overall operation for the liveness test.
Considering both the reliable and unreliable transport, each
three tuple is designed to contain such redundant items.
B. Cryptographic ID Based on Infinite Hash Chain
A new BC-cID named “BC-cID-F” of entity x is con-
structed based on the infinite hash chain, as shown in Fig.
2-(C). However, the multiple hash chains of Construction 5 are
modified to embed the PK information into them, i.e., mod-
ified (multiple) hash chains, mhcx (i) for i ≥ 1, are generated
using Construction 7.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10615
Construction 8 BC-cID-F
On input Kx ∈R {0, 1}k
• call mhc(Kx , 1) to generate mhcx (1) = {x0 (1) , x1 (1) , . . . , xn (1) };
• cIDx ← h(x0 (1) || PKx (1) );
• for i = 1, 2, 3, . . . . {
. call mhc(Kx , i+1) to generate mhcx (i+1) = {x0 (i+1) ,
x1 (i+1) , . . . , xn (i+1) };
. for j = 1, 2, 3, . . . , n−1 {
generate a 3-tuple (xj (i) , x0 (i+1) , h(j+1)(i) );
}
. generate a 3-tuple (xn (i) , x0 (i+1) , h(1)(i+1) ));
}
Procedure 1: Registration
On input (cIDx , x0 (1) , PKx (1) )
Run (chaincode)
• if cIDx is not unique, exit (“duplicate cID”);
• if cIDx  = h(x0 (1) || PKx (1) ), exit (“invalid cID”);
• append (cIDx , PKx (1) , x0 (1) , _ , _ ) to the BC;
Using Construction 8, a “BC-cID-F” of entity x is generated,
i.e., cIDx = h(x0 (1) || PKx (1) ) and each three tuple (OTP) can
be used for both entity authentication and public-key rotation.
It is assumed in this study that any entity can register its BC-
cID-F generated if it is unique and valid. Let E = {x, y, z, . . .} be
a set of entities to be registered on the BC. Using Construction 8,
entity x ∈ E generates its first modified hash chain, mhcx (1) ,
where cIDx = h(x0 (1) || PKx (1) ). When entity x registers (cIDx ,
x0 (1) , PKx (1) ) at the BC, the chaincode of the BC performs a
uniqueness test on cIDx , as in Procedure 1.
If it is already registered by other entity, entity x gener-
ates another modified hash chain based on Kx  = Kx and
repeats the registration. Subsequently, it is verified whether
cIDx = h(x0 (1) ||PKx (1) ). If the verification is successful, an ini-
tial entry (A = cIDx , B = PKx (1) , C = x0 (1) , D = __, E = __)
for entity x is appended to the BC, where “__” denotes a null
value and will be padded with an appropriate value as entity
x updates its own entry at the BC.
C. BC Update and BC Query
Entity x can update its entry at the BC to change its cur-
rent commitment value stored in C. If the current commitment
value is the last one of the current hash chains, then the key
rotation to update the current PK stored in B is performed.
Otherwise, it verifies whether the nonce generated by entity
x is valid when the nonce is employed to perform various
security protocols with other entities (Appendix B shows an
example scenario for the BC update). In particular, the key
rotation can be performed by jumping to the first hash value
of the next hash chain (more details will be presented in
Section V-D.) even if the current commitment is not the last
one in the current hash chain.
Suppose entity x’s current entry at the BC is (A = cIDx ,
B = PKx (i) , C = xj (i) , D = x0 (i+1) , E = h(α)(β) /1), where
α = j+1 and β = i for j ∈ [1, n−1]; and α = 1 and
β = i+1 for j = n. A = cIDx is entity x’s BC-cID-F and
B denotes its current PK. C, D, and E are the same as those
10616 IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022

Fig. 3. BC-update procedures initiated by entity x.

∗ ∗
Procedure 2 genBCupdate xj (i) ) = h(xj∗ (i ) ||PKx (i ) ) for j ∈ [1, n−1] or if D (=
∗ ∗
On input (Kx , i ≥ 1 and j ∈ [1, n]) x0 (i+1) ) = h(xj∗ (i ) ||PKx (i ) ) for j = n. Upon a successful ver-
/* compute new indices for BC-update */ ification, the current entry at the BC is changed to (A = cIDx ,
• i* ← i; j* ← j+1; α* ← j*+1; β* ← i*; ∗ ∗ ∗
• if (j = n−1) {α* ← 1; β* ← i*+1};
B = PKx (i ) , C = xj∗ (i ) , D = x0 (i +1) , E = h(α ∗ )(β ∗ ) /1).
• if (j = n) {i* ← i+1; j* ← 1}; Fig. 3 shows the method to generate and process the BC-
/* compute chain seed, PK and OTP */
∗ ∗ ∗ ∗
update transaction (Procedures 2 and 3) through a concrete
• (PKx (i ) , xn (i ) , PKx (i +1) , xn (i +1) ) ← comPK (Kx , i*); example.
∗ ∗ (β ∗) ∗) ∗ ∗
• if (β = i ) {PKx ← PKx } else {PKx (β ) ← PKx (i +1) };
(i
Entity x’s entry in the BC is shown after each BC-update
∗ ∗ ∗
• xjα ∗ (i ) ← comHash (n−j*, xn (i ) , PKx (i ) );
∗ ∗ ∗ is performed by entity x, where the initial entry for (i = 1,
• x0 (i +1) ← comHash (n, xn (i +1) , PKx (i +1) );
(β ∗) (β ∗) ∗ j = 0) is stored upon a successful registration. When the
• xα ∗ ← comHash (n−α*, xn , PKx (β ) );
∗ ∗ first BC-update{cIDx , PKx (1) , x1 (1) , [x0 (2) , h21 ]} is sent to the
• h(α ∗ )(β ∗ ) ← h(xα ∗ (β ) ||x0 (i +1) );
∗ ∗ ∗ chaincode of the BC by entity x( 1 ), the chaincode verifies if
• return (cIDx , PKx (i ) , xj∗ (i ) , x0 (i +1) , h(α ∗ )(β ∗ ) )
x0 (1) = h(x1 (1) ||PKx (1) ). Upon a successful verification, entity
x’s entry is changed as follows (❶): (A = cIDx , B = PKx (1) ,
Procedure 3 procBCupdate C = x1 (1) , D = x0 (2) , E = h21 ). D = x0 (2) is not yet confirmed
∗ ∗ ∗
On input (cIDx , PKx (i ) , xj∗ (i ) , [x0 (i +1) , h(α ∗ )(β ∗ ) ]) as a valid root of the next hash chain because E = h21 cannot
Run (chaincode) ∗ ∗ ∗ ∗
be verified without knowing x2 (1) . Hence, the verification on
• if C  = h(xj∗ (i ) || PKx (i ) ) and D  = h(xj∗ (i ) || PKx (i ) ) E = h21 is delayed until the next BC-update transaction is
exit (“invalid BC update”);
∗ ∗ processed.
• C ← xj∗ (i ) ; D ← x0 (i +1) ;
∗ ∗ When the second BC-update{cIDx , PKx (1) , x2 (1) ,
• if C = h(xj∗ (i ) || PKx (i ) ) {
. if E = ‘_’ {E ← h(α ∗ )(β ∗ ) }; [x0 (2) , h31 ]} is sent by entity x (❷), E = h21 can be
∗
. if E = h(xjα ∗ (i∗) || x0 (i +1) ) {E ← 1}; verified using x2 (1) . Upon a successful verification ( 2 ), E is
} set to 1, which means that the root (x0 (2) ) of the next hash
∗ ∗ ∗
• if D = h(xj∗ (i ) || PKx (i ) ) { E ← h(α ∗ )(β ∗ ) ; B ← PKx (i ) }; chain is ready to be used as a commitment value when the
• return (“valid BC update”); current hash chain is exhausted. In case of (i = 1, j = n−1),
the BC-update transaction ( 3 ) changes the current commit-
ment value (❸) from xn−1 (1) to xn (1) , but [x0 (2) , h12 ] does not
in Section V-A. Entity x generates the BC-update transaction, change E because x0 (2) has been already verified as a root of
∗ ∗ ∗
BC-update{cIDx , PKx (i ) , xj∗ (i ) , x0 (i +1) , h(α ∗ )(β ∗ ) }, as in the next hash chain. When the current hash chain is exhausted
(i ∗) (i ∗ +1)
Procedure 2, where (xj∗ , x0 , h(α ∗ )(β ∗ ) ) is the OTP as for (i = 1, j = n), the next BC-update transaction ( 4 )
defined in Section V-A. Two functions, comPK(.) and initiates the next hash chain initialization on the BC upon the
comHash(.), are for deriving a chain seed (as well as the PK) successful verification of x0 (2) = h(x1 (2) ||PKx (2) ). Therefore,
of a hash chain and a specific hash value within a hash chain, x1 (2) becomes the current commitment value (❹), and entity
respectively, which are defined in Appendix C. x’s entry is changed to (A = cIDx , B = PKx (2) , C = x1 (2) ,
∗ ∗
When receiving BC-update{cIDx , PKx (i ) , xj∗ (i ) , D = x0 (3) , E = h22 ), where D = x0 (3) is not yet verified as a
(i ∗ +1)
x0 , h(α ∗ )(β ∗ ) }, the chaincode of the BC processes valid root of the next hash chain as the verification on E = h22
it as in Procedure 3. The chaincode verifies if C(= is performed on the next BC-update. Upon a successful

Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
Procedure 4 procBCquery
On input (cIDx )
Run (chaincode)
• if cIDx does not exist, exit (“No such cID”);
• return (cIDx , PKx (i) , xj (i) );
Fig. 4. Jump the current hash chain for flexible key rotation and synchro-
nization.
verification (❺) with the next BC-update transaction ( 5 ), E is
set to 1.
Any entity can query the current PK and commitment value
of entity x, as shown in Procedure 4. Suppose entity x’s current
entry is (A = cIDx , B = PKx (i) , C = xj (i) , D = x0 (i+1) ,
E = h(α)(β) ). When a BC-query transaction, BC-query{cIDx },
is sent to the chaincode of the BC, (cIDx , PKx (i) , xj (i) ) is
returned.
D. Flexible Key Rotation and Synchronization
As mentioned previously, the key rotation occurs in two
cases. First, when the current hash chain mhcx (i) is exhausted,
the current public key PKx (i) has already been used n times to
perform several security protocols with other entities. Hence,
“n” is a security parameter that limits the usage of the current
PK. The other is when the compromise of the private key
SKx (i) is suspicious. In this case, a jump to the next hash
chain can be realized without consuming the remaining hash
values of the current hash chain.
Suppose the public key PKx (i) of the current hash chain
mhcx (i) should be updated, the current commitment value is
xj1 (i) for some j1 < n [as shown in Fig. 4-(a)], and the cur-
rent entity x’s entry at the BC is (A = cIDx , B = PKx (i) ,
C = xj1 (i) , D = x0 (i+1) , E = 1). When the entity x sends a
BC-update{cIDx , PKx (i+1) , x1 (i+1) , [x0 (i+2) , h(2)(i+1) ]} to the
BC, it is processed normally by the chaincode after verify-
ing x0 (i+1) = h(x1 (i+1) ||PKx (i+1) ) as x0 (i+1) is the confirmed
root value of the next hash chain mhcx (i+1) . When the BC
update is successful, the entries of entity x become (A = cIDx ,
B = PKx (i+1) , C = x1 (i+1) , D = x0 (i+2) , E = h(2)(i+1) ).
Suppose desynchronization exists between the BC and
entity x in terms of the hash chain. For example, entity
x’s current commitment value at the BC is xj1 (i) for some
j1 < n, whereas entity x maintains xj2 (i+1) for some j2 < n, as
shown in Fig. 4-(b). In this case, when the entity x sends a
BC-update{cIDx , PKx (i+1) , xj2 (i+1) , [x0 (i+2) , h(j2 +1)(i+1) ]} to
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10617
Definition
 1 ECDH  Function  
ECDH SKx , PKy = ECDH SKy , PKx = qx .qy .G
where (SKx = qx , PKx = qx .G) and (SKy = qy , PKy = qy .G)
are the entity x’s and the entity y’s key pairs, respectively.
the BC, the discrepancy between them is resolved after verify-
ing xj (i+1) = h (xj+1 (i+1) || PKx (i+1) ) for j = j2 −1, j2 −2, . . . ,
1, 0. Therefore, entity x’s entries at the BC is updated as
(A = cIDx , B = PKx (i+1) , C = xj2 (i+1) , D = x0 (i+2) ,
E = h(j2 +1)(i+1) ). In both cases (a) and (b) in Fig. 4, a security
condition must be satisfied for key rotation and synchroniza-
tion, i.e., E should be set to 1. Otherwise, the next commitment
values, x1 (i) and xj2 (i+1) , for key rotation and synchronization
cannot be verified.
In a dID architecture, no centralized authorities are avail-
able to enforce key rotation policy. Hence, the entity that owns
the public key determines the time of the public-key rotation.
A basic strategy to rotate the public key in the BC-cID-F
is to limit the usage of the current key pair by rotating the
key pair when the current hash chain is completely exhausted.
However, the proposed BC-cID-F is flexible in that it can also
rotate the key pair before the current hash chain is exhausted.
E. Authenticated Key Exchange With BC-cID-F
A BC-based authenticated key exchange (BC-AKE)
between two entities is proposed to demonstrate the applica-
bility of the proposed BC-cID-F to various security protocols.
Because its role is identical to that of the TLS/DTLS hand-
shake protocol, it can be adapted for a new security mode for
the TLS/DTLS handshake.
Suppose that SK and PK are elliptic curve Diffie–Hellman
private and public keys, respectively. An elliptic curve E(Fp )
over a finite field Fp , where p is a prime, is a set of points
satisfying Y 2 ≡ X 3 + aX +b (mod p). The EC-domain param-
eters are denoted by (p, a, b, G, N), where N is a large prime
divisor of the order of the curve E(Fp ), and G is a base-
point generator of order N. Hence, SK = q ∈ {0, 1}l and
PK = pkGen(SK) = q.G = Q. We define a function, ECDH(.),
for an elliptic curve Diffie–Hellman key computation in the
following definition.
A BC-AKE is performed between two entities, x and y.
As shown in Fig. 5 ( 1 ), entity x’s current entry at the BC
is (cIDx , PKx (1) , x2 (1) , x0 (2) , h31 ), whereas that of entity y
is (cIDy , PKy (2) , y3 (2) , y0 (3) , h42 ). After querying the BC to
obtain entity y’s current PK and the commitment value, i.e.,
PKy (2) and y3 (2) , respectively, entity x derives a session key
skxy = kdf (mkxy , x2 (1) || y3 (2) ), where mkxy = ECDH(SKx (1) ,
PKy (2) ). MIC(skxy ) denotes a message- integrity code for
{cIDx , x3 (1) } or {cIDy , x4 (2) } using a symmetric key skxy .
When receiving ❶{cIDx , x3 (1) , MIC(skxy )} from entity
x, entity y queries the BC to obtain entity x’s current
PK and the commitment value, i.e., PKx (1) and x2 (1) ,
respectively, and verifies if x2 (1) = h(x3 (1) ||PKx (1) ). Upon
a successful verification, a session key skxy = kdf (mkxy ,
x2 (1) ||y3 (2) ), where mkxy = ECDH(SKy (2) , PKx (1) ) is derived,
based on which MIC(skxy ) can be verified. When receiving
10618
Fig. 5. BC-AKE with entity x and entity y.
❷{cIDy , y4 (2) , MIC(skxy )} from entity y, entity x verifies if
y3 (2) = h(y4 (2) ||PKy (2) ) and MIC(skxy ) are valid.
When the BC-AKE above is performed successfully, a
mutual authentication between them is attained and a session
key is shared. Finally, the entries of both entities at the BC
should be updated to replace the current commitment values,
x2 (1) and y3 (2) , by new ones, i.e., x3 (1) and y4 (2) , respectively.
As shown in the BC-AKE based on BC-cID-F, when two
entities perform a security protocol based on BC-cID-F, each
entity should update its own commitment value at the end
of the security protocol. However, this must be performed by
each entity to prevent the ID-stealing attacks; more details are
provided in Section V-B.
VI. S ECURITY A NALYSIS AND D ISCUSSIONS
A. Adversarial Model and Security of Infinite Hash Chain
As in Lamport’s OTP [17] based on Construction 3,
the OTP based on the proposed infinite hash chain
(Construction 6) of Fig. 2-(B) requires two security assump-
tions to function as a secure prover authentication protocol.
First, an authenticated channel should be provided between
the prover (entity x) and verifier (chaincode), together with the
verifier authentication. Second, the integrity of the three-tuple
OTPs, which are maintained by the verifier, should be guar-
anteed. The two requirements above can be satisfied because
the BC network is employed: 1) the prover can be securely
connected with the BC network when the TLS/DTLS with
the verifier authentication is provided appropriately between
them and 2) the integrity of the three-tuple OTPs stored at
the BC can be guaranteed. Additionally, it is also assumed
that the verifier (chaincode) does not behave maliciously,
which means that the integrity of the chaincode is guaranteed
as well.
Under the aforementioned security assumptions, the adver-
sarial model for the proposed OTP (called the “basic adver-
sarial model”) is such that the adversary can access the
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
OTPs but cannot modify them when delivered via the normal
authenticated channel. Hence, even though the adversary
observes the current OTP (xj (i) , x0 (i+1) , h(j+1)i ) from the
prover, it cannot forge the next OTP from the observed OTP.
Proposition 2: Under the basic adversarial model, the
adversary cannot generate three-tuple OTPs accepted by the
verifier.
Proof: The security of the proposed OTP is based on
the preimage resistance of the cryptographic hash function.
Suppose the jth three-tuple OTP (xj (i) , x0 (i+1) , h(j+1)i ) has
been successfully processed by the verifier, which means that
it is also exposed to the adversary. When the adversary derives
(A, x0 (i+1) , B) for the (j+1)th OTP, the following condition
should be satisfied: xj (i) = h(A) and h(j+1)i = h(A|| x0 (i+1) ),
where B can be an arbitrary value as it is not verified right
now. However, deriving such A is not feasible because of the
preimage resistance.
When the TLS/DTLS with verifier authentication is not pro-
vided appropriately, various attacks against TLS/DTLS can
be mounted, such as man-in-the-middle and session-hijacking
attacks [33]. An example of the weakness of the TLS/DTLS is
as follows: if an adversary’s certificate can be installed into the
prover’s root certificate storage, the adversary can successfully
impersonate the verifier when the prover is redirected to the
adversary site instead of to the genuine verifier site. Therefore,
the basic adversarial model is then extended to include the
possibility that the adversary will modify the current three-
tuple OTP from the prover (called the “extended adversarial
model”).
The adversary’s goal is to modify the (i · n + 1)th OTP,
namely, (x1 (i) , x0 (i+1) , h(2)(i) ) for i = 1, 2, 3, . . . , by replac-
ing x0 (i+1) by A0 chosen by the adversary. If h(2)(i) = h
(x2 (i+1) ||x0 (i+1) ) = h (x2 (i+1) ||A0 ), A0 can be registered as a
valid root value of the next hash chain, i.e., {x0 (i+1) , x1 (i+1) ,
x2 (i+1) , . . . , xn (i+1) } is replaced by {A0 , A1 , A2 , . . . , An } such
that Aj = h(Aj+1 ) for j ∈ [0, n−1] and some An chosen by
the adversary. Hence, the adversary can intercept the control
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
over the subsequent sessions from the original prover after
the (i+1)n OTP session. However, it is not feasible because
of the second preimage resistance of the cryptographic hash
function. This is summarized as Proposition 3.
Proposition 3: Under the extended adversarial model, the
adversary cannot intercept the OTP sessions from the original
prover.
B. Key Rotation and ID-Stealing Attack
Once the private key of BC-dID (Construction 1) or BC-cID
(Construction 2) is exposed to an adversary, the adversary can
impersonate its owner to perform various security protocols
with other entities. Furthermore, in the BC-dID, the adversary
can steal the corresponding BC-dID by posting a new self-
signed certificate to the BC. When the key is compromised, it
is not recognizable to its owner at that time; therefore, the only
defense against the key compromise is to perform the key rota-
tion periodically to reduce the vulnerability window. However,
the proposed BC-cID-F is robust to ID-stealing attacks result-
ing from the key compromise, since the vulnerability win-
dow does not exist due to the hash chain value used as
the OTP.
The proposed BC-cID-F is based on an infinite hash chain
comprising multiple finite hash chains, mhcx (i) for i = 1,
2, . . . , each of which is associated with a distinct public key
PKx (i) . Suppose x0 (2) is the root value registered proactively
for the next hash chain mhcx (2) . When the current hash chain
is exhausted, the next commitment value will be x1 (2) such that
x0 (2) = h(x1 (2) ||PKx (2) ). If an adversary can find A1 and PKA
(= PKx (2) ) such that x0 (2) = h(A1 ||PKA ), the adversary can
take over the control of cIDx , resulting in the security breach
of the proposed BC-cID-F. However, owing to the property
of the cryptographic hash function, it is not feasible to find
{A1 and (SKA , PKA )} such that h(x1 (2) ||PKx (2) ) = h(A1 ||PKA ),
as shown in Proposition 4.
Proposition 4: BC-cID-F is robust to the ID-stealing attack
under the extended adversarial model.
Proof: Suppose entity x’s current entry in the BC is
(A = cIDx , B = PKx (i) , C = xj (i) , D = x0 (i+1) , E = 1) for
some j < n, and entity x sends a BC-update{cIDx , PKx (i+1) ,
x1 (i+1) , x0 (i+2) , h2(i+1) } to the BC for a key rotation. After
generating a key pair (SKA , PKA ) and {A1 , A2 , . . . , An } such
that Aj = h(Aj+1 ||PKA ) for j ∈ [1, n−1] and An ∈R {0, 1}l ,
the adversary modifies entity x’s BC update as follows: {cIDx ,
PKA , A1 , . . .}. To be accepted by the BC, the condition
x0 (i+1) = h(A1 || PKA ) should be satisfied. However, it is
refused by the BC chaincode owing to the property of the
cryptographic hash function. For a formal proof by reduction,
the following experiment ExpA is defined for h(.), an adversary
AdvA , and a security parameter l.
ExpA (h(.), AdvA , l): The adversary AdvA is given w and
outputs w, where w, w ∈ {0, 1}∗ . ExpA (h(.), AdvA , l) = 1 if
and only if w = w and h(w) = h(w).
A hash function h(.) is second-preimage resistant if for all
probabilistic polynomial-time (PPT) adversaries AdvA there is
a negligible function negl(.) such that Pr[ExpA (h(.), AdvA ,
l) = 1] ≤ negl(l). Let AdvB be a PPT adversary replac-
ing (x1 (i+1) , PKx (i+1) ) by (A1 , PKA ) such that x0 (i+1) =
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10619
Protocol 1 Challenge–Response Based on BC-dID
• entity x ← entity y: Ry
• entity x → entity y: cIDx , Ry , Sig(SKx )
Protocol 2 Challenge–Response Based on BC-cID-F
• entity x → entity y: cIDx , x3 (1) , Sig(SKx (1) );
h(x1 (i+1) ||PKx (i+1) ) = h (A1 ||PKA ) and PKx (i+1) = PKA . So,
the following experiment is defined.
ExpB (h(.), AdvB , l): The adversary AdvB is given the
entity x’s BC update and outputs (A1 , PKA ) after gener-
ating a key-pair (SKA , PKA ) and {A1 , A2 , . . . , An } such
that Aj = h(Aj+1 ||PKA ) for j ∈ [1, n−1] and An ∈R {0,
1}l . ExpB (h(.), AdvB , l) = 1 if and only if h(x1 (i+1) ||
PKx (i+1) ) = h(A1 || PKA ) and PKx (i+1) = PKA .
Consider the following adversary AdvA attacking h(.) in
ExpA (h(.), AdvA , l) using adversary AdvB as a subroutine.
AdvA :
On input w = x1 (i+1) || PKx (i+1)
z : = (x1 (i+1) , PKx (i+1) ).
Run AdvB (z).
AdvB returns z = (A1 , PKA ).
w : = A1 || PKA
AdvA outputs w.
It is evident that Pr[ExpA (h(.), AdvA , l) = 1] ≥
Pr[ExpB (h(.), AdvB , l) = 1]. Since h(.) is a second-preimage
resistant hash function, Pr[ExpA (h(.), AdvA , l) = 1] ≤ negl(l).
It is concluded that Pr[ExpB (h(.), AdvB , l) = 1] Pr[ExpA (h(.),
AdvA , l) = 1] negl(l).
C. Impersonation and Session-Hijacking Attack
In addition to the ID-stealing attack discussed in
Section VI-B, a few security protocols based on BC-dID and
the proposed BC-cID-F are investigated to estimate the secu-
rity effects resulting from the compromise of the private key.
Protocol 1 shows a simple challenge–response protocol based
on BC-dID. After receiving a random number Ry from entity
y, entity x generates and sends Sig(SKx ) to entity y. Sig(SKx )
can be verified using PKx obtained through querying the
BC. However, when the private key (SKx ) of entity x is exposed
to an adversary, the adversary can mount an impersonation
attack against the following protocol.
The purpose of Protocol 2 is the same as that of Protocol 1,
except that it is based on BC-cID-F. Assuming entity x’s entry
in the BC is (cIDx , PKx (1) , x2 (1) , . . . ), entity y queries the BC
to obtain PKx (1) and x2 (1) . Subsequently, both x2 (1) = h(x3 (1) ||
PKx (1) ) and Sig(SKx ) are verified to authenticate entity x. As
each hash value (next commitment value) is an implicit chal-
lenge for each authentication session, the challenge–response
protocol comprises a single message. Additionally, because
the next commitment value cannot be derived from the
previous commitment values without knowing the seed value,
Protocol 2 is secure against the impersonation attack even
though SKx (1) is compromised.
Furthermore, the proposed BC-AKE based on BC-cID-F
discussed in Section V-E is secure against the impersonation
attack with the compromised key. It is not feasible for the
10620
Protocol 3 Security-Enhanced BC-AKE Based on BC-cID-F
• entity x → entity y: {cIDx , Enc(PKy (2) , x3 (1) ), MIC(skxy )}
• entity x ← entity y: {cIDy , Enc(PKx (1) , y4 (2) ), MIC(skxy )}
TABLE I
S ECURITY C OMPARISON OF F OUR DID S CHEMES FOR K EY ROTATION
adversary to impersonate either entity x or entity y whose
private key is exposed, as the next commitment value of either
of them is not known to the adversary. However, a session-
hijacking attack with a compromised key can be mounted: in
Fig. 5, when the private key SKx (1) of entity x is exposed, the
adversary can hijack the session between them after obtaining
{cIDx , x3 (1) , MIC(skxy )} and blocking entity x’s subsequent
communication as the adversary obtains the next commitment
value x3 (1) , which can be used by entity y to authenticate
entity x. However, the vulnerability window induced by the
key compromise is limited: for the current commitment value
xj (i) , the adversary can hijack the sessions between entity x
and other entities only n–j times, after which the key rotation
is performed by entity x.
To suppress such a session-hijacking attack, the next commit-
ment values, x3 (1) and y4 (2) , from both entities can be encrypted
using each other’s public key, as shown in Protocol 3; this is
adapted from the BC-AKE in Section V-E, where Enc(PK, m)
denotes the encryption of m with the public key PK.
A pair of public and private keys associated with the dID
is used to prove the ownership of the dID. Hence, the pub-
lic key is not directly used to encrypt the application data,
even though the security-protocol data such as commitment
values are encrypted using the public key. A possible solu-
tion for encrypting the application data is to generate a pair
of ephemeral public and private keys and encrypt it using the
ephemeral public key.
D. Security Comparisons for Key Rotations
In this section, both BC-dID (Construction 1) and BC-cID
(Construction 2) are compared with two proposed DIDs, BC-
cID-L (Construction 4) and BC-cID-F (Construction 8), in
terms of security of the key rotation, as shown in Table I.
First, a basic key rotation capability denotes that the public key
associated with dID (or cID) can be updated without changing
the current dID (or cID). It can be provided by BC-dID, BC-
cID-L, and BC-cID-F: in the case of BC-cID, if a key rotation
is required, a new cID should be created and substituted for
the old one.
Second, in case of BC-dID, BC-cID, and BC-cID-L, the
only defense against the SK compromise is to perform the
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
Fig. 6. Generation of seed value for each hash chain.
key rotation periodically to reduce the vulnerability window.
However, such a security policy is enforced not from the DID
schemes themselves but from the DID owner’s decision. On
the other hand, the key rotation for BC-cID-F is automati-
cally performed when the current hash chain is exhausted.
Especially, the key rotation for BC-cID-F is also possible with
the DID owner’s decision before the current hash chain is not
exhausted.
Third, an adversary with the compromised SK can mount an
impersonation attack against the entity authentication protocol
based on BC-dID, BC-cID, or BC-cID-L. However, in the case
of BC-cID-F, such an attack is not feasible as long as the
next commitment value playing the role of the OTP is not
available to the adversary. Finally, the ID-stealing attack due
to the compromised SK is feasible through the BC update for
key rotation in case of BC-dID, while it is not feasible for
both BC-cID-L and BC-cID-F as the commitment value is not
known to the adversary.
E. Key Management Issues
As mentioned in Construction 7, each hash chain
mhcx (i) = {xj (i) | xj (i) = h(xj+1(i) ||PKx (i) ) for j ∈ [0, n−1]}
for i = 1, 2, . . . , is generated based on xn (i) = h(Kx ||“chain
seed”||i) and SKx (i) = kdf (Kx , “key seed”||i), as shown in
Fig. 6, where PKx (i) = pkGen(SKx (i) ). The only secret value
that entity x should retain is Kx , which is eventually a master
seed for the infinite hash chain.
Entity x can derive any hash value xj (i) based on the mas-
ter seed Kx . For example, assuming n = 5, x2 (10) can be
derived as follows: given two seed values for the 10th hash
chain, x5 (10) = h(Kx ||“chain seed”||10) and SKx (10) = kdf (Kx ,
“chain seed”||10), the following hash values are generated:
x4 (10) = h(x5 (10) ||PKx (10) ), x3 (10) = h(x4 (10) ||PKx (10) ), and
x2 (10) = h(x3 (10) || PKx (10) ), where PKx (10) = pkGen(SKx (10) ).
Hence, a total of (n−j)+1 hash computations, one pkGen com-
putation, and one kdf computation are required to derive xj (i)
from Kx .
Regarding the key-derivation function, an HMAC-based
KDF (HKDF) [34] is used, which is known as a secure
pseudorandom number generator, and whose security proof is
detailed in [35]. The scheme HKDF is specified as HKDF(xts,
skm, ctxInfo) = K(1)|| K(2)||K(3), . . . , where xts (can be 0) is
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
a salt value, skm is a source key material, and ctxInfo is an
arbitrary string. Each K(i) can be used as an individual key
and defined as follows.
prk = HMAC(xts, skm).
K(1) = HMAC(prk, ctxInfo||0).
K(i + 1) = HMAC(prk, K(i)|| ctxInfo||i) for i ≥ 1.
For our key-derivation function, xts = 0, skm = Kx, ctx-
Info||i−1 = “key seed”||i−1, so that SKx (i) = kdf (Kx , “key
seed”||i) = K(i) for i ≥ 1.
F. Security Bootstrapping for Secure BC Access
Each entity can access the BC network directly or indi-
rectly through an agent node. For resource-constrained entities
such as IoT devices, each entity is assumed to have access
to the BC network through an agent node directly participat-
ing in the BC network. Therefore, security bootstrapping is
required such that each entity can securely access the agent
node. During the security bootstrapping phase, either the man-
ufacturer or the owner of the device (entity) preinstalls both
the IP/MAC addresses and the PK of an agent node. The
agent’s PK is employed to provide the authenticated chan-
nel between the agent and the device (entity) such that the
integrity of both BC-update and BC-query can be guaranteed
using the security protocol, such as TLS/DTLS. To prevent
from the man-in-the-middle attack, agent authentication is
also required, whereas device (entity) authentication is not
necessary. As various security protocols [30]–[32] are avail-
able to provide an authenticated channel between each entity
(resource-constrained device) and the agent, it is assumed in
this study that such a channel exists.
VII. P ERFORMANCE E VALUATION
A. Cryptographic Operations for BC-Update
Cryptographic overheads for generating and processing a
BC-update transaction (Procedure 2 and 3) are discussed in
this section. Suppose entity x’s current entry at the BC is
(A = cIDx , B = PKx (i) , C = xj (i) , D = x0 (i+1) , E = h(α)(β) ),
where α = j+1 and β = i for j ∈ [1, n−1], and α = 1
and β = i+1 for j = n. Depending on the amount of state
information maintained by entity x, the cryptographic over-
heads for generating the BC-update transaction are variable.
Entity x can generate it with {Kx , (i, j)} as in Procedure 2.
However, the overall cryptographic overheads can be reduced
when entity x maintains {Kx , (i, j), (PKx (i) , SKx (i) ), (PKx (i+1) ,
SKx (i+1) ), x0 (i+1) }. In particular, it is reasonable to maintain
the current key pair (PKx (i) , SKx (i) ) to be used for various
security protocols.
First, the BC-update for key rotation requires 2n+2 hash
computations, one kdf computation, and one pkGen computa-
tion, which are equivalent to generating the (i·n+1)th OTP for
i = 1, 2, 3, . . .. Furthermore, the BC-update for a new commit-
ment value requires n−j+1 hash computations for j ∈ [1, n−2]
and requires n+3 hash computations for j = n−1. Meanwhile,
only two hash computations are required for processing the
two types of BC-updates above. Table II shows the crypto-
graphic overheads for generating and processing a BC-update
transaction based on three schemes: BC-dID (Construction 1),
BC-cID-L (Construction 4), and BC-cID-F (Construction 8).
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10621
TABLE II
C RYPTOGRAPHIC OVERHEAD C OMPARISON OF
F OUR DID S CHEMES FOR K EY ROTATION
B. Testbed for Blockchain Using Hyperledger Fabric
Hyperledger fabric is a well-known platform for permis-
sioned BCs, which securely tracks its execution history in an
append-only replicated ledger data structure. Two main com-
ponents of the Fabric network are peer nodes and orderers.
Each peer node maintains both chaincodes and a ledger com-
prising a world state and a BC. A world state is a database that
holds the current key-value pairs of a set of ledger states. The
world state renders it easy for a program to obtain the current
value of these states. Meanwhile, the BC is a transaction log
that records all the changes that determine the world state.
Transactions are collected inside blocks that are appended to
the BC. Entities always connect to peers when they require
access to the ledger and chaincodes.
When the transactions generated by the application are sent
to the chaincodes, the chaincodes are executed to query or
update a ledger. The consensus mechanism (ordering service)
by which applications and peers interact with each other to
ensure that every peer’s ledger remains consistent is mediated
by orderers.
We implemented a Fabric network comprising four peers
and three orderers on Ubuntu with Hyperledger Fabric, as
in Fig. 7, where the chaincode was written in Go language,
and the peers were executed on separate Docker containers on
the same machine. Entities are assumed to be the resource-
constrained nodes on the low-power wireless personal area
network (LoWPAN) based on the 6LoWPAN and the IEEE
802.15.4, so that Wismotes on the Contiki Cooja simulator
were employed for entities. Turnslip6 supported by the Contiki
was employed for the SLIP connection from the agent node
to the 6LoWPAN border router (6LBR).
The application on the agent node generates a transac-
tion proposal for either BC-query or BC-update request from
Wismote (entity x) and sends it to the BC. A transaction
response from the BC is passed to the Wismote via the agent
node. Especially, the transaction proposal for BC-update (key
rotation) is sent to the four peers and processed by each of
their chaincodes. It is appended to the BC and the result of
processing the BC-update feeds into the world state. Hence,
all the history of BC-update transactions for key rotation
is maintained in the BC, whereas the world state maintains
entity x’s current entries (the most recent public key and
commitment value).
The EC-domain parameters were set to secp256k1 [36]
for EC key pair generation (pkGen(.)) and ECDSA
10622
Fig. 7. Test bed for BC-update and BC-query.
Fig. 8. Comparison of three schemes for execution times. (a) Execution Time for Crypto. Operations on Wismote. (b) Execution Time for processing
Transaction Proposal / Response.
TABLE III
AVERAGE E XECUTION T IMES OF C RYPTOGRAPHIC P RIMITIVES
(sigGen and sigVer), and SHA-256 and HKDF with HMAC-
SHA-256 were used for the cryptographic hash function h(.)
and the key-derivation function kdf (.), respectively. Table III
shows the average execution times (for ten runs on the Wismote
and on the Docker container) of the cryptographic primitives
that were employed for generating and processing the BC-
update for key rotation. For the execution times of ECDSA,
h(.), and kdf (.), both the message length and the key length
are set to 32 bytes.
Three schemes (BC-dID, BC-cID-L, and BC-cID-F) are
compared in Fig. 8-(a) in terms of the execution times for
cryptographic operations performed on the Wismote to create
the transaction proposals for Registration, BC-update, and
BC-query. In case of BC-query, there are no cryptographic
operations to be performed on the Wismote.
The BC-cID-L requires the most expensive cost to regis-
ter (cIDx , x1 , PKx (1) ) at the BC for the first time since a
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
hash chain of length n and the associated n EC key pairs
should be generated (for performance comparison, n was set
to 10). However, a hash chain of length n and only one
EC key pair are required to be generated for Registration of
BC-cID-F. The BC-cID requires 1 pkGen (EC key pair gen-
eration using secp256k1), 1 hash (SHA-256), and 1 sigGen
(ECDSA using secp256k1) computations, where the process-
ing times for hash, sigGen, and pkGen are 3.448, 1790.748,
and 1649.810 ms, respectively, for the BC-update generation
on the Wismote. For BC-cID-L and BC-cID-F, the hash val-
ues (xj or xj (i) ) are not stored when cIDx is generated for
Registration but generated on the fly from the seed value (xn
or xn (i) ), considering the storage limit of the sensor device
when n becomes large. The BC-cID-F requires n−j hash and
n−j pkGen computations for the BC-update generation, while
the BC-cID-F requires 2n+2 hash and 1 pkGen computations.
Hence, the BC-cID-L also requires the most expensive cost
for the BC-update generation, while the BC-cID-F is shown
to be done faster than the others.
Since the agent node plays the role of the proxy for the
Wismote, it assembles the result of cryptographic operations
performed on the Wismote and sends a transaction proposal
to the BC. On successful processing, the corresponding
transaction response is returned to the Wismote via the agent
node. Fig. 8-(b) shows a comparison of three schemes in
terms of the round-trip delay between the Wismote and the
BC, starting from the Wismote. The round-trip delay does
not include the execution time for the cryptographic opera-
tions on the Wismote, but those performed on the chaincode
(Procedures 1, 3, and 4) to verify the transaction proposal. As
PARK AND NAM: NEW APPROACH TO CONSTRUCTING DECENTRALIZED IDENTIFIER FOR SECURE AND FLEXIBLE KEY ROTATION
Fig. 9. Example scenario for BC update.
shown in the figure, the execution times for processing both
transaction proposal and transaction response are not highly
variable for three schemes except for the initial Registration.
VIII. C ONCLUSION AND F UTURE W ORK
DID based on BC technology is the next-generation identity
model applicable to various application domains. It serves as
a type of decentralized certificate that is created and managed
by each entity such that the various security breaches induced
by the certificate authority (which is not well managed) can
be avoided and a long-pending problem of the multiple iden-
tifiers for a single entity can be addressed. In this study, we
investigated the security weaknesses of the conventional DID
model and proposed a new DID model, called BC-cID-F, to
address the security issues of the conventional model. It was
designed based on an infinite one-way hash chain, which is an
extension of Lamport’s one-way hash chain. The infinite one-
way hash chain was used not only for generating OTPs but
also for providing flexible key-rotation capability. As shown in
the BC-AKE protocol, the proposed BC-cID-F can be a use-
ful cryptographic primitive to enhance both the security and
efficiency of various security protocols.
The following remaining two issues associated with the DID
management may be investigated in future studies: 1) key
recovery and 2) ID squatting. The current key sharding
approach is disadvantageous as it relies on the trusted entities,
whereas no effective solutions exist thus far for suppressing
ID squatting. Hence, further research is required to design a
mechanism that is integrated with our proposed key scheme
to address the two issues above.
A PPENDIX A
Lamport’s OTP based on hash chain [17] has several
advantages over other OTPs. First, a shared secret is not
required between the prover (P) and the verifier (V) for
prover authentication (P1). Second, only a lightweight hash
function is used for OTP generation and verification (P2).
However, as discussed in Section III-C, a new hash chain
must be generated, and a new root value must be registered
(reregistration) when all hash values of a current hash chain
are used. Various schemes [28], [29], [37], [38], including
our proposed scheme, have been proposed to eliminate
reregistration.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
10623
TABLE IV
C OMPARISON OF S EVERAL OTP S BASED ON H ASH C HAIN
A public-key chaining scheme [29] employs public-key
cryptography to generate and verify OTPs. Although rereg-
istration and shared secret are not required, the computa-
tional burden on P and V becomes significant because it is
not based on the lightweight hash function (one public-key
computation is approximately comparable to 500–1000 hash
computations in terms of processing time). Unlike Lamport’s
scheme, which uses the hash chain in the reverse order, two
schemes [37], [38] that use the hash chain in the forward
order were proposed. Even though these schemes eliminate
the necessity of reregistration, they lose the advantage of
Lamport’s scheme because a shared secret is required between
P and V. On the contrary, a scheme [28] that interconnects
several short hash chains was proposed to eliminate reregistra-
tion, while maintaining the advantage of the original Lamport’s
scheme. However, these schemes are not appropriate for the
design of BC-cID-F because of the inherent structure of the
hash chain employed in each scheme. Table IV presents a com-
parison of several schemes including our proposed scheme, in
terms of P1, P2, P3, and P4.
A PPENDIX B
The hash values were employed as nonces for several
security protocols performed with other entities (entities w,
y, and z), where AKE and MA represent the authenticated
key exchange protocol and mutual authentication, respectively.
After completing each security protocol with another entity,
entity x performs the BC update operation to update the current
commitment value. Fig. 9 ( 1 and 2 ) shows that the n hash
values of the first hash chain were used for n distinct security
10624
Function 1 comPK
On input (Kx , i)
• PKx (i) ← pkGen(kdf (Kx , “key seed”||i));
• xn (i) ← h(Kx ||“chain seed”||i);
• PKx (i+1) ← pkGen(kdf (Kx , “key seed”||i+1));
• xn (i+1) ← h(Kx ||“chain seed”||i+1);
• return (PKx (i) , xn (i) , PKx (i+1) , xn (i+1) );
Function 2 comHash
On input (a , xn (i) , PKx (i) )
• A ← a;
• X ← xn (i) ;
• while (A > 0) {
• X ← h(X|| PKx (i) ); A ← A–1};
• return (X);
protocols with other entities; subsequently, a BC update was
performed for the key rotation. Fig. 9 ( 3 and 4 ) shows that
entity x became suspicious of the private key compromise and
then jumped for the key rotation to the first hash value of the
third hash chain without consuming the remaining hash values
of the second hash chain.
A PPENDIX C
See Functions 1 and 2.
R EFERENCES
[1] P. Dunphy and F. A. P. Petitcolas, “A first look at identity manage-
ment schemes on the blockchain,” IEEE Security Privacy, vol. 16, no. 4,
pp. 20–29, May/Jun. 2018.
[2] K. C. Toth and A. Anderson-Priddy, “Self-sovereign digital identity:
A paradigm shift for identity,” IEEE Security Privacy, vol. 17, no. 3,
pp. 17–27, May/Jun. 2019.
[3] A. Tobin and D. Reed, The Inevitable Rise of Self-Sovereign Identity,
Sovrin Found., Provo, UT, USA, 2016.
[4] C. Lundkvist, R. Heck, J. Torstensson, Z. Mitton, and M. Sena, uPort:
A Platform for Self-Sovereign Identity, uPort, Brooklyn, NY, USA, 2017.
[5] C. Fromknecht, D. Velicanu, and S. Yakoubov, CertCoin: A Namecoin
Based Decentralized Authentication System, MIT, Cambridge, MA,
USA, 2014.
[6] B. Leiding, C. H. Cap, T. Mundt, and S. Rashidibajgan, “AuthCoin:
Validation and authentication in decentralized networks,” in Proc. 10th
Mediter. Conf. Inf. Syst., 2016, pp. 1–14.
[7] M. Ali, J. C. Nelson, R. Shea, and M. J. Freedman, “Blockstack:
A global naming and storage system secured by blockchains,” in Proc.
USENIX Annu. Tech. Conf., 2016, pp. 181–194.
[8] Y. Kortesniemi, D. Lagutin, E. Elo, and N. Fotiou, “Improving the pri-
vacy of IoT with decentralized identifiers,” J. Comput. Netw. Commun.,
vol. 2019, Mar. 2019, Art. no. 8706760.
[9] A. S. Omar and O. Basir, “Identity management in iot networks using
blockchain and smart contracts,” in Proc. IEEE Int. Conf. Internet
Things, 2018, pp. 994–1000.
[10] Y. Ren, F. Zhu, J. Qi, J, Wang, and A. K. Sangaiah, “Identity manage-
ment and access control based on blockchain under edge computing for
the Industrial Internet of Things,” Appl. Sci., vol. 9, no. 10, p. 2058,
2019.
[11] “Retrieved from Christopher Allen’s Blog.” [Online]. Available:
http://www.lifewithalacrity.com/. (Accessed: Oct. 20, 2020).
[12] C. Allen et al., “Decentralized public key infrastructure,” in Proc.
Rebooting Web Trust, Nov. 2015, pp. 1–21.
[13] A. Shamir, “How to share a secret,” Commun. ACM, vol. 22, no. 11,
pp. 612–613, Nov. 1979.
[14] A. Loibl and J. Naab, “Namecoin,” in Proc. Seminars Future Internet
Innov. Internet Technol. Mobile Commun., 2014, pp. 107–113.
[15] H. Kalodner, M. Carlsten, P. Ellenbogen, J. Bonneau, and A. Narayanan,
“An empirical study of namecoin and lessons for decentralized names-
pace design,” in Proc. Workshop Econ. Inf. Security, 2015, pp. 1–27.
Authorized licensed use limited to: UNIVERSITY PUTRA MALAYSIA. Downloaded on May 17,2023 at 07:15:55 UTC from IEEE Xplore. Restrictions apply.
IEEE INTERNET OF THINGS JOURNAL, VOL. 9, NO. 13, JULY 1, 2022
[16] D. Reed, M. Sporny, D. Longley, C. Allen, R. Grant, and M. Sabadello,
Decentralized Identifiers (DIDs) V1.0: Core Data Model and Syntaxes,
W3C, Cambridge, MA, USA, 2019.
[17] L. Lamport, “Password authentication with insecure communication,”
Commun. ACM, vol. 24, no. 11, pp. 770–772, 1981.
[18] E. Androulaki et al., “Hyperledger fabric: A distributed operating system
for permissioned blockchains,” in Proc. 13th Eur. Conf. Comput. Syst.,
2018, pp. 1–15.
[19] L. Zahn, Network Computing Architecture. Upper Saddle River, NJ,
USA: Prentice-Hall, 1990.
[20] P. Leach, M. Mealling, and R. Salz, “A universally unique identi-
fier (UUID) URN namespace,” IETF, RFC 4122, 2005.
[21] N. Leavitt, “Internet security under attack: The undermining of digital
certificates,” Computer, vol. 44, no. 12, pp. 17–20, 2011.
[22] H. Berghel, “Equifax and the latest round of identity theft roulette,”
Computer, vol. 50, no. 12, pp. 72–76, 2017.
[23] M. Blaze, “A cryptographic file system for unix,” in Proc. 1st ACM
Conf. Commun. Comput. Security, 1993, pp. 33–43.
[24] T. Aura, “Cryptographically generated addresses (CGA),” IETF, RFC
3972, 2005.
[25] J. Arkko, J. Kempf, B. Zill, and P. Nikander, “Secure neighbor discov-
ery,” IETF, RFC 3971, 2011.
[26] C. Perkins, D. Johnson, and J. Arkko, “Mobility support in IPv6,” IETF,
RFC 6275, 2011.
[27] A. Shamir, Identity-Based Cryptosystems and Signature Schemes
(LNCS), vol. 196. Heidelberg, Germany: Springer, 1985, pp. 47–53.
[28] C. S. Park, “One-time password based on hash chain without shared
secret and re-registration,” Comput. Security, vol. 75, pp. 138–146,
Jun. 2018.
[29] K. Bicakci and N. Baykal, “Infinite length hash chains and their applica-
tions,” in Proc. IEEE 11th Int. Workshops Enabling Technol., Jun. 2002,
pp. 1–5.
[30] S. Raza, H. Shafagh, K. Hewage, R. Hummen, and T. Voigt, “LiTHE:
Lightweight secure CoAP for the Internet of Things,” IEEE Sensors J.,
vol. 13, no. 10, pp. 3711–3720, Oct. 2013.
[31] S. Raza, L. Seitz, D. Sitenkov, and G. Selander, “S3K: Scalable secu-
rity with symmetric keys—DTLS key establishment for the Internet of
Things,” IEEE Trans. Autom. Sci. Eng., vol. 13, no. 3, pp. 1270–1280,
Jul. 2016.
[32] T. Kothmayr, C. Schmitt, W. Hu, M. Brünig, and G. Carle, “DTLS based
security and two-way authentication for the Internet of Things,” Ad Hoc
Netw., vol. 11, no. 8, pp. 2710–2723, 2013.
[33] C. Meyer and J. Schwenk, “Lessons learned from previous SSL/TLS
attacks—A brief chronology of attacks and weaknesses,” in Proc. IACR
Cryptol. ePrint Archive, 2013, pp. 1–15.
[34] H. Krawczyk and P. Eronen, “HMAC-based extract-and-expand key
derivation function (HKDF),” IETF, RFC 5869, 2010.
[35] H. Krawczyk, Cryptographic Extraction and Key Derivation: The
HKDF Scheme (LNCS 6223). Heidelberg, Germany: Springer, 2010,
pp. 631–648.
[36] Recommended Elliptic Curve Domain Parameters, Stand. Efficient
Cryptography, Certicom Res., Waterloo, ON, Canada, 2010.
[37] S. Bittl, “Efficient construction of infinite length hash chains with perfect
forward secrecy using two independent hash functions,” in Proc. 11th
Int. Conf. Security Cryptography, Aug. 2014, pp. 1–8.
[38] M. H. Eldefrawy, M. K. Khan, K. Alghathbar and E. S. Cho, “Broadcast
authentication for wireless sensor networks using nested hashing and the
chinese remainder theorem,” Sensors, vol. 10, no. 9, pp. 8683–8695,
Sep. 2010.
Chang-Seop Park (Member, IEEE) received the B.A. degree from Yonsei
University, Seoul, South Korea, in 1983, and the M.Sc. and Ph.D. degrees in
computer science from Lehigh University, Bethlehem, PA, USA, in 1987 and
1990, respectively.
He has been with the Department of Software Science, Dankook University,
Yongin, Republic of Korea, since 1990. He has been working on the wire-
less mobile network security during the last ten years. His research interests
include network security, cryptographic protocols, and coding theory.
Hye-Min Nam received the B.Sc. degree in software science from Dankook
University, Yongin, Republic of Korea, in 2019, where he is currently pursuing
the master’s degree in computer science.
His research interests include blockchain, wireless sensor network security,
and cryptographic protocols.