SPROOF: A Platform for Issuing and Verifying Documents

in a Public Blockchain

Clemens Brunner, Fabian Knirsch and Dominik Engel

Center for Secure Energy Informatics, Salzburg University of Applied Sciences, Puch bei Hallein, Austria

Keywords:

Blockchain, Certiﬁcate, Privacy-friendly, Digital Document, Pseudonym.

Abstract:

Managing educational certiﬁcates or records of personal achievements often comes at the cost of handling

documents, loss of data or malicious counterfeits. Especially in the case of printed certiﬁcates, both the origin

and the integrity of certiﬁcates are hard to verify. Furthermore, such documents can be lost or destroyed due to

unseen circumstances. Reissuing certiﬁcates can then be cost intensive, hard or impossible, e.g., if the issuing

organization has been closed. While issuing and signing documents digitally solves some of these issues,

this still requires centralized trusted infrastructures and still does not allow for easy veriﬁcation or recovery

of lost documents. In this paper, we present SPROOF, a platform for issuing, managing and verifying digital

documents in a public blockchain. In the proposed approach, all data needed for veriﬁcation of documents and

issuers is stored decentralized, transparent, and integrity protected. The platform is permissionless and thus

no access restrictions apply. Rather, following principles of the Web of Trust, issuers can conﬁrm each other

in a decentralized way. Additionally, scalability and privacy issues are taken into consideration.

1 INTRODUCTION

Educational certiﬁcates and other records of perso-

nal achievements are still most commonly issued as

a paper document. These documents are often easy

to counterfeit, can be lost and are hard to verify. In

order to verify the correctness of such documents for,

e.g., a job application, one has to manually contact all

issuing institutions for verifying the integrity and va-

lidity of the paper document and the printed records.

Furthermore, issuing – and reissuing such paper do-

cuments in case they get lost – can be a cost and labor

intensive process. While documents can be issued and

signed digitally, this only solves some of the problems

and requires a centralized and trusted infrastructure

that has – in the past – already shown to be unreliable

in some circumstances (Durumeric et al., 2013). Ad-

ditionally, traditional digitally signed documents do

not allow for easy veriﬁcation or recovery of lost do-

cuments and especially do not support the complete-

ness feature which is introduced below.

In this paper, SPROOF, a platform for storing di-

gital documents in a public blockchain, is presented.

The work builds on the initial proposal of such a plat-

form by Brunner (2017). In this paper, ﬁrst, the ar-

chitectural building blocks of SPROOF are presented,

and second, the detailed protocol that uses a block-

chain and a distributed storage is discussed.

As a document, we deﬁne a digital ﬁle that is

granted from an issuer to a receiver, e.g., a diploma

granted from a university to a student or records of

achievements granted from an company to a custo-

mer. Such a document can represent any data that

has an issuer and a receiver. The proposed approach

uses a blockchain for decentralized, transparent, and

integrity protected management of issued documents.

The approach is fully permissionless and does not al-

low single entities to gain control over issued docu-

ments or to prevent others to verify documents. Furt-

hermore, validation is easy and can be automatized

for a large number of documents from different issu-

ers and for different subjects.

The contribution of this work is twofold: It is

shown how documents can be issued, received and

veriﬁed while being fully decentralized, permission-

less and transparent. In addition, the ability to group

related documents from the same issuer is outlined.

Scalability and privacy issues are taken into conside-

ration.

In order to issue, receive and verify documents, in

SPROOF the following roles are deﬁned:

Issuer: The issuer of a document can be a company,

an educational institution or basically anyone who

Brunner, C., Knirsch, F. and Engel, D.

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain.

DOI: 10.5220/0007245600150025

In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 15-25

ISBN: 978-989-758-359-9

wants to grant a document. The platform itself po-

ses no limitations on issuers and there is no central

third party to control issuers.

Receiver: The receiver of a documents can be a stu-

dent for an educational certiﬁcate, an employee or

even a company. Similar to issuers, there is no

control over receivers.

Veriﬁer: The veriﬁer represents anyone who wants

to view and verify the validity of documents. A

veriﬁer also wants to authenticate the identity of

an issuer or a receiver. Authentication is fully de-

centralized and follows the principles of the Web

of Trust (WoT). This role can be assumed by, e.g.,

an employer.

These participants interact via a platform for sto-

ring and managing digital documents at low cost,

with a simple veriﬁcation feature, and with a relia-

ble storage of data. We deﬁne the following desired

properties:

Decentralization: The platform is completely de-

centralized and especially allows the veriﬁcation

of data without a single trusted third party. Furt-

hermore, veriﬁcation of past documents must be

possible even if the issuing institution is not exis-

tent anymore.

Permissionless: The platform is permissionless and

thus no single entity has control over the partici-

pants. Any participant has full access and can add

new or has the possibility to revoke own issued

documents without being required to register at a

third party.

Integrated Issuer Veriﬁcation: The platform provi-

des built-in mechanisms to verify the identity of

issuers. Thus, no additional or centralized chan-

nel is needed.

Transparency: The platform is transparent and

every participant has read access to validate a gi-

ven document. Privacy of documents is preserved

by not revealing details of the receiver or sensitive

content of a digital document, such as the name,

without the consent of the receiver.

Completeness: Issuers have the ability to group do-

cuments and veriﬁers can check whether a group

of documents is complete or not, i.e., if some do-

cument are intentionally hidden by the receiver

(e.g., verifying a Bachelor’s diploma includes ve-

rifying all related courses). This can be enforced

by the issuer at the time of granting documents

and is explained in detail in Section 4.

The rest of the paper is structured as follows:

Section 2 compares SPROOF to state of the art ap-

proaches in the ﬁeld of educational certiﬁcate mana-

gement and with respect to the stated requirements.

Section 3 describes the basic building blocks of this

work and the proposed protocol. Section 4 then des-

cribes the roles and the SPROOF protocol in detail.

Section 5 conducts a security analysis of the propo-

sed protocol and Section 6 summarizes this work and

gives an outlook to future research.

2 RELATED WORK

In this section, related work in the ﬁeld of blockchain-

based digital document management is presented. Ta-

ble 1 shows a comparison of such approaches in the

ﬁeld of educational certiﬁcates. The related work

is evaluated with respect to our initial requirements,

which are decentralization, permission management,

transparency, support for integrated issuer veriﬁca-

tion and completeness, as described in the previous

section.

The University of Nicosia

was the ﬁrst (2014) to

the Bitcoin blockchain. A hash of an index document,

which contains a list of hashes of all certiﬁcates for

a speciﬁc semester is registered on the blockchain.

Their approach is decentralized, permissionless and

transparent, but does not allow for integrated issuer

veriﬁcation and for validating the completeness of is-

sued academic certiﬁcates.

The MIT Media Lab is working on a project cal-

led Blockcerts

. Their approach is similar to the one

implemented by the University of Nicosia, i.e., regis-

tering the root hash of a Merkle tree of hashes of do-

cuments on a public blockchain. This approach is de-

centralized, permissionless and transparent. The pro-

ject is not attempting to map the digital identity to the

real identity of an institution and thus does not allow

for integrated issuer veriﬁcation and validation. Ad-

ditionally, verifying the completeness of issuing do-

cuments is not possible.

By Gr

ather et al. (2018), an approach for a Life-

long Learning Passport (LLP) is presented which is

very similar to the approach of Blockcerts. Their ap-

proach is decentralized, transparent and additionally

they support a mechanism for issuer veriﬁcation. Ho-

wever, they use a hierarchical scheme for issuer accre-

ditation and therefore it is not fully permissionless.

https://digitalcurrency.unic.ac.cy/free-introductory-

mooc/self-veriﬁable-certiﬁcates-on-the-bitcoin-

blockchain/academic-certiﬁcates-on-the-blockchain/

[retrieved: August 16, 2018]

https://www.blockcerts.org/ [retrieved: August 16,

2018]

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Table 1: Comparison of related work with respect to decentralization, permission management, transparency, support for

integrated issuer veriﬁcation and completeness.

Decentralized Permissionless Transparent Integrated Issuer Completeness

Veriﬁcation

University of Nicosia 3 3 3 7 7

Blockcerts 3 3 3 7 7

LLP 3 7 3 3 7

SPROOF 3 3 3 3 3

Verifying the completeness of issuing documents is

not possible.

We are not aware of any scheme that meets all of

the initial stated requirements and, in particular, re-

solves the completeness issue in a decentralized, per-

missionless, and transparent way, which is one of the

main contributions of SPROOF.

3 BUILDING BLOCKS

This section introduces the fundamental building

blocks for SPROOF. First, the concept of public

storage and blockchain is introduced, and the advan-

tages and challenges for using such a technology are

brieﬂy discussed. Second, the principles of key ma-

nagement in HD wallets are explained. The latter is

crucial for the completeness feature.

3.1 Public Storage

By Nakamoto (2008), Bitcoin is proposed as a decen-

tralized, permanent, trustless public ledger. The pro-

posed approach is the ﬁrst to reliably solve the dou-

ble spending problem

and sets the foundations for

the concept of decentralized, permissionless append-

only databases, commonly referred to as blockchain.

In general, a blockchain can be seen as a global state

machine where updates are performed by conﬂicting-

free, authenticated transactions. Following the ini-

tial approach by Nakamoto (2008), many imple-

mentations have been proposed in recent years, also

for ﬁelds other than ﬁnancial transactions, see e.g.,

(Kosba et al., 2016; Christidis and Devetsikiotis,

2016; Knirsch et al., 2018).

For SPROOF we use a public permissionless

blockchain, e.g., Bitcoin or Ethereum (Wood, 2017a),

in order to create a platform where nobody, not even

a selected consortium, has the right to exclude data

or participants (W

ust and Gervais, 2017). SPROOF

is built on top of a public blockchain and does not

intend to develop a new blockchain for this purpose.

The blockchain is used by SPROOF in order to have

The problem that two conﬂicting transactions spend the

same funds twice.

a veriﬁable global state of ordered pieces of data in

a decentralized, transparent manner and without the

need of a single trusted platform operator. The use of

a blockchain in SPROOF comes with two main issues:

scalability and storage costs.

Blockchain implementations often come with li-

mitations on the scalability (Croman et al., 2016), i.e.,

the number of transactions and the amount of data that

can be stored or processed within a certain amount

of time. Polkadot (Wood, 2017b; Eyal et al., 2016)

proposes a strategy for solving these scalability is-

sues by decoupling the consensus architecture from

the state-transition mechanism. This means that all

data is accepted to become part of the blockchain, i.e.,

the data is stored and distributed, but the semantics

of that data and thus the actual validity are processed

independently and off-chain. For SPROOF we only

need the blockchain to register chronologically orde-

red pieces of data and thus the consensus is built off-

chain by processing data with a publicly known rule

set separately, the SPROOF protocol.

Storage on a public blockchain is often limited in

terms of size (e.g., 80 Bytes of data in Bitcoin) or ex-

pensive (Unterweger et al., 2018). To avoid this pro-

blem, SPROOF only adds hashes of data to the block-

chain within a transaction. The corresponding raw

data is then stored in a distributed hash table (DHT).

Data stored in such a DHT inherits the immutability

and ordering property from the blockchain if a cryp-

tographically secure hash function is used to calculate

the hash that is sealed in the blockchain. In order to

create a fully decentralized platform, also the DHT

needs to be managed in a decentralized way. For ex-

ample, established DHTs such as IPFS (Benet, 2014)

or Swarm

can be used.

Blockchains use public-private key cryptography

(Difﬁe and Hellman, 1976) to represent a user and

to sign transactions. The public keys can be seen as

pseudonyms, because they can be created ofﬂine and

without the need of an identiﬁcation process. Howe-

ver, this does not provide full anonymity, since public

blockchains are transparent. If an attacker knows that

a pseudonym is linked to an identity, the attacker also

http://swarm-gateways.net/bzz:/theswarm.eth/ [retrie-

ved: August 23, 2018]

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain

has the possibility to see all transactions which have

been recorded in the blockchain since the beginning

and are linked to that pseudonym (Reid and Harrigan,

2013). A solution to this traceability problem is to

generate a new key pair for each transaction, hence

to use an address only once. One method to gene-

rate keys out of a single seed is explained in the next

section.

3.2 Key Management

In most blockchains, users are represented by a

unique ID derived from a public-private key pair

using the Elliptic Curve Digital Signature Algorithm

(ECDSA) (Johnson et al., 2001). In order to solve

the traceability problem, a new key pair for each tran-

saction is created. A key derivation function (KDF)

is therefore used to derive one or more private keys

from a single password

, master key or a pseudo

random number, a so-called seed S. In the following,

a method to deterministically derive hierarchically

structured pseudorandom public-private child keys

),(Q

),... ,(Q

) out of a single master

key pair (

d), is explained and illustrated in Figure

1. Each child key can be used as a new master key,

hence it is possible to build an inﬁnite hierarchical

tree. This concept is called a hierarchical determinis-

tic (HD) wallet.

(

, d

) (Q

, d

)

Seed

. . .

Figure 1: Representation of a HD wallet, where child key

pairs (Q

),. . .,(Q

) are derived from a parent key

(

d) and a seed S.

The ECDSA is based on (the assumed hard-

ness of) the elliptic curve discrete logarithm problem

(ECDLP), which is denoted as follows: E(K) deno-

tes an elliptic curve over a ﬁeld K. A generator of

the elliptic curve is referred to as P ∈ E(K) with an

order p. These parameters are publicly known. With

the private key d ∈ K it is easy to calculate the pu-

blic key Q ∈ E(K), which is a point on the elliptic

curve, using the formula Q = dP. Recovering d by

only using Q and P constitutes breaking one instance

of the ECDLP. Although there exists no formal proof,

the ECDLP is commonly assumed to be hard to in-

vert if the underlying elliptic curve is properly chosen

(Johnson et al., 2001).

The KDF of an HD wallet uses a cryptographi-

cally secure hash function H (·) which maps an index

i and a public key Q ∈ E(K) to an element of K. The

Deriving a key from a password is not recommended

(Vasek et al., 2016).

index is the number for the child key pairs (Q

which is calculated as follows:

d + H (i,

Q) (mod p) (1)

= d

P (2)

One of the main properties of HD wallets is that

each child public key Q

can be calculated without

using (and needing to know) a private key, by

Q +

H (i,

Q)P. This is called master public key property.

A known vulnerability of HD wallets, however, is

that it is possible to calculate the master private key

d with the knowledge of the master public key

Q and

an arbitrary child private key d

, by using the derived

formula

d = d

− H (i,

Q)( mod p). This vulnerability

can be bypassed by allowing so-called hardened child

keys, where also the public keys are derived from the

master private key, instead of the master public key.

Such keys lose the master public key property. Anot-

her approach for HD wallets that tolerates key leakage

is presented by Gutoski and Stebila (2018).

In SPROOF, HD wallets are used to derive key

pairs out of a single seed to generate pseudonyms,

which are then used for receiving documents. The

use of multiple pseudonyms allows to release only a

selected subset of documents to a veriﬁer.

4 SPROOF

In this section, we describe SPROOF, a decentrali-

zed, permissionless, integrity-protected and transpa-

rent platform for granting, storing and verifying di-

gital documents. There are three basic roles in the

upkeep of SPROOF: issuer, receiver and veriﬁer.

For the communication between the users repre-

senting these roles, two distinct channels are needed:

a public and a private one. The public channel is used

for publicly available data that is stored on a block-

chain, i.e., the issuing of a document. The private

channel is needed to transfer non-publicly available

and direct personal or sensitive information required

for issuing and verifying documents.

Any information sent over the public channel is

denoted as an event. Events are the only way to

add information to the publicly available data set of

SPROOF. Events are signed by the issuer and are sea-

led and integrity protected with the help of the block-

chain and a DHT.

In the following, we ﬁrst describe the processes to

create an issuer, then ways to trust an unknown issuer,

the generation of a privacy-friendly representation for

receivers and ﬁnally, necessary steps to verify a docu-

ment.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

4.1 Issuer

The role of an issuer represents any organization or

person who wants to grant documents, e.g., a univer-

sity. Issuers need to be publicly known, trustworthy

and veriﬁable.

In order to create a new account, an issuer esta-

blishes a public-private key pair. The public key is

the representation of the issuers public proﬁle P

SPROOF and the private key is needed to sign events

triggered by the issuer. The key pair itself provides no

information about the organization or person behind

and is thus pseudonymous. However, issuers need to

be identiﬁable and therefore P

needs to be linked to

the issuers organization. This can be done by adding

a new E

Identity Claim

event. This event includes all ne-

cessary data to address the issuer, e.g., the name of the

company or organization. Since the platform is per-

missionless and decentralized there are no restrictions

for generating such identity claims and there is no sin-

gle trusted third party to verify the correctness of the

provided claims. To increase the trustworthiness of an

issuer, additional E

Identity Evidence

events can be provi-

ded. These events, also created by the issuer, pro-

vide additional evidence by connecting the SPROOF

account with already established central trusted plat-

forms, e.g., social media accounts or known public

key infrastructures. To link a social media account,

the issuer needs to add an E

Identity Evidence

event in-

cluding a reference to a publicly accessible message,

e.g., a post in an online social network, which con-

tains P

. To link an X.509 certiﬁcate, the issuer needs

to add an E

Identity Evidence

event including the certiﬁ-

cate and a signature over P

created by the conﬁrmed

private key of the X.509 certiﬁcate. Note that this pro-

cess is possible for all types of PKI certiﬁcates. This

allows to connect several, already established central

trusted infrastructures, to P

. There is no limitation in

the number of E

Identity Evidence

events, hence an issuer

can add multiple E

Identity Evidence

events to strengthen

its P

While the methods to increase trustworthiness of

an issuer described above are based on central trusted

authorities, this is used as bootstrapping to build a

decentralized conﬁrmation network which borrows

concepts from the WoT (Caronni, 2000). In a WoT

others must be able to conﬁrm the identity of the

issuer, by sending a E

Conﬁrm

event. The purpose of a

conﬁrmation is that the sender veriﬁes the receivers

identity claim. Conﬁrmations are linked to the iden-

tity claim that was added last. This is to rule out the

possibility of an issuer to maliciously rename itself

after collecting some conﬁrmations. Before an issuer

conﬁrms another issuer it needs to verify P

and the

provided identity claim.

This can be done based on the identity evidence

events or also outside SPROOF, e.g., during a perso-

nal meeting. This means that – in return – an issuer

may lose its reputation if it conﬁrms a fake issuer. A

conﬁrm event contains a boolean value, either a posi-

tive or negative trust indicator and arguments to jus-

tify the decision. Conﬁrmations can thus be used to

create networks of issuers. Given such a network, ne-

wly added issuers can quickly gain reputation by a

conﬁrmation from a well-known and established is-

suer. As an example, consider a network of univer-

sities. While a newly established university sets up

relationships with well-established institutions for re-

search and teaching collaborations it can – in the same

way – gain conﬁrmations in SPROOF after a while.

Once one or more major institution conﬁrmed the in-

tegrity of the new university, this sets up a WoT.

4.2 Receiver

A receiver of a document is, analogously to an is-

suer, represented with a public key. This public key

is used together with the corresponding private key

to prove the ownership of a document to a veriﬁer.

Reusing the same pseudonym for all documents that

a receiver gets would lead to the receiver being only

able to share all documents ever received at once to

a veriﬁer, which would not be privacy-friendly and

also impractical for the receiver. Once a third-party

knows the pseudonym, it would be able to view all

documents issued in the past and also all future ones.

To avoid this traceability problem, fresh pseudonyms

can be created for each document exploiting the pre-

viously presented properties of HD wallets. Note that

only leaves of the pseudonym tree should be used

for receiving a document. By doing so, the privacy

is preserved by the fact that it is practically impossi-

ble to invert a cryptographically secure hash function.

Therefore, it is not possible to calculate parent pseu-

donyms by knowing the corresponding child pseudo-

nyms.

As shown before, the public-private key pairs are

deterministically generated out of the random seed S

using a HD wallet K

, as described in Section 3.2.

This seed is the main secret and is needed for recove-

ring all derived pseudonyms.

Using K

, the receiver is able to generate child

pseudonyms P

,. .. ,P

. Each of those pseudonyms

can be used as a new master key for further sub-

pseudonyms for a speciﬁc issuer. A pseudonym is

shared with an issuer using the private channel. From

this pseudonym, the issuer is able to generate further

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain

sub-pseudonyms by using the master public key pro-

perty of HD wallets. Note that this can be done wit-

hout revealing any information about the correspon-

ding private keys.

The ability to derive sub-keys enables further fea-

tures, e.g., if an issuer wants to link a document which

has dependencies to other already issued ones. This

can be the case for a series of educational certiﬁca-

tes that build on each other, e.g., required courses for

getting a bachelor’s degree. Given a parent pseudo-

nym, all descendants are veriﬁably connected to this

parent. If, for instance, pseudonym P

, see Figure 2,

represents a Bachelor’s diploma, all sub-pseudonyms

including P

,. .. ,P

, which may represent particu-

lar courses, are permanently and publicly linked to

the Bachelor’s diploma. We call this property forced

completeness, since it can be enforced by the issuer

and cannot be hidden. Note that a receiver can still

share documents P

,. .. ,P

separately and indepen-

dently and without revealing the parent pseudonym

and thus the corresponding document. If a receiver

shares more than one pseudonym that are used for

documents issued by the same issuer, which can be

avoided by sharing a pseudonym on a higher level of

the pseudonym tree, the veriﬁer can conclude that the

receiver shows an incomplete information. This is, to

the best of our knowledge, a feature that is unique to

SPROOF.

The concept of completeness is shown in Figure

2, where the privacy and completeness property are

indicated by arrows. Privacy is provided bottom-up,

whereas completeness is achieved top-down.

Seed

. . .

Privacy

Completeness

Figure 2: Pseudonym tree with derived keys and documents

in the leaves. Completeness is achieved by a unique, easily

veriﬁable path from the top to the bottom and privacy is

achieved by the impossibility to retrieve parent keys from a

given leaf key.

Note that the pseudonym itself contains no infor-

mation about the real identity of the receiver, e.g. the

name of the person. However, a mean of linking a do-

cument to the real identity of the receiver needs to be

established. Otherwise, receivers may collaborate and

share documents among each other by sharing private

keys of their pseudonyms.

To link a document to the real identity of a recei-

ver, the receiver has to create a ﬁle including identi-

ﬁcation data, denoted as ID

. The data contained in

this ﬁle must be enough for the issuer – and all pos-

sible veriﬁers – to determine the real identity of the

receiver.

One approach to create ID

is to copy the infor-

mation printed on an ID-Document, i.e., name, date

of birth, etc., or by use of any other trusted third party.

Another way is to use a machine readable code of

an ID-Document, an image of a passport, or a ﬁnger-

print. To protect the privacy of the receiver, only the

hash reference of ID

is added to the document. Gi-

ven the cryptographic hash reference of some data,

it is practically impossible to reconstruct the original

data. However, cryptographic hash functions are de-

terministic, hence an attacker who holds a copy of,

knows or guesses the identiﬁcation data of the recei-

ver is able to calculate the hash value and thus disc-

lose information about the receiver. To avoid this vul-

nerability, a salt is added to ID

, to obfuscate the hash

reference (Gauravaram, 2012). If we use the same salt

value for all hash calculations, the traceability pro-

blem arises again because of the resulting hash value

being the same for all documents. Therefore, different

salt values need to be generated for each document.

To reduce the risk of losing the salt values a hierar-

chical deterministic generation function is used. The

seed to generate the master salt S

is S||sufﬁx where

sufﬁx is a publicly known ﬁxed phrase, || denotes a

concatenation and S is the same seed as used for the

generation of K

. The salt value for a speciﬁc child

pseudonym in the pseudonym tree is recursively cal-

culated by hashing the parent salt concatenated with

the child’s index.

Note that the salt value can be seen as a secret nee-

ded for disclosing the identiﬁcation data on a (other-

wise publicly visible) document. This value should

not be publicly available, since otherwise a veriﬁer or

adversary is able to detect all documents by knowing

4.3 Document

In this section the processes to create and add a do-

cument to SPROOF is described in abstract form and

an exemplary list of ﬁelds for a document and the ne-

cessary steps to grant and revoke documents are pre-

sented. Generally, in SPROOF a document is a digital

ﬁle where the public key of the issuer and the pseu-

donym of the receiver, including a salted hash of the

identiﬁcation data, is publicly known.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

4.3.1 Format

A document consists of an issuer and a receiver,

which are always publicly known. The other ﬁelds

like title, description, evaluation, expiry dates, etc.

can either be public or private. For the private ﬁelds

of the document the issuer just adds a salted hash re-

ference of the private information. Salt values are

freshly generated, like that one used for the identi-

ﬁcation data. The corresponding raw data is then in

the hands of the issuer and the receiver only. To allow

the veriﬁer to validate the private part of the docu-

ment, the receiver needs to share the corresponding

raw data with the veriﬁer over a private channel. This

allows the veriﬁer to recalculate and compare the hash

to the one in the document. Also, hybrid methods are

possible where, e.g., the title and the description is

public, but the grade is hidden in the private part.

4.3.2 Grant Documents

In order to add a document to SPROOF, the receiver

has to register at an issuing institution. For this pur-

pose, the receiver chooses a master pseudonym P

which has not already been used by another issuer

and which represents a new leaf in the pseudonym

tree. The receiver then needs to transmit the iden-

tiﬁcation document ID

, P

, and the corresponding

master salt SALT

for the pseudonym P

over a pri-

vate channel to the issuer. The issuer has to verify if

matches to the real identity of the receiver and

check if P

is not already used as receiver for a do-

cument. Once this process is completed, the receiver

is registered at an issuer. Furthermore, the receiver

permits the issuer, by sharing its pseudonym, to de-

rive new sub-pseudonyms and the corresponding sal-

ted hash value of ID

to grant documents. With this

approach the issuer is able to decide the ordering and

structuring of its issued documents by deriving new

sub-pseudonyms out of the shared master pseudonym.

The completeness feature can thus be enforced at the

time of granting documents. A veriﬁer can later check

the set of all documents granted to a given pseudo-

nym and all derived sub-pseudonyms. The veriﬁer

can thus be sure that no document were hidden by the

receiver. Documents are granted and stored using the

Grant Document

event. This is illustrated in Figure 3.

4.3.3 Revoke Documents

Documents are not always valid for an unlimited pe-

riod of time. Sometimes an expiration date is sufﬁ-

cient, e.g., for a ﬁrst aid course or a driving license.

Additionally, an issuer may also decide to revoke a

Receiver Issuer SPROOF

, ID

, SALT

Verify registration

Grant and store document

Notify about granted document

Figure 3: Process for granting a document in SPROOF. The

receiver registers at the issuer and passes the pseudonym

which should be used for the new document. The issuer

veriﬁes the registration and grants a new document.

document, e.g., when it detects plagiarism in a gra-

duation paper or for other reasons. Therefore, an is-

suer which grants a document has the possibility to re-

voke it at a later point in time. This is done by adding

an E

Revoke Document

event, which only the issuing insti-

tute is allowed to do. This event includes the hash of

the document, and a reason to justify the revocation.

The E

Revoke Document

event is appended to the public

storage and therefore available and transparent to all

veriﬁers.

4.4 Events

Events are the only way to add information to

SPROOF and they are sealed in a public blockchain.

In this work, only issuers are allowed to add events.

The reason is that adding an event requires a tran-

saction on a blockchain. Adding a transaction to a

blockchain usually comes at the cost of at least a

fraction of cryptographic tokens. We assume that is-

suers are willing to buy some tokens, but receivers

may not. To be considered as valid, each event needs

to follow speciﬁc rules, as described in Section 4.1.

Invalid events are ignored. Note that due to the de-

coupling of the consensus mechanism of the block-

chain from the SPROOF protocol, invalid events may

become part of the blockchain data, but are not consi-

dered by SPROOF users. Therefore, the publicly avai-

lable data set of SPROOF is a chronologically ordered

list of valid events. A blockchain node only needs to

check if the blockchain transaction is valid and does

not need to validate if the corresponding data repre-

sents a valid SPROOF event. This reduces the costs

for a transaction to the blockchain.

Since storage space on a blockchain is often limi-

ted and expensive, only the hash reference of data is

sealed into a transaction. Adding a new transaction

for each event would imply that an issuer, which

wants to grant n documents, also needs to add n tran-

sactions. This is inefﬁcient and expensive. Therefore,

events are combined into a chronologically ordered

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain

list and the hash reference of this list of events is then

registered into a single transaction, as illustrated in Fi-

gure 4. The issuer has to sign this transaction, inclu-

ding the hash reference, and add it to the blockchain

as part of a transaction. Once the transaction is in-

cluded and conﬁrmed, it is traceable and authentic to

the issuing institute, integrity-protected and publicly

readable.

Issuer

Event 1

Event 2

. . .

Event n

eaf6...a1d7

Blockchain

DHT

create

calculate

store

sealed

Figure 4: For adding events to SPROOF, one or more events

are collected and written to a DHT. The hash reference of

that DHT entry is then sealed in the blockchain and thus

publicly visible to all participants.

At this point, only the hash reference of events is

sealed in the blockchain. The corresponding raw data

is stored in a DHT, where the sealed hash value is

used to address the raw data. The issuer has to ensure

that the raw data is available and complete. A regis-

tration of events in the blockchain that does not pro-

vide the raw data is transparent visible to all veriﬁers

and would therefore damage the reputation of the is-

suer. A transaction that is considered for the SPROOF

data set is always sent to the publicly known SPROOF

blockchain address. Therefore, for validation purpo-

ses, a veriﬁer only needs to consider transactions sent

to this address.

4.5 Veriﬁcation

Transactions in SPROOF can be validated by practi-

cally anyone in the world. For this purpose, a veri-

ﬁer needs to iterate over all transactions in the block-

chain that are sent to the SPROOF address. The veri-

ﬁer then downloads the corresponding raw data from

the DHT. After that, the veriﬁer is able to execute

each event of the SPROOF protocol and check if it is

valid and should be added to a local database. The

database represents the precalculated global unique

state of SPROOF. Note that this includes also revo-

cation events for documents. Additionally, this data-

base can then be used to view and validate documents

and to authenticate issuers and receivers. This client-

side validation process can be done programmatically

on a trusted computer that is controlled by the veri-

ﬁer. Since hashes can be assumed to be collision free

(Damg

ard, 1988), the data stored in the DHT is im-

mutable. Changing the raw data would results in a

different hash reference, not matching the one sealed

in the public blockchain.

4.5.1 Receiver

The veriﬁer can validate a receiver by two different

approaches. In both approaches, the receiver has to

share a pseudonym P

with the veriﬁer. Using P

, the

veriﬁer is able to ﬁnd all documents that are granted

to P

or any descendants of P

. In the ﬁrst approach

the receiver remains anonymous, whereas in the other

the receiver has to disclose ID

. Both approaches are

described below.

For the anonymous approach, the veriﬁer has to be

convinced by the receiver to be in possession of the

private key of a pseudonym P

. For this purpose, the

receiver creates a veriﬁcation document, which inclu-

des the following ﬁelds (Veriﬁer Name, Blockhash,

) and is signed using the private key that belongs

to P

. This document is shared with the veriﬁer via

a private channel. The veriﬁer is now able to check

if the provided signature matches to P

and has to

check if the signed Veriﬁer Name is correct. The

Blockhash acts as a decentralized timestamp to detect

outdated signatures. This needs to be done in order

to reduce the risk of an attacker for reusing the ve-

riﬁcation document. With this information the veri-

ﬁer can conclude that the receiver knows the private

key of P

, that all documents granted to any deriva-

tion path of P

belong to the receiver and furthermore

the veriﬁer knows the minimum age of the signature

by comparing the Blockhash. Considering that recei-

vers may cooperate and share pseudonyms, it is not

always enough to verify a receiver without identiﬁca-

tion. For the approach where the receiver discloses

the used identiﬁcation data, the receiver shares ID

SALT

and P

with the veriﬁer. With SALT

and ID

the veriﬁer is able to calculate and validate the obfus-

cated hash values of the identiﬁcation data for all do-

cuments granted to P

. Finally, the veriﬁer needs to

crosscheck ID

with an ofﬁcial ID-Document to see

if it matches to the real identity of the receiver.

4.5.2 Issuer

To decide if an issuer is trustworthy, a veriﬁer can

check the publicly available E

Identity Evidence

events

and decide whether the provided information is suf-

ﬁcient to trust an issuer P

. Additionally, the linked

X.509 certiﬁcates can be veriﬁed. In case that the

Identity Evidence

events are insufﬁcient, another way is

to use the conﬁrmation network to ﬁnd a path from a

known trustworthy party to the issuer.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

4.6 Combine Issuer and Receiver

In Section 4.1, the process for issuers to create a pu-

blic proﬁle is described. This process is not limited

to issuers, but also allows receivers to create a public

account where the receiver has the possibility to disc-

lose privately received documents and attach them to

their public proﬁles. With the use of HD wallets it is

possible to generate, out of a single seed S, multiple

hierarchically structured public-private key pairs. The

ﬁrst child can be used as the representation for issuers

to grant documents and by receivers to publish docu-

ments. The second child can be used as the master

key for possible pseudonyms, which is illustrated in

Figure 5.

Public

Private

Seed

. . .

Figure 5: A SPROOF account can be split into a public and

a private part. While the public part is used for granting and

receiving documents, whereas the private part is used as a

master key for new pseudonyms.

To publish a privately received documents to a

public proﬁle two signatures are needed. One from

the receivers pseudonym and one from the public ac-

count. The second signature is implicitly provided by

adding the transaction to the blockchain. This is done

by triggering an E

Link Document

event.

4.7 Summary

In this section, the processes for generating issuers,

receivers and processes for granting and revoking do-

cuments were presented. The platform is permissi-

onless and therefore provides, for issuers, a decen-

tralized way to add identity claims for bootstrapping

accounts. Necessary data to verify the issuer and the

document is publicly available without any read re-

strictions. A privacy-friendly way to generate pseu-

donyms and link identiﬁcation data of a receiver to

a publicly accessible document has been shown. The

generation of pseudonyms enables the platform to ful-

ﬁll the completeness property. Combining events al-

lows to add data to the blockchain in a scalable way.

5 EVALUATION

In this section the SPROOF protocol is evaluated with

respect to maliciously acting issuers, receivers and ve-

riﬁers. Additionally, general attacks to the SPROOF

platform are considered.

A malicious issuer may create a fake proﬁle. The-

refore the fake issuer sets up a E

Identity Claim

event and

adds numerous E

Identity Evidence

events to strengthen its

fake proﬁle. By consistently creating fake social me-

dia accounts, a fake website, etc. this makes it hard

to identity a true issuer from a fake one. However

the core idea of the WoT is that multiple established

and trusted issuers conﬁrm the identity of new issu-

ers. A veriﬁer of a document, attempting to validate

the identity of the issuer, can identify such fakes, by

starting at one or more known trusted issuers and fol-

lowing the paths to the fake issuer. In case there exist

no paths or a majority of negatively rated conﬁrma-

tions only, these are strong indications that the docu-

ment has been created by a fake issuer. Additionally,

a veriﬁer can validate the X.509 certiﬁcates linked to

the issuer. In case that these X.509 certiﬁcates are in-

valid, linked to non-ofﬁcial websites or not available,

this are also strong indicators of a fake issuer. Issuers

may revoke documents with a malicious intent and

without justiﬁcation, or publicly release identiﬁcation

data of documents it has previously issued. While this

is a general problem, it would only affect the speci-

ﬁc documents from this issuer and not the receivers’

whole accounts.

A malicious receiver may attempt to collaborate

with other receivers to share pseudonyms and thus

collecting documents that were issued to another re-

ceiver. However, this is prevented by adding identi-

ﬁcation data to documents, which uniquely identiﬁes

a speciﬁc receiver, e.g., a ﬁngerprint. Note that this

data is not publicly stored in the blockchain, but only

the hash reference is linked to a document in order to

protect privacy. In case the receiver wants to remain

anonymous at the time of veriﬁcation such an attack

is feasible, however it is up to the veriﬁer to allow an

anonymous veriﬁcation at the risk of shared pseudo-

nyms.

A malicious veriﬁer may reuse or publish received

documents and the corresponding identiﬁcation data.

In the process of sharing a document to a veriﬁer the

Veriﬁer Name and the Blockhash are contained and

signed by the receiver. Reusing a document is practi-

cally impossible since this would require to change

the Veriﬁer Name and the Blockhash within the signed

data. While publishing received documents cannot be

prevented in SPROOF it would only affect the speciﬁc

documents shared with this malicious veriﬁer.

Malicious attackers may add a huge amount of va-

lid or invalid events at once or seal a hash reference

where the raw data stored in the DHT is not availa-

ble or signiﬁcantly large. However, adding a tran-

saction to the blockchain is only possible with a sig-

nature which is linked to a public key. Adding invalid

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain

events or hash references where the raw data is not

available will downgrade the reputation of an issuer.

A timeout for reading data from the DHT and a limit

for the number of events which are allowed to be se-

aled within one transaction can be used to protect the

platform from such attacks.

6 CONCLUSION

In this paper, a platform for managing digital docu-

ments has been presented. The paper proposes the ar-

chitectural building blocks and a protocol for issuing,

receiving and verifying digital documents. A block-

chain is used to seal hashes of data stored in a Dis-

tributed Hash Table and a Hierarchical Deterministic

Wallet is employed for key management. This allows

for features such as completeness, i.e., the ability to

prevent receivers from hiding certain documents. The

platform additionally sets up a Web of Trust of is-

suers and thus provides integrated issuer veriﬁcation.

In summary, the management of documents is fully

decentralized, permissionless and transparent. Future

work will focus on evaluation of the prototypical im-

plementation and explore the abilities of the propo-

sed scheme for other ﬁelds of application. Attribute-

based identiﬁcation for receivers will be integrated by

extending the SPROOF protocol.

ACKNOWLEDGMENTS

The overall support of Rainer B

ohme from the Uni-

versity of Innsbruck as the supervisor of (Brunner,

2017) and especially the initial idea of using HD wal-

lets to build pseudonym trees to enable the complete-

ness feature is gratefully acknowledged. The authors

also like to acknowledge Michael Fr

owis and Pascal

Sch

ottle for discussions about this topic. The ﬁnan-

cial support by the Federal State of Salzburg is grate-

fully acknowledged. Funding by the Austrian Rese-

arch Promotion Agency (FFG) under project number

865082 (ProChain) is gratefully acknowledged.

REFERENCES

Benet, J. (2014). IPFS - Content Addressed, Versioned, P2P

File System (DRAFT 3). Technical report, IPFS.

Brunner, C. (2017). Eduthereum: A System for Storing Edu-

cational Certiﬁcates in a Public Blockchain. Master’s

thesis, Universit

at Innsbruck.

Caronni, G. (2000). Walking the Web of Trust. In 9th

International Workshops on Enabling Technologies:

Infrastructure for Collaborative Enterprises (WET

ICE 2000), pages 153–158, Gaithersburg, MD, USA.

IEEE.

Christidis, K. and Devetsikiotis, M. (2016). Blockchains

and Smart Contracts for the Internet of Things. IEEE

Access, 4:2292–2303.

Croman, K., Decker, C., Eyal, I., Gencer, A. E., Juels, A.,

Kosba, A., Miller, A., Saxena, P., Shi, E., G

un Sirer,

E., Song, D., and Wattenhofer, R. (2016). On Scaling

Decentralized Blockchains. In International Confe-

rence on Financial Cryptography and Data Security,

pages 106–125, Christ Church, Barbados. Springer.

Damg

ard, I. B. (1988). Collision Free Hash Functions and

Public Key Signature Schemes. Advances in Crypto-

logy — EUROCRYPT’ 87, pages 203–216.

Difﬁe, W. and Hellman, M. (1976). New Directions in

Cryptography. IEEE Transactions on Information

Theory, 22(6):644–654.

Durumeric, Z., Kasten, J., Bailey, M., and Halderman, J. A.

(2013). Analysis of the HTTPS Certiﬁcate Ecosy-

stem. In Proceedings of the 2013 conference on Inter-

net measurement conference (IMC ’13), pages 291–

304, Barcelona, Spain. ACM.

Eyal, I., Gencer, A. E., Sirer, E. G., and van Renesse, R.

(2016). Bitcoin-NG: A Scalable Blockchain Proto-

col. In Proceedings of the 13th Usenix Conference

on Networked Systems Design and Implementation,

NSDI’16, pages 45–59, Santa Clara, CA. USENIX

Association.

Gauravaram, P. (2012). Security analysis of salt||password

hashes. In International Conference on Advan-

ced Computer Science Applications and Technolo-

gies (ACSAT), pages 25–30, Kuala Lumpur, Malaysia.

IEEE.

ather, W., Augustin, S., Sch

utte, J., Kolvenbach, S., Au-

gustin, S., Ruland, R., Augustin, S., and Wendland,

F. (2018). Blockchain for Education: Lifelong Lear-

ning Passport. In Proceedings of 1st ERCIM Block-

chain Workshop 2018, Amsterdam. European Society

for Socially Embedded Technologies (EUSSET).

Gutoski, G. and Stebila, D. (2015). Hierarchical determi-

nistic Bitcoin wallets that tolerate key leakage. In 19th

International Conference on Financial Cryptography

and Data Security (FC 2015), San Juan, Puerto Rico.

Springer.

Johnson, D., Menezes, A., and Vanstone, S. (2001).

The Elliptic Curve Digital Signature Algorithm

(ECDSA). International Journal of Information Se-

curity, 1(1):36–63.

Knirsch, F., Unterweger, A., and Engel, D. (2018). Privacy-

preserving Blockchain-based Electric Vehicle Char-

ging with Dynamic Tariff Decisions. Journal on Com-

puter Science - Research and Development (CSRD),

33(1):71–79.

Kosba, A., Miller, A., Shi, E., Wen, Z., and Papamanthou,

C. (2016). Hawk: The Blockchain Model of Cryp-

tography and Privacy-Preserving Smart Contracts. In

2016 IEEE Symposium on Security and Privacy (SP),

pages 839–858, San Jose, CA, USA. IEEE.

ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic

Cash System. Technical report.

Reid, F. and Harrigan, M. (2013). An Analysis of Anony-

mity in the Bitcoin System. In Altshuler, Y., Elovici,

Y., Cremers, A. B., Aharony, N., and Pentland, A.,

editors, Security and Privacy in Social Networks, pa-

ges 197–223. Springer New York.

Unterweger, A., Knirsch, F., Leixnering, C., and Engel,

D. (2018). Lessons Learned from Implementing

a Privacy-Preserving Smart Contract in Ethereum.

In 2018 9th IFIP International Conference on New

Technologies, Mobility and Security (NTMS), Paris,

France. IEEE.

Vasek, M., Bonneau, J., Castellucci, R., Keith, C., and

Moore, T. (2016). The Bitcoin Brain Drain: A Short

Paper on the Use and Abuse of Bitcoin Brain Wal-

lets. In 20th International Conference on Financial

Cryptography and Data Security (FC 2016), Christ

Church, Barbados. Springer.

Wood, G. (2017a). Ethereum: A Secure Decentralised Ge-

neralised Transaction Ledger. Technical report, Ethe-

reum.

Wood, G. (2017b). Polkadot: Vision for a Heterogeneous

Multi-Chain Framework. Technical report, Parity.io.

ust, K. and Gervais, A. (2017). Do you need a Block-

chain. Technical report, International Association for

Cryptologic Research.

SPROOF: A Platform for Issuing and Verifying Documents in a Public Blockchain