PharmaLedger – Advanced confidentiality methods

This project has received funding from the Innovative Medicines Initiative 2 Joint Undertaking under grant agreement No 853992. This Joint Undertaking receives
support from the European Union’s Horizon 2020 research and innovation programme and EFPIA.
Copyright © PharmaLedger Consortium 2020 – 2023 PharmaLedger: www.pharmaledger.eu IMI: www.imi.europa.eu
D3.6 Advanced confidentiality methods
Deliverable No D3.6
Work package No. and Title WP3 PharmaLedger Architecture and Reference Implementation
Version - Status v3.1 - final
Date of Issue 02/12/2021
Dissemination Level Public (PU)
Filename D3.6 Advanced confidentiality methods_v3.1_final
Ref. Ares(2021)7816590 - 17/12/2021

This project has received funding from the Innovative Medicines Initiative 2 Joint Undertaking under grant agreement No 853992. This Joint Undertaking receives
support from the European Union’s Horizon 2020 research and innovation programme and EFPIA.
Copyright © PharmaLedger Consortium 2020 – 2023 PharmaLedger: www.pharmaledger.eu IMI: www.imi.europa.eu
Copyright © 2020-2022, PharmaLedger Consortium
Disclaimer: Any information on this deliverable solely reflects the author’s view and neither IMI nor the European Union or EFPIA
are responsible for any use that may be made of the information contained herein.
This document and its contents remain the property of the beneficiaries of the PharmaLedger Consortium and may not be re-
used, distributed or reproduced without the expressed written approval of the PharmaLedger Coordinators, Maria Eugenia Beltran
and Daniel Fritz (Universidad Politécnica de Madrid and Novartis respectively; contact@pharmaledger.eu)
THIS DOCUMENT AND INFORMATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE

PharmaLedger – 853992 | Deliverable D3.6 v3.1| PUBLIC 3/34
DOCUMENT INFO
Authors
Authors Organisation
Sînică Alboaie RMS
Ana Balan RMS
Michael Sammet University Hospital Würzburg
Christos Patsonakis CERTH
Darlene MacDonald NVS
Nicu-Cosmin Ursache RMS
Marco Cuomo NVS
Amol Shah ABBVIE
Document History
Date Version Editor Change Status
10/01/2020 V1.0 Sînică Alboaie
Table of contents and Initial
content
Draft
26/06/2021 v2.0
Sînică Alboaie
Ana Balan
Amol Shah
Christos Patsonakis
Darlene MacDonald
Marco Cuomo
Michael Sammeth
Sebastian Dumitrescu
Nicu-Cosmin Ursache
Continuous input in sections
(Separate documents and
WP3 working streams)
Summarized and joined
together in June 2021)
Draft
30/06/2021 v3.0 Ana Balan
Review, editing and
formatting
Draft
15/07/2021 v3.0
María Eugenia Beltrán/
Cecilia Vera
Final review for submission Final
02/12/2021 v3.1
María Eugenia Beltrán/
Cecilia Vera
Reviewers comments
integrated
Final
Disclaimer: Any information on this deliverable solely reflects the author’s view and neither IMI nor the European
Union or EFPIA are responsible for any use that may be made of the information contained herein.

TABLE OF CONTENT
EXECUTIVE SUMMARY..................................................................................................................................5
1. INTRODUCTION.....................................................................................................................................6
2. STATE OF THE ART RESEARCH...............................................................................................................8
2.1. W3C DID and VC standards...........................................................................................................8
2.2. Data Sharing alternatives............................................................................................................13
3. PHARMALEDGER PLATFORM SPECIFIC RESEARCH .............................................................................16
3.1. Confidentiality methods directly obtained from the OpenDSU Architecture ............................17
3.2. Confidentiality attacks on the PharmaLedger platform .............................................................18
3.3. Ledger selection as a confidentiality method.............................................................................22
3.4. Trustless collaborations vs. the cost of auditability....................................................................26
3.5. Computation over encrypted (secret) inputs .............................................................................27
3.6. OpenDSU and use cases as choreographies. OpenDSU and ZKP................................................29
4. CONCLUSIONS.....................................................................................................................................32
4.1. Risks from excessive properties of the confidentiality methods................................................32
4.2. Future research...........................................................................................................................32
BIBLIOGRAPHY ............................................................................................................................................33
LIST OF FIGURES
Figure 1 Antagonism between user transparency and user privacy ............................................................6
Figure 2: Solid architecture with blockchain anchored hashes ..................................................................14
Figure 3 Topology of DIF Identity Hubs.......................................................................................................15
Figure 4 Encrypted Data Vaults ecosystem ................................................................................................15
Figure 5: Combination of centralized archetypes.......................................................................................24
Figure 6: Comparative of system archetype due to censorship resilience and privacy .............................25
Figure 7: Tamper resilience and auditability comparative .........................................................................25
Figure 8 Various constraints regarding auditability and trustless collaboration........................................26
Figure 9 Appropriate solution for each category........................................................................................30
LIST OF TABLE
Table 1: Summary of critiques and concerns about DID-related standards proposed by W3C.................12
Table 2 Confidentiality methods and impact for the Pharmaledger Use Cases.........................................16
Table 3: OpenDSU Confidentiality methods summary...............................................................................17
Table 4: Actor impacting confidentiality.....................................................................................................18
Table 5: types of attacks on confidentiality that are relevant in the PharmaLedger use cases.................20
Table 6: Attacks on the confidentiality measure of the OpenDSU.............................................................21
Table 7: mitigation solutions to attacks on confidentiality identified........................................................22
Table 8: generic use cases in which the concept of executing an algorithm on secret data......................27
Table 9: the privacy features of the algorithm, input and result................................................................28
Table 10: Use Case constraints regarding confidentiality and verifiability.................................................29
Table 11: Future research...........................................................................................................................32

EXECUTIVE SUMMARY
This report summarizes the research activities completed in task T3.4 (Research and identification of
advanced confidentiality methods) in order to provide best practices for supporting software
development in T3.5 (Reference Implementaton of Advanced Confidentiality Methods) [1].
In this deliverable, we documented the development research achievements regarding the PharmaLedger
blockchain platform and many of the activities required to modify and improve the prerequisite
blockchain technologies used to build the PharmaLedger platform. During this task, while implementing
the platform, a series of challenges were identified and documented. In addition, innovations regarding
smart contracts execution and changes regarding deployment of the blockchain platform were proposed.
We believe that the implementation of the use cases will generate further suggestions for improvements.
Development and research continues and provides further input for the prerequisite blockchain
technologies used to build the PharmaLedger platform.

1. INTRODUCTION
In the PharmaLedger platform architecture principles document [2], the following requirements have
been identified as necessary to consider with respect to confidentiality methods used within the
PharmaLedger ecosystem:
1. Technical implementations shall be future-proof in general and technology agnostic in particular,
such that any hard dependency on specific vendors or solutions are to be avoided when developing
the code.
2. PharmaLedger use cases shall be enabled to independently integrate any credential issuers,
decentralized identities, or any other kind of validation methods relevant in the market (also the
traditional X.509 standard).
3. Confidentiality solutions shall offer flexible approaches for discovering an acceptable compromise
between sometimes conflicting aspects, e.g., security model, privacy constraints, economical
interest of for-profit PharmaLedger participants, protection of patients and other non-profit users
against the surveillance economy, and user experience respectively the usability of the
PharmaLedger ecosystem to the different stakeholders.
Whereas requirements (1) and (2) can largely be addressed by proper system design and selection of
appropriate technologies, requirement (3) constitutes a more conceptual challenge that possibly needs
to be addressed specifically per use-case taking into consideration the respective stakeholders involved.
Here, a brief review of the key terms that we employ when describing confidentiality considerations of
digital identities is provided. As many of these terms have been adopted from social sciences and originally
describe general, subjective concepts in the real world that to date have only vaguely been defined in the
context of digital systems such as distributed ledgers, establishment of the common understanding and
usage of terms is essential.
Figure 1 Antagonism between user transparency and user privacy
Digital systems that allow users to retain most of their PII allow for a high level of privacy (left edge of the
scale), but become trust-unworthily by failing to identify participants by their real-world attributes. By
exposing PII, real-world users become transparent and therefore also trustworthy to the system (right edge
of the scale), but lack privacy. The "slider" between these two concepts needs to be adjusted to build trust
on both sides, the user side as well as the system side.
Throughout this report the use of the term "privacy" refers to the concept of protecting personally
identifiable information (PII) of users. On the contrary, "transparency" determines the degree to which
the users expose PII to the system they are using. The concept of "trust" describes the degree to which
one party (i.e., the trustor) is willing to rely on the actions of another party (i.e., the trustee). Naturally,
users of a distributed ledger are likely to build trust in the system when the preservation of their privacy

is high, whereas the systems (respectively, the other users of the ledger) increasingly trust users who are
transparent.
Obviously, the concepts of "privacy" and "transparency" are competing with each other. The objective of
a trusted environment is to create trust on both sides, i.e., between each particular user of the system
and all the other interacting persons, entities, and parties of the system. In order to achieve this goal, a
use-case specific compromise for the adjustment between "privacy" and "transparency" needs to be
found (Figure 1).
"Confidentiality" in turn includes "privacy", but also extends to the safeguarding of entrusted information
that may include trade or other secrets.
The report is structured as follows: we first review established models for handling digital identities in
distributed systems, particularly with respect to their approaches to the privacy-transparency antagonism
(Section2 STATE OF THE ART RESEARCH), before critically comparing the safeguarding methods proposed
in these models specifically to the confidentiality methods we present the so-called "OpenDSU"
architecture for the PharmaLedger Project (Section3 PHARMALEDGER PLATFORM SPECIFIC RESEARCH).
Finally, we provide a summary of the result, conclusions and a proposal for further steps to be considered
during software development in task T3.5 (Reference Implementaton of Advanced Confidentiality
Methods).

2. STATE OF THE ART RESEARCH
Over the recent years, digital systems have gradually moved away from traditionally employed central
database systems, where each organization controls the access to user data they store, and data owners
are authenticated by classic usernames and passwords. The more recent introduction of federated
identity systems enables users to verify their digital identity with a third party providing credential services
hence reducing the exposure of their personal information whilst accessing the applications of numerous
organizations.
However,concerns regarding possible data leakage and potential abuse by malicious providers of
federated identities have surfaced and as such, modern systems are moving towards more user-centric
concepts of control: verifiable credentials aim at encapsulating the minimal amount of personal data
necessary in order to "bind" a certain user to some data or transaction. As suggested by the naming,
verifiable credential schemas are designed to promote verification processes, but with ever less personal
information exposed by the users, the issues of user validation are growing complex even with elaborate
methods for verification in place.
With these new challenges also paradigms of thinking about limiting the access for potentially malicious
data controllers moves towards concerns regarding confidentiality issues that might arise from potentially
malicious users. More specifically, currently developed technologies must address the challenge of how
to create trust in a trustless digital environment, where the interacting users or entities present quasi zero
information regarding their identities.
2.1. W3C DID and VC standards
The World Wide Web Consortium (W3C) has become a major authority for researching, developing, and
establishing standards for the internet and complementary distributed systems. The degree of maturity
(from low to high) for specification proposals provided by W3C is specified as:
1. Working draft
2. Candidate recommendation
3. Proposed recommendation
4. W3C recommendation
In the context of our present research, W3C provides a "candidate recommendation" document on
distributed identities, and a "W3C recommendation" standard on verifiable credentials (VCs). In the
further subsections, we will ew these and other relevant documents in order to present an image of
current state of the art protocols.
2.1.1. Digital identities: Verification vs. Validation
In a world that is becoming more digital, access to information and services covering many aspects of life
are becoming increasingly accessible through internet platforms. To access these platforms, one needs to
transfer his/her identity to the digital world [3] in order to establish "trust" and enable interactions with
other persons and organizations across the network. However, one cannot expect to gain trust from other
actors just because they have a digital identity. In order to get trusted, the digital identity and its owner
need to go through verification and validation processes.
Verification is the process of checking that the information of the digital identity is correct and that we
are interacting with the real party that has been granted access to the respective information. Validating
is going a step further, it is acknowledging (trusting) the verified identity to access some resources in order
to cooperate. A physical credential, such as the picture on an official identity document, can be used to
verify that the document holder is the owner of the document. The document itself can be verified to see
if it is authentic. If there is still a doubt, to be able to fully validate an official identity document as the

passport and completely trust its owner, it is possible to check a government database to see if all the
information is valid.
In the same way, the owner of a digital identity can be verified and validated. To verify that the user is the
real owner of the identity, passwords (something only the owner should know) are used. To reinforce this
verification, two-factor authentication where the owner has to confirm the connection on his device
(something he has) as well three factor authentication such as biometrics (something he is) can be used.
Now, if it is not enough for an organisation to trust the owner, it is possible to verify the owner has entered
correct information for her/his digital identity profile. To do so, the organisation can ask the owner to
share supporting documents with personal information, such as a passport or a recent bill to verify
personal details e.g. name and address. However, in order to validate this information, the organisation
has to check further e.g. the government database to see if the information matches or contact the service
provider to confirm if the identity owner is one of their customers.
2.1.2. Verification and validation issues of physical and current digital identities
While the authentication part is solid, verification and validation lack smoothness. To date most digital
systems have been designed from the organisation's point of view anduser information is maintained in
the databases of all the services accessed. Not only do these practices raise concerns regarding t privacy
and protection of data asusers must create an identity per service they use, often providing the same
information and supporting documents again and again. Moreover, when identity management and
validation is controlled by a central company, users can experience difficulties interacting "freely" with
other entities as algorithms will control, to some extent, transactions and peers to transact with.
It is also challenging for organisations who have few options to verify and validate the information
provided by the user. They have often no other choice than to rely on a single source of trust that could
be corrupted.
2.1.3. Decentralized Identifiers and Verifiable Credentials Standards
In contrast to organization-centric ID management, the concept of Decentralized Identities (DIDs) has
recently been designed so that they may be decoupled from centralized registries, identity providers, and
certificate authorities. Amongst other approaches to DIDs, in particular the Self-Sovereign Identity (SSI)
model has been theorized to address the problem of digital identities, for which proofs of concept are
under active development. Based on 10 principles [4], this model is designed with the user at its core.
Distributed ledger technology (DLT), popularly known as "blockchain", allows the creation of a
decentralized and immutable registry for digital identities. Identifiers representing digital identities on
this registry are by nature decentralized. These decentralized identifiers (DIDs) can be used to represent
people, objects [5], datasets [6], etc. To authenticate as the owner of these identities, users need a
cryptographic key that is created at the registration. To support management of cryptographic keys and
seamless interaction with the network, wallets, that is light software applications in the form of browser
extensions, mobile apps or websites, make the bridge between the user and the DLT.
In this model, verifiable credentials (VC) [4] are associated with digital identities in the same way that
physical credentials are tied to identities. The difference is that VCs are designed for web environments
where it is more difficult to verify and validate the information due to the fact that digital patterns are
more easily tampered with than their biological or physical counterparts, as such, confidence in a virtual
vis-à-vis needs to be provided by complementary mechanisms. Hence, in order to bring trust in an a priori
trustless environment, VCs require to be cryptographically secure, privacy respecting, and machine-
verifiable [4].

2.1.4. Verification and validation issues of DID and VC
There are ongoing efforts [4] to standardize concepts of DIDs and VCs from the W3C organization and we
agree that it is important to continue work on these specifications in order to provide interoperable
solutions. In fact, several innovations for DID ecosystems have recently been proposed, and we are
focusing ourselves on a (novel) implementation of “digital sovereignty” for identities of physical persons
or organizations, and in addition, for objects such as data and applications.
However, these novel standards must be considered carefully. First and foremost, the proposed methods
and protocols have not been reviewed by a wide community of security/cryptographic experts. This leads
on one hand often to the development of unnecessarily complex algorithms and, on the other hand,
sometimes to algorithms only vaguely described in DID specifications, which possibly could be substituted
by well-known cryptography techniques. Critical reviews of these standards are necessary because its
absence could lead to privacy and security harm to users [7].
Particularly one point that we want to discuss in the present document is validation, as thebecause W3C
specification is very vague on this point. In addtion, the the W3C specification values privacy over
transparency. While we agree that privacy is very important, we think an “absolute” privacy is not
desirable as it makes validation strategies harder to perform on the identity owner. The absence of strong
validation strategies would make digital identity owners less accountable and would result in a loss of
trust [3] [8].
Moreover, we would rather avoid having too many standards on data models, Domain Specific languages
(DSLs) and protocols and concentrate on general purpose languages that provide more space for
developers to build solutions to their use cases more easily and to let them create custom strategies for
validation. Indeed, standards are required to achieve interoperability between all the actors of a network,
but interoperability is realized through semantics rather than through over-complex data models. The
biggest challenge for self-sovereign identities remains its general adoption, and we need a solution that
can be readily adopted by developers, enabling them to seamlessly focus on solving their specific tasks
based on self-sovereign identities.
2.1.5. DID shortcomings
Decentralized Identifiers (DIDs) as defined by the W3C standard [9], aim to provide a uniform naming
scheme for "subjects" (e.g., physical users and entities) as well as for "objects" (i.e., physical, digital, logical
things). This scheme is composed of a so-called "DID method" specifying the registry to which a DID has
been issued, and a "key" that is used to identify the DID at the corresponding registry end-point. As for
web-based resource identifiers, Universal Resource Identifiers (URIs), the W3C standard expects the
registry to permit the corresponding issuer to resolve a DID document for the given key. However, the
current lack of defining access controls in the W3C standard makes the specification even more prone to
correlation attacks [7] than traditional centralized or federated identity systems. Moreover, the W3C DID-
specifications in their current format do not enforce the privacy of any attributes attached to the
Verifiable Credentials produced by service end-points accessed via DID documents, and merely
recommend that DID documents should not contain PII.
In addtion to these technical shortcomings, another questionable concept in the W3C DID handling is
whether the unified retrieval of DIDs is necessary at all, or in other words, up to which degree the retrieval
of DID documents via centralized servers proposed by W3C actually contradicts the philosophy behind
DIDs. The W3C standard foresees that DID documents once retrieved are stored in a public blockchain,
which represents a unified and therefore central instance for querying DIDs. In many cases, however, DID
documents are provided by third-party services that function also correspondingly as identity providers.
Therefore, direct contact with these decentralized issuers seems more efficient than the excessive
redirection proposed by W3C.

2.1.6. VCs shortcomings
Verifiable Credentials (VCs) are provided according to the W3C DID specification along with the requested
DID documents and therefore rely on serialization of digital signatures they comprise. To this end, some
examples in the W3C VC specification [4] employ the Semantic Web Resource Description Framework
(RDF) format, which turns out to be problematic for serializing VCs in more than one way: (i) RDF does not
specify a syntax like XML, but "semantic" graphs that can be canonicalized and serialized in different ways
[10]; (ii) RDF lacks standardized bit-serialization as necessary for signatures [11]; (iii) W3C encourages VC
implementations [12] to detach "data proofs" (i.e., signatures) from the actual "payloads" (i.e., messages),
which paves the way for signature exclusion and signature replacement attacks [13] (McIntosh and Austel,
2005). These shortcomings stem from the conflict between implementing user privacy and the aims by
W3C to "link” data by reusing URIs as labels of nodes in the graph [14]. However, since VCs in general are
not dependent on RDF serialization, these considerations are specific to issues that may arise from the
W3C specifications for VCs.
A ubiquitous challenge for VC-based authentication systems is, in contrast, that the verification of data
ownership by checking digital signatures does not extend to the validation of the VC-presenting user or
entity, i.e. the confirmation that the presented VC actually belongs to the presenter. On the one hand VC
users could be validated by relying on documents issued by central authorities of trust (e.g., driving
license), which however would largely prevent the use of DIDs, require authenticable documents and also
involve third authorities in the validation process. On the other hand, cryptographic methods for the
remote authentication of biometric markers have been proposed [15]. However, these systems require
biometric-dependent information (helper data), which could potentially reveal significant PII from the
corresponding user [16]. There is an ongoing controversy on how to resolve the conflicts between user
privacy and user validation, with no standard yet having been settled.
2.1.7. Relevant Types of VCs and Methods for Verification
Traditionally signed VCs are usually confirmed by the verifier in four steps:
1. Locally compute the hash of a presented VC as specified by the credential schema (e.g. SHA256).
2. Resolve the VC issuer's DID and retrieve the public key.
3. Calculate the local signature from the local hash and the public key.
4. Compare the local signature to the credential signature. If there is a match the verification is
successful; if there are discrepancies, the verification fails.
In contrast Zero Knowledge Proof (ZKP)-enabled credentials minimize the user information exposed to a
system. In this case, a prover provides VCs as well as a signature over the original VC content. This
signature can be re-computed by the presenter based on the VCs, to give proof of ownership and also of
authenticity of the data.
2.1.8. Summary of critiques and concerns about DID-related standards proposed by W3C
As introduced in the last section, the DID standards recently proposed by W3C have not yet been
thoroughly reviewed by sufficient members of the security/cryptographic community. Therefore, these
often proprietary and also unnecessarily complex protocols/algorithms hamper transparent
communication especially with non-technical stakeholders, e.g., business representatives, but also
amongst programmers without a strong background in cryptography. Hence, in our present report we will
carefully scrutinize the claims of privacy and security by cryptographic methods employed in W3C-
standards for VC/DID concepts, in order to pinpoint the merits and risks of these emerging (potential)
standards later on in our final report.

Table 1: Summary of critiques and concerns about DID-related standards proposed by W3C
Critiques Examples / Explanation
Impact on confidentiality when
loading from linked documents
from internet
JavaScript Object Notation for Linked Data (JSON-LD) as well as
Semantic Web serialization can depend on the resolution of
external, potentially insecure documents to URIs to "link" data,
similar in spirit to XML namespaces. The same argument holds true
for DID documents that include external resources.
Risk of contradictory or arbitrary
standards
Semantic Web graphs described by RDF can be serialized in
different manners, which in the absence of specification by W3C
standards often are determined in an ad-hoc fashion.
Nonessential complexity
introduced by Domain Specific
Languages (DSLs)
We can say that W3C Standards introduce new DSLs in the form of
DID documents, VC documents, and presentation schemas. There
is a tendency (and a temptation) to add new features to these DSLs
in the name of standardization (to minimise the custom code from
the validation and replace it with standardised verification).
However, our position is that this path creates unnecessary
complexity and makes the standards harder to implement and
incompatible with real use cases.
The problem of modelling generic
interfaces for verifiable data
registries (VDRs)
In the absence of concrete specifications for DID documents in the
W3C standard, issuing services can include heterogeneous data,
including elements that reveal PII of the user.
Decentralized Key Management
System (DKMS) proposals
The W3C universal naming scheme envisions the DIDs retrieved
from decentralized third-party services to be stored and queried in
a public blockchain, which produces counterproductive overhead
by sending back and forth requests that would not be necessary
when directly contacting the corresponding issuers.
DID Authentication/Secret
Exchanges
Although DIDs claim to support zero-knowledge proofs, there is no
advanced cryptography used outside of RSA and elliptic curve
Ed25519 signatures in the standards themselves.
One time use DIDs If DIDs are supposed to be for one-time usage, then an anonymous
credential scheme could actually substitute the blockchain-
anchored use of DIDs, providing a higher degree of efficiency.

Critiques Examples / Explanation
Portability of the Digital Wallets There are no clear standards with respect to how private keys
associated with DIDs should be handled. We believe that key
management and wallet programmability could influence the
winners in the battles between DID methods and therefore all the
extensions and particularities of the Key Storage solution could be
as influential as the standards. Additionally, these DIDs are used for
signing and encryption. Ability to have proper key management for
signing and encryption is the key differentiator between DID
methods and will dictate the actual libraries that can be embedded
in the digital wallets.
Limitations in judging the security
and privacy properties
DID documents tend to be resolved using third parties, which may
disclose PII. Typically, these documents are stored in publicly
accessible blockchains.
Individual metadata is not
ontology-friendly, not
abstractable/classifiable
The type of credentials employed not only determines the
verification protocol, but depending on the trust in the issuer
requires custom code for validation. This again leads to not being
able to rely on standardized verification.
Schemas are still code Configurations and schemas are assimilable with code and as such,
have the same trust issues as any code. Schemas cannot be
evaluated for "truthfulness", you need to check and trust the
implementation (e.g., by checking the provenance of the signed
code).
2.2. Data Sharing alternatives
Traditional data stores are designed around the notion of separating storage of dat; which we can imagine
as a "server", from a layer of applications; which represent "clients" that make use of the stored data. In
order to safeguard the privacy of data, encryption is an essential measure to take into consideration.
Questions such as which components of the architecture have access to the (unencrypted) data and who
controls the private keys need to be addressed.
● Client-side encryption offers a high level of security and privacy, especially if the metadata can be
encrypted as well, but does not imply that the corresponding data vault is optimized for storing
such (individually) encrypted data and the question of key management becomes more complex
when data needs to be shared.
● Storage-side encryption is usually implemented as whole-disk encryption or filesystem-level
encryption, which provides well understood and space-efficient algorithms, however requires the
private keys to be managed by the service provider or controller of the storage server, which
usually is a different entity than the user who is storing the data.

As an intermediate solution gateway-side "encryption as a platform" systems have emerged, e.g Tahoe-
LAFS [17] which perform encryption and decryption themselves in a way that is transparent to the client
application,. Although gateway-side encryption eliminatesthe client of responsibilities forkey
management, it requires the keys to reside on "gateway" servers, which encrypt the data before passing
it to the storage servers, undermining users ability to control their data in a self-sovereign fashion.
2.2.1. Solid
The Semantic Web architecture known as "Solid" has been designed by the W3C director and inventor of
the Web, Berners-Lee, originally to decentralize the Web by transferring control of data from a central
authority to users [18]. The core concept of this architecture is based on so-called "Solid Pods", i.e.,
containers to store data in RDF either locally on a device such as a mobile phone or on a cloud server
selected by the user. Approaches connecting the Solid architecture and Blockchain employ cryptographic
hashes of these pods to anchor data like VCs in a distributed ledger for verification purposes [19], with
example certification use case applications such as those in test-vaccination scenarios arising in the
current COVID-19 pandemic [20]. Clearly, such approaches provide users full control over storage and
ownership of their data. However, as the Solid architecture lacks kernel security modules or other
confidentiality methods [7]. responsibilities concerning persistent data storage (e.g., when storing data
on ones own mobile device) and privacy/protection (e.g., when employing cloud storage by a provider)
are delegated to the user.These shortcomings severely limit Solid-based approaches, rendering
blockchain-anchored storage in Solid Pods particularly unsuitable for peer-to-peer transactions required
by several use cases considered in this work.
Figure 2: Solid architecture with blockchain anchored hashes
Data (purple hexagons, middle) is stored at the user's premises and hash-anchored to a blockchain (red
circles to the right). Figure reproduced from [20]
2.2.2. Identity Hubs by decentralized Identity Foundation (DIF)
Similar to the Solid architecture, DIF's Identity Hubs [21] are document-based data stores that provide
end users the option of either installing and running the server portion of the data store on a local device
they control, or to sign up to an already configured instance hosted by a trusted third-party e.g., a
commercial provider, an affiliated institution, etc.. Data remains stored on a server organized in
collections. In contrast to Solid Pods, peer-to-peer communications through DID authentications are
central to the Identity Hub design, managed through a DID resolver responsible for instance for the
management of the end user's profile, transmission of human- or machine-readable messages through
the Actions interface, or pointers to external services. As a trade-off, such a concept of system-wide DID
resolution prevents self-sovereign identity management by users and therefore limits privacy. Moreover,
also encryption standards were ignored in the basic concept and only proposed as an option later-on [22].

Figure 3 Topology of DIF Identity Hubs
A blockchain-backed DID Resolver allows to resolve DIDs of other users for exchanging messages. Figure
reproduced from [21]
2.2.3. Encrypted Data Vaults
W3C proposed guidelines for "Encrypted Data Vaults" [23], which envision identifier-agnosticprivacy-
respecting storage solutions where users can pass on their keys in encrypted form together with the data
to be stored. In order to enable data sharing amongst multiple entities possibly employing DIDs, Encrypted
Data Vaults provide one or multiple standard authorization schemes, such as OAuth2, Web Access
Control, or platforms implementing the authorization capabilities for linked data systems standards [24].
However, whereas some client responsibilities such as encryption and versioning are delegated to the
server, other tasks such as data chunking and replication remain with the user by design. Furthermore,
Encrypted Data Vaults allow malicious service providers, though not in possession of the keys used for
encryption, to exploit information about the size, modification frequency and access patterns of the
stored files to derive information about the nature of transactions or correlation patterns between
multiple entities sharing access. Such attacks are facilitated by some of the meta-data, e.g. version
numbers, remain unencrypted and/or authentication methods are not enforced by the Encrypted Data
Vaults specification [25].
Figure 4 Encrypted Data Vaults ecosystem
The diagram provides an overview of types of components that are emerging and the roles they play in
different architectures. Encrypted Data Vaults fulfil a storage role. Figure reproduced from [23]

3. PHARMALEDGER PLATFORM SPECIFIC RESEARCH
OpenDSU is used as the foundation for all PharmaLedger Use Cases and intermediates the usage of
blockchains. We have identified a set of confidentiality methods that heavily impacts (helps)
confidentiality of the PharmaLedger Use cases.
Table 2 Confidentiality methods and impact for the Pharmaledger Use Cases
# Method Confidentiality Impact
#1 Cryptographically
validated code
The OpenDSU architecture has an important impact on the confidentiality
and security of the platform. The security model, based on data encryption
but code signing, can lead to leaks of information about the type of DSUs
used, impacting privacy.
#2 Zero access
blockchain
anchoring
On-chain data storage is minimized to anchors (which generally contain
secure cryptographic information hashes - enough entropy). This minimizes
the amount of information available to other participants in the blockchain
network.
#3 Symmetric
encryption
All DSUs are stored on servers in the form of symmetrically encrypted bricks.
Each brick is encrypted with a unique randomly generated key. In this way
the sensitive data from the point of view of confidentiality are protected
against reading and correlations. Symmetric encryption is also used for
communication between OpenDSU wallets.
#4 Multiple
blockchain
domains and
Decentralized
Gateway
Architecture(DGA)
OpenDSU support for multiple blockchain domains and DGA architecture
can be seen as an architecture that supports data segregation, in such a way
as to minimize metadata correlation attacks.
#5 Pluginisable DID
methods,
Validation
Strategies
OpenDSU allows the addition of DID methods (but also other methods for
identifying actors, such as X.509 certificates, be they individuals or
organizations) The Validation Strategies concepts allow finding the
appropriate level of compromise between confidentiality and auditability.
#6 OpenDSU
Cryptographic
Methods
OpenDSU is extensible, being based on the idea of code signed and
anchored in a ledger. This approach allows the gradual introduction of new
cryptographic techniques to protect confidentiality.
The OpenDUS methods are synthesized in the table below and are documented in the subchapters as part
of the current research status of task D3.4.

3.1. Confidentiality methods directly obtained from the OpenDSU Architecture
The OpenDSU architecture offers a number of methods for obtaining confidentiality and privacy.In the
following table e present an overview of the most important methods offered by OpenDSU.
Table 3: OpenDSU Confidentiality methods summary
OpenDSU feature Benefit sought
Cryptographically validated code By signing the code, the responsibility can be clearly assigned.
For example, in the case of supply chain attacks it will be easy to
detect the initiator of such an attack. Even if the supplier was
itself a victim of a successful attack, the responsibility
assignment will put pressure on the business to consider doing
the best development methods. By using digital signatures and
proper management of credentials, OpenDSU aims to raise the
bar on managing code from the responsibility point of view.
These aspects will have an indirect but clearly positive effect on
confidentiality and can be considered a powerful confidentiality
method.
Zero access blockchain anchoring OpenDSU anchoring minimizes the amount of data and
metadata available in a public ledger. Various strategies for
anchoring are currently being researched as part of the T3.3 task
(Blockchain platform adaptation).
Symmetric encryption DSUs are encrypted using Symmetric encryption
Encrypted messages As documented in the deliverables related to tasks T3.3, T3.4 and
T3.9OpenDSU offers the possibility to transmit encrypted
messages between wallets. The transmission of encrypted
messages is one of the most important pillars of ensuring the
confidentiality of communication in PharmaLedger systems.
Multiple Blockchains The PharmaLedger architecture based on the existence of
several blockchains is in itself a method of achieving
confidentiality by restricting access to metadata associated with
transactions (anchors, transaction completion times or
transaction patterns).
Support for lightweight clients One of the relevant privacy issues in most systems that use
blockchain is that they need a gateway that mediates
communication between wallets (which we can see as
blockchain lightweight clients) and blockchain. These gateways
are unavoidable and relatively harmless in an enterprise
environment but can severely affect the confidentiality of users

OpenDSU feature Benefit sought
e.g. patients who do not have their own blockchain nodes and
trusted gateways to communicate securely. OpenDSU tries to
offer a DGA architecture therefore reducing the risk of a single
gateway obtaining metadata or even real data.
Pluginisable DID methods OpenDSU allows the integration of code libraries that implement
any kind of DID method. Different DID Methods provide different
privacy characteristics. This allows the application developers to
choose the DID methods that ensure the right balance between
trust, auditability and privacy.
Validation Strategies OpenDSU is agnostic in terms of the data validation method. In
this deliverable we explain the difference between validation
and verification as well as the fact that OpenDSU allows the use
of different technologies and standards to obtain data
validation.
Open/extensible architecture Because OpenDSU is based on the idea of having signed code and
signed data stored in Data Sharing Units, we are confident that
the OpenDSU architecture will allow for the further integration
of new privacy techniques.
3.2. Confidentiality attacks on the PharmaLedger platform
In the following table we have documented the current understanding of the actors within the
PharmaLedger use cases and their role in jrelevant to confidentiality. The identification of the actors
allows us to carry out a risk analysis and specify the types of confidentiality methods required in
PharmaLedger. This identification will be elaborated within task T3.4.
Table 4: Actor impacting confidentiality
Actors impacting confidentiality
GDPR typical actors
Data owner Typically, are users: People that have a limited access to
sensitive data are enlarging their access) or companies.
Data controller As they determine the purposes of the data collection and
how it will be processed they can impact confidentiality e.g
by sharing confidential data with entities that may exploit,
add, modify or delete data.
Data processor Typically, that get restricted access to confidential(private)
data from data controllers. They could do reverse

Actors impacting confidentiality
engineering and deanonymization attacks to reveal
attributes of confidential transactions even in (partially)
encrypted data, by analysing meta-data such as size and
updating frequency of files.
Developers
Actual programmers Backdoors in code to undermine security or authentication
methods.
People or organisation controlling the
external dependencies (libraries with
code, hardware) - supply chain
stakeholders
They can add backdoors in code to undermine security or
authentication methods.
Infrastructure
Communication or computation
Infrastructure providers
They can remove or add data, particularly in the absence
of mechanisms that guarantee immutability. Intercept or
manipulate unencrypted messages in transit, spy or
manipulate unencrypted resting data.
IT (operational) personnel They can abuse their rights to remove or add data,
particularly in the absence of mechanisms that guarantee
immutability. They can install systems to automatically
intercept or manipulate unencrypted messages in transit,
spy or manipulate unencrypted resting data.
Internal attackers: from employees,
family members with physical access to
devices
Get hold of user-managed keys that grant access to
confidential data, as well as unencrypted data stored on
local devices.
State actors Because of their large areas of influence, we can consider
them infrastructure providers
Other actors
External attackers An attacker is a person or organisation that succeeds in
getting access to confidential data without any special
permission from users or data controllers.
In the following table we have identified the types of attacks on confidentiality that are relevant in the
PharmaLedger use cases. Identifying the category of attacks allows us to conduct a risk analysis and specify
the types of confidentiality methods required in PharmaLedger. This identification will be elaborated and
documented within the next update of task T3.4.

Table 5: types of attacks on confidentiality that are relevant in the PharmaLedger use cases.
Data leakages attacks
Security attacks: Unauthorized access to confidential data obtained by exploiting bugs or faults
Side channel attacks: Data leakages are hidden in normal looking activities.
Social engineering attack: Unauthorized access obtained through social engineering
Privacy attack: A system issue is breaching the expectations of the laws (e.g. GDPR)
Supply chain attacks: Unauthorized access to confidential data using as vector of attack libraries and
dependencies
Impersonation attacks
Impersonation: An attacker gets access and control over an identity (e.g. to a private keys) and use it
in malicious ways
Deanonymization attacks
Correlation attacks: External attackers create profiles for persons or companies
Timing attacks: Recovery of PII based on correlation with external records and matches based on
simultaneity of events
Crowd anonymity failures: Deanonymization happens because only a reduced number of persons can
produce an event and the simple existence of the information about the event identifies the originator
of the event
Attacks to the credibility of the confidentiality method
Political/Business drawbacks: The confidentiality methods have side effects (for example caused by
leaky/improper abstractions) with potential of creating serious problems in the system exploitation.
Bad user experience or inability to discover the source of a problem during an attack or any system
malfunction could be good examples. Such attacks (even theoretical ones) tend to disqualify a
confidentiality method, even ones that have significant benefits on confidentiality overall.
In the following table we have identified the types of attacks on the confidentiality measure of the
OpenDSU. Identifying these categories of attacks allows us to do a risk analysis and a clarification on the
types of confidentiality methods required in PharmaLedger. This identification will be elaborated within
the task T3.4 and documented in the next deliverable.

Table 6: Attacks on the confidentiality measure of the OpenDSU
Architecture
Element
Potential attacks Malicious Actors Impact
Cryptographically
validated code
Deanonymization attacks regarding the usage of
credentials, bricks and digital signatures could
potentially impact confidentiality. In practical
terms, it will be possible to determine what code
is used by the patients or health professionals. The
impact is low because the actual data is protected
by strong encryption, only patterns of activity and
some metadata can be derived.
Infrastructure Low
Zero access
blockchain
anchoring
Security attacks are possible against the pseudo
random generators used to obtain the keys (or if
the KeySSIs are using low levels of entropy)
Developers Medium
Symmetric
encryption
random generators used to create keys
Developers,
Infrastructure
Low
Encrypted
messages
random generators used to create keys.
Deanonymization attacks can be conducted by
actors related to the infrastructure providers.
Developers,
Infrastructure
Low
Support for
multiple
Blockchains
actors related to the infrastructure providers
Infrastructure
Support light
clients
organising data exchanges between Infrastructure
providers
Developers,
Infrastructure
Low
Pluginisable DID
methods
Security attacks are possible.
Deanonymization attacks are possible.
Developers,
Infrastructure
Low
Validation
Strategies
Security attacks are possible.
Deanonymization attacks are possible.
Developers
Infrastructure
Low
Open/extensible
architecture
Security attacks are possible. Developers Low
In the following table we have identified the mitigation solutions to attacks on confidentiality identified
in the previous tables. The research on the mitigation will be elaborated further within the task T3.4 and
documented in the next deliverable.

Table 7: mitigation solutions to attacks on confidentiality identified
Architecture Element Potential mitigations
Cryptographically
validated code
Other active mitigations against correlation attacks can have severe impacts
on the system. All the internal processes around the system should be
documented and audited periodically. This is an area of active research and will
be documented in the next deliverable.
Zero access
blockchain anchoring
Security evaluation of the code and of the architecture, for example analysis of
the types of KeySSI and what entropy that is used. This is an area of active
research that will continue.
Symmetric encryption Security evaluation of the code and of the architecture should be periodically
conducted. This is an area of active research that will continue.
Encrypted messages Security evaluation of the code and of the architecture should be periodically
Support for multiple
Blockchains
Security evaluation of the code and of the architecture should be periodically
conducted. The confidentiality impact from selection of the right ledger is
explained in the next chapter. This is an area of active research that will
continue.
Support light clients Security evaluation of the code and of the architecture should be periodically
Pluginizable DID
methods
Validation Strategies Security evaluation of the code and of the architecture should be periodically
conducted.
This is an area of active research that will continue.
Open/extensible
architecture
conducted. Initial results are presented in chapter 3.5 named “Computation
over encrypted (secret) inputs”. This is an area of active research that will
continue.
3.3. Ledger selection as a confidentiality method
In this section, we describe the results obtained in T3.4 in relation to the problem of choosing the type of
"access gateway" for wallets and applications that use blockchain.
A Distributed Ledger is not located somewhere abstractly in the cloud but under the control of concrete
entities. These entities provide access to a replica of the ledger via a “gateway” controlled by somebody.
External customers can access the blockchain through these "gateways". From this perspective we
identified 3 archetypes of interaction with a distributed ledger:
● CGA (Centralised Gateway Archetype): the clients are trusting a central gateway;

○ SL – Single Ledger (a centralised database with a blockchain data structure)
○ DL – other decentralised ledgers
● DGA (Decentralised Gateway Archetype): the clients are asking multiple gateways and
decide who to trust by some sort of voting;
● NGA (NO Gateway Archetype): extends the DGA pattern by enabling a (direct)
communication method between the clients and gateways that prevents any profiling or
censorship attempts by the gateway.
System
Archetype:
Single Ledger -
SL
SL &
Anchoring
Distributed
Ledger - DL
(CFT)
DL &
Anchoring
BFT DL
Gateway
Archetype:
CGA DGA NGA CGA DGA NGA CGA DGA NGA CGA DGA NGA CGA DGA NGA
Latency 1 2 3 1 3 3 2 3 2 2 2 2
1
2
1
2
1
2
Throughput 5 5 3 5 4 2
3
4
3 2 3 3
1
2
1
2
1
2
1
2
Privacy 1 3 5 1 3 5 1 3 5 1 3 5 1 3 5
Censorship
Resilience
1
2
3
4 1
2
3
4 1 4 4 1 4 5 1 4 5
Tamper
Resilience
1 1 1 3 3 3 3 3 3 4 4 4 5 5 5
Auditability 1 1 1
2
3
2
3
2
3
3 3 3 4 4 4 5 5 5
Scale 1
1
2
2
2
3
3
3
4
4 5
The above table provides a rough rating for the effects of a CGA/DGA/NGA gateway archetype on the
previously introduced system archetypes, i.e., different single ledger (SL) and distributed ledger (DL)
types. The rating measures various performance and security properties based on a Likert Scale, ranging
from a value of 1 (red) -- entailing low guarantees regarding the respective property -- up to a maximum

value of 5 (green). Values are further scaled relative to the performance of archetype combinations
compared herein: e.g., for the property "Throughput" we assign the lowest values to BFT DLs, indicating
these perform overall worst in our comparisons of this property, as opposed to SLs with CGA-interactions,
which with a rating value of 5 are amongst the top performers in our comparison of this property.
For each of the assessed properties, we treat each archetype in a “black box” fashion, i.e., considering a
specific property we are exclusively concerned about the guarantees that an archetype provides to clients
interacting with it. To this end, we model the service provided by each archetype as an abstract state
machine, composed of a persistent state and a state transition function. We further assume a transaction-
based interaction pattern among clients and the individual stateful archetypes. Clients submit (signed)
arbitrary requests (transactions) to the service, which are input to the state transition function, together
with the service’s current state, and executed in an atomic fashion. Note that for evaluating properties
we limit the concept of privacy to the service’s ability to monitor network-related traffic and perform
correlations to derive information about the attributes of the client. In other words, we do not examine
privacy regarding the contents of the transaction itself.
Analysing the results from our rating estimates we first find that, as a rule of thumb, combinations of
centralized (system and gateway) archetypes generally provide the best possible performance, in terms
of latency and throughput, as illustrated in the following Diagram.
Figure 5: Combination of centralized archetypes
Furthermore, our comparative study shows that, across all system archetypes, the choice of the gateway
archetype is the dominant factor regarding censorship resilience and privacy. Improvements in either of
these properties, however, come at the expense of performance losses due to an increased latency caused
by communicating with multiple gateways (DGA), or the even higher latency penalties originating from
network anonymization (NGA).

Figure 6: Comparative of system archetype due to censorship resilience and privacy
In addition, our results demonstrate that tamper resilience and auditability are dependent exclusively on
the system archetype, more specifically its degree of centralization and fault model. SL provides the worst
tamper resilience guarantees, which, however, can be improved when the services state is periodically
anchored in a BFT (public) blockchain.
Figure 7: Tamper resilience and auditability comparative

With respect to DL, we estimate that a total ordering across all transactions, even in the crash fault model,
can be considered fairly equivalent with the tamper resilience guarantees of “SL & Anchoring”. Regarding
auditability, “SL & Anchoring” and “DL & Anchoring” exhibit better guarantees compared to their non-
anchored counterparts, and therefore represent more interesting system archetypes with respect to this
property. However, we want to stress the fact that these guarantees are directly dependent on the
anchoring frequency, i.e., how often the services state is anchored on the BFT (public) blockchain.
Depending on the use case of these system archetypes, the auditability guarantees of the aforementioned
approaches may or may not be acceptable.
3.4. Trustless collaborations vs. the cost of auditability
We next set off to contrast the needs with the costs that might impact the selection of a ledger technology
for business use cases emerging from industry. Clearly, global transparency and performant but strict
consistency through blockchains comes at a considerable price for enterprises. That becomes even more
evident when considering that transactions in most use cases are not at all as simple as cryptocurrency
payments. Auditability, on the other hand, is one major objective that industry aims to accomplish in
several use cases, and that can be facilitated by the use of ledger systems. However, even in use cases
where blockchain technologies enable new ways of collaboration between companies or people, the strict
consistency of all data in a ledger might be wasteful and unnecessary. In this section we therefore attempt
to address the seemingly paradoxical question of "how billion-dollar industries might have survived
without blockchains?"
Figure 8 Various constraints regarding auditability and trustless collaboration
In the above table, we identify five areas of potential business cases, and a blockchain architect needs to
select the appropriate ledger for each of them. We grouped these use case areas by their dependence on
the underlying Business Logic. Under the term "Business Logic", we understand business processes that
are represented digitally by smart contract instances, blockchain-related service orchestrations, or
executable choreographies. From the point of auditability, these business processes have more than one
stakeholder, otherwise the usage of blockchains would be questionable. An immediate observation is
that--in most cases--the business logic of a business process does not depend on the state of other
processes. In this regard, processes can have interactions and can be influenced by other external events

from the real world, but not have dependencies on digital contents anchored in the blockchain or created
by other blockchain anchored business processes.
These observations make a huge difference in how to choose the ledger and what can be delegated off-
chain to obtain blockchain-specific characteristics without paying the price for a global consensus: for use
cases in the "independent business logic" category, it is feasible to move the validation outside of the
blockchain and therefore to keep the blockchain strategy only for providing a strict order of events, as
required for auditability.
The motivation for developing the OpenDSU concept starts off with the paradigm that having a single
blockchain technology, or one unique blockchain deployment pattern that covers all the use cases of an
industry, is hardly a benevolent or competent advice. Such a strategy will not work, respectively, the price
will be astronomically high. With OpenDSU, we propose a unified approach for the architecture, allowing
us to reuse code where possible, but not fixing the blockchain technologies that can be employed nor the
deployment patterns. Anchoring with OpenDSU can and will be implemented in ledgers that have
different use case tailored capabilities, and that are deployed in different ways. Particularly the
deployment flexibility is of paramount importance, because even with the most advanced privacy-
preserving technology available, the essentially sensible decision is to not share data, anchors, zero-
knowledge proofs, anonymized transactions, etc. if/whenever there is no real business or technical
requirement for sharing. Therefore, the main aim of the OpenDSU approach is to facilitate sharing and
auditability in the best privacy-preserving way.
3.5. Computation over encrypted (secret) inputs
In task T3.4 we have identified the most important cryptographic techniques and tools that could be used
in the development of the platform and use-cases. We list below the techniques that allow working with
algorithms that receive as input secret (confidential) data and produce verifiable results: Homomorphic
Encryption (HE), Multi Party Computation (MPC), Multi Party Storage (MPS), Differential Privacy (DP),
Indistinguishable Obfuscation (IO), Bloom Filters (BF), Cryptographic Accumulators (CA), Zero Knowledge
Proof (ZKP), Digital Signatures (DS), Commitment Schemes (CS).
The table below presents generic use cases in which the concept of executing an algorithm on secret data:
Table 8: generic use cases in which the concept of executing an algorithm on secret data
# Generic Use Case PharmaLedger Use case
#1 Secret voting Possible
(governance)
#2 Revealing at the end voting Existing
(governance)
#3 Public Algorithm running one single secret input and secret
result
Possible
(Protect patients' privacy)
#4 Public Algorithm running on many secret inputs and verifiable
result
Possible
(Protect patients' privacy)
#5 Auditable data validations In most use cases

#6 Data validations without ability to do any correlation with the
involved “identities”
Improbable
#7 Secret Algorithm running one single secret input and returning
a secret result
Possible
(e.g., protect IP)
#8 Secret Algorithm running one multiple secret inputs and
returning a secret but verifiable result
Possible
(Get a research result)
#9 Secret Algorithm running one public inputs Improbable
These generic use cases are explained in the table below in terms of the privacy features of the algorithm,
input and result along with cryptographic techniques with the potential to be used as an implementation
solution.
Table 9: the privacy features of the algorithm, input and result
# Algorithm Inputs Inputs Secrecy Result Secrecy Techniques
#1 Voting Multiple Secret Verifiable HE, ZKP
#2 Voting Multiple Secret until end Verifiable MPS, HE, CS
#3 Public Single Secret Secret HE
#4 Public Multiple. Secret Verifiable DP, MPC, BF,
CA, CS
#5 Public Multiple. Secret Public DS, CS (Any)
#6 Public Multiple. Secret Public CS, DS (Special)
#7 Secret Multiple. Secret Public HE
#8 Secret Any Secret Verifiable HE, MPC, CS
#9 Secret Any Public Any IO, CS
Voting algorithms can be clearly identified because we know the typical rules: each voter casts a secret
ballot but the result is public and verifiable. Verifiability refers to the fact that the counting is done
correctly and each participant with the right to vote votes a maximum of once. We differentiate between

“revealing at the end voting” and secret voting. It may sometimes be desirable to reveal the votes after
the counting ends so as not to influence the vote during voting but to see at the end how the members
of a group voted.
As examples of public algorithms that require secrecy, we can evidence the tendering algorithms (select
the best bidder) or algorithms that compute the reputation of members.
For secret algorithms we could imagine new algorithms such as deep-learning trained models. Throughout
the project, WP3 partners will communicate with the use cases teams (WP2) and will explain the potential
of using these new cryptographic techniques to improve various confidentiality aspects of the applications
developed within the PharmaLedger platform.
During this reporting period, special attention was paid mostly to issues #4 and #5 related to data
validation and emerging technologies (Decentralized Identities and Verifiable Credentials). In the
following chapters we mainly document this activity. In the next deliverable of this task, we will document
the other research efforts necessary for Pharmaledger use-cases and for example voting in the
governance tools.
Aspects relevant to the PharmaLedger platform IoT use cases are documented mainly in the deliverables
of the T3.9 task to avoid overlapping between deliverables.
3.6. OpenDSU and use cases as choreographies. OpenDSU and ZKP
In the last section, we have identified three major use case categories based on independent business
logic, where blockchains can be employed to solve business problems between multiple companies (i.e,
"choreographies"). However, each of these use case categories implies different constraints regarding
confidentiality and verifiability, as summarized by the following table:
Table 10: Use Case constraints regarding confidentiality and verifiability
Category Confidentiality Verifiability
Small-Group
Choreography
Transactions are visible only between
a small group of partners.
The transactions are auditable periodically
and the incentives for attackers are few.
Trustless Group
Choreography
Not all transactions should be visible to
the group (but some will be).
Incentives for attacks exist.
Human auditability of the data required.
Network
Choreography
The visibility of the transactions should
be minimized as much as possible.
The incentives for attackers are high!
Human auditability is limited to the code.
Consequently, we propose solutions for the enumerated categories as sketched in the following diagram:

Figure 9 Appropriate solution for each category
Our proposed solutions include Zero Knowledge Proofs (ZKP), a quite recent and complex approach that
in literature is already often considered as the "silver bullet" for solving blockchain’s privacy issues mainly
because ZKP justifies the price of computations required for validation when delegated to third parties.
However, ZKP validation can be circumvented for the analysed enterprise use cases by anchoring the
computational results once in a blockchain, against which interested parties can validate as needed (cf.
OpenDSU Bluepaper [26]).
Indeed, as a line of research ZKP is attractive and promising future advances. However, ZKP only sounds
generic and a perfect solution when ignoring current risks, scalability issues and difficulties in the strategy
with respect to how to store and share private data. Admittedly, in the absence of evaluating known
boundaries, however, the proposed ZKP concept turns visionary and cannot debunk suspicions of being
mostly a hype. Additionally, ZKP is usually described from a cryptographer's, i.e., a mathematician's, point
of view, who simply would label data as public, private, etc. However, consideration must be given to
other factors, such as from where to get and where to store private and public data; how these
transactions are communicated and in addition, knowing how to manage that complexity., , As the ZKP
concepts usually present some rather abstract primitives on how to integrate these components properly,
these tasks are neither simple nor obvious to solve.
In contrast, the OpenDSU concept we are proposing is aiming to solve these issues in off-chain respectively
near-chain storage as well as in thus required computations, and at the same time OpenDSU is agnostic
to the usage of ZKP. However, OpenDSU is also based on the idea that in most cases ZKP can be avoided
and substituted by more intuitive solutions that are already available. To deepen this discussion a bit
more, there are two major directions in which we could exploit ZKP in the OpenDSU context:
1. Patients/companies could present ZK-based verifiable credentials to give proof to a verifier.
However, ZKP allows the possibility that the holder of a credential can pass this credential on
to another entity/party, for motives of material benefits, obfuscation, etc. . We currently do
not see how this weakness can be solved. Therefore, the usefulness of ZKP is not clear if it is
required to deanonymize the holder, or, if a trusted intermediary is required to guarantee
the unicity in a set of holders.
2. Smart contracts within a small group of companies could theoretically still be secured with
ZKP. However, such a strategy requires keeping data confidential with encryption and
sharing corresponding keys respectively data only with the right members of the group.
Beyond this scenario, ZKP is useful only if the involvement of a third party for validation
purposes is needed. Typically, the third party is creating some useful software and it can
promote and commercially position its solution in some form of “blockchain as a utility”. In
such case data is to be hidden from the third party. OpenDSU can achieve such computational

integrity by reducing the role of the third party to just an interaction through a key/value
database with minimal validation (and without ZKP).
In most cases, the DSU-anchoring model [27] of OpenDSU can remove the need for revealing any data to
the software creator or to the utility provider. DSUs move the computation off-chain, that is, in wallets or
agents controlled by participants and not by the utility providers. Anyway, even when employing ZKP, the
computations on encrypted data, i.e., to generate proofs, should be kept off-chain.
We recognize that OpenDSU’s validation made at the anchoring level could not suffice, leveraging as a
major disadvantage the risk of spamming: an attacker could create numerous versions of DSUs to block
the progress of some business processes. In enterprise solutions, this attack will be noticed and the
attacker can be punished. There exist ZKP cases, where off-chain logic involves choreographies between
many companies, which should be able to validate all transactions without revealing data to each other.
The question arises, whether in most situations simpler and safer solutions based on digital signatures
and encryption could be found. These "boring" solutions could suffice for many of the use cases, would
be safer, much simpler to understand and to program. Although ZKP sounds attractive and generally
applicable to all cases, there is a price to pay that it is difficult to estimate a priori. The risks of new and
complex cryptography, but also potential performance issues when scaling to the level of millions/billions
of people/processes, limits the appeal for ZKP usage.

4. CONCLUSIONS
This deliverable reflects the current status of the research from T3.4 and may contain unfinished or slightly
incorrect hypotheses and conclusions. In the coming months, these results will be elaborated and sent for
publication, review and scientific/technical validation.
4.1. Risks from excessive properties of the confidentiality methods
It would be naive to neglect the fact that any useful tool can be employed for both, the bad and the good.
By our studies, we arrived at the position that there could be cases in which confidentiality methods can
be undesirable, or even dangerous. That can easily be seen by the obvious cases in which illegal material
may be stored or in which malware networks controlling canters could be implemented using the
confidentiality methods employed for normal use cases. But also, in general, enterprise environments will
weaken the confidentiality methods as a consequence of requirements for clear auditability and ability to
censor and control the company's infrastructure. Therefore, a balanced point of view is necessary when
evaluating confidentiality issues, and we will consider all sides during our further investigations in the
WP3 confidentiality research task.
4.2. Future research
Table 11: Future research
Research Area Observations
Open DSU Usage
patterns
We foresee the potential of developing new guidelines for the OpenDSU
developers based on PharmaLedger use case implementations.
This area is directly correlated with the use cases and we can enumerate
research areas such as:
● Impact of the Key Management on confidentiality
● PharmaLedger Use Case Specific Confidentiality Challenges
● Types of Verifiable Credentials suitable for Use Cases
● Avoidance of the Cloud Agents during integrations
Impact of the
revocation. Privacy
preserving, granular
revocation
Revocation should be supported at all levels of granularity (DIDs, public
keys, credentials, presentations without or with long expiry time). We
should have privacy friendly mechanisms for enabling both, issuer- and
holder-controlled revocations.
IoT specific challenges Documented in T3.9 deliverables.
The main objective of our future research is to provide new tools, guidelines and advice for use case
implementers. This research will continue to draw inputs from the use case development and provide
output for T3.5. Overall, T3.4 task is advancing well considering our relevant research results, interesting
insights, and the proposition of quality solutions for developers.

BIBLIOGRAPHY
[1] P. Consortium, “D3.8 Reference implementation of advanced confidentiality methods,”
2021.
[2] P. Consortium, “D3.1 PharmaLedger framework architecture,” 2020.
[3] M. Kubach, C. H. Schunck, R. Sellung and H. Roßnagel, “Self-sovereign and Decentralized
identity as the future of identity management?,” Proceedings of the Open Identity Summit
2020, Lecture Notes in Informatics (LNI) ed., vol. 305, Gesellschaft für Informatik, 2020.
[4] M. Sporny, D. Longley and D. Chadwick, “Verifiable Credentials Data Model 1.0
Recommendation,” Available: https://www.w3.org/TR/vc-data-model/, 19 November
2019.
[5] M. Alblooshi, K. S. and Y. Alhammadi, “Blockchain-based Ownership Management for
Medical IoT (MIoT) Devices,” Proceedings of the 13th International Conference on
Innovations in Information Technology (IIT), IEEE,, pp. 151-156., 2018.
[6] I. Barclay, A. Preece, I. Taylor, S. Radhai and J. Nabrzyski, “Certifying Provenance of Scientific
Datasets with Self-sovereign Identity and Verifiable Credentials,” Proceedings of the 12th
International Workshop on Science Gateways (IWSG), 2020.
[7] H. Halpin, “Vision: A Critique of Immunity Passports and W3C Decentralized Identifiers,”
Proceedings of the 6th International Conference on Research in Security Standardisation:
Security Standardisation Research (SSR), Lecture Notes in Computer Science, 2020.
[8] M. Kubach and H. Roßnagel, “A lightweight trust management infrastructure for self-
sovereign identity,” in Proceedings of the Open Identity Summit 2021, Lecture Notes in
Informatics (LNI) ed., Bonn, Gesellschaft für Informatik, 2021, pp. 155-166.
[9] D. Reed, “Decentralized Identifiers (DIDs) v1.0 Core architecture, data model, and
representations,” https://www.w3.org/TR/2021/CRD-did-core-20210616/, Standard, W3C,
2021.
[10] O. Lassila and R. R. Swick, “Resource Description Framework (RDF) Model and Syntax
Specification, W3C Recommendation.,” no. Available at:
https://www.w3.org/TR/1999/REC-rdf-syntax-19990222, 2021.
[11] J. J. Carroll, “ Signing RDF Graphs,” The Semantic Web - ISWC, vol. Springer Berlin Heidelberg,
p. 369–384., 2003.
[12] D. Chadwick, “Verifiable Credentials implementation guidelines 1.0, W3C
Recommendation,” no. Available at: https://www.w3.org/TR/vc-imp-guide/, 2019.
[13] M. McIntosh and P. Austel, “XML signature element wrapping attacks and
countermeasures,” Proceedings of the 2005 workshop on Secure web services. New York,
NY, USA: Association for Computing Machinery (SWS ’05), p. 20–27, 2005.
[14] M. Hansen and H. Tschofenig, “A Terminology for Talking about Privacy by Data
Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity,
and Identity Management,” Vols. Available at: http://dud.inf.tu-
dresden.de/literatur/Anon_Terminology_v0.34.doc, 2010.
[15] E. Syta, “Private eyes: Secure remote biometric authentication,” 12th International Joint
Conference on e-Business and Telecommunications (ICETE), p. 243–250, 2015.
[16] C. Rathgeb and A. Uhl, “A survey on biometric cryptosystems and cancelable biometrics,”
EURASIP Journal on Information Security, pp. 1-25, 2011.
[17] B. Byfield, “Hide Cloud Data from the Cloud Vendor: Secure Storage with Tahoe-LAFS, Linux
Pro Magazine,” no. Available at:

https://www.linuxpromagazine.com/Online/Features/Hide-Cloud-Data-from-the-Cloud-
Vendor, 2014.
[18] E. Mansour, “A Demonstration of the Solid Platform for Social Web ApplicationsSt,”
Proceedings of the 25th International Conference Companion on World Wide Web. Republic
and Canton of Geneva, CHE: International World Wide Web Conferences Steering Committee
(WWW'16 Companion), pp. 223-226, 2016.
[19] M. Ramachandran, “Towards Complete Decentralised Verification of Data with
Confidentiality: Different ways to connect Solid Pods and Blockchain,” Companion
Proceedings of the Web Conference 2020. New York, NY, USA: Association for Computing
machinery (WWW'20), pp. 645-649, 2020.
[20] M. Eisenstadt, “COVID-19 Antibody Test/Vaccination Certification: There’s an App for That,”
IEEE Open Journal of Engineering in Medicine and Biology, vol. 1, p. 148–155, 2020.
[21] D. Buchner, “Identity Hub, Decentralized Identity Foundation (DIF),” no. Available at:
https://github.com/decentralized-identity/identity-hub/blob/main/spec/spec.md, 2021.
[22] D. Buchner, “ Identity Hub Data Encryption and Sharing, Hub Encryption Proposal,” no.
Available at: https://github.com/decentralized-
identity/papers/blob/master/Hub%20Encryption%20Proposal%20-%20Draft%201.pdf,
2019.
[23] D. Longley, “Encrypted Data Vaults 0.1, Encrypted storage for the Web,” no. Available at:
https://digitalbazaar.github.io/encrypted-data-vaults/, 2020.
[24] C. Lemmer Webber, M. Sporny and M. S. Miller, “Authorization Capabilities for Linked Data
v0.3, An object capability framework for linked data systems,” no. Available at: https://w3c-
ccg.github.io/zcap-ld/, 2020.
[25] A. Guy, “Encrypted Data Vaults,” no. Available at:
https://nbviewer.jupyter.org/github/WebOfTrustInfo/rwot9-prague/blob/master/final-
documents/encrypted-data-vaults.pdf., 2019.
[26] S. Alboaie, M. Cuomo, C. N. Ursache, D. Sava, A. Gheorghiu, A. Shah and L. Alboaie, OpenDSU
Bluepaper (Draft 2.0), opendsu.com, 2020.
[27] S. Alboaie and B. Mastahac, “Anchoring,” [Online]. Available:
https://opendsu.com/?openDSU/rfc004.html.

PharmaLedger – Advanced confidentiality methods

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PharmaLedger – Advanced confidentiality methods

Similar to PharmaLedger – Advanced confidentiality methods (20)

More from PharmaLedger

More from PharmaLedger (12)

Recently uploaded

Recently uploaded (20)

PharmaLedger – Advanced confidentiality methods