AccA: A Decentralized and Accumulator-Based Authentication and

Authorization Architecture for Autonomous IoT in Connected

Infrastructures

Hannes Salin

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

ange, Sweden

ﬁ

Keywords:

Trust Model, Trust Architecture, Cryptographic Accumulators, C-ITS, Authentication, Authorization.

Abstract:

In the realm of Intelligent Transport Systems and connected infrastructures, the use of IoT devices offers

improved safety and efﬁcient trafﬁc management. However, the emergence of trends such as Social IoT,

particularly in ad-hoc networking, poses a signiﬁcant challenge for cybersecurity and trust between nodes.

To address this, we propose an efﬁcient trust model architecture designed speciﬁcally for dynamic, ad-hoc

environments where IoT interactions are frequent. Our model focuses on decentralized authorization, where

trust is established on the object level, rather than relying on centralization. Our proposed architecture is

backed by security proofs and a proof-of-concept implementation using nested cryptographic accumulators,

which shows the effectiveness and feasibility of the proposed trust mechanism.

1 INTRODUCTION

Connected road- and railway infrastructures, such as

Cooperative Intelligent Transport Systems (C-ITS),

are complex environments with moving and station-

ary nodes. The main objective of C-ITS in the road

vehicle industry is to facilitate communication be-

tween vehicles and the surrounding infrastructure,

thus enhancing road safety and optimizing trafﬁc ﬂow

(Zeddini et al., 2022). Furthermore, the integration of

drones into C-ITS architectures has been explored as

it could potentially broaden the range of potential ap-

plications (Valle et al., 2021). Internet of Things (IoT)

and industrial IoT (IIoT) are also two major technolo-

gies within these types of environments. While the

advent of new technology and connected infrastruc-

tures creates many opportunities for novel applica-

tions, there is a pressing need for secure architecture

and trust models within these systems. This is be-

cause the large number of connections and the for-

mation of relationships between nodes require robust

authentication and authorization processes (Shahab

et al., 2022; Galego and Pascoal, 2022). Numerous

access control models (ACM) exist, and many of them

are separated into different layers, e.g. cloud-, object-

, and virtual layers (Gupta et al., 2022). Moreover,

from an architectural perspective, the networking lay-

https://orcid.org/0000-0001-6327-3565

ers must also be considered for the access control, e.g.

application- or transport layers in the TCP/IP stack.

An ACM speciﬁes how a user or object gains access

to speciﬁc functions or capabilities in other objects.

The Discretionary Access Control (DAC) model is

an identity-based model where a user or object has

complete control over its own resources, and con-

trol the permissions given to other users or objects.

Usually this model is implemented as an access ma-

trix, authorization table or access control list (Ravidas

et al., 2019). Another model is the Role-based Ac-

cess Control (RBAC) model which instead of iden-

tities grants permissions to predeﬁned roles of users

or objects. Several other type of ACM can be used

as well, e.g. Attribute-based Access Control (ABAC)

which restricts access via attributes, also expressed as

policies (Ravidas et al., 2019).

1.1 Problem Statement

Trust management in IoT environments remains a

challenge (Chahal et al., 2020; Khan et al., 2020;

Sharma et al., 2020; Hammi et al., 2022). Our goal

is to investigate how short-lived networks of collab-

orative interactions between IoT devices, where each

device dictates its own authorization mechanism, can

be provided using efﬁcient and secure means.

170

Salin, H.

AccA: A Decentralized and Accumulator-Based Authentication and Authorization Architecture for Autonomous IoT in Connected Infrastructures.

DOI: 10.5220/0011959200003482

In Proceedings of the 8th International Conference on Internet of Things, Big Data and Security (IoTBDS 2023), pages 170-177

ISBN: 978-989-758-643-9; ISSN: 2184-4976

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

1.2 Related Work

The usage of cryptographic accumulators have previ-

ously been investigated in the domain of ad-hoc net-

working, particularly in the domain of C-ITS, how-

ever regarded in the context of authentication (Zuo

et al., 2021; Salin et al., 2021), secret key storage

(Salin and Fokin, 2022), vehicle pseudonymization

orster et al., 2014) and vehicle certiﬁcate revocation

(Heng et al., 2022). Although efﬁcient solutions for

authentication are proposed, no combined authentica-

tion and authorization mechanism was found, using

a secure accumulator-based architecture. Lauinger et

al. proposed an authorization scheme for Internet of

Vehicles built on accumulators and zero-knowledge

proofs, however, the architecture needs a manag-

ing root authority for the accumulators and not self-

contained in each object, i.e. the vehicle (Lauinger

et al., 2021). Finally, in the comprehensive study by

Khan et al. on IoT-speciﬁc authorization schemes, no

accumulator-based solutions were to be found either

(Khan et al., 2022).

1.3 Contribution

Our contribution consists of a novel secure authenti-

cation and authorization architecture for ad-hoc and

short-lived IoT environments. We also provide a se-

curity analysis and a proof of concept implementation

with a performance analysis.

1.4 Structure of the Paper

In Sec. 2 we provide necessary preliminaries includ-

ing systems settings and the threat model. In Sec. 3

we introduce the access control architecture with the

proposed protocols. Sec. 4 provides a correctness and

security analysis of the protocols and Sec. 5 elabo-

rates on the proof of concept implementation. We

conclude our paper in Sec. 6.

2 PRELIMINARIES

We refer to H as a secure hash function H : {1, 0}

∗

→

{1, 0}

for some ﬁxed n, resistant to preimage attacks.

The output of H , i.e. the hash digest H (m) is an

element of a secure group G. We denote the generator

of G as g.

Deﬁnition 1 (Strong RSA Assumption). Let k be a

security parameter. Given a k-bit RSA modulus N and

a random element x ∈ Z

∗

, there exists no probabilistic

polynomial-time algorithm that outputs y > 1, and α

such that α

= x mod N, except with negligible prob-

ability.

The accumulator we use in our architecture is

based the dynamic RSA-based scheme, proposed by

Benaloh and De Mare (Benaloh and de Mare, 1994).

However, our proposed architecture does not rely on

a speciﬁc accumulator per se, but instead of detailing

the architecture with an accumulator as a black box,

we illustrate the overall architecture using the RSA-

based scheme.

Deﬁnition 2. Let p and q be strong primes. Let a ∈ Z

be relatively prime to pq = N, secure under Def. 1.

To accumulate element x

the following computation

is done: Z ← a

mod N. A witness extraction for x

i.e. w

, we compute w

= a

j=1: j̸=i

, over Z with n

elements. To verify that x

∈ Z we compute w

= Z.

To delete x

we compute x

−1

, then run Z

′

← Z

−1

Thus, the scheme has three major procedures we

consider in our architecture:

Acc(x): accumulates element x into Z by exponenti-

ation, as described in Def. 2. Also, this procedure

returns the corresponding witness w when x is ac-

cumulated.

Del(x): deletes element x

from Z by accumulating

the inverse to x

, as described in Def. 2.

Ver(w, x, Z): veriﬁes if x

is accumulated into Z, re-

turns 1 if accepted, 0 otherwise.

The accumulator we use in our proposal is proven

secure under the strong RSA-assumption in Def. 1.

Boneh-Lynn-Shacham (BLS) short signatures

(Boneh et al., 2001) are based on pairings and con-

sists of a set of procedures and a key-pair (sk, pk) of

private and public keys respectively (of the signer).

The signature σ is computed as follows:

(m)

= σ (1)

where g is the chosen generator in G. The signature

is veriﬁed by checking that the equation

ˆe(σ, g)

= ˆe(H (m), pk) (2)

holds.

2.1 System Setting

We describe a typical C-ITS setting where IoT nodes

and vehicles are referred to as objects - denoted OBJ

- and humans in the system as users. A user always

has an associated device, i.e. object, as means of com-

munication with other users or objects. We denote an

ad-hoc network with multiple connections to different

OBJ ’s as NET. We highlight that a certain NET is a

AccA: A Decentralized and Accumulator-Based Authentication and Authorization Architecture for Autonomous IoT in Connected

Infrastructures

171

bounded logical network for a designated area, e.g. a

smart home network, a clustered drone network or a

VANET. Each NET have at least one authorized reg-

istration object that allows other objects to register to

the NET. However, in contrast to isolated public key

infrastructure (PKI) settings, object registration is the

only function for the registration object. All subse-

quent authentications and authorizations are made by

the participating objects themselves since the objects

are the entities that provide the accessible capabili-

ties within them. We assume standard communica-

tion between objects to be secured via encryption, ex-

cept particular messages that according to standards

are chosen un-encrypted (European Telecommunica-

tions Standards Institute, 2014). In a NET, differ-

ent actors are differentiated, e.g. authorities (police,

government etc.), private third parties (companies and

business) and other objects. These actors are referred

to as types. A certain object may have a standard

trust setup with a limited number of types that can

be handled. However, due to the ad-hoc environment

in the NET, the authorization matrix the object pos-

sesses can be updated. The functions an object may

give access to can be to share certain (vehicle, trafﬁc,

geographical or sensory) data, turning on/off different

functions or allowing proxy connections for extended

communication.

2.2 Threat Model

We consider a threat model, using adversaries that ei-

ther observe the ad-hoc network of connections NET

from the outside, or is part of the same network as

a participant, hence adversary A is an object within

the given system setting, as described in Sec. 2.1. A

have the ability to capture and record data transfer be-

tween nodes in any given NET. A does not have the

computational ability to steal or tamper memory data

from other objects, nor can it access any secret keys.

All other participants are honest, non-tampered ob-

jects OBJ

, ..., OBJ

. We deﬁne two security exper-

iments for A in the given NET architecture:

Exp

: This experiment, denoted type A

, is when

the adversary tries to gain access to function f

object OBJ

which it has not access to according

to an authorization mechanism. However, A is

part of the NET and otherwise trusted to access

other functions of the target object.

Exp

: This experiment, denoted type A

, is when

the adversary is not part of the NET but tries to

get access to function f

in object OBJ

, hence

there is no storage of any keys nor data of A in

OBJ

We note that the index of the object is k, but w.l.o.g

it can be any participant, thus we ﬁx the targeted ob-

ject to have index k for simplicity. Exp

represents

an attack which is very plausible due to dishonest

users or objects that are compromised; by accessing

the internal software, hardware tampering or lack of

user security awareness (Gangolli et al., 2022; Poly-

chronou et al., 2021; Sadhu et al., 2022).

3 THE ACCESS CONTROL

ARCHITECTURE

Our architecture provides authorization without the

need for a central party, except initial registration for a

certain area that this party handles. Instead, as trusted

parties in the environment after registration, all ob-

jects can handle the authorization separately based

on the individual needs. The ACM that is embed-

ded in our architecture is thus a DAC and RBAC hy-

brid where access is granted by the object itself, and

based on roles (types). We denote the model as the

Accumulator-based Authentication and Authorization

model: AccA.

The core part of the architecture is built on an au-

thorization matrix M which embeds an authentica-

tion vector V . The two objects are combined and

stored securely as an accumulated element of a cryp-

tographically secure accumulator Z, where V itself is

also an accumulator embedded as an element in M .

The authorization matrix M is an (m +1) × n-matrix,

representing the m available functions f

, f

, ..., f

be accessed in the object, and n types which are al-

lowed to have authorization. The additional row al-

lows for storage of the authentication vectors, see

Tab. 1. The matrix M is represented as n vectors

Table 1: The authorization matrix with m functions (each

row), n types (each column) and one corresponding authen-

tication vector for each type.

··· ID

1,1

2,1

3,1

··· b

n,1

1,2

2,2

3,2

··· b

n,2

. ···

1,m

2,m

3,m

··· b

n,m

··· V

, ..., M

where each vector M

corresponds to col-

umn i in M , i.e. M

= (b

, V

), where each b

a bit string with corresponding bits 0 or 1 for each

function, i.e. which functions ID

is allowed and

= b

i,1

i,2

··· b

i,m

. Thus, b

i, j

is the speciﬁc autho-

rization marker for user j, i.e. for an authorization

IoTBDS 2023 - 8th International Conference on Internet of Things, Big Data and Security

172

User 2

Request access to

Central IoT (OBU)

............

User 1

User k

Figure 1: Ad-hoc system setting where k vehicles connect dynamically via an initial registration to a Registration Authority

(RA) using the Reg

protocol. User 2 requests access to capability f

in vehicle k. Authentication and authorization is

through the accumulator Z that executes in the IoT-capable Onboard Unit (OBU) in the vehicle, integrating to multiple IoT-

and sensory devices in the vehicle. The OBU is regarded as an object.

matrix with a set of functions, then b

i, j

has a bit value

of 1 for each function it have access to, 0 otherwise.

Next, the embedded authentication vector V

con-

sists of accumulated signatures of each allowed par-

ticipant. The authentication vector is speciﬁed in de-

tail:

Deﬁnition 3. Let v

= {σ

i,1

, σ

i,2

, ..., σ

i,n

} be a set of

signatures σ

i, j

= H (ID

||α

)

where H is a secure

hash function, sk the private key of object j, ID

the object identiﬁer of type ID

and α

a registra-

tion value. We then call the accumulator V

= g

i,1

·σ

i,2

···σ

i,n

the authentication vector for type ID

The vector and matrix accumulation relationship

is as follows:

Z = g

= g

···M

= g

)·(b

)···(b

)

(3)

We note that M in practical terms can be written

as a single vector with 2n elements, but we continue

to refer to the set of M

’s for readability. In the rest

of the paper we consider each b

as integers since the

bit string from its binary representation expresses the

bits for access in M .

There are two types of witnesses used for an ob-

ject’s Z: primary witnesses ω and secondary wit-

nesses w. For an object OBJ

, the witness ω

proves

the existence of M

, hence ω

= Z. This witness

is used by the object internally (that handles Z) to

ensure the authentication vectors are intact. The sec-

ondary witness w

is generated by the object itself dur-

ing registration for another object OBJ

. Similarly as

, the proof is computed as w

i, j

= V

and w

is used

in each request to OBJ

for authentication and autho-

rization via V

We deﬁne a combined authentication and autho-

rization protocol, using a secure accumulator Z with

procedures Acc and Ver for accumulation and ver-

iﬁcation of an element respectively. The architec-

ture builds on that each object OBJ

has a key-pair

, pk

and a secure storage area with an accumula-

tor Z established. The NET need a trusted infrastruc-

ture party, typically found in the C-ITS environment

as a RSU or similar; we denote this trusted party as

the registration authority (RA) (European Telecom-

munications Standards Institute, 2021). The RA does

not need to be part of all executions in the AccA ar-

chitecture, except one initial interaction with all ob-

jects that would like to be part of the NET at some

future point. The aim of the RA is to establish trust

with the object and allow it into the NET for further

interactions. Upon gaining access through the RA,

objects within the network are responsible for inde-

pendently granting and revoking access to their inter-

nal functions to other objects within the network. A

simpliﬁed overview of the system settings where we

illustrate AccA is depicted in Fig. 1. The architecture

consists of four sub-protocols:

Reg

(OBJ

): this protocol runs between an ob-

ject OBJ

and the RA. Any type of initial authen-

tication can be used, speciﬁc for the NET. Af-

ter establish a secure channel, the following sub-

protocol runs:

1. OBJ

sends its public key pk

= g

to the RA.

2. The RA responds with α





where z

is a random value generated at the RA.

3. The RA stores z

, its inverse

and pk

in a

registration table, and the sub-protocol ends.

AccA: A Decentralized and Accumulator-Based Authentication and Authorization Architecture for Autonomous IoT in Connected

Infrastructures

173

Reg

OBJ

(OBJ

, OBJ

): this protocol runs when

OBJ

need to establish an authorization in OBJ

Both objects needs to be registered to the RA as a

prerequisite.

1. OBJ

sends a request ρ

= (σ

i,1

H (OBJ

||α

)

, α

, f

)

2. OBJ

sends α

to the RA after receiving

from OBJ

3. The RA respond with β

= g

4. OBJ

compute:

e(α

, β

)

= e(pk

, pk

) (4)

that veriﬁes OBJ

is registered in the RA,

thus OBJ

creates (or updates) a binary string

i,1

that corresponds access to f

for type 1 of

OBJ

. We note that an object may register sev-

eral types, which is determined by the identity

in σ

i,1

5. OBJ

accumulates σ

i,1

into Z and in particu-

lar V

using the Acc procedure, which in turn

output corresponding witnesses ω

and w

, re-

spectively. w

is sent back to OBJ

and ω

stored locally in OBJ

Auth(OBJ

, OBJ

, f

): this protocol runs between

two registered objects where OBJ

seek access to

in OBJ

. OBJ

sends a request ρ

access

= (h

H (w

)

, w

, g

). We note that g

can only be

computed by OBJ

since

(α

)

= g

(5)

where the inverse

can only be computed by

the holder of the secret key sk

, i.e. OBJ

. The

request is handled as follows:

1. OBJ

veriﬁes the BLS signature h

e(h

, g)

= e(H (w

), pk

). (6)

2. OBJ

veriﬁes that the requester is the correctly

registered object:

e(g

, β

)

= e(g, pk

) (7)

3. If successfully veriﬁed, OBJ

performs two

witness proofs: ω

for the internal check of the

validity of the authorization matrix, and then

for the authentication vector V

verifying the

witness w

, i.e. authenticating and authorizing

OBJ

for f

Rev(OBJ

, OBJ

, f

): this protocol revokes access

of f

in OBJ

for OBJ

. In all its simplicity,

OBJ

runs the accumulator procedure Del to re-

move σ

i,1

The usual C-ITS setup utilizes PKI for the fun-

damental trust management, using central authorities

and certiﬁcate issuers (Hammi et al., 2022). However,

in our proposed model, the authorization part is han-

dled dynamically within the NET by each OBJ . The

reason is that each OBJ only grants access to its own

capabilities and not on behalf of other objects, given

the underlying trust that the RA provided via the reg-

istration. Yet, that trust is veriﬁed in every authoriza-

tion registration. Therefore, the RA is only used ini-

tially for registration purposes, and all future authen-

tication and authorization is managed by the objects

themselves.

4 SECURITY ANALYSIS

Our security analysis focuses on the threat model out-

lined in Sec. 2.2. In forthcoming proofs we denote

that an element x is excluded from a set X by X \ {x}.

Theorem 1. The AccA architecture procedures

Reg

correctly register an object OBJ

to the RA,

and Reg

OBJ

correctly registers an object OBJ

into

OBJ

for function f

Proof. Let OBJ

and the RA generate their key-pairs

, pk

and sk

, pk

respectively. After the ﬁrst ex-

change, OBJ

stores α

= g

and the RA stores z

and g

. For object OBJ

to verify that the registra-

tion is completed and that α

is correct, RA returns

= g

to OBJ

, then it can check that:

e(α

, β

) = e



, g



(8)

= e



)

, (g

)



(9)

= e



, (g

)



(10)

= e



, pk



. (11)

For OBJ

to register access to f

in OBJ

, af-

ter successful veriﬁcation as described above, it run

Reg

OBJ

for accumulation. If OBJ

decide to allow

for f

then the witness w

is sent back to OBJ

follows: since σ

i, j

= H (ID

||α

)

and is accumu-

lated as Acc(σ

i, j

) = (g

)

i, j

, the returning witness is

= g

\{σ

i, j

}

. From Def. 2 we see that it holds by def-

inition. Hence, we conclude that Reg

and Reg

OBJ

We also prove the correctness of granting access

to a valid object in the model:

IoTBDS 2023 - 8th International Conference on Internet of Things, Big Data and Security

174

Theorem 2. An object OBJ

is successfully granted

function f

in object OBJ

if there is a valid authenti-

cation vector V , and likewise, is not granted access to

if OBJ

have no authentication vector established

in OBJ

Proof. OBJ

receives ρ

access

= (h

H (w

)

, w

, g

) and runs the standard BLS

signature veriﬁcation as in Eq.6 and Eq.7. These

veriﬁes correctly since:

e(h

, g) = e(H (w

)

, g) (12)

= e(H (w

), g

) (13)

= e(H (w

), pk

) (14)

and

e(g

, β

) = e

, g

= e

g, g

(15)

= e

g, g

= e(g, g

) (16)

= e(g, pk

). (17)

If the veriﬁcation is successful, the double witness

veriﬁcation with ω

and w

, using Ver from Def. 2

runs. Assume OBJ

does not have a valid registration

in M

, then the internal veriﬁcation



M \{M

}



= g

···M

= Z (18)

will not hold, hence the protocol will abort. This im-

plies that OBJ

must be registered in OBJ

. Next,

assume that V

does not contain σ

i, j

, then the veriﬁ-

cation

i, j



\{σ

i, j

}



i, j

= g

1, j

···σ

i, j

···σ

m, j

= V

(19)

will not hold, hence not give access to OBJ

. We

recall that v

= σ

1, j

··· σ

m, j

such that g

= V

To conclude, the protocol have ensured that OBJ

is indeed the correct witness holder of w

using the

provably secure BLS scheme, it will only continue the

protocol if OBJ

internally verify that M

is intact,

and ﬁnally grant access to f

only if w

is a valid proof

of the access signature σ

i, j

Theorem 3. The proposed architecture is secure in

the Exp

setting.

Proof. Let A be an adversary registered to the RA

and previously registered to OBJ

for a function f

A seeks access to f

which is not part of the binary

string b

that represents A’s current access in OBJ

We consider two cases:

1. A tries to forge a witness. Let σ

p,A

be the sig-

nature registered for A. Assume A computes w

which is a forgery of w

. When OBJ

check the

membership proof, it means that

p,A

= V

(20)

should hold if successfully forged. But since w

\{σ

p,A

}

it means that the adversary needs to

compute all remaining signatures σ

i, j

in OBJ

’s

accumulator, hence need to either forge the sig-

natures or steal the secret key sk

for each

OBJ

. BLS signatures are provably secure

against forgery (Boneh et al., 2001). Extracting

the signatures from an existing valid witness w

corresponding to some other function f

, would

break the security of the strong RSA assumption

(Benaloh and de Mare, 1994). Therefore, even

if A knows that the same signatures are accumu-

lated in w

as in w

, it is computationally infeasi-

ble to retrieve the signatures. Stealing the secret

keys would imply compromising the object’s se-

cure storage which would require a stronger ad-

versary. Thus, forging a witness successfully is

negligible. Moreover, forging the required signa-

ture σ

i,A

during registration is therefore also infea-

sible due to the security of BLS.

2. A tries to use a previously used witness w

∗

that

authorized f

but is now revoked. This case is

trivial since a revocation of σ

i,A

means that the

entry is completely deleted from V

, therefore

i,A

∗

̸= V

regardless of the value of σ

i,A

We note that manipulating b

is not possible since it

is generated in OBJ

and totally dependent on what

function f

was granted during Reg

OBJ

. To summa-

rize, we conclude that forging a witness w

would

break the accumulator scheme in Def. 2, hence break-

ing the strong RSA-assumption (Def. 1). Mount-

ing a replay-attack using a revoke witness would

break the correctness of the scheme, proven valid in

Thm. 2.

A registered object, after the Reg

protocol, has

a possibility to maliciously register for a function in

another object during Reg

OBJ

. However, since we as-

sume a dynamic, non-centralized environment NET,

where each object determines to whom a registration

can be granted, mitigation for such unauthorized reg-

istrations is not in scope for this paper.

Theorem 4. The proposed architecture is secure in

the Exp

setting.

Proof. Let A be an adversary not registered to the

same NET as OBJ

, but with the ability to send mes-

sages to any target object in any network. In Exp

AccA: A Decentralized and Accumulator-Based Authentication and Authorization Architecture for Autonomous IoT in Connected

Infrastructures

175

the adversary seek access to f

in OBJ

which is a

registered object, hence A has two options:

1. Mount an unauthorized registration to OBJ

. As-

sume A has no registered values in the RA. This

case requires A to run Reg

OBJ

, i.e. to forge a re-

quest message ρ

. Since A is not previously

registered to the RA, it must generate a forged

= g

for some z

. Assume A generates a

forgery ρ

∗

= (σ

i,A

, α

, f

). However, when

running Reg

OBJ

, α

is validated against the RA to

receive β

, but since there is no z

in RA the re-

quest is rejected and no β

exists. Therefore, re-

gardless of what type of forgery ρ

∗

contains,

an unauthorized registration in OBJ

implies the

storage of z

in RA which contradicts our assump-

tion.

2. Forge a request ρ

access

. Assume A has no regis-

tered values in the RA. A tries to forge ρ

access

, w

, g

), i.e. it must generate three compo-

nents. We consider each case-by-case:

(a) Generate w

: from Thm. 3 we know that a wit-

ness is not possible to forge or extract.

(b) Generate h

: since h

= H (w

)

it must suc-

cessfully forge w

, and as concluded above this

is not possible.

: as in case 1 above, there is no

, hence no β

in OBJ

, therefore it does not

matter what value g

will have, the protocol

will abort in any case.

Therefore, none of the components are possible

to generate for A, since any successful forgery

would contradict the initial assumption of A not

having any values registered in the RA.

These two cases then conclude that AccA is secure

under Exp

5 PROOF OF CONCEPT

We implemented the main parts of the AccA architec-

ture, and conducted a set of experiments to investigate

the performance. A Python wrapper of the MCL li-

brary (Mitsunari, 2019) was used with a type A curve,

BLS12 381. The hashAndMapTo function provided

in the MCL-library was used for hash function H

when computing signatures, but also to convert accu-

mulator elements. H maps to a group element in G.

Since the accumulator Z accumulates both integers

and accumulators V ∈ G, we use the hashAndMapTo

conversion for each M

m1 = [b_1, v_1]

m1hash = G1.hashAndMapTo(bytes(m1))

This minor implementation detail costs on aver-

age 0.0930 ms each time a new M

needs to be added

or updated. Since a NET is assumed to be short-lived

and highly dynamic, the overhead is considered neg-

ligible (but included in the performance tests). All

tests were executed 1000 times, and the average tim-

ings are noted in Tab. 2. Tests run on an Intel Core

i5, 2.7GHz platform. As shown in Tab. 2, the Auth

protocol is most expensive, naturally due to all veri-

ﬁcation procedures. We compared our results to the

performance analysis made by Ometov et al. where

several IoT devices were tested with a set of cryp-

tographic primitives (Ometov et al., 2016). With a

simpliﬁed comparison, we note that a pairing and a

curve point multiplication, on an Intel Edison, 500

MHz Dual-Core, takes 580 ms and 0.1 ms, respec-

tively. Hence our protocol for Auth in OBJ

would

take approximately 1160 ms. in the Intel Edison IoT

device, if we adjust pessimistically that accumulator

veriﬁcation is at least as costly as as curve point mul-

tiplication. Similarly, for Reg

OBJ

it would take ap-

proximately 600 ms. for the RA.

Table 2: Computational performance in each object (ms).

Protocol OBJ

RA OBJ

Reg

- 0.0671 -

Reg

OBJ

0.0181 1.3905 -

Auth - - 2.5749

Rev - - 0.0717

6 CONCLUSION

We have shown the feasibility and efﬁciency of AccA

in terms of computational performance, and proven it

secure against two different types of attacks. AccA

can be used for autonomous IoT in short-lived and

decentralized environments where only an initial reg-

istration is needed to a trusted third party. For future

work we propose further investigation in how to re-

duce the interactive part of the protocols for efﬁciency

reasons.

REFERENCES

Benaloh, J. and de Mare, M. (1994). One-way accumu-

lators: A decentralized alternative to digital signa-

tures. In Helleseth, T., editor, Advances in Cryptology

— EUROCRYPT ’93, pages 274–285, Berlin, Heidel-

berg. Springer Berlin Heidelberg.

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.

IoTBDS 2023 - 8th International Conference on Internet of Things, Big Data and Security

176

Chahal, R. K., Kumar, N., and Batra, S. (2020). Trust

management in social internet of things: A taxonomy,

open issues, and challenges. Computer Communica-

tions, 150:13–46.

European Telecommunications Standards Institute (2014).

ETSI EN 302 637-2: Intelligent Transport Sys-

tems (ITS); Vehicular Communications; Basic Set

of Applications; Part 2: Speciﬁcation of Coopera-

tive Awareness Basic Service. https://www.etsi.org/

standards. Accessed: 2022-05-15.

European Telecommunications Standards Institute (2021).

ETSI TS 102 940 V2.1.1: Intelligent Transport Sys-

tems (ITS); Security; ITS communications security ar-

chitecture and security management; Release 2. https:

//www.etsi.org/standards. Accessed: 2022-11-18.

orster, D., Kargl, F., and L

ohr, H. (2014). Puca: A

pseudonym scheme with user-controlled anonymity

for vehicular ad-hoc networks (vanet). In 2014 IEEE

Vehicular Networking Conference (VNC), pages 25–

32.

Galego, N. M. C. and Pascoal, R. M. (2022). Cybersecurity

in smart cities: Technology and data security in intel-

ligent transport systems. In Mesquita, A., Abreu, A.,

and Carvalho, J. V., editors, Perspectives and Trends

in Education and Technology, pages 17–33, Singa-

pore. Springer Singapore.

Gangolli, A., Mahmoud, Q. H., and Azim, A. (2022). A

systematic review of fault injection attacks on iot sys-

tems. Electronics, 11(13).

Gupta, M., Bhatt, S., Alshehri, A. H., and Sandhu, R.

(2022). Authorization Frameworks for Smart and

Connected Ecosystems, pages 39–61. Springer Inter-

national Publishing, Cham.

Hammi, B., Monteuuis, J.-P., and Petit, J. (2022). Pkis in

c-its: Security functions, architectures and projects: A

survey. Vehicular Communications, 38:100531.

Heng, X., Qin, S., Xiao, Y., Wang, J., Tao, Y., and Zhang,

R. (2022). A strong secure v2i authentication scheme

from pki and accumulator. In 2022 2nd International

Conference on Consumer Electronics and Computer

Engineering (ICCECE), pages 98–103.

Khan, A., Ahmad, A., Ahmed, M., Sessa, J., and Anisetti,

M. (2022). Authorization schemes for internet

of things: requirements, weaknesses, future chal-

lenges and trends. Complex & Intelligent Systems,

8(5):3919–3941.

Khan, W. Z., Hakak, S., Khan, M. K., et al. (2020). Trust

management in social internet of things: Architec-

tures, recent advancements, and future challenges.

IEEE Internet of Things Journal, 8(10):7768–7788.

Lauinger, J., Ernstberger, J., Regnath, E., Hamad, M., and

Steinhorst, S. (2021). A-poa: Anonymous proof of

authorization for decentralized identity management.

In 2021 IEEE International Conference on Blockchain

and Cryptocurrency (ICBC), pages 1–9.

Mitsunari, S. (2019). ”MCL cryptolibrary”. https://github.

com/herumi/mcl.

Ometov, A., Masek, P., Malina, L., Florea, R., Hosek,

J., Andreev, S., Hajny, J., Niutanen, J., and Kouch-

eryavy, Y. (2016). Feasibility characterization of cryp-

tographic primitives for constrained (wearable) iot de-

vices. In 2016 IEEE International Conference on

Pervasive Computing and Communication Workshops

(PerCom Workshops), pages 1–6.

Polychronou, N.-F., Thevenon, P.-H., Puys, M., and

Beroulle, V. (2021). A comprehensive survey of

attacks without physical access targeting hardware

vulnerabilities in iot/iiot devices, and their detection

mechanisms. ACM Trans. Des. Autom. Electron. Syst.,

27(1).

Ravidas, S., Lekidis, A., Paci, F., and Zannone, N. (2019).

Access control in internet-of-things: A survey. Jour-

nal of Network and Computer Applications, 144:79–

101.

Sadhu, P. K., Yanambaka, V. P., and Abdelgawad, A.

(2022). Internet of things: Security and solutions sur-

vey. Sensors, 22(19).

Salin, H. and Fokin, D. (2022). An authenticated accumula-

tor scheme for secure master key access in microser-

vice architectures. In Bastieri, D., Wills, G. B., Kac-

suk, P., and Chang, V., editors, Proceedings of the 7th

International Conference on Internet of Things, Big

Data and Security, IoTBDS 2022, Online Streaming,

April 22-24, 2022, pages 119–126. SCITEPRESS.

Salin, H., Fokin, D., and Johansson, A. (2021). Authen-

ticated multi-proxy accumulation schemes for dele-

gated membership proofs. In Luo, B., Mosbah, M.,

Cuppens, F., Othmane, L. B., Cuppens, N., and Kallel,

S., editors, Risks and Security of Internet and Systems

- 16th International Conference, CRiSIS 2021, Virtual

Event, Ames, USA, November 12-13, 2021, Revised

Selected Papers, volume 13204 of Lecture Notes in

Computer Science, pages 162–171. Springer.

Shahab, S., Agarwal, P., Mufti, T., and Obaid, A. J. (2022).

Siot (social internet of things): A review. In Fong, S.,

Dey, N., and Joshi, A., editors, ICT Analysis and Ap-

plications, pages 289–297, Singapore. Springer Na-

ture Singapore.

Sharma, A., Pilli, E. S., Mazumdar, A. P., and Gera, P.

(2020). Towards trustworthy internet of things: A sur-

vey on trust management applications and schemes.

Computer Communications, 160:475–493.

Valle, F., Cooney, M., Mikhaylov, K., and Vinel, A. (2021).

The integration of uavs to the c-its stack. In 2021 IEEE

29th International Conference on Network Protocols

(ICNP), pages 1–6.

Zeddini, B., Maachaoui, M., and Inedjaren, Y. (2022). Se-

curity threats in intelligent transportation systems and

their risk levels. Risks, 10(5).

Zuo, X., Li, L., Luo, S., Peng, H., Yang, Y., and Gong,

L. (2021). Privacy-preserving veriﬁable graph inter-

section scheme with cryptographic accumulators in

social networks. IEEE Internet of Things Journal,

8(6):4590–4603.

AccA: A Decentralized and Accumulator-Based Authentication and Authorization Architecture for Autonomous IoT in Connected

Infrastructures

177