An Authenticated Accumulator Scheme for Secure Master Key Access in

Microservice Architectures

Hannes Salin

and Dennis Fokin

Department of Information and Communication Technology, Swedish Transport Administration, Borl

ange, Sweden

Independent Researcher, Sweden

Keywords:

Key Management, Microservices, Cryptographic Accumulators, Pairing-based Cryptography, Secure Key

Storage.

Abstract:

We consider the use-case of Internet of Things ecosystems with an API-driven microservice architecture,

where the need for accessing cryptographic functions is crucial. Devices communicate with a microservice

backend, which in turn integrates to a secure key storage in order to compute digital signatures or message

encryption. Access to a secure storage must be executed securely and naive approaches such as passwords

or certiﬁcates are used in practice today, which still may be open to impersonation attacks. With the usage

of efﬁcient cryptographic accumulators we therefore propose a secure key access scheme with the microser-

vices ecosystem in mind, and provide initial results from a proof-of-concept implementation in Java and jPBC,

where we show a performance- and communication complexity analysis. Finally, we provide a security anal-

ysis of the scheme in the random oracle model.

1 INTRODUCTION

Standardization of Internet of Things (IoT) Represen-

tational State Transfer (REST) architecture is still on-

going (Ker

anen et al., 2021) and addresses what is

nowadays a well-known type of architecture in soft-

ware engineering. Using REST API:s is well aligned

with an underlying microservice architecture - it is

far from unusual to adopt a microservices architec-

ture over a monolithic one; with higher demands of

scalability and resilience, it also gives the beneﬁt of

seamlessly combining different modules of a system,

developed with different technology stacks. An API-

driven pattern enables this modularity, but also gives

rise to several security related challenges. Authenti-

cation and authorization seems to be the most com-

monly addressed security mechanisms in a microser-

vices context (Pereira-Vale et al., 2019). However,

despite a range of industry best practices on how

to approach these challenges, not much is scientiﬁ-

cally established for the general case of authenticat-

ing services for secure access. Given an ecosystem

of IoT devices built on a microservices architecture,

where possibly a subset of these need frequent access

to cryptographic functions such as digital signatures

or encryption, requirements for strong authentication

and secret key access are needed. One approach is to

store secret keys on each and every service. However,

that would lead to severe security implications since

an adversary would only have to compromise the ser-

vice in order to gain access to the secret key. In some

cases (e.g. for transaction signatures), a master key is

needed, thus a single point of storage must exist. This

problem is often addressed by using Hardware Secu-

rity Modules (HSM) and/or vaults, for secure storage.

On the other hand, to access an HSM or vault, a pass-

word, key or similar is still needed for authenticated

access; this problem seems unsolvable since regard-

less of how far we apply a layer of security, an entity

still needs to authenticate itself at some point.

1.1 Problem Statement

In an IoT-driven environment with clusters of devices

connecting to backend services, i.e. a microservices-

based ecosystem, with provided functionality that in-

clude cryptographic operations (such as digital signa-

tures or encrypting data), the secret key(s) must be se-

curely stored. We consider particularly high-sensitive

systems in connected environments such as Intelligent

Transport Systems (ITS) where both vehicles and in-

frastructure can be connected. With many types of

IoT devices such as cameras, radars, and other sen-

sory devices, data needs to be transmitted to interme-

Salin, H. and Fokin, D.

An Authenticated Accumulator Scheme for Secure Master Key Access in Microservice Architectures.

DOI: 10.5220/0010989400003194

In Proceedings of the 7th International Conference on Internet of Things, Big Data and Security (IoTBDS 2022), pages 119-126

ISBN: 978-989-758-564-7; ISSN: 2184-4976

119

diate nodes; different types of trafﬁc data needs to be

exchanged between providers and/or consuming parts

of the backend services (NordicWay, 2021). Also, the

European Commission has initiatives considering the

inclusion of end user smartphone data collection and

distribution for trafﬁc planning purposes, using API-

driven solutions (Joinup, 2021).

We need to investigate a suitable solution for key

access procedures in a HSM, from a microservice

node. The access must have enough security but still

balance between performance and scalability. Typical

REST API:s can have layers of security for the actual

API calls, but we also need to ensure that the protocol

that triggers an HSM operation is authenticated and

sound; TLS is a good way to secure the communica-

tion, but the request procedure of accessing the secret

key/crypto operation within the HSM must also not be

breakable or leak sensitive data that can compromise

a client or HSM.

1.2 Cryptographic Accumulators

A cryptographic accumulator is an efﬁcient algorithm

for proving set-membership. Given an element y in

some set Y , it is possible for a prover to prove for

a veriﬁer that y ∈ Y without revealing any other in-

formation of the elements. By using a (ﬁxed-size)

witness for an element in the accumulator, a veriﬁ-

cation of that element’s set (non)-membership is pos-

sible. The security lies in the hardness of comput-

ing such witness for elements not belonging to the

set Y , i.e. forge a membership proof. The notion

of one-way accumulators was ﬁrst proposed by Be-

naloh and de Mare (Benaloh et al., 1993), known as

RSA accumulators. To illustrate the idea, we give a

short overview of a simple RSA accumulator func-

tion f (x) = A

mod N where A is the accumulator

(holding all the elements) and N = pq for primes

p,q. Initially the accumulator consists of the element

= g, then after accumulating x

we get A

= g

and for a sequence of elements x

,...,x

we get

= (g

)

,...x

= g

...x

. Now, to create a wit-

ness for element x

we compute w

= g

...x

i−1

i+1

...x

and to prove that x

∈ A

we can simply verify that

= g

...x

i−1

i+1

...x

= A

Cryptographic accumulators can be categorized

into static, dynamic and universal types. Static ac-

cumulators cannot alter the set, i.e adding/removing

elements, whereas dynamic accumulators have this

ability. Universal accumulators provide both alter-

ation and the possibility to perform veriﬁcation of

non-membership proofs, i.e. prove that y 6∈ Y .

1.3 Related Work

A recent survey indicates that both products and pro-

gramming libraries are available for most types of

key access solutions, e.g. software vaults and cryp-

tographic primitives for Secure Multi-Party Compu-

tations (SMPC) (Salin and Fokin, 2021). Regard-

ing SMPC and similar solutions, nothing has become

widely adopted as of yet in the industry, although

seemingly on the rise. Moreover, identiﬁed naive ap-

proaches for key access are storing the secret key em-

bedded in the application (during build), in a database

with stored database credentials in a property ﬁle or

storing pointers to the actual key in a conﬁguration

ﬁle. These solutions imply direct vulnerability if the

device or node is compromised.

A typical approach in industry is using a tradi-

tional public key infrastructure (PKI) for microser-

vice authentication, hence the usage of certiﬁcates be-

tween nodes. In (Pahl and Donini, 2018) a certiﬁcate-

based methodology for IoT authentication is pre-

sented, where additional authentication data is em-

bedded in each executable. The proposal shows

promising scalability and could most likely be used

for a microservice authenticated access to a key stor-

age. However, the solution still builds on PKI key

management which handles revocation and key dis-

tribution in a non-efﬁcient way in a large-scale de-

ployment. In some scenarios, authentication could

be a collaborative approach, i.e. a set of microser-

vices that would need to split some access creden-

tial among them and perform a SMPC scheme. Harn

(Harn, 2012) proposed a group authentication proto-

col designed speciﬁcally to be a many-to-many au-

thentication system, instead of the more classical ap-

proaches of having a one-to-one relationship, e.g. one

prover and one veriﬁer. This was accomplished by

using Shamir’s secret sharing. We could view this in

a microservice perspective where the group is a set

of IoT backend services, computing access collabo-

ratively. While this solution is efﬁcient, an adversary

could gain access to one of the shares and through a

replay attack become authenticated. A further attack

vector with Shamir’s secret sharing scheme is that a

party could become compromised and send a non-

legitimate secret to the entity collecting the secrets.

This would break the secret sharing protocol. Another

secret sharing approach for key management has been

proposed (Li et al., 2014) with the angle of adding a

layer of data security by including derived convergent

keys for data encryption, secured by a master key.

However, as noted previously, secret sharing schemes

also come with certain drawbacks, and is therefore on

its own not a complete solution for the situation re-

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

120

searched in this paper.

1.4 Contribution

We propose a novel solution to securely provide mas-

ter key access in a microservice ecosystem, construct-

ing an accumulator-based scheme with witness split-

ting and an interactive request access mechanism.

Our contribution consists of:

• a proposed secure master key access scheme with

witness splitting and a dynamic cryptographic ac-

cumulator,

• a security and correctness analysis of the proposed

scheme,

• a proof-of-concept implementation of the scheme

in Java with a performance- and communication

complexity analysis.

2 PRELIMINARIES

We introduce a set of cryptographic primitives nec-

essary for building our proposed scheme. The accu-

mulator is based on a dynamic non-adaptive scheme

in (Karantaidou and Baldimtsi, 2021), which in turn

is proven secure under the q-Strong Difﬁe-Hellman

Assumption (q-SDH). A secure hash function H is

a collision-free function H : {1,0}

∗

→ G resistant to

preimage attacks. We denote x

←− A to be an element

x chosen randomly (uniformly) from a set A.

Deﬁnition 1. Let G

be multiplicative

groups of prime order p. A pairing is a bilinear map

ˆe : G

× G

→ G

with the following properties:

• Bilinearity: For all x ∈ G

,y ∈ G

then

ˆe(x

) = ˆe(x,y)

for any a,b ∈ Z.

• Non-degeneracy: For generators g

∈ G

∈

then ˆe(g

) 6= 1.

• Efﬁcient: The map ˆe can be efﬁciently computed.

If G

= G

then we call the pairing symmetric.

Deﬁnition 2. Let k ∈ N be a security parameter and

G a cyclic group of order q > 2

. Let g be a genera-

tor of G. The Discrete Logarithm Problem (DLP) is,

given a randomly chosen y,g ∈ G, to ﬁnd the unique

x ∈ Z

∗

such that y = g

Deﬁnition 3 (q-Strong Difﬁe-Hellman Assump-

tion). Let g be a randomly chosen generator to the

cyclic group G, with prime order p, and a randomly

chosen element x ∈ Z

. Given the set {g

|i ∈ Z

∪

{0}} for some integer q, a probabilistic polynomial-

time (PPT) adversary can only compute the pair

(c,g

x+c

) ∈ Z

× G with a negligible probability.

The Boneh-Lynn-Shacham (BLS) short signature

scheme (Boneh et al., 2001) is used in our proposed

architecture for creating speciﬁc client witness values.

BLS is based on pairings and consists of four proce-

dures where signatures are computed by σ = H (m)

with secret key sk. A signature is then validated by

ˆe(σ,g)

= ˆe(H (m),pk) where pk is the public key of

the signer.

2.1 System Settings

Let ID

,...,ID

be a set of n microservices; we refer

to each node as a client. Each service is running on a

trusted, hardened (secured) container in an orchestra-

tion platform, handling the communication pipeline

between all nodes. Another node, H S M , is a secure

storage service containing a master key k and can per-

form cryptographic functions f

(·).

We assume an IoT device can trigger implicit ac-

cess to the H S M node by requesting a service at

some ID

, either from an IoT interface integrating di-

rectly with ID

or as part of the microservice ecosys-

tem. Communication is via API:s between the nodes,

assumed securely established using TLS or similar

well-known deployable solutions. The authentica-

tion of the IoT device in the public network, is ab-

stracted on the surrounding system-level, e.g. by to-

kenization/federation or other type of authentication

framework, terminating before ID

requests access to

H S M , thus out-of scope and not relevant for our pa-

per.

3 ACCUMULATOR MASTER KEY

ACCESS SCHEME

Our proposed master key access scheme builds on

a similar accumulator construction given in (Karan-

taidou and Baldimtsi, 2021), but with an interactive

additive witness update mechanism based on the dis-

crete logarithm problem. We use the accumulator to

securely keep track of eligible clients that should have

access, and use the interactive witness mechanism to

ensure forward secrecy and authentication. Clearly,

similar types of accumulator constructions based on

pairings can be used as a cryptographic primitive;

we illustrate the idea with the dynamic non-adaptive

scheme in (Karantaidou and Baldimtsi, 2021). By us-

ing an accumulator, a single value can be stored in the

HSM instead of a database with identities, key val-

ues and so on. This approach would reduce the com-

plexity of key management since revocation is sim-

ply equivalent to removing the key access value for

An Authenticated Accumulator Scheme for Secure Master Key Access in Microservice Architectures

121

a client in the accumulator. Another strength in our

approach is also the ease of implementation and the

increased difﬁculty for an adversary to simply steal

a password or secret key from a client; since each

access attempt generates an ephemeral intermediate

value, combined with a witness splitting technique,

no replay attacks are possible.

3.1 Overview

A master key k is stored in a secure module H SM .

A client with identity ID needs access to compute a

cryptographic function f

(m), e.g. a signature or en-

cryption over a message m. In order to compute f

(m)

and thereby implicitly accessing k, following proce-

dure will establish an authenticated access:

• ID publish public key pk

• ID and H S M agrees on security parameters

par = {G, q,g, ˆe,H }.

• ID computes registry value σ

= H (ID)

and

sends to H S M .

• H S M derives a client-speciﬁc access value k

H (ID)

+ H (ID)

H S M

• H S M accumulates k

into a client access

accumulator and generates a witness w

GenWitness(k

• H S M splits w

into w

and w

using

SplitWitness and immediately updates the shares

using the UpdateWitness procedure.

• H S M share w

to ID.

• At this stage, H S M is securely storing k

in the

accumulator and the client possess the partial wit-

ness w

, thus the client is not storing the com-

plete witness nor the access value (or even has any

knowledge of what that value is).

• When the client wants access, it sends w

H S M .

• H S M responds with a challenge g

where z

−→

∗

for the ith iteration of request.

• The client computes (g

)

= g

·sk

and sends

to H S M .

• H S M veriﬁes that ˆe(g

·sk

−z

) = ˆe(g,g)

ˆe(g,pk

), since the inverse to z

is only known to

H S M .

• If successful both parties updates w

= w

·sk

, and H S M also updates w

= (w

)

−

·sk

, using the UpdateWitness procedure, thus

invalidates the old shares.

In the last step, when updating the partial witness,

we refer to a mechanism where the witness w

can

be split into w

, and later in time gets updated

in such a way that the new shares are bound to an

ephemeral value and the secret key of the client. Rely-

ing on the discrete logarithm problem, the challenge-

response part with g

·sk

ensure that H S M can ver-

ify the authenticity of ID and thereby proceed with the

key updating procedure. We illustrate the complete

sequence of our scheme in Tab. 1.

3.2 Scheme Description

We deﬁne our master key access scheme as follows:

Setup(1

) → (par): generates secure Difﬁe-Hellman

groups, pairing function and hash functions, col-

lected into par = {G,q,g, ˆe, H }. To initialize an

empty accumulator, a random value u

←− Z

∗

generated and the starting accumulator value is set

to v

= g

. The H S M itself also generates a pri-

vate signature key sk

H S M

. The client also gener-

ates public and secret keys pk

,sk

,ID) → (⊥,w

) : A client with iden-

tity ID register access to the H S M using a signed

proof σ

= H (ID)

and receives the partial

witness w

after the H S M has veriﬁed against

. Register function is computed as follows:

= σ

+ H (ID)

H S M

(1)

= H (ID)

+ H (ID)

H S M

(2)

Next, procedures Accumulate and SplitWitness

are used as subroutines in order to ﬁnally return

to the client.

Accumulate(k

) → w

: accumulates k

and gen-

erates a witness w

for the access key of ID

(eligible for access). If k

is not already in-

serted, the accumulation from state t to t + 1 is

computed as v

t+1

= v

+sk

H S M

and the witness

= (v

t+1

)

+sk

H S M

SplitWitness(w

) → w

: splits the witness

into two shares, using the following formula

where s

←− G

= s (3)

= w

− s (4)

UpdateWitness(w

z·sk

) → w

updates the witness shares using g

z·sk

where

←− Z

∗

= w

+ g

z·sk

(5)

= (w

)

− g

z·sk

(6)

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

122

Table 1: Sequence diagram of the accumulator-based secure master key access scheme.

Client ID Message H S M

←− Z

∗

, pk

= g

par = {G, q,g, ˆe,H , v

} k

←− Z

∗

,sk

H S M

←− Z

∗

= H (ID)

−−−−−−−−−−→

= σ

+ H (ID)

H S M

= Accumulate(k

)

←−−−−−−−−−− w

) = SplitWitness(w

)

Request access to f

(·) σ

−−−−−→

←−−−−−−−−−− g

←− Z

∗

)

z·sk

,m −−−−−−−−−−→

ˆe(g

−z

z·sk

)

= ˆe(g,pk

)

= CombineWitness(w

)

(m) = Access(w

,σ

,m)

Updates and store w

) = UpdateWitness(w

z·sk

)

after successful veriﬁcation of ˆe(g

−z

z·sk

)

ˆe(g,pk

CombineWitness(w

) → w

: combines the

witness shares as follows:



+ g

z·sk



(7)

= w

+ g

z·sk

I D

+ ((w

)

(8)

= w

+ w

= w

. (9)

Access(w

,σ

,m) → f

(m): A client accessing

function f

(·) which uses the secret master key

k to perform a cryptographic operation. Uses

the witness and veriﬁes that k

is accumulated.

Witness checking for k

is done by verifying

ˆe(w

H S M

) = ˆe(v

t+1

,g).

4 SECURITY ANALYSIS

4.1 Security Model and Setup

The underlying accumulator scheme is shown to be

secure under the q-SDH assumption in the appendix

of (Karantaidou and Baldimtsi, 2021). However,

since we use it as a cryptographic building block we

provide an overall security analysis of our scheme

and focus on those parts surrounding the accumula-

tion veriﬁcation and unforgeability.

We build our security analysis on the random or-

acle model (ROM), using a set of oracles that a prob-

abilistic polynomial-time (PPT) adversary A can uti-

lize. The Combine procedure in the scheme is mod-

eled as an oracle that can be queried a polynomial q

number of times, serving the adversary fresh values.

Deﬁnition 4. Let O

Combine

be a combine oracle which

takes a witness share w

and outputs a valid

witness w

∗

, i.e. O

Combine

) = w

∗

such that

Access(w

∗

,σ

∗

,m) = 1 for any message m and cor-

responding signature σ

∗

We also consider a hash (signature) oracle, simi-

lar to O

Combine

, but instead returns a signature σ

∗

H (x)

Deﬁnition 5. Let O

Sign,ID

be a signature oracle which

returns a BLS signature on any binary input string ID

using the secret key of ID. The signature will validate

successfully, i.e. Access(w

∗

,σ

∗

,m) = 1 given a valid

witness w

∗

Deﬁnition 6. Let sub be a polynomial-time subrou-

tine which extracts a secret key, given σ

∗

and a wit-

ness. sub returns the secret key of either the client or

H S M .

Deﬁnition 7 (Security Experiment I). We deﬁne the

security experiment EXP

Sign,ID

as follows: the adver-

sary A receives a valid witness w

∗

to use once (i.e.

no updates of shares will leak to the adversary) for re-

questing access. The adversary can only extract one

key during the experiment using sub. A wins the game

if the advantage

ADV

(EXP

Sign,ID

) = Pr[(O

Sign,ID

(ID) = σ

∗

)

∧



sub(σ

∗

) = sk

∨ sk

H S M



] (10)

is not negligible, i.e. the probability of success for A

to extract one of the secret keys in order to forge k

and thereby be able to access H S M in any forthcom-

ing requests.

Deﬁnition 8 (Security Experiment II). We deﬁne

the security experiment EXP

Combine

as follows: the

An Authenticated Accumulator Scheme for Secure Master Key Access in Microservice Architectures

123

adversary A receives a previous share w

j,i−1

where

j ∈ {1,2} and can query O

Combine

for a combined wit-

ness q times, except for the latest updated witness con-

taining z

. A is assumed to have access to the client

signature σ = H (ID)

. A wins the game if the ad-

vantage

ADV

(EXP

Combine

) = Pr[(O

Combine

1,i−1

) = w

∗

)

∧ (Access(w

∗

,σ,m) = 1)] (11)

is not negligible, i.e. the probability of success for A

generating a valid witness given an old witness share.

This would demonstrate the security against replay

attacks with regards to witness shares.

4.2 Analysis

We need to validate that an accumulated value k

correctly veriﬁed by the witness w

, and that the sub-

routine using Access is correctly executing f

(·) when

the client is authenticated, and rejects otherwise.

Theorem 1. Algorithms Accumulate and Access ver-

iﬁes correctly.

Proof. We note that Accumulate implicitly validates

by returning the witness for the accumulated value,

e.g. k

will generate w

, bound to ID and H S M in

state t + 1:

= (v

t+1

)

+sk

H S M

= (v

)

+sk

H S M

+sk

H S M

= v

(12)

Thus the witness correctly represents the existence of

in the accumulator. Next, we consider the correct-

ness of the proof checking mechanism:

ˆe(w

H S M

) = ˆe(v

H S M

) (13)

= ˆe(v

,g)

+sk

H S M

(14)

= ˆe(v

+sk

H S M

,g) (15)

= ˆe(v

t+1

,g) (16)

Theorem 2. The H S M node veriﬁes the ephemeral

value g

z·sk

correctly.

Proof. In the intermediate step of the protocol we

need to ensure that the H S M node correctly veriﬁes

the ephemeral value before proceeding with the wit-

ness combination procedure. The check consists of

the pairing ˆe(g

−z

z·sk

)

= ˆe(g,pk

) and we prove

its correctness (note that −z is the inverse element to

z, i.e. z · (−z) = (−z) · z = 1):

ˆe(g

−z

z·sk

) = ˆe(g,g)

(−z)·z·sk

(17)

= ˆe(g,g)

(18)

= ˆe(g,pk

) (19)

Theorem 3. Procedures Register and Access pre-

serves the un-forgeability of signatures in the scheme,

i.e. secure under the security experiment of type I.

Proof. The client signature is given by a BLS sig-

nature σ

= H (ID)

, and further the client ac-

cess value is only an addition of the H S M ’s ver-

sion of signature, resulting in k

= H (ID)

H (ID)

H S M

. Knowledge of either term in k

will

not give any advantage in ﬁnding the secret keys due

to the security of BLS (Boneh et al., 2001). Therefore

the probability

Pr[(O

Sign,ID

(ID) = σ

∗

) ∧ (sub(σ

∗

) = sk

)] (20)

is negligible since sub must then be an algorithm

breaking BLS. Also, knowing both terms and being

able to extract k

will not break the scheme in any

way since the ﬁnal veriﬁcation is independent of veri-

fying k

itself, but rather veriﬁes that k

is correctly

accumulated.

Now, let A be an adversary having access to

a signing oracle O

Sign,ID

and a witness w

∗

t+1

)

+sk

H S M

. It is shown in the appendix of

(Karantaidou and Baldimtsi, 2021) that accumulation

is secure under the q-SDH assumption, hence w

∗

will

not give the adversary any advantage in extracting the

secret keys since both are again secured as BLS sig-

natures and now also in the exponent of the accumu-

lation, thus

Pr[sub(w

∗

) = (sk

∨ sk

H S M

)] (21)

is negligible. Finally, above result implies that

ADV

(EXP

Sign,ID

) is negligible.

Our scheme uses a split-and-refresh technique for

the witness, often used for lightweight private key

management (Selvi et al., 2019; Ferreira and Da-

hab, 2002). The idea is to split the secret value into

two shares and after every usage, a random value is

generated and used for recomputing the shares in a

way such that the combined value is still the original

one. Afterwards the previous shares are deleted from

memory.

Theorem 4. Algorithms SplitWitness and

CombineWitness correctly split and updates w

invalidating any previous, outdated share w

, i.e.

secure under the security experiment of type II.

Proof. Consider witness w

, ﬁrst splitted in the ini-

tial stage by SplitWitness and directly updates, thus

the ﬁrst time the two shares are w

= w

+ g

·sk

and w

= (w

)

− g

·sk

. Clearly the witness is

combined efﬁciently as w

+ g

·sk

+ (w

)

−

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

124

·sk

= w

. Next, for the ith consecutive iteration

of updating the key shares, we get

s +

∑

i=1

·sk

− s −

∑

i=1

·sk

+ w

= w

. (22)

Assume the ith iteration of H S M access occur and

denote the current key shares as w

1,i

and w

2,i

Next, assume an attacker get access to a previous

key share w

1,i−1

. This implies that the attacker

also lacks the latest g

since the previous share is

computed on g

i−1

, or explicitly w

,i−1

= w

,i−2

i−1

. Since CombineWitness combines correctly,

the attacker needs either sk

or a value α such that

CombineWitness(α,w

,i−1

) = w

. For the ﬁrst

case, the attacker need to break the DLP since sk

only previously used in computations in the exponent

of H (ID)

and g

i−1

·sk

. In the second case it must

hold that (assuming the attacker can force H S M to

execute CombineWitness with arbitrarily z’s, i.e. us-

ing oracle O

Combine

α + (w

,i−1

)

i−1

− g

i−1

·sk

(23)

= α + w

,i−1

− g

i−1

·sk

(24)

= w

(25)

which implies α = w

+ g

i−1

·sk

thus the attacker

need both witness shares, or again need to solve the

DLP (to extract sk

) in order to solve α. The same

argument holds if the attacker have access to a previ-

ous share w

,i−1

and we conclude that

Pr[O

Combine

(α) = w

∗

∧Access(w

∗

,σ, m) = 1] (26)

is negligible due to the hardness of DLP, thus we con-

clude that the scheme is secure against replay attacks

of the witness shares.

5 IMPLEMENTATION

Our proof-of-concept implementation includes a scal-

able microservices ecosystem, built on a containeriza-

tion architecture to emulate a typical real-world im-

plementation as closely as possible. Each container

contains a service with a REST API for communi-

cation. The implementation is written in Java and

the Spring Boot framework, together with the Java

Pairing-Based Cryptography library (jPBC). This is a

Java porting of a C library called PBC and provides

the mathematical framework needed for pairing-

based cryptography (De Caro and Iovino, 2011). For

our implementation, the Type A pairings were cho-

sen for its simplicity. These are constructed on the

curve y

= x

+x over a ﬁeld F

for some prime q = 3

mod 4. Group G

is of prime order r where r is also

a prime factor of q + 1. Our chosen q was a 318-bit

integer. Note that operations are computed as stan-

dard group element operations on the elliptic curve,

i.e. curve point addition and multiplication.

5.1 Cryptographic Execution Efﬁciency

The protocol consists of six functions, noted in Tab. 3.

In order to attain a clear understanding of how

the scheme affects efﬁciency, every function went

through a performance analysis measuring the ap-

proximate time in milliseconds. Each function was

executed 100 times on a MacBook Pro, 2017, with

2.3 GHz Dual-Core Intel Core i5, 16 GB 2133 MHz

LPDDR3 on macOS Big Sur 11.2. An analysis of

each separate mathematical operation was also mea-

sured, given in Tab 2.

Table 2: Performance analysis of mathematical operations

where e are elements (points) on the pre-conﬁgured elliptic

curve, and n are 318-bit integers.

Operation Time (ms)

e.pow(n) 17.59

.powZn(e

) 8.98

.add(e

) 0.04

pairing 4.85

e.mul(n) 17.45

.mul(e

) 0.04

hash(n) 0.019

random(e) 2.78

random(n) 0.051

Table 3: Performance analysis of the scheme’s procedures.

Function Time (ms)

setup() 36.79

accumulate() 26.79

splitWitness() 2.37

updateWitness() 63.17

combineWitness() 104.64

access() 75.38

5.2 Communication Efﬁciency

We conducted a brief communication analysis in

terms of efﬁciency of sending and receiving re-

quests/responses between a microservice node and

the H S M node. Using TLS for secure communica-

tion is industry standard; however it will give a signif-

icant overhead in communication complexity due to

TLS handshake procedures and other types of estab-

An Authenticated Accumulator Scheme for Secure Master Key Access in Microservice Architectures

125

lishments for new connections. We measured our im-

plementation (one microservice) repeatedly with TLS

and without TLS, in order to understand the connec-

tion overhead. For 1000 repeated new connections the

mean proportion of using TLS compared to not using

TLS was ∆ = 0.9227, i.e. about 92% of the total con-

nection time is dedicated to the TLS protocol.

Table 4: Communication analysis of the scheme’s API con-

nections.

API no TLS (ms) TLS (ms)

/registerClient 96.657 540.98

/requestAccess 169.18 926.81

/proveAccess 175.54 985.12

Total execution time: 441.38 2452.91

The API consists of three main endpoints:

/registerClient is the initial registration of a client in-

cluding key access value generation, /requestAccess

is for requesting access and thus handle the ephemeral

value g

z·sk

, and ﬁnally /proveAccess will trigger the

actual crypto function f

(·). These HTTP endpoints

take a set of parameters in base64 string format and

are converted into byte streams when handled by the

node. To conclude the experiment, the timing results

for our proof of concept implementation lies within

reasonable timings. As a comparison, a microservice

node in our experiment that only connects to a se-

cure website and receives a HTTP OK response, had

a mean timing of 768.95 ms.

6 CONCLUSION

We have shown a theoretical construction of an

authenticated accumulator-based master key access

scheme, proven its security under type I and II secu-

rity experiments, i.e. secure against forgery and reply

attacks. Our proof-of-concept implementation shows

promising results indicating the feasibility and easy-

to-adopt approach in a microservices context. We ar-

gue that the level of implementation is signiﬁcantly

easier using wrapper crypto libraries such as jPBC,

than developing code using low-level languages; it

is also closer to real-world microservices applica-

tions where high-level programming languages such

as Java and C# is de facto choice in industry.

REFERENCES

Benaloh, J., de Mare, M., and Automation, G. (1993). One-

Way Accumulators: A Decentralized Alternative To

Digital Signatures. pages 274–285. Springer-Verlag.

Boneh, D., Lynn, B., and Shacham, H. (2001). Short

signatures from the weil pairing. In Advances in

Cryptology–ASIACRYPT ’01, LNCS, pages 514–532.

Springer.

De Caro, A. and Iovino, V. (2011). jpbc: Java pairing based

cryptography. In Proceedings of the 16th IEEE Sym-

posium on Computers and Communications, ISCC

2011, pages 850–855. IEEE. [Online; accessed 08-

February-2022].

Ferreira, L. C. and Dahab, R. (2002). Blinded-key sig-

natures: securing private keys embedded in mobile

agents. In In Proceedings of the 2002 ACM sympo-

sium on Applied computing (ACM SAC’02, pages 82–

86. ACM Press.

Harn, L. (2012). Group authentication. IEEE Transactions

on computers, 62(9):1893–1898.

Joinup (2021). Intelligent transport systems - coopera-

tive, connected and automated mobility (its-ccam) and

electromobility (rp2020). https://joinup.ec.europa.eu/

collection/rolling-plan-ict-standardisation/. [Online;

accessed 27-November-2021].

Karantaidou, I. and Baldimtsi, F. (2021). Efﬁcient construc-

tions of pairing based accumulators. In 2021 2021

IEEE 34th Computer Security Foundations Sympo-

sium (CSF), pages 373–388, Los Alamitos, CA, USA.

IEEE Computer Society.

Ker

anen, A., Kovatsch, F. M., and Hartke, K. (2021).

Guidance on restful design for internet of things

systems. Internet-Draft draft-irtf-t2trg-rest-iot-08,

IETF Secretariat. https://www.ietf.org/archive/id/

draft-irtf-t2trg-rest-iot-08.txt.

Li, J., Chen, X., Li, M., Li, J., Lee, P. P., and Lou, W. (2014).

Secure deduplication with efﬁcient and reliable con-

vergent key management. IEEE Transactions on Par-

allel and Distributed Systems, 25(6):1615–1625.

NordicWay (2021). Interchange node under the nordic way

project. https://github.com/NordicWayInterchange.

[Online; accessed 08-February-2022].

Pahl, M.-O. and Donini, L. (2018). Securing iot mi-

croservices with certiﬁcates. In NOMS 2018 -

2018 IEEE/IFIP Network Operations and Manage-

ment Symposium, pages 1–5.

Pereira-Vale, A., M

arquez, G., Astudillo, H., and Fernan-

dez, E. B. (2019). Security mechanisms used in

microservices-based systems: A systematic mapping.

In 2019 XLV Latin American Computing Conference

(CLEI), pages 01–10.

Salin, H. and Fokin, D. (2021). Mission impossible: Secur-

ing master keys.

Selvi, S. S. D., Paul, A., Rangan, C. P., Dirisala, S., and

Basu, S. (2019). Splitting and aggregating signatures

in cryptocurrency protocols. In 2019 IEEE Interna-

tional Conference on Decentralized Applications and

Infrastructures (DAPPCON), pages 100–108.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

126