SSI Strong Authentication using a Mobile-phone based Identity Wallet

Reaching a High Level of Assurance

Andreas Abraham

, Christopher Schinnerl and Stefan More

Institute of Applied Information Processing and Communications (IAIK), Graz University of Technology, Graz, Austria

Keywords:

Self-Sovereign Identity, Identity Management, Distributed Ledger, Strong Authentication, Identity Wallet.

Abstract:

Assurance in digital authentication means represents a fundamental requirement in the authentication process

of digital identities. Different level-of-assurance (LoA) describe the trustworthiness of the authentication spec-

iﬁed by various standards. Some traditional governmental identity systems achieve a high LoA. Nevertheless,

the recent self-sovereign identity (SSI) model, which utilizes identity wallets to ensure that the identity data

control remains with the related user, still lacks a high LoA, detaining the full potential of SSI such as using it

for sensitive use-cases like for eGovernment or public administration services. This work tackles this problem

by starting with assessing related LoA standards. Based on this assessment are requirements deﬁned to achieve

an LoA high. These requirements are utilized in the process of deﬁning and evaluating our proposed concept.

Our generic serves as the foundation for other developers, aiming to elevate the LoA in their SSI systems.

The implementation of a proof-of-concept showcases the feasibility and practicability of our concept. In the

evaluation, we identify measures provided by our concept, used to meet the deﬁned requirements, and discuss

the design decisions.

1 INTRODUCTION

Digitalization stimulates innovation in the ﬁeld of

digital identities and identity management (IdM). IdM

models started with the isolated identity model (Zwat-

tendorfer et al., 2014), in which the service provider

(SP) and identity provider (IdP) are represented by

the same party and evolved over time to the federated

and user-centric identity models. In the user-centric

model, the user’s identity data are stored within the

user domain, while a central trusted party still issues

the identity data.

With the emergence of blockchain technology,

new opportunities arose in various ﬁelds, including

IdM. The concept of Self-Sovereign Identity (SSI)

represents an evolvement of the user-centric identity

model (Abraham, 2017). SSI makes users of iden-

tity data the sovereign owners of their data without

the need for a central trusted party to manage it.

The relevance and potential of SSI is shown by the

research community (Houtan et al., 2020; Manski,

2020; Liu et al., 2020; Dong et al., 2020). Addi-

tionally, the European Commission (EC) recognized

https://orcid.org/0000-0002-4163-9113

https://orcid.org/0000-0001-7076-7563

the potential of SSI early on by launching the Euro-

pean self-sovereign identity framework

(ESSIF) use

case group within the European blockchain services

infrastructure

(EBSI).

One essential component of an SSI system is the

so-called identity wallet: A piece of software often

supported by special hardware, which is responsible

for storing and managing cryptographic key material,

identiﬁers as wells as identity data (Kondova and Er-

bguth, 2020). Wallets are often implemented as mo-

bile phone or browser applications. Since our daily

life is becoming increasingly mobile phone-centered,

the demand on mobile identity wallets is growing.

This is reﬂected by the various implementations of

identity wallets available, which we discuss in Sec-

tion 3. Each of these wallet projects focuses on dif-

ferent aspects such as usability or security and privacy

of the stored data.

An identity system should be applicable in vari-

ous ﬁelds and also support usage of sensitive services

such as eGovernment or online banking. In order for

https://ec.europa.eu/cefdigital/wiki/pages/viewpage.

action?pageId=262505734, Accessed: 2021-02-10.

https://ec.europa.eu/cefdigital/wiki/display/

CEFDIGITAL/EBSI, Accessed: 2021-02-10.

Abraham, A., Schinnerl, C. and More, S.

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance.

DOI: 10.5220/0010542801370148

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 137-148

ISBN: 978-989-758-524-1

137

the SP to have enough trust and guarantees in the au-

thentication data to accept an identity, a high level of

assurance (LoA) is required. The European eIDAS

framework (Commission, 2015) deﬁnes LoA in three

levels: low, substantial, and high. Each of these LoA

speciﬁes different requirements and for LoA high, the

requirements are the strictest and most challenging to

fulﬁll but also provide the most assurance in the data.

Having a digital identity that achieves high LoA ben-

eﬁts both users and Service Providers (SP): Users can

use their digital identity for a wider range of services,

while SPs have a high certainty that the identity data

are correct and correspond to the related person. This

enables the use of an identity system for use-cases and

sensitive services such as an ID card on the mobile

phone, a passport or driving license. While traditional

identity systems already achieve LoA high, at the mo-

ment none of the available SSI wallet solutions is ca-

pable of reaching the LoA high.

Contribution. In our paper, we tackle this issue

by being the ﬁrst work that proposes a generic con-

cept enabling a mobile phone based identity wallet to

achieve the LoA high. The proposed architecture can

be used by implementers of existing wallets to achieve

this highest LoA. A SSI wallet supporting the LoA

high provides beneﬁts such as increased trust in the

identity data. This furthermore enables use of a SSI

for sensitive services such as eGovernment or other

services which require high quality of identity data.

Our contribution consists of four main parts:

(I) Evaluation of LoA Requirements. To deﬁne

the requirements for a mobile wallet implementation

in order to achieve LoA high, we evaluate the rele-

vant standards related to LoA, namely ISO 29115 (In-

ternational Organization for Standardization (ISO),

2013) and the eIDAS implementation act (Commis-

sion, 2015). Based on this evaluation, we deﬁne seven

system requirements, which we use as a basis for de-

signing our architecture. These requirements can also

be used to evaluate other wallet implementations.

(II) Wallet Architecture. Based on these require-

ments, we design a generic architecture of a wallet

that reaches the LoA high. Components of this archi-

tecture were selected through an assessment of soft-

ware and hardware solutions that meet those require-

ments. The resulting architecture uses a trust (TSP)

as IdP to register the (de-central/sovereign) SSI, en-

suring no in-person registration is required while still

complying with LoA high requirements. Our wallet

architecture utilizes the secure element of the mobile

phone as well as a second key on a FIDO2 hardware

token, which introduces two strong factors in addi-

tion to the temper-resistant key protection required to

fulﬁll the LoA requirements. By building on exist-

ing SSI standards, we ensure that our architecture is

compatible and thus useful for existing wallet imple-

mentations as well.

(III) Demonstrator Implementation. To show

the feasibility of our architecture and its practicabil-

ity, we implement a proof of concept (PoC) wallet for

iOS. To protect the key material and ensure user pres-

ence, we use the iPhone’s secure enclave and a Yu-

biKey as FIDO2 token. By using cryptographic accu-

mulators, our proof of concept also supports privacy-

preserving revocation of identity data.

(IV) Evaluation. To demonstrate that our archi-

tecture achieves an LoA high, we evaluate our archi-

tecture with regard to our requirements. Additionally,

we discuss the security, design decisions and other as-

pects of our work.

Outline. The rest of this paper is structured as fol-

lows: Section 2 brieﬂy introduces the building blocks

of our system. In Section 3 we discuss the related

work in this ﬁeld and give a high-level comparison

with our work. Section 4 details the architecture of

our system together with the actors, the relevant LoA

requirements, and a formal protocol description. The

implementation details of our PoC are shown in Sec-

tion 5. We conclude the paper with an evaluation and

discussion in Section 6.

2 PRELIMINARIES

2.1 Self-Sovereign Identity System

Identity management (IdM) describes the tools

and processes required to manage digital identities

throughout the whole identity lifecycle. IdM also

evolved over time (Zwattendorfer et al., 2014) accord-

ing to the needs of the ecosystem starting with the iso-

lated IdM model in which the identity provider (IdP)

and the service provider (SP) are located at the same

party. A recent IdM model describes the user-centric

model, which focuses on the user.

Self-sovereign identity (SSI) is an IdM model,

which can be seen as the further evolution of the user-

centric model. The two main beneﬁts of SSI is that

the user is in full control over their own identity data

as well as not to have to rely on a central trusted au-

thority or party.

Figure 1 depicts the main actors of an SSI sys-

tem including their interactions. The architecture of

an SSI system uses a distributed ledger (DL) to elim-

inate a central trusted authority and to distribute trust

SECRYPT 2021 - 18th International Conference on Security and Cryptography

138

Figure 1: High-Level Architecture of an SSI System.

among the network of nodes. The SSI network, con-

sisting of semi-trusted nodes, serves as a decentral-

ized public key infrastructure (DPKI). Semi-trusted

nodes are represented by organizations or companies

such as banks or universities. Thus, the network

might not be open for everyone to host a node, in-

stead, a consortium is hosting those nodes.

The actors of such an SSI system are the users

who want to use their digital identity in order to per-

form identiﬁcation and authentication, e.g., towards

online services. The issuer represents a party that is-

sues credentials like an IdP. In contrast, the veriﬁer is

the party verifying the identity data provided by the

user, which can be an SP. Notably, private informa-

tion such as private key material or personal identi-

ﬁable information (PII) are not stored on the ledger

but stored off-ledger. Only public information such

as public keys are stored on the ledger.

2.2 Decentralized Identiﬁers (DIDs)

Decentralized identiﬁers (DIDs) (W3C Working

Draft, 2019) were designed with the main purpose of

enabling SSIs. The main advantage is that for the cre-

ation of such a DID a central trusted party is not re-

quired. DIDs are URLs that resolve to an entry on the

DL, the so-called DID document.

DID documents are stored on the DL and are used

to verify the related DID. DID documents contain

three main sections: the proof purposes, veriﬁcation

methods as well as service endpoints. DID documents

also contain the public keys related to the DID. By

signing a challenge with its private key, a veriﬁer can

resolve a DID to its DID document and verify the sig-

nature with the public key of the DID document. If

the ledger in which the DID document is stored is a

consortium ledger, there might be policies on how to

those policies and on the governance of the DL, the

existence of the DID document on the DL represents

a root of trust.

2.3 Veriﬁable Credentials (VCs)

The W3C veriﬁable credential (VC) data

model (Sporny et al., 2019) deﬁnes the data for-

mat for veriﬁable information. Credentials are

identity-related information asserted for a speciﬁc

identity. The VC speciﬁcation states the mechanisms

to express those credentials online to ensure that

they are cryptographically secure, respecting privacy

as well as being machine-readable. VCs are often

used in SSI systems because of their ﬂexible and

lightweight format.

2.4 Level of Assurance (LoA)

The level of assurance (LoA) deﬁnes the level of con-

ﬁdence in digital identities when performing identiﬁ-

cation and authentication. The conﬁdence lies in as-

pects such as the protection of assets like key material,

the protection against unauthorized access or usage

and maintenance of audits and logs, besides other as-

pects (International Organization for Standardization

(ISO), 2013). This work focuses on the LoA speci-

ﬁcations ISO 29115 (Entity authentication assurance

framework (International Organization for Standard-

ization (ISO), 2013)) and the European implement-

ing regulation (EU) 2015/1502 (Commission, 2015).

These two standards were selected since our work fo-

cuses on being compliant with European standards,

with ISO 29115 representing the foundation of the

European implementation regulation for LoA.

In these standards, the LoA framework consists

of a technical and an organizational and management

part. The technical part is split into three phases: (I)

the enrollment phase, in which the identity prooﬁng

of the user and the registration is performed, (II) the

credential management phase, concerning the creden-

tial creation, issuance, storage, revocation, etc., and

ﬁnally (III) the entity authentication phase focusing

on the authentication. The ISO standards deﬁnes four

different LoA whereas the European regulation only

deﬁnes three: low, substantial, and high, where ISO

LoA 4 is equivalent to EU LoA high.

2.5 Fast Identiﬁcation Online (FIDO)

Fast identiﬁcation online (FIDO) (The FIDO Al-

liance, 2020) was founded by the FIDO alliance, an

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance

139

open industry association with the main goal to de-

velop an authentication standard aiming to get rid

of the usage of passwords. Instead, FIDO supports

many other authentication technologies such as biom-

etry factor like ﬁngerprint or face recognition, trusted

platform modules (TPMs), security tokens on USB

sticks, and more. When mentioning FIDO in this

work, we refer to the current version of the FIDO

speciﬁcations, called FIDO 2. FIDO 2 consists of

two parts: The ﬁrst part, Webauthn, is a standard-

ized API used by websites to register and authenti-

cate with hardware authenticators. A FIDO authenti-

cator can be part of external hard or software or actu-

ally being a part of the user’s device and responsible

for generating public private key-pairs. The second

part is the client-to-authenticator protocol (CTAP),

which handles the communication between a client,

such as a web browser, and the hardware authenti-

cator. We chose the FIDO protocol as a foundation

for our implementation as it allowed us to reuse exist-

ing libraries and SDKs. It also allowed us to explore

adjusting and reusing an existing standard to ﬁt our

requirements.

3 RELATED WORK

This section details the work related to our project.

In particular, we list an excerpt of SSI identity wallet

implementations, focusing on wallets that are in an

advanced development state. Nevertheless, none of

the listed identity wallet projects below achieves the

LoA high with respect to (Commission, 2015).

Our work focuses on achieving an LoA high,

which differs from the related work, since achieving

a certain LoA is not the focus of most of the projects.

Wallet Implementations. Jolocom SmartWallet

an identity wallet by Jolocom (Jolocom, 2021). This

wallet app can be used for managing identity data

where the users are in control over their own data.

Nonetheless, the focus in this wallet is not to achieve

a certain LoA.

DIZME (this is me) is a project by the trust over

IP foundation

aiming to ﬁll the gap between SSI

and eIDAS compliance (Foundation, 2021). This

project details the governance and technology utilized

to achieve certain LoA levels. Nevertheless, DIZME

achieves LoA levels up to substantial.

https://github.com/jolocom/smartwallet-app, Accessed

at: 2021-02-09.

https://trustoverip.org/, Accessed at: 2021-02-09.

Connect.Me

is a commercial wallet implementa-

tion by Evernym

. Connect.Me is a wallet focusing

on holding and sharing credentials, which utilizes se-

cure 1-to-1 communication channels for exchanging

data as well as zero-knowledge proofs to achieve se-

lective disclosure. Nevertheless, the main objective is

not to achieve a certain LoA, instead providing a wal-

let implementation that works well with the Sovrin

network and other Evernym components.

Alastria Wallet

is a wallet implementation of

Alastria(Alastria, 2021). Alastria in a non-proﬁt or-

ganization building SSI including its own distributed

Ledger network. This wallet implementation aims to

be use the Alastria network.

Research on Wallets. The work of (Dai et al.,

2021) focuses on the Trustzone

on mobile devices

to create and store cryptographic key material as well

as to perform critical operations to ensure security

and reduce attack risks. Providing tamper-resistant

storage for cryptographic key material reﬂects one re-

quirement of LoA high. Nevertheless, this work does

not address other requirements to achieve LoA nor is

the focus on achieving a certain LoA. Besides, a mo-

bile phone’s secure element might not be sufﬁciently

secure enough to fulﬁll the tamper-resistant hardware

requirement.

In the work of (Iqbal et al., 2020) lies the focus on

mobile phone-based wallets, which are applying ﬁn-

gerprint as authentication factor especially consider-

ing the usability for the elderly. The usability of soft-

ware components especially for the elderly for which

it can be harder to understand the necessary steps

when performing authentication describes an impor-

tant aspect when designing and implementing digital

wallets. The cryptographic key material in this work

is protected through ﬁngerprint veriﬁcation as well as

bind to the actual user. Nevertheless, the focus of this

work is mainly on usability considering speciﬁcally

the elderly and not achieving a certain LoA.

A speciﬁcation to evaluate aspects of SSI systems

also considering a digital wallet as storage is pre-

sented in (Naik and Jenkins, 2020). Additionally a

comparison of Sovrin

and uPort

is shown consid-

https://www.evernym.com/products/#ConnectMe, Ac-

cessed at: 2021-02-09.

https://www.evernym.com, Accessed at: 2021-02-09

https://github.com/alastria/alastria-wallet, Accessed at:

2021-02-09.

https://developer.arm.com/ip-products/security-ip/

trustzone, Accessed at: 2021-02-16.

https://sovrin.org/, Accessed at: 2021-02-16.

uPort is not Serto https://www.serto.id/, Accessed at:

2021-02-16.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

140

ering various aspects such as sovereignty, storage-

control, security and privacy besides others. This

work also evaluates the storage of sensitive data

which leads to the digital wallet.

In contrast, this work has the main focus on

achieving the LoA high and considering more than

only the tamper resistant storage requirements to

achieve the LoA high.

4 CONCEPT

This section details our proposed concept, including

involved actors, requirements, and a protocol descrip-

tion. Figure 2 illustrates the high-level architecture

including actors, phases and main process ﬂows.

4.1 Actors

Prover. A prover represents a user that wants to au-

thenticate towards a veriﬁer.

Identity Wallet. The identity wallet is software,

which can also utilize hardware like a secure ele-

ment to store key material, used on a mobile phone

to manage key material as well as the veriﬁable cre-

dentials (VCs) of the prover.

Hardware Key. This hardware key represents a

tamper-resistant hardware device in possession of

the prover where the secret key of the prover is se-

curely created, stored and used.

Registration Authority. The registration authority is

responsible for adding the prover to the SSI system

including registering the public keys. To authenti-

cate a prover, it consults a trusted IdP. The role of

registration authority can be performed by any node

in the distributed ledger network.

Identity Provider (IdP). The IdP is responsible for

authenticating the prover as well as to issue iden-

tity data for the prover. The registration authority

utilizes the IdP for authenticating the prover.

Veriﬁer. In our concept, the veriﬁer represents a ser-

vice provider (SP), like an online eGovernment ser-

vice, or a party where the prover wants to perform

authentication, for instance a police ofﬁcer.

SSI Network. The SSI network serves as decentral-

ized public key infrastructure (DPKI) in which

semi-trusted nodes host a copy of the permissioned

ledger. A consensus mechanism is used to agree on

what is added to the DL.

4.2 Requirements

This subsection states the compiled system require-

ments a system needs to fulﬁll in order to achieve

the LoA high. The requirements are the result of our

evaluation of the two relevant LoA standards: the eI-

DAS implementation act (Commission, 2015) as well

as the ISO 29115 standard (International Organiza-

tion for Standardization (ISO), 2013). These stan-

dards cover the four main phases (I) enrollment, (II)

electronic identiﬁcation mean management, (III) au-

thentication and (IV) management and organization.

We chose the two standards for evaluation over

NIST (National Institute of Standards and Technol-

ogy (NIST), 2020), since the eIDAS implementation

act plays a vital role within Europe and provides a

cross-border recognizable LoA. We evaluated ISO

29115 in addition since it provided the foundation of

the eIDAS implementation act.

After assessing the two standards, we compile the

following requirements R which have to be met in or-

der to achieve the LoA high.

R1 Binding of Identity Data to the Prover. The

identity proving used for this binding must fulﬁll

LoA high. The binding is based on a unique

identiﬁer representing the prover. The binding has

to follow nationally recognized procedures.

R2 Tamper-resistant Storage of the Key Material.

The key material used for prover authentication

must be stored in a tamper-resistant way to prevent

it from misuse or theft.

R3 Ensure the Validity of the Identity Data. The

veriﬁer must be able to verify the status of the

identity data, such as the revocation status.

R4 Authentication Mechanism. The authentication

mechanism must utilize multi-factor authentication

to strengthen the security and to prevent attacks

such as guessing, replay attacks, communication

manipulation and ofﬂine attacks.

R5 Identity Proving. The identity proving must be

based on already existing electronic identiﬁcation

means that fulﬁll the same LoA and must not be re-

peated in person.

R6 Issuance of Identity Data. It must be ensured

that the issued identity data are delivered only to the

corresponding prover.

R7 Revocation of Identity Data. The prover must

be able to revoke the related identity data used for

authentication.

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance

141

Figure 2: High-level architectural overview of our solutions consisting of its two main phases: 1. the registration phase and

2. the authentication phase.

4.3 Architecture

This subsection details our architecture, including

a description of the registration and authentication

phase as well as a formal deﬁnition of the proto-

cols. The overall architecture including its actors, two

phases and main process ﬂows is depicted in Figure 2.

Phases. This paragraph introduces the generic pro-

tocol for the two main phases, ﬁrst the registration and

second the authentication phase.

In the registration phase, the DID document of

the prover is registered on the DL. Protocol 1 shows

this phase in a formal way. To start the process, the

prover creates the necessary key material, DID, and

DID document using their identity wallet on a smart-

phone and a secure hardware token.

The prover uses their phone wallet to create key

material based on parameters provided by the reg-

istry. To achieve LoA high, the wallet creates two

key pairs: The ﬁrst pair sk

, pk

is created on the

smartphone, while the second key pair sk

uhw

, pk

uhw

is created using a special tamper-resistant hardware,

which secures the secret key and only exports the cor-

responding public key pk

uhw

. To prove that the second

key pair was actually generated on the secure hard-

ware, this hardware device also generates a key at-

testation att

uhw

for the generated key. After generat-

ing those two key pairs, the prover’s wallet uses the

two public keys pk

, pk

uhw

to generate a DID DID

(as described above) and corresponding DID docu-

ment Doc

. This DID document contains both public

keys pk

, pk

uhw

, the device attestation att

uhw

, and is

signed using both secret keys.

The registration phase continues on the registry,

which receives the signed DID document from the

prover and veriﬁes the signatures using the encapsu-

lated public keys. The registry also veriﬁes the key

attestation to ensure a proper hardware was used, and

that the key was really generated on this hardware.

The steps laid out by the WebAuthn speciﬁcation for

Registering a New Credential (W3C, 2020d) are be-

ing followed. Additionally, the certiﬁcate chain of the

certiﬁcate, which was used for signing the key attes-

tation, is build to ensure that it was issued by a trusted

certiﬁcate authority (CA).

To authenticate the prover and to obtain related at-

tributes, the registry forwards the prover to a trusted

IdP. At the IdP, the prover performs identiﬁcation and

authentication, using an existing identity system with

a sufﬁciently high LoA (for example a government

ID). After doing so, the IdP uses the prover’s identity

to obtain the identity attributes {a

, ..., a

}. Those at-

tributes are serialized into a veriﬁable credential VC

and signed by the IdP using its DID DID

IdP

’s secret

key sk

IdP

. The VC also contains the DID of the prover

DID

to link the VC to their identity. Afterwards, the

IdP encrypts the VC with the public key of the prover,

signs it again and sends it back to the registry, which

veriﬁes the signature on the encrypted VC. This way,

the registry cannot learn the sensitive identity data of

the prover. The registration phase concludes after the

registry requested to write the DID document to the

DL, and send the identity VC to the prover, who de-

crypts and stores it in their identity wallet.

In the authentication phase, the prover shows the

identity VC to a veriﬁer and proves ownership of the

corresponding DID. Protocol 2 shows the steps of this

process in a formal way..

To start this phase, the veriﬁer creates a random

SECRYPT 2021 - 18th International Conference on Security and Cryptography

142

Registration:

on prover’s wallet

1. send registration request to registry (node)

2. receive keys creation parameters params

key

3. generate wallet keys sk

, pk

← keygen()

4. request hardware key generation including

params

key

= {param

, ..., param

}

on Hardware Key

5. request prover interaction

6. generate hardware key sk

uhw

, pk

uhw

← keygen()

7. generate key attestation att

uhw

← attest(pk

uhw

)

8. returns pk

uhw

, att

uhw

on prover’s wallet

9. create identiﬁer DID

← genDID(pk

, pk

uhw

)

10. create DID document

Doc

← genDoc(DID

, pk

uhw

, att

uhw

)

11. sign DID Doc σ

Doc

← sign(Doc

, sk

Doc

← sign(Doc

, sk

uhw

)

12. send key creation response to registry including

Doc

, σ

Doc

and σ

Doc

on Registry

13. check signatures on response

veri f y(σ

Doc

, Doc

, pk

) ∧

veri f y(σ

Doc

, Doc

, pk

uhw

) = true

14. check key attestation of hardware key

veri f y(att

uhw

, pk

uhw

, pk

device

) = true

and authenticate pk

device

using trusted pk

the hardware manufacturer.

15. forwad prover to IdP for authentication

on IdP

16. processes prover authentication using existing

ID, retrieve person attributes {a

, ..., a

}

17. create VC

← genVC(A

, DID

IdP

) where

attributes A

= {a

, ..., a

}

18. generate signature σ

← sign(VC

, sk

IdP

)

19. issue VC

, σ

to registry

on Registry

20. verify signature veri f y(σ

, VC

, pk

IdP

) =

true

21. request write of Doc

to the DL

22. issue signed VC

to prover

Protocol 1: Registration Protocol.

challenge c, signs it using its secret key sk

, and sends

c, σ

together with DID

the to the prover.

The prover retrieves the veriﬁer’s public key pk

from the DL and uses it to verify the signature on

the challenge. To prove ownership of their own DID,

the prover signs the challenge using both prover keys

, sk

uhw

. Since this is only possible if the prover

is in possession of the phone as well as the secure to-

ken, and those factors comply with the stated require-

ments.

The prover sends both signatures as well as the

signed VC to the veriﬁer, which uses the DID from

the VC to retrieve the prover’s DID document. To

ensure the prover is in possession of the secret keys

corresponding to the DID, the veriﬁer then veriﬁes the

signatures on the challenge.

Additionally, the veriﬁer also checks if the hard-

ware device used by the prover is trusted, and veri-

ﬁes if the hardware key was actually created by this

device. This is checked the same way as during the

registration phase by using the attestation data from

the DL and its own PKI of trusted manufacturers. To

ensure that the VC was issued by a trusted IdP, the

veriﬁer further checks the issuer. The authentication

phase concludes with a revocation check of the DID

and VC using the DL.

If all checks passed, the veriﬁer retrieves the

identity attributes from the now trusted VC for

further processing.

Authentication:

on veriﬁer

1. create challenge c and sign σ

← sign(c, sk

)

2. send authentication request to the prover in-

cluding c, σ

and DID

on Prover’s wallet

3. request Doc

← resolve(DID

)

4. validate signature veri f y(σ

, c, pk

) = true

5. sign challenge σ

← sign(c, sk

) and σ

←

sign(c, sk

uhw

)

6. send response including DID

, σ

, VC

, σ

and σ

on Veriﬁer

7. request Doc

← resolve(DID

)

8. check DID ownership ver f iy(σ

, c, pk

) ∧

veri f y(σ

, c, pk

uhw

) = true

9. check key attestation of pk

uhw

(same as in Protocol 1, Step 14)

10. request Doc

IdP

← resolve(DID

IdP

)

11. check identity data

veri f y(σ

, VC

, pk

IdP

) = true ∧ DID

∈ VC

12. check validity status of VC

checkRevocation(VC

) = true

Protocol 2: Authentication Protocol.

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance

143

DID Creation Deﬁnition. In our proposed archi-

tecture, we deﬁne a DID creation method, based on

the DID speciﬁcation (W3C Working Draft, 2019),

to ensure that both public keys are directly linked to

each other and also to ensure uniqueness. Both of

the keys are stored on different devices, and one of

the device is a tamper-resistant hardware. Since ver-

iﬁers use the user’s DID to retrieve the required key

material needed to verify ownership proofs and cre-

dentials, we utilize our DID deﬁnition to support two

keys. We achieve this by concatenating the public part

of the mobile wallet key with the hardware public key:

genDID(pk1, pk2) = did : SSI : pk1 : pk2 (1)

The resulting identiﬁer are separated in different parts

by utilizing the colon ” : ”. The ﬁrst part is the static

string did, which represents the type of identiﬁer, de-

centralized identiﬁer (DID) in this case. SSI repre-

sents the DID method, which refers to the used ledger.

pk1 represents the public key of the mobile phone and

pk2 the public key of the hardware key.

5 IMPLEMENTATION

This section details the concrete instantiation of our

generic architecture starting with an overview of

the implemented components in Section 5.1. To

preserve user’s privacy, our implementation utilizes

accumulator-based revocation, which is detailed in

Section 5.3. Additionally, an overview of the inter-

action between the components of our demonstrator

in Section 5.2. This implementation shows the feasi-

bility of our concept.

5.1 Components

In this subsection, we detail the components of our

implementation. For the proof-of-concept (PoC), we

implement the mobile phone wallet including the us-

age of the hardware token. Additionally, the PoC

further consists of a webserver used as IdP, registry

and service provider (SP). Since our architecture and

PoC are focused on the key handling and the authen-

tication protocol, we implement this functionality and

mocked parts which are not directly in focus such as

the integration in a DL and IdP. All components com-

municate with each other using HTTPs redirects and

callbacks in the prover’s browser.

Wallet Application. For the mobile wallet, we im-

plement a mobile application for iOS 14. The wal-

let leverages the iPhone’s internal secure enclave

for generating and storing the wallet keys sk

and

. It communicates with an external hardware key

over the phone’s Lightning plug to generate and store

the second key pair and corresponding key attesta-

tion. The public keys pk

and pk

uhw

are utilized to

generate DID

and it’s corresponding DID document,

which is later transmitted to the registry.

Hardware Key. To achieve LoA high we extend the

user’s wallet with a hardware token. This hardware

token is used to generate the second key pair sk

uhw

and pk

uhw

together with a key attestation att

uhw

using

the device’s attestation certiﬁcate.

For our demonstrator, we chose the Yubikey

5Ci token

. This token was selected because of

its iPhone compatibility, it is FIDO2-licensed, and

the manufacturer offers extensive documentation and

SDK support. By using an open authentication stan-

dard instead of implementing a custom protocol we

greatly improve adaptability thanks to a variety of

available FIDO2 devices. Even if it turned out that

the Yubikey 5Ci does not fulﬁll a speciﬁc authority’s

security requirements, a different FIDO2 key could

easily be utilized. Using key attestations, every reg-

istry and SP can decide what manufacturer and device

they deem secure for their use case offering additional

ﬂexibility.

Registry, IdP and Service Provider. To simulate

the interaction of our wallet implementation with reg-

istry, IdP, and SP, we develop a server implementa-

tion of these components mocking some of the func-

tionality. These server components are developed as

lightweight go applications and perform the opera-

tions described in Section 4.3 as well as the simula-

tion of a DL.

5.2 Phases

Our concept consists of two phases. First, the regis-

tration phase in which the user creates keys and has to

proof his identity towards an IdP and ﬁnally gets the

VC issued. The second phase represents the authenti-

cation process towards a veriﬁer.

https://support.apple.com/guide/security/

secure-enclave-overview-sec59b0b31ff/web, Accessed:

2021-02-02

https://www.yubico.com/at/product/yubikey-5ci/, Ac-

cessed: 2021-02-02

SECRYPT 2021 - 18th International Conference on Security and Cryptography

144

5.2.1 Registration Phase

After initializing the registration, the wallet receives

a key creation request from the registry. This request

speciﬁes what type of FIDO2 hardware key may be

used for the SSI creation. First, the wallet forwards

the speciﬁcation to the hardware token, which creates

a second key pair (sk

uhw

, pk

uhw

). The resulting cre-

dential creation response from the token contains the

attestation response with the attestation object (W3C,

2020c) and the collected client data (W3C, 2020b).

The attestation object contains the attestation att

uhw

and the newly created pk

uhw

, among other informa-

tion. The collected client is a JSON object containing

a random challenge generated by the server, the origin

of the key creation request as well as the type of the

request.

After the creation of hardware key material, the

wallet uses the secure enclave to create the wallet key

pair (sk

, pk

), protected by facial recognition.

The resulting public keys pk

uhw

and pk

are then

combined into a DID and DID document in the fol-

lowing way: Since the two authentication methods

need to be uniquely identiﬁable within the DID doc-

ument, the ids are extended with #wallet-key and

#H5LVnEVQG... respectively. The former is simply

a hardcoded identiﬁer while the latter is the credential

id returned by the authenticator which is required for

the authenticator to be able to look up the key in its

internal storage.

Before sending the DID document back to the reg-

istry, it needs to be signed with both keys. Thus, the

wallet creates a FIDO2 credential assertion request,

which contains the credential id. Instead of the hash

of collected client data (as speciﬁed by FIDO2), the

wallet passes a hash of the DID document for signing

to the token, resulting in sig

uhw

. The second signature

sig

is created by signing the DID document hash

using the wallet key sk

. Finally, the full credential

creation response and the signed DID document are

sent to the registry.

After successful veriﬁcation of the credential cre-

ation response and signed DID document, the registry

forwards the user for authentication to the IdP.

In our implementation, the authentication with the

IdP is simulated, but in a real-world system, the IdP

would authenticate the user with means to guarantee

an LoA high. The IdP then prepares VCs using the

JSON Web Token proof format as speciﬁed in the VC

Data Model (W3C, 2020a) and signs them using its

private key sk

IdP

. Next, the IdP uses the pk

to en-

crypt the VC for the user and signs the hash of the

encrypted VC again in order for the registry to very

the signature.

Finally, the registry stores the signed DID docu-

ment and the authenticator attestation att

uhw

on the

ledger and sends the VCs to the user. The user’s wal-

let receives the VCs and stores them on the mobile

device’s local ﬁlesystem.

5.2.2 Authentication Phase

Similar to the registration, the authentication is ini-

tialized by the wallet with a request to the SP. The

SP then resolves the user’s DID contained in the re-

quest into a signed DID document by contacting the

DL. After conﬁrming that signatures on the DID doc-

ument are correct, att

uhw

is retrieved from the DID

document and veriﬁed. If it is valid and was created

by a trusted manufacturer, the SP extracts the creden-

tial ID from the DID document and responds with a

challenge in form of a credential assertion response to

the wallet.

The wallet needs to sign the challenge and the

VCs used for login with both the wallet key sk

and

the hardware token key sk

uhw

. Therefore, it forwards

the assertion response and collected client data to the

hardware key. This time, the collected client data ad-

ditionally contains a ﬁeld for the VCs to also sign

them as part of the assertion. To ensure user consent,

the user needs to approve this signature via a user

presence check by pressing a button on the token. Af-

ter signing with the hardware key, the collected client

data is also signed with the wallet key. To authorize

the secure enclave to sign the request, the user needs

to unlock the device using facial recognition.

The wallet concludes the authentication by creat-

ing a non-revocation proof for the used VCs (cf. Sec-

tion 5.3) and submits it alongside the response to the

SP.

5.3 Revocation

To ensure that the VCs used for authentication are still

valid, it is important that a veriﬁer retrieves revocation

information from the DL. Our revocation implemen-

tation is based on the work of (Boneh et al., 2019; Li

et al., 2007).

Accumulator-based revocation is a type of revoca-

tion that makes use of cryptographic accumulators. A

cryptographic accumulator is a commitment to a set

of values of a constant size. This is useful to store it

on a DL where space is limited. The accumulator can

be queried for a contained element without revealing

any of the other elements. To use it for revocation, we

make every element in the accumulator correspond to

a non-revoked VC. As the issuer revokes VCs, the ac-

cumulator is updated. If a user wants to revoke a VC,

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance

145

they need to contact the issuer to update the accumu-

lator.

Our used accumulator is a RSA-based accumu-

lator. For a given RSA group with modulus N and

generator g, let C be a set of primes. Each prime

corresponds to a VC. Further, let p

be the product

of all primes in C. Then the value of the accumula-

tor A is A = g

modN. The membership proof w

prime x, which proofs that A contains x is given by

= g

modN. The proof can be veriﬁed against A

as follows: w

modN = g

modN = A.

We refer to these prime numbers in S as validity

tails (VT). Since the VTs need to be known to be able

to compute w

, but the issuer of a VC shouldn’t be

contacted every time the VC is used, the set of VTs for

the accumulator never changes. The issuer publishes

the accumulators’ VTs in the form of a tails ﬁle to be

retrieved for ofﬂine proof creation. Each index in the

tails ﬁle corresponds to exactly one VT.

This also means that whenever the accumulator is

updated on the DL, the revoked tail indices need to

be shared on the DL. It indicates what VTs were re-

moved from the accumulator.

During the authentication phase (cf. Protocol 2),

the wallet prepares non-revocation proofs for the VCs

it needs to transmit to the SP. To achieve this, it

fetches the validity tails for the corresponding crypto-

graphic accumulators from the DL using the VC’s ac-

cumulator id. The accumulator id is contained within

the signed VCs together with the VC’s correspond-

ing validity tail. The wallet uses the validity tails cur-

rently contained within the accumulator as indicated

by the response to compute the witness.

The resulting non-revocation witnesses and the

credential assertion response containing the hardware

key signature are sent to the SP alongside the wallet

signature and the collected client data. Next, the SP

veriﬁes the signatures on the collected client data and

extracts the VCs. For each VC, it fetches the latest ac-

cumulator value from the ledger and veriﬁes that the

transmitted witness’ and validity tail’s RSA product

match its value. If that is the case for both VCs, they

are still valid (not revoked) and the authentication is

successful.

DL nodes allow fetching the validity tails of a

cryptgraphic accumulator speciﬁed within a VC to

compute the witness for a non-revocation proof. Each

of these tails contain a ﬂag indicating whether a spe-

ciﬁc validity tail is currently contained within the ac-

cumulator. In a production use-case, the tails would

not be stored directly on the ledger, but be provided

by the VC issuer. Only a bitﬁeld indicating whether

a validity tail’s inclusion state changed needs to be

written to the ledger.

6 EVALUATION AND

DISCUSSION

6.1 Requirements to Concept Mapping

This subsection details how our concept addresses the

requirements in order to achieve a LoA high. First,

we list and detail the measures M from our concept

used to meet our deﬁned requirements. Second, we

map those measures to the related requirements R,

depicted in Table 1, and show the fulﬁllment of all

requirements.

M1 Identity Proving. The identity proving de-

scribes processes how the user proves his identity

towards an authority during the registration process.

In our concept, we are re-using previously per-

formed identity proving by redirecting the prover

during the registration to an IdP for authentication.

M2 Usage of Authorative IdP. During the registra-

tion process, the prover is being redirected to a

trusted IdP for performing identiﬁcation and au-

thentication. After successfully authenticating the

prover, the authoritative IdP issues the VC contain-

ing the prover’s as well as the issuers DID with a

LoA high.

M3 Authentication at IdP. The prover performs

strong authentication towards the IdP to receive a

VC.

M4 Hardware Key. Our concept is based on a hard-

ware key stored in a tamper resistant way and fur-

ther serves as additional authentication factor (pos-

session).

M5 Hardware Key Attestation. The hardware key

utilized in this work supports key attestation. This

way, the hardware device can create a key attesta-

tion, which can further be used to verify that the

hardware key was really created on certain hard-

ware.

M6 Revocation Mechanism. Our concept provides

a privacy-preserving revocation concept where the

prover or issuer can revoke their credentials and ver-

iﬁer can check the validity of the data used during

authentication.

M7 Mobile Phone with Biometry Support. In our

proposed architecture, we utilize a mobile phone

based wallet. The wallet key is protected by Bio-

metric authentication like ﬁngerprint or face recog-

nition; this process increases the binding to the

prover. Additionally, the mobile phone itself is an-

other authentication factor (factor possession).

SECRYPT 2021 - 18th International Conference on Security and Cryptography

146

M8 Issue Encrypted VC. In our registration proto-

col, we propose that the issued VC is encrypted

for the related prover. Even though the registra-

tion authority receives the encrypted and signed VC

as proof of successfully identiﬁcation and authenti-

cation, it cannot learn sensitive identity data of the

prover.

Table 1: This table represents the mapping of requirements

R to measures M.

R1 R2 R3 R4 R5 R6 R7

M1 X X

M2 X X

M3 X X

M4 X X

M5 X

M6 X X

M7 X X

M8 X

6.2 Security Evaluation

This subsections brieﬂy summarizes the security eval-

uation of our proposed architecture. The main aspect

covered by our evaluation is that an attacker should

not be able authenticate at a veriﬁer by using a VC

belonging to someone else. Also, the veriﬁer must be

able to verify the validity of the identity data.

Identity Data Veriﬁcation. The identity data in

form of a VC are directly linked to the related prover

by including its DID into the VC. Further, the prover’s

DID is linked to the key pairs in the prover’s posses-

sion. Only after the user has performed strong au-

thentication at an IdP (trust service provider accord-

ing to (Commission, 2015)) and additionally proved

the ownership of the DID (involving both key pairs),

the DID of the prover is added to the VC and issued in

encrypted form to the prover. Also, the veriﬁer checks

the validity status of the identity data by performing

a revocation check of the VC. Additionally, since the

VC is encrypted for the prover, an attacker could not

decrypt it without having access to the private key of

the prover.

Authentication Means. The trust in the authenti-

cation means is based on multi-factor authentication:

The wallet key is protected by a biometric factor and

thus linked to the related person. Additionally, in or-

der to perform authentication, the prover has to be in

possession of the smartphone and also of the hard-

ware key. The provided VC is directly linked to the

DID and thereby to both key pairs.

6.3 Discussion

Hardware Token. One one hand, the additional hard-

ware token offers stronger trust and security in the au-

thentication method. On the other hand, an additional

device represents a hustle and usability drawback. Af-

ter our analysis, we are convinced that without this ad-

ditional tokens a LoA high cannot be achieved – even

when creating and storing the key on secure elements

on the mobile phones. The keys could be misused

when e.g. the device is rooted.

Missing Key Backup. In many cases, a drawback

of hardware tokens/keys is that they cannot be backed

up. This is also the case for other authentication

means: when loosing a physical ID card or a passport

a user has to request a new one.

Usage of Standard IdP. In our concept, the IdP is-

sues a VC for the user. Nevertheless, maybe not all

IdPs want to or are capable of issuing VCs. In this

case, it is possible to apply the work of (Abraham

et al., 2019) and simply re-use an identity assertion

and prove attributes from it. This way, our system can

be applied to almost any existing IdM system.

7 CONCLUSIONS

In SSI, identity wallets are used to store and manage

digital identity data of corresponding users as well

as related cryptographic key material. Those wal-

lets lack an LoA high, which is necessary to enable

SSI systems for advanced use-cases such as accessing

public administration services, or to establish a digital

driver’s license.

In our work, we tackle this problem by deﬁning

system requirements to achieve an LoA high. These

requirements are based on an assessment of common

LoA standards. We further deﬁned a generic con-

cept that can be used to achieve LoA high utilizing

a mobile phone-based wallet. Additionally, we im-

plemented a demonstrator showing the feasibility of

our system utilizing a privacy-preserving revocation

approach. In the evaluation, we map the measures,

provided by our concept, to the requirements to high-

light their fulﬁllment. We further performed a se-

curity evaluation of our system as well as discussed

the design decisions. Thus, our generic concept can

be utilized by e.g. other wallet projects in order to

achieve high or to use the requirements and the mea-

sures to evaluate their system.

SSI Strong Authentication using a Mobile-phone based Identity Wallet Reaching a High Level of Assurance

147

ACKNOWLEDGEMENTS

This work was supported by the European Union’s

Horizon 2020 Framework Programme for Research

and Innovation under grant agreement No. 871473

(KRAKEN).

REFERENCES

Abraham, A. (2017). Self-Sovereign Identity - Whitepa-

per about the Concept of Self-Sovereign Identity

including its Potential. https://technology.a-sit.at/

en/whitepaper-self-sovereign-identity/, Online, Ac-

cessed: 2021-02-10.

Abraham, A., H

orandner, F., Omolola, O., and Ramacher,

S. (2019). Privacy-preserving eid derivation for self-

sovereign identity systems. In Information and Com-

munications Security ICICS 2019, Beijing, China,

volume 11999 of LNCS, pages 307–323. Springer.

Alastria (2021). Alastria Builds Future. https://www.

alastria.io/en/, Online, Accessed: 2021-02-09.

Boneh, D., B

unz, B., and Fisch, B. (2019). Batching tech-

niques for accumulators with applications to iops and

stateless blockchains. In Boldyreva, A. and Miccian-

cio, D., editors, Advances in Cryptology – CRYPTO

2019, pages 561–586, Cham. Springer International

Publishing.

Commission, T. E. (2015). Commission implementing reg-

ulation (eu) 2015/1502. Online, Accessed: 2021-01-

20.

Dai, W., Wang, Q., Wang, Z., Lin, X., Zou, D., and Jin,

H. (2021). Trustzone-based secure lightweight wallet

for hyperledger fabric. Journal of Parallel and Dis-

tributed Computing, 149:66–75.

Dong, C., Wang, Z., Chen, S., and Xiang, Y. (2020). BBM:

A blockchain-based model for open banking via self-

sovereign identity. In Chen, Z., Cui, L., Palanisamy,

B., and Zhang, L., editors, Blockchain - ICBC 2020

- Third International Conference, Held as Part of

the Services Conference Federation, SCF 2020, Hon-

olulu, HI, USA, September 18-20, 2020, Proceedings,

volume 12404 of Lecture Notes in Computer Science,

pages 61–75. Springer.

Foundation, T. L. (2021). dizme. https://www.dizme.io,

Online, Accessed: 2021-02-09.

Houtan, B., Haﬁd, A. S., and Makrakis, D. (2020). A survey

on blockchain-based self-sovereign patient identity in

healthcare. IEEE Access, 8:90478–90494.

International Organization for Standardization (ISO)

(2013). ISO/IEC 29115:2013(en) Information

technology — Security techniques — Entity authen-

tication assurance framework. Online, Accessed:

2021-01-20.

Iqbal, S., Irfan, M., Ahsan, K., Hussain, M. A., Awais,

M., Shiraz, M., Hamdi, M., and Alghamdi, A.

(2020). A novel mobile wallet model for elderly us-

ing ﬁngerprint as authentication factor. IEEE Access,

8:177405–177423.

Jolocom (2021). Jolocom Decentralized identity & access

management. https://jolocom.io/, Online, Accessed:

2021-02-09.

Kondova, G. and Erbguth, J. (2020). Self-sovereign iden-

tity on public blockchains and the gdpr. In Proceed-

ings of the 35th Annual ACM Symposium on Applied

Computing, SAC ’20, page 342–345, New York, NY,

USA. Association for Computing Machinery.

Li, J., Li, N., and Xue, R. (2007). Universal accumulators

with efﬁcient nonmembership proofs. In Katz, J. and

Yung, M., editors, Applied Cryptography and Network

Security, pages 253–269, Berlin, Heidelberg. Springer

Berlin Heidelberg.

Liu, Y., Lu, Q., Paik, H., Xu, X., Chen, S., and Zhu, L.

(2020). Design pattern as a service for blockchain-

based self-sovereign identity. IEEE Softw., 37(4):30–

36.

Manski, S. (2020). Distributed ledger technologies, value

accounting, and the self sovereign identity. Frontiers

Blockchain, 3:29.

Naik, N. and Jenkins, P. (2020). Self-sovereign iden-

tity speciﬁcations: Govern your identity through

your digital wallet using blockchain technology. In

2020 8th IEEE International Conference on Mobile

Cloud Computing, Services, and Engineering (Mo-

bileCloud), pages 90–95.

National Institute of Standards and Technology (NIST)

(2020). NIST Special Publication 800-63 - Digital

Identity Guidelines. Online, Accessed: 2021-02-05.

Sporny, M., Longley, D., and Chadwick, D. (2019). W3C

Veriﬁable Credentials Data Model 1.0. Online, Ac-

cessed: 2021-01-20.

The FIDO Alliance (2020). Fast Identiﬁcation Online

(FIDO) - Speciﬁcations . Online, Accessed: 2021-

01-20.

W3C (2020a). Veriﬁable credentials data model 1.0. https://

www.w3.org/TR/vc-data-model/#proof-formats, On-

line, Accessed: 2021-01-27.

W3C (2020b). Webauthn2: Collectedclient-

data. https://www.w3.org/TR/webauthn/

#dictdef-collectedclientdata, Online, Accessed:

2021-01-27.

W3C (2020c). Webauthn2: Packed attestation state-

ment format. https://www.w3.org/TR/webauthn/

#sctn-packed-attestation, Online, Accessed: 2021-01-

27.

W3C (2020d). Webauthn2: Registering a new credential.

W3C Working Draft (2019). Decentralized Identiﬁers

(DIDs) v1.0 - Core Data Model and Syntaxes. Online,

Accessed: 2021-01-12.

Zwattendorfer, B., Zefferer, T., and Stranacher, K. (2014).

An overview of cloud identity management-models.

In WEBIST (1), pages 82–92. SciTePress.

SECRYPT 2021 - 18th International Conference on Security and Cryptography

148