ETSI GR PDL 014 V1.1.1 (2022-10)

Permissioned Distributed Ledger (PDL); Study on non-repudiation techniques

DGR/PDL-0014_non_repud_tech

General Information

• Status: Not Published
• Technical Committee: PDL - Permissioned Distributed Ledger
• Current Stage: 12 - Completion
• Due Date: 11-Oct-2022
• Completion Date: 10-Oct-2022

Standards Content (Sample)

GROUP REPORT
Permissioned Distributed Ledger (PDL);
Study on non-repudiation techniques
Disclaimer
The present document has been produced and approved by the Permissioned Distributed Ledger (PDL) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR PDL 014 V1.1.1 (2022-10)

Reference
DGR/PDL-0014_non_repud_tech
Keywords
interoperability, scalability, security, smart contract

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GR PDL 014 V1.1.1 (2022-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Introduction to Non-Repudiation Techniques . 8
4.1 Definition . 8
4.2 Types of Non-Repudiation . 8
4.2.1 Introduction. 8
4.2.2 Non-Repudiation of Origin (NRO) . 9
4.2.3 Non-Repudiation of Emission (NRE) . 9
4.2.4 Non-Repudiation of Receipt (NRR) . 9
4.2.5 Non-Repudiation of Submission (NRS) . 9
4.2.6 Non-Repudiation of Delivery (NRD) . 9
4.2.7 Non-Repudiation of Transport (NRT) . 9
4.3 Generalized Non-Repudiation Scenarios . 10
4.4 Non-Repudiation Process . 10
5 Objects of Non-repudiation . 11
5.1 Introduction . 11
5.2 Pre-requisite . 11
5.2.1 Evidence Recovery . 11
5.2.2 Redact . 11
5.2.2.1 Introduction . 11
5.2.2.2 Difference between Data Masking and Data Redacting . 12
5.2.3 Robustness . 12
5.2.4 Performance . 12
5.2.5 Transparency and Auditability . 12
5.2.6 Coalition Resistance . 12
5.2.7 Evidence . 12
5.2.8 Fairness . 12
5.2.9 Order Preserving . 13
5.2.10 Protection Granularity. 13
5.2.11 Digital Signatures . 13
5.2.11.1 Introduction . 13
5.2.11.2 Considerations . 13
5.2.11.2.1 Hashing and Signing Algorithm . 13
5.2.11.2.2 Hashing and Key Sizes . 13
5.2.11.2.3 Certificate Authority (CA). 13
5.2.12 Types of Digital Signatures . 13
5.2.12.1 Introduction . 13
5.2.12.2 Aggregate Signatures . 14
5.2.12.3 Group Signatures . 14
5.2.12.4 Ring Signatures . 14
5.2.12.5 Blind Signatures . 14
5.2.12.6 Proxy Signatures . 14
5.2.13 Evaluating Signature Schemes . 14
5.2.13.1 Introduction . 14
5.2.13.2 Bilinear Pairing (BP) based schemes . 15
ETSI
4 ETSI GR PDL 014 V1.1.1 (2022-10)
5.2.13.3 Non BP based schemes . 15
5.2.13.4 Overheads due to Mathematical operations . 15
5.3 Smart Contracts . 15
5.4 Oracles . 16
5.5 Trust Anchors . 16
5.6 Governance. 16
6 Scenarios . 16
6.1 Introduction . 16
6.2 Attacks to Data Communication . 17
6.3 Malicious Participants . 17
6.4 PDL Network External Storages . 18
6.4.1 Introduction. 18
6.4.2 External Smart Contracts . 19
6.4.3 External PDL Networks . 19
6.4.4 GDPR Considerations . 20
6.4.5 Oracles . 21
7 Mitigation Techniques . 21
7.1 Introduction . 21
7.2 Reputation-based Solutions . 21
7.3 Periodic Audits . 22
7.4 Incentivisation . 22
7.5 Governance Role . 23
7.6 Trusted Third Party (TTP) . 23
7.7 Zero Knowledge Proof (ZKP) . 23
8 Recommendations . 23
History . 24

ETSI
5 ETSI GR PDL 014 V1.1.1 (2022-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Permissioned Distributed
Ledger (PDL).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR PDL 014 V1.1.1 (2022-10)
1 Scope
The present document covers the non-repudiation challenges in Permissioned Distributed Ledgers (PDLs), the
non-repudiation strategies/technologies, and their viability in PDLs. It also defines the limitations in non-repudiation
strategies in PDLs and possible future directions.
The present document discusses PDL based end-to-end architecture that provides non-repudiation. This includes non-
repudiation for input and output data for a PDL, such as external PDLs and smart contracts.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF RFC 4270: "Attacks on Cryptographic Hashes in Internet Protocols".
NOTE: Available at https://datatracker.ietf.org/doc/html/rfc4270.
[i.2] David Chaum: "Blind Signatures for untraceable Payments".
NOTE: Available at http://blog.koehntopp.de/uploads/Chaum.BlindSigForPayment.1982.PDF.
[i.3] Masahiro Mambo, Keisuke Usuda, Eiji Okamoto: "Proxy Signatures for Delegating Signing
Operation".
NOTE: Available at https://dl.acm.org/doi/pdf/10.1145/238168.238185.
[i.4] ETSI GS PDL 012: "Permissioned Distributed Ledger (PDL); Reference Architecture".
NOTE: Available at https://www.etsi.org/deliver/etsi_gs/PDL/001_099/012/.
[i.5] D. Boneh: "Aggregate Signatures", in Encyclopedia of Cryptography and Security, H. C. A. van
Tilborg and S. Jajodia, Eds. Boston, MA: Springer US, 2011, p. 27.
[i.6] ETSI TS 133 303 (V14.1.0): "Universal Mobile Telecommunications System (UMTS); LTE;
Proximity-based Services (ProSe); Security aspects (3GPP TS 33.303 version 14.1.0 Release 14)".
[i.7] D. He, J. Chen, and R. Zhang: "An efficient identity-based blind signature scheme without bilinear
pairings", Comput. Electr. Eng., vol. 37, no. 4, pp. 444-450, Jul. 2011, doi:
10.1016/j.compeleceng.2011.05.009.
[i.8] T. Peacock, P. Y. A. Ryan, S. Schneider, and Z. Xia: "Verifiable Voting Systems", Comput. Inf.
Secur. Handb., pp. e293-e315, 2013, doi: 10.1016/B978-0-12-803843-7.00090-9.
ETSI
7 ETSI GR PDL 014 V1.1.1 (2022-10)
[i.9] D. A. Wijaya, J. Liu, R. Steinfeld and D. Liu: "Monero Ring Attack: Recreating Zero Mixin
th
Transaction Effect", 2018 17 IEEE International Conference On Trust, Security And Privacy In
Computing And Communications/12th IEEE International Conference On Big Data Science And
Engineering (TrustCom/BigDataSE), 2018, pp. 1196-1201, doi:
10.1109/TrustCom/BigDataSE.2018.00165.
[i.10] Goldreich, Oded, and Yair Oren: "Definitions and properties of zero-knowledge proof systems".
Journal of Cryptology 7.1 (1994): 1-32.
NOTE: Available at https://www.wisdom.weizmann.ac.il/~oded/PSX/oren.pdf.
[i.11] Manoj Kumar Chande, Cheng-Chi Lee & Chun-Ta Li (2018): "Cryptanalysis and improvement of
a ECDLP based proxy blind signature scheme", Journal of Discrete Mathematical Sciences and
Cryptography, 21:1, 23-34, DOI: 10.1080/09720529.2017.1390845.
[i.12] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, and R. Dahab: "Nanoecc: Testing the limits
of elliptic curve cryptography in sensor networks", in European conference on Wireless Sensor
Networks. Springer, 2008, pp. 305-320.
[i.13] ETSI GS PDL 011: "Permissioned Distributed Ledger (PDL); Specification of Requirements for
Smart Contracts' architecture and security".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/PDL/001_099/011/01.01.01_60/gs_PDL011v010101p.pdf.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
auditability: ability of an object to undergo a thorough examination and evaluation
NOTE: Generally, auditability is measured against criteria defined by certain authority, such as the
PDL governance.
governance: collection of rules and tools that control the behaviour and function of a PDL Platform (see ETSI
GS PDL 012 [i.4]).
identifiable natural person: one who can be identified, directly or indirectly, in particular by reference to an identifier
such as a name, an identification number, location data, an online identifier or to one or more factors specific to the
physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
mainchain: primary non-dependent chain which forms the PDL network
PDL participants: nodes which form the PDL network
personal data: any information relating to an identified or identifiable natural person
sidechain: sub-chain which is dependent on a mainchain
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programmable Interface
ETSI
8 ETSI GR PDL 014 V1.1.1 (2022-10)
BP Bilinear Pairing
CA Certificate Authority
CRC Cyclic Redundancy Check
ECDSA Elliptic Curve Digital Signature Algorithm
GDPR General Data Protection Regulation
I/O Input/Output
IoT Internet of Things
MD5 Message Digest 5
NFT Non-Fungible Token
NR Non-Repudiation
NRD Non-Repudiation of Delivery
NRE Non-Repudiation of Emission
NRO Non-Repudiation of Origin
NRR Non-Repudiation of Receipt
NRS Non-Repudiation of Submission
NRT Non-Repudiation of Transport
PKI Public Key Infrastructure
RSA Rivest-Shamir Adleman
SHA Secure Hashing Algorithm
TCP Transmission Control Protocol
TTP Trusted Third Party
ZKP Zero Knowledge Proof
4 Introduction to Non-Repudiation Techniques
4.1 Definition
IETF RFC 4270 [i.1] defines non-repudiation as:
"A Security service that provides protection against false denial of involvement in a communication."
Distributed ledges inherently implement non-repudiation through strategies such as digital signatures. Also, every node
in the network keeps a record copy; therefore, it is theoretically unrealistic to deny a digitally signed transaction.
However, in some situations, it is required to verify data integrity. For example, in the cases of smart contract
offloading [i.2].
Therefore, non-repudiation, particularly in PDLs, can be defined as:
"Verification techniques and strategies that can provide secure proof that the data entered to/from the PDL are from
a valid source and is unaltered, that is, same as entered by the source."
For example, when capturing temperature data, it can be confirmed that the data captured from the thermometer is
unaltered, but it cannot be guaranteed that the thermometer is accurate. In such a case, strategies such as device identity
will play a key role.
EXAMPLE: Laboratory calibration confirmation and data, will be associated with the device (e.g. thermometer)
identity.
Permissioned Distributed Ledgers (PDLs) provide accountability to the transactions through their inherent properties
such as transparency. Historic transactions provide an audit trail for a future audit and produces undeniable records.
However, in an end-to-end scenario, a PDL will not be a solitary entity and will include other functional components
such as oracles and external data storage.
4.2 Types of Non-Repudiation
4.2.1 Introduction
In distributed ledgers, the role of non-repudiation is to collect evidence, verify and authenticate the source of data. In
this clause, the types of non-repudiation relevant to PDLs are discussed.
ETSI
9 ETSI GR PDL 014 V1.1.1 (2022-10)
4.2.2 Non-Repudiation of Origin (NRO)
Non-Repudiation of Origin (NRO) is an application layer consideration and proves that the data is from the source
claimed by the message.
PDLs often take data inputs from various data sources, for instance, via oracles or in/directly from the devices. In such a
situation, the authenticity of the data source will need to be verified.
4.2.3 Non-Repudiation of Emission (NRE)
Non-Repudiation of Emission (NRE) is a network layer consideration. It provides proof that the data sent is accurate
and unaltered while being sent to and stored on the PDL.
In PDLs, this problem may occur when a user sends a valid message and a malicious party in the middle tampers with
the message.
EXAMPLE: A user sends a bid through smart contract execution, a malicious user changes the bid as per
latter's advantage.
4.2.4 Non-Repudiation of Receipt (NRR)
Non-Repudiation of Receipt (NRR) is the false denial of the receipt of a message. Typically, Permissioned Distributed
Ledgers are inherently resilient to NRR because of their distributed nature. As long as the majority (as required by the
consensus mechanism) of nodes receive the message correctly, it will be distributed to all the other nodes even if they
maliciously deny the receipt from the sender.
4.2.5 Non-Repudiation of Submission (NRS)
Generally Non-Repudiation of Submission (NRS) provides proof that the sender submitted the data for delivery.
Since Permissioned Distributed Ledgers are implemented on the public Internet they are prone to transaction delay and
network layer congestion. For example, a remote device sends data to a PDL node, and the transaction is delayed due to
network conditions. In certain cases, such delay may render the data invalid. Non-Repudiation of Submission offers a
set of tools that can prove that a transaction is valid.
Additionally, NRS may resolve some security vulnerabilities for the PDLs related to receipt of data from external
resources. For instance, when the data or a smart contract is sent by an external storage or oracle, it is prone to
malicious activity (e.g. virus) in the PDL. NRS provides the sender and the recipient the ability to verify the integrity of
the data and the proof of submission.
4.2.6 Non-Repudiation of Delivery (NRD)
NRD provides the sender a set of tools that can prove that data was submitted and delivered to the recipient even if the
recipient denies the receipt and/or fails to act upon the data received.
In PDLs, typically NRD is addressed in the context of Trusted Third Party (TTP) and provides the proof that the data
was handed to the TTP or a Delivery Agent for delivery. Yet, distributed ledgers, in particular, PDLs advocate
distributed trust and there is no TTP by the definition of PDL. Despite the distributed trust, PDLs should still offer NRD
to enable data and smart contract efficiency and distribution. Specifically, in situations where the smart contracts are
stored on third-party managed external storage.
4.2.7 Non-Repudiation of Transport (NRT)
Non-Repudiation of Transport (NRT) provides the proof that the data was sent by the sender and transported by the
delivery agent (e.g. transport channel). NRT is different from NRD, due to the fact that there may be several transport
entities involved in one end-to-end message delivery.
ETSI
10 ETSI GR PDL 014 V1.1.1 (2022-10)
4.3 Generalized Non-Repudiation Scenarios
Unreliable Communication Channel: The sender sends a transaction that is dropped/delayed due to poor connectivity
conditions or malicious activities on the transmission channel such as Man-in-The-Middle Attack. This may affect both
the sender and the recipient because it may cause delay or non-approval of transactions and consequently may result in
monetary losses for the parties.
Malicious Sender: The device user or sender is malicious and sends wrong, late or no data. In the example of smart
contract external storage, it may include both the owner and the user of the device [i.2].
Malicious Receiver: The receiver of the data is being malicious and denies the receipt of the data. In a PDL scenario,
the receiver is expected to be PDL nodes. However, this problem may arise when data traverses an intermediate
object/entity such as an API.
4.4 Non-Repudiation Process
By definition, the non-repudiation, is a technique to generate proof that, at a later date, both the service and receiver can
use to ensure proper operation of the PDL. Four phase processes for non-Repudiation are defined in [i.3] as follows:
Evidence Generation
The evidence of the message is generated by the respective participants of the system, for example, a sender or receiver.
This evidence will later be used by the parties to verify that the data was transmitted/received by the other participant
and prevent them denying generation/receipt of the data.
Evidence Transfer and Storage
The evidence generated by the sender/receiver are expected to be stored securely in local/governance-controlled
storage.
Evidence Verification
The evidence of the transfer (of assets or an entity) is expected to be verifiable.
Dispute Resolution
In the case of PDLs, dispute resolution can be handled by the governance.
Evidence
Evidence Evidence Dispute
Transfer and
Generation Verification Resolution
Strorage
Figure 1: Non-repudiation process
ETSI
11 ETSI GR PDL 014 V1.1.1 (2022-10)
Table 1: Examples of non-repudiation and possible solutions
Challenges/Objects Example Scenarios where Possible solutions
challenges occur
Mismatched data - sent by the NRE, NRD The sender sent the data and the receiving
originator and received by the recipient party received that but the proofs are
are inconsistent or not the same mismatching, or not same. In this scenarios, the
dispute can be launched and governance can
step-in to resolve the issue.
Delayed data - data arrived at the NRT, NRD, NRE Timestamps can be recorded in a hashed form
destination after the allotted period of together with the data. Sometimes, timestamps
time can be encrypted part of the data. This problem
applies to the time-critical data.
Tampered data (both accidental and NRE, NRD Regular device health checks, and monitoring of
malicious) - the data sent is tampered transmission delays/losses can help the parties
by the sender, receiver or a man-in- to identify the real reason of data tampering. In
the-middle PDLs, the governance, can also take
compliance actions against the parties with poor
transmission record and may set standards for
connection and security requirements. Multiple
transmission ways can also be adopted to
ensure the integrity of data.
Erroneous data - the data sent is NRE Here regular device checks and governance
incorrect or not complying with the compliance strategies can help.
agreed/set standards
Missing/incomplete data - the data is NRE, NRD, NRD Governance compliance strategies and regular
not sent at all/or missed by the node checks can help.
communication channel
Data Re-ordering - data arrives in a NRE, NRD, NRT Application layer protocols for reordering the
sequence different than it was sent packets, at a cost of additional delays.

5 Objects of Non-repudiation
5.1 Introduction
In PDLs, data is written to a ledger by internal and external participants. This includes PDL nodes and oracles; the main
objective is that the data integrity is maintained. In this clause, the key properties for a non-repudiation mechanism are
highlighted.
5.2 Pre-requisite
5.2.1 Evidence Recovery
In networks, the evidence (e.g. receipt) are sent through a wireless/wired link. These links may suffer from disruption or
performance issues that may cause data loss, which may result in delayed or lost evidence. In some applications, such
delays in evidence arrival may cause the stakeholders losses such as a delayed bid. Therefore, the evidence generated by
either party needs to be recoverable with correct parameters (e.g. time original evidence was sent).
5.2.2 Redact
5.2.2.1 Introduction
In business applications particularly a document may include numerous details such as stakeholders' personal
information and previous business dealings. When a number of parties involved in a dealing or business, the whole
document cannot be disclosed to all the parties, nor the non-repudiation of a complete document is required. For
example, in a loan application, non-repudiation of finances may be required, and stakeholders' personal records may be
irrelevant and can be kept hidden through mechanisms such as encryption.
ETSI
12 ETSI GR PDL 014 V1.1.1 (2022-10)
A good non-repudiation mechanism ought to provide Redaction. That is participants are allowed to disclose the relevant
part of the data for non-repudiation purposes only and the rest of the document (the document for non-repudiation) can
be hidden/masked. The non-repudiation proof will be for a revealed/disclosed part of the document (the document for
non-repudiation) only.
5.2.2.2 Difference between Data Masking and Data Redacting
The difference between data redaction and data masking is that the former hides the sensitive details such as credit card
information. Data Masking may cause the risk on digital platforms because nullified attributes may cause unpredictable
results (e.g. divide by zero).
Data Redacting changes the data by replacing part or all of the actual data and other techniques such as encryption. The
result is an attribute with readable but meaningless information for interceptor.
Both techniques are useful for GDPR compliance purposes.
5.2.3 Robustness
A non-repudiation mechanism is expected to be unbreakable by advanced systems such as quantum computing. Such
that a malicious party will not be able to break the security mechanism and produce false non-repudiation proofs under
any circumstances.
5.2.4 Performance
The non-repudiation protocol is needed to be computation and space efficient. In a PDL scenario, performance metrics
such as latency, bandwidth and computational power of the devices (e.g. PDL nodes, external storage) should be taken
into account when adopting a NR protocol.
5.2.5 Transparency and Auditability
Distributed ledgers (both permissioned and permissionless) are transparent by definition and design, which is one of the
reasons for their wide adoption. To maintain the property of transparency, non-repudiation protocols used by PDL
networks, need to be transparent and auditable. The code and algorithms of a NR protocol will be freely auditable and
open-sourced.
5.2.6 Coalition Resistance
To maintain the trustworthiness of a PDL platform, NR protocols adopted by such platform should be coalition
resistant. It should discourage any collusion between the PDL stakeholders in a manner that may influence the decisions
of a consensus or governance.
5.2.7 Evidence
Evidence produced by a NR protocol is secure, non-changeable and transparent. It is generated in a timely manner and
communicated securely over a communication channel.
Most of the existing non-repudiation systems use receipts as an evidence of delivery. Using cryptographic methods
(e.g. CRC) can ensure that recipient has received message unaltered. In such a case NR protocol will ensure that the
receipts generated are unforgeable, untamperable and generated with minimal network resources. Moreover, the
receipts are communicated in a timely manner. The receipts can provide details such as time, date and other metrics
defined by the PDL governance.
5.2.8 Fairness
A non-repudiation protocol should not give advantage, in terms of, for example, computational power and memory, to
one party over another. Governance can ensure that non-repudiation algorithms adopted by the PDL platform are
adequately implemented by all the internal and external participants. However, in some situations, governance may
need to ask the nodes to make necessary upgrades to enable a more robust non-repudiation algorithm. The point is, no
one party, under any circumstances, gets benefited over another.
ETSI
13 ETSI GR PDL 014 V1.1.1 (2022-10)
5.2.9 Order Preserving
In case of TCP communication, data may arrive in different order. Indeed, packet headers allow reassembly of the
packets and enable to correct the order of messages at the receiver's end. This property is also required to be available at
the non-repudiation layer. It is important that the non-repudiation technique is able to verify the order of the messages
sent by the source.
5.2.10 Protection Granularity
The non-repudiation proofs can be verified at the byte or message level or periodically (e.g. every second or every
10 bytes or so). The governance of the PDL may specify the required granularity at the time of the PDL initialization.
5.2.11 Digital Signatures
5.2.11.1 Introduction
Digital signatures provide a method to verify the authenticity of a document digitally. The sender signs the hash of the
document/data, to be signed, with its private key and sends the document/data along with the corresponding public key.
Generally, in distributed ledgers, participants (i.e. nodes) use digital signatures to verify the Non-Repudiation of Origin
(NRO). Such non-repudiation enables trust in the distributed ledgers.
5.2.11.2 Considerations
5.2.11.2.1 Hashing and Signing Algorithm
The document/data is hashed and encrypted with sender's private key producing a digital signature. There are several
hashing and signing algorithms available for digital signatures such as MD5, ECDSA, RSA and SHA and others. The
choice of signing algorithm depends on factors such as computational power and required level of security.
In PDLs, however, governance approved hashing and signing algorithms will enable the consistency and uniformity in
the PDL system.
5.2.11.2.2 Hashing and Key Sizes
The consideration of hashing algorithm leads to the consideration of key size. Hashing algorithms vary with key sizes,
for instance, SHA-3, supports, several key sizes such as 20 and 32 bytes. Signing algorithms such as RSA need to
support appropriate key sizes (i.e. > 3 072 bits) to ensure secure signing of the data.
It is up to the governance of the PDL to choose a suitable key size with a suitable hashing and signing algorithm. Note
that hash can be keyed or non-keyed, the reliability of the protocol depends on the final digest length. Governance may
also consider such factors whilst choosing hashing and signing algorithms.
5.2.11.2.3 Certificate Authority (CA)
Digital signatures need public/private key pairs. Certificate authorities can be used to verify the validity of public keys.
They maintain the mapping between the public key and key holder. Although self-issued public/private keys are widely
used, it is a good practice to use CA-registered keys to ensure the genuinity and traceability of the identity.
In PDLs, several models for a Certificate Authority (CA) are possible. A CA can be a subsidiary of the governance, or
an external entity accepted by the governance for key management. In the situations of external participants, the
external governance may issue the keys which may be acceptable by the other PDL network. The governances may
maintain a list of approved/recommended external certificate authorities.
5.2.12 Types of Digital Signatures
5.2.12.1 Introduction
There are several types of digital signature schemes proposed by the industry and the academia. Yet, all the schemes
have their pros and cons. In this clause, some of the widely-discussed schemes are highlighted.
ETSI
14 ETSI GR PDL 014 V1.1.1 (2022-10)
5.2.12.2 Aggregate Signatures
Aggregate signature algorithm combines the digital signatures of two or more parties and produces a single signature
which validates all the signatures. In a PDL scenario, aggregate signatures can be useful for validating the external data.
For example, an API can take the input from several data sources, to ensure the validity of data and combines all the
signature and produce an aggregate signature. Yet, aggregate signatures conceals the identity of the signers, it is
difficult to trace the individual signers in this case.
5.2.12.3 Group Signatures
A group member signs the document on behalf of the whole group. Group signatures removes the link between the
signer of the document and its public key, hence, even if the adversary acquires the private keys of the group members,
they will not know, which group participant, in fact, signed the document. Generally, group signatures are useful when
the anonymity of the signers is required. The signer is known to the group and is selected by an algorithm.
5.2.12.4 Ring Signatures
Ring signatures are similar to group signatures, however, in Ring Signatures, signers are selected randomly from the
group. None of the participants of the group have the knowledge about the actual singer beforehand, therefore they
provide higher degree of privacy in the PDL network. Due to the random selec
...