Long-term digital signatures · 2019-07-13 · simple mp3 ﬁle. Which is not the case of a XAdES...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Long-term digital signatures

Pedro Cunha

DISSERTATION

Mestrado Integrado em Engenharia Informática e Computação

Supervisor: Rui Maranhão, Ph.D.

March 5, 2015

Long-term digital signatures

Pedro Cunha

Mestrado Integrado em Engenharia Informática e Computação

March 5, 2015

Abstract

Digital signatures are a requirement for the future.

Information in general and documents in particular (the standard being PDF) is increasinglybecoming more about bits and bytes and less about paper. But the only way to ensure that thishappens successfully is to make a digital signature in all things as equivalent to a traditional one.A signature in itself has undergone major modification throughout the time, from wax seals tohand-written signatures. The next step is digitalization. However, simple digital signatures arenot sufficient, since they have a very limited lifespan. This thesis approaches the method of long-term digital signatures in a way that, since there is no definite evaluation between the standardsthat exist today, there is no clear way to define which one is the best. Hence, one of the goals isto demonstrate in which situation should each one be used and make it more definite which oneis preferable. Since there is no single or "best" standard, there isn’t also a software that can bedefined as the one to use where long-term digital signatures are concerned.

After a series of tests using the three standards, this dissertation proposes not only a case-by-case use of each standard, but also a software that was developed to aid in the growth of digitalsignatures as the main method of signing documents and files. The main conclusions are thatCAdES is the by-default standard to be used. It is both faster and occupies the least amount ofspace on disk, which, even though a one for one comparison with XAdES doesn’t seem a lot, if weconsider thousands of files to be signed, it can reach significant savings. One main disadvantageis that CAdES signatures can’t be seen in the file. An mp3 file with a signature will appear as asimple mp3 file. Which is not the case of a XAdES signature, since the output is in XML lan-guage. This format can break the functionality of the files, though, if attached to them, hence wesave it for XML files, since it made sense to maintain the same formatting scheme of the originalfile. PAdES is used in one and only one circumstance: to sign PDF files in which the signature isto be included inside the PDF. PAdES uses CAdES as its main signature creation method, but itmakes it so that PDF readers that show signatures can display the ones created using PAdES. Thisis specially important for enterprise use and official documents.

Keywords Digital Signatures, Time-stamp, Long-term, Cryptography, Public-key, Public KeyInfrastructure

i

Resumo

Assinaturas digitais são um requerimento para o futuro.

A informação em geral e a documentação em particular estão a manifestar-se cada vez maisem bits e bytes e cada vez menos em papel. Mas a única forma de garantir que isto acontececom sucesso é através da criação de assinaturas digitais, em tudo equivalentes às tradicionais. Opróprio conceito de assinatura sofreu alterações ao longo do tempo, desde selos com cera até àsassinaturas manuscritas. O próximo passo é a digitalização. Contudo, assinaturas digitais simplesnão são suficientes, visto que têm um período de vida muito limitado. Esta tese aborda o método deassinaturas digitais de longo-prazo de uma forma através da qual se demonstra em que situaçõescada um dos standards deve ser usado e se define qual deles é preferível. Visto que, na faltade uma ou da melhor especificação, não haverá consequentemente um software definido comorecomendável no que às assinaturas de longa duração diz respeito.

Após uma série de testes, utilizando os três standards, propomos não só a sua utilização casoa caso, como também um software desenvolvido para ajudar no crescimento do uso de assinaturasdigitais enquanto principal método para assinar ficheiros e documentos. Concluímos que o CAdESé o standard a ser usado por defeito. É, ao mesmo tempo, mais rápido e ocupa o menor espaçoem disco. Sem prejuízo de numa comparação um para um com o XAdES a diferença não sermuita, se considerarmos milhares de ficheiros que precisam de ser assinados, o CAdES consegueatingir poupanças bastante significativas. Contudo, este standard tem uma principal desvantagemem relação ao XAdES: se a assinatura for incluída num ficheiro, não há maneira de saber (à "vistadesarmada") que ela está lá. Isto é, um ficheiro mp3 continuará a pare- cer apenas um simplesficheiro mp3, o que não acontece usando o XAdES, visto que a assinatura é sempre em XML.No entanto, este formato pode quebrar a funcionalidade original do ficheiro, pelo que será usadoapenas em ficheiros já de si em XML, visto que, para estes, faz sentido manter tudo na mesmalinguagem de anotação. Por fim, o PAdES é usado numa única circunstância: para assinar docu-mentos em PDF cuja assinatura tenha de ser incluída com o próprio documento. O PAdES usa,internamente, para assinar ficheiros, o CAdES, mas fá-lo de forma a que os leitores de PDF queconseguem ler assinaturas as possam mostrar, o que é especialmente importante para uso empre-sarial e para documentos oficiais.

Palavras Chave Assinaturas Digitais, Assinaturas Temporais, Longa Duração, Criptografia,Chave Pública, Infrastrutura de Chave Pública

iii

Acknowledgements

Several people were fundamental in the development of this Thesis. I would like to thank ProfessorRui Maranhão for all its guidance, Renato Portela for giving me the opportunity to work alongsideall the people in MULTICERT, as well as all the advice, guidance and teachings.

I would also like to thank José Martins for his assistance in figuring out the outline of thesoftware and all the laughs, Rui Baeta for all the back and forth discussions about the technologiesused in the Thesis and Robert Bielecki for his help and support in using core framework in whichthe Thesis stands.

Thank you as well to all the other people working at MULTICERT for making my time therea great one.

Finally, I would like to give a special thank you to my family for all their support throughoutthese years that led to this conclusion and for believing in me all this time.

Pedro Cunha

v

“Secured Signing enables us to finalise deals and to sign contractswith our worldwide customers within minutes. Our ability to efficiently close

these deals results in positive responses from our clients and therefore increased sales”

John Kavanagh, Director, ASC MIGRATION

vii

Contents

1 Introduction 11.1 Dissertation Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Document’s Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work and State of the Art 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 PKCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 PKCS #1 RSA Cryptography Standard . . . . . . . . . . . . . . . . . . 52.2.2 PKCS #7 CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 PKCS #11 Cryptographic Token Interface Standard . . . . . . . . . . . . 62.2.4 PKCS #12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 PKI - Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 XMLDSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Trusted Time-stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 XAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 CAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.8 PAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.9 ASiC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.10 AdES-Baseline Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.11 SD-DSS - Digital Signature Service . . . . . . . . . . . . . . . . . . . . . . . . 162.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 LTDSIGS - Long-Term Digitial Signature Service 193.1 AdES Selection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 LTDSIGS-Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 LTDSIGS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 LTDSIGS-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Testing and Validation 334.1 Comparing the AdES family . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Testing Data and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.2 Metrics Comparison and Analysis . . . . . . . . . . . . . . . . . . . . . 374.1.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 e-Signature Validation Plugtest . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ix

CONTENTS

4.2.1 Plugtest Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2 LTDSIGS Signatures Validation . . . . . . . . . . . . . . . . . . . . . . 444.2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Conclusion 475.1 Results and Objectives Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2 Summary and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.1 Retesting with New/New Versions of AdES Standards . . . . . . . . . . 495.3.2 Improving LTDSIGS-Client’s GUI . . . . . . . . . . . . . . . . . . . . . 495.3.3 Implement Support for more Hardware Providers . . . . . . . . . . . . . 495.3.4 Use ASiC for Detached Signatures . . . . . . . . . . . . . . . . . . . . . 50

References 51

A Testing Environment 55

x

List of Figures

2.1 Basic XAdES diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 XAdES-BES, XAdES-T and XAdES-C diagram . . . . . . . . . . . . . . . . . . 102.3 XAdES-X and XAdES-X-L diagram . . . . . . . . . . . . . . . . . . . . . . . . 112.4 XAdES-A diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 CAdES-BES diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 CAdES-T diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 CAdES-T diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 CAdES-A diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 LTDSIGS General Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 AdES Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 LTDSIGS-Server’s high-level diagram . . . . . . . . . . . . . . . . . . . . . . . 263.4 Messaging Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 LTDSIGS-Client High-level Architecture . . . . . . . . . . . . . . . . . . . . . 283.6 LTDSIGS-Client GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 LTDSIG-Client Managing Interface . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Interaction and Cross-Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Initial Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Signature Generation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xi

LIST OF FIGURES

xii

List of Tables

3.1 AdES use per packaging time per data type. . . . . . . . . . . . . . . . . . . . . 20

4.1 Supported types for AdES standard per packaging . . . . . . . . . . . . . . . . . 344.2 Comparison between non-detached AdES signatures in size and time . . . . . . . 354.3 Comparison between non-detached AdES signatures in size and time . . . . . . . 354.4 Comparison between detached AdES signatures in size and time . . . . . . . . . 364.5 Final evaluation between AdES standards . . . . . . . . . . . . . . . . . . . . . 374.6 ETSI Plugtest Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . 44

xiii

LIST OF TABLES

xiv

Abbreviations

W3C World Wide Web ConsortiumPKCS Public Key Cryptographic StandardsPKI Public Key InterfaceHTTP Hypertext Transfer ProtocolXML eXtendible Markup LanguageASN.1 Abstrance Syntax Notation OneCMS Cryptographic Message SyntaxXMLDSIG XML Digital SignatureAdES Advanced digital Electronic SignatureXAdES XML AdESCAdES CMS AdESPAdES PDF AdESCA Certificate AuthoritySSL Secure Sockets LayerANSI American National Standards InstituteMIME Multipurpose Internet Mail ExtensionsDSA Digital Signature AlgorithmETSI European Telecommunications Standard InstituteCRL Certificate Revocation ListAPI Application Programming InterfaceOCSP Online Certificate Status Protocol

xv

Chapter 1

Introduction

Going well into the 21st century, information and communication have become increasingly more

digital in nature[Sys09]. We see this not only in the amount of personal information people are

uploading to the Internet, but also in the growth of digital government and on-line communica-

tion. With the increase of documentation (official and unofficial) that is being shared and sent

by e-mail, by on-line submission or even by digital storage devices, the issue of authenticating

the author of said documents has become a very important concern. While the current crypto-

graphic system works on doing this, the time-frame during which it does so is very limited (i.e.

a signature created with the Portuguese Citizen Card would be valid, on its own, for about 4 years).

If we take into account that it is possible to verify the author of physical documents that are

hundreds of years old, a 2 or 4 year limit during which a digital signature/certificate is valid is

indeed too short. If documents are to make a definite leap towards complete digitalization, there

needs to be a way to guarantee that 20, 30 or even 100 years from now, a file signed today can

be traced back to its original author/signer. Hence the need arises for a digital signature which

not only withstands the passage of time but does so in such a way that overcomes its possible

cryptographic algorithm deprecation, possible tampering attempts and/or repudiation.

1.1 Dissertation Context

This thesis’ work is mainly in the field of cryptography, more specifically in the fields of long-time

digital signatures, public-key standards and signature validation. It was developed while working

closely with the company Multicert - Serviços de Certificação Electrónica S.A., under Eng. Re-

nato Portela.

Multicert is a 100% Portuguese company whose main focus is the issuing of digital certificates,

being the industry leader in Portugal with over 4 million certificates issued in 2010. They also

1

Introduction

present solutions in digital receipts, e-voting and information management. The company was

also involved in the creation of Portugal’s citizen’s card and the e-passport. It also developed

(alongside CTT - Correios de Portugal) and sells the official service used by the Lawyer’s Bar

Association to sign e-mails.

1.2 Motivation

The authenticity of a document is only valid while its digital signature is. For this reason, the long-

term preservation of a digital signature can pose a challenge to the current society. Certificates can

be revoked, companies that were trusted CAs at some point can fall in disgrace at another point in

time and cryptographic algorithms can become obsolete (i.e. DSA). To handle this issue, several

standards were created in order to provide digital signature with the capability of withstanding the

passage of time.

Despite this, there is no clear information or hint whatsoever as to which standard to use or

why in different scenarios. For said reason, this dissertation’s purpose was to study the problematic

of the use of digital signatures valid for long periods of time, compare the different standards in

order to discover the more pragmatic differences in using one or another and develop a prototype

solution that can the resulting conclusions to provide a more ubiquitous way to use long-term

digital signatures.

1.3 Goals

Given the fact that signatures need to be created using trusted certificates, the process of key-

generation and certificate requesting that was initially considered to be a part of the end software’s

functionalities was dropped. Therefore, the proposed solution is the following:

• Comparative studying of existing AdES standards given a set of metrics

– Space

– Ease of Use

– Performance

– User Experience

– Data Types

• Architecture and design of a Software Solution that can decide which of the AdES standards

to use.

• The Software must be able to handle as the source of the key-pair and corresponding Cer-

tificates both hardware devices and digital files

• The Software must analyze if a signature is becoming insecure due to the passage of time

and proceed accordingly

2

Introduction

• Testing of the application in the community

1.4 Document’s Structure

This document is divided into 5 chapters. The present one, the first, serves as an introduction to the

thesis, by stating the problem at hand and the thesis’s objective. Chapter 2 describes in detail the

state of the art related to digital signatures and the problematic of its long-term validation, includ-

ing a description of the current standards (XADES, CADES and PADES) as well as alternative

solutions that have been researched. It will also include a brief introduction to public-key cryp-

tography and certificates, in order to better frame the problem at hand. On Chapter 3, it presented

the LTDSIGS software as fulfillment of the objectives stated above, divided between the AdES

selection algorithm and the architecture of the different components of the solution. In Chapter 4,

the testing results are presented, both for the algorithm and to the end artifacts of the LTDSIGS

software, the signatures themselves. Finally, Chapter 5 presents the conclusions of the work and

the objectives proposed as well the contributions made and improvements that could be made in

the future.

3

Introduction

4

Chapter 2

Related Work and State of the Art

2.1 Introduction

The subject of long-term digital signatures encompasses many areas of the cryptography field,

from simple hashing of data to advanced encryption methods. This first section aims at providing

background context by diving into the state-of-the-art of cryptography itself, what algorithms are

considered nowadays to be safe and optimal and how they work. Later sections will discuss digital

signatures in themselves and how their time-spans can be extended to whatever limits are required.

2.2 PKCS

The Public Key Cryptographic Standards are specifications produced by the RSA laboratories

alongside security experts to help in advancing and improving public-key cryptography around

the world. First published in 1991, the PKCS has since become the main standard for many

current systems, including SSL, S/MIME (Secure MIME) and ANSI X9 documents. There are

currently 15 issues of PKCS, the following being the ones relevant to this thesis.

2.2.1 PKCS #1 RSA Cryptography Standard

This document[JK03] provides recommendations for the implementation of public-key cryptog-

raphy based on the RSA[RSA83] algorithm. In it are described the aspects of RSA concerning

cryptographic primitives, encryption schemes and digital signatures.

Currently on version 2.2, it defines the mathematics behind the implementation of the RSA

algorithm, including the creation of public and private keys. It also defines the primitive operations

that provide information on how to turn the mathematical formulas into algorithms that can be

computed.

The schemes defined in PKCS#1 are what puts the primitives into a security context by defin-

ing higher level algorithms to achieve certain objectives, such as encryption/decryption of data

5


and digital signatures schemes. These are signatures with appendix, as in, a hash function is run

through the data in question, producing a half-way representation, which is then signed with the

private key. This way, the hash data is proportional to the key being used, which usually has a size

much smaller than the original data.

Its relevance for this thesis is that PKCS#1 is the very foundation of secure cryptography

nowadays, which will be used to provide the ways to digitally sign documents in the first place,

before time constraints are even considered.

2.2.2 PKCS #7 CMS

The Cryptographic Message Syntax[HS09] is the standard for sending messages across a PKI that

are protected by cryptography. It can be used to encrypt, sign, produce digests and authenticate

all formats of digital data. It is built around certificate-based keys (the X.509 format) and is the

key component of S/MIME and digital time-stamping protocol. The popular and very wide spread

open source OpenSSL software is an implementation of CMS, being able to provide all of CMS’s

functionalities. It uses ASN.1 [Lar00] as its encoding format, making it ideal for networking

communications.

As far as PKCS#7’s relevance to the project, it provides the base for one of the current stan-

dards in long-term digital signatures. It also provides the way for requesting CAs for their part in

authenticating the signer of the document.

2.2.3 PKCS #11 Cryptographic Token Interface Standard

Several companies use physical hardware to store the cryptographic components used in public-

key cryptography (the public and private keys and the certificates used to sign data). In order to

provide a standardized interface for communication between the hardware and the software, RSA

specified PKCS#11 ([Woo03]). This standard is comprised by a platform independent API that

produces cryptographic tokens, which in turn contains the crypto information. It is used by Mozilla

Firefox and OpenSSL to provide access to smart cards and USB tokens, such as the Portuguese

Citizen’s Card.

It is this standard that provides the Software Solution created during the Dissertation the API

required to interact with external hardware sources of cryptographic information, namely the Por-

tugue Citizen’s Card and the SafeNet USB token.

2.2.4 PKCS #12

Instead of a hardware source, the cryptographic information required can also be stored as a file

inside the computer. For this, it is commonly used the PKCS #12 ([KMRM14]) format. Said

format is a somewhat equivalent of a zip archive, meaning that inside it stores both the private

key and its X.509 certificate and it can even store all the members of the chain of trust. It can

contain different sections inside, named SafeBags, that can be protected by different passwords

and encryption algorithms, making it possible to separate the private keys from the certificates, for

6


example. These files use the extensions .p12 and .pfx, the last one being the result of Microsoft’s

PFX (Personal Information Exchange) extension to PKCS #12.

These files are widely used, hence their use as one of the sources of cryptographic information

for the creation of digital signatures in the project.

2.3 PKI - Public Key Infrastructure

PKI is the main infrastructure beneath secure communications across the Internet[Vac04]. It al-

lows for users to communicate securely through a public, unprotected network through the use of

public-key cryptography and digital certificates that are made available from the PKI that certify

the key-pair values. At the moment, it is the technology behind why SSL and HTTPS (HTTP

through a secure connection) can provide security to the end users, protecting them from mali-

cious users that try to pretend themselves to be someone (or some company) they are not as well

as from someone who is "listening" to the connection.

PKI implements all of the PKCSs stated above (2.2) and more, relying on the strength of

public-key cryptography to ensure the safety of information being transmitted.

It consists in the following 4 entities:

• A CA that gives user’s digital certificates to certify their public-keys.

• An authority that verifies that a CA can be trusted to issue CAs.

• A virtual storage unit where the certified public keys (and respective certificates) are stored.

• A system to manage certificates that can handle new issuing and revocation.

Long-time digital signatures require a PKI of this sort with an additional entity, responsible for

verifying the time at which a signature was created for that document and for storing it alongside its

time-stamp. This entity (or another trusted one) is responsible for ensuring the signature remains

valid throughout the time (or until it is no longer relevant), as will be discussed in later sections.

2.4 XMLDSIG

An XML digital signature[BBF+08] is the closest to the perfect analogy of a "wet signature" (a

traditional signature made on paper). If taken into account that a normal digital document can

be described using XML language, XMLDSIG defines a collection of XML elements that could

be inserted into (if it signs part of the data, it’s called an enveloped signature, if the signature

contains the entire data it’s referred to as an enveloping signature) or even connected to the original

document’s XML (detached signature). This would allow the recipient to verify the authenticity

of the sender as a normal signature would. The syntax specified for XMLDSIG was developed by

the combined efforts of W3C and IETF (Internet Engineering Task Force) and it’s been the official

W3C recommendation since 2002[Sal03].

7


A XMLDSIG follows a single name-space available at the W3C website. Hence, at the top of

all XMLDSIGs, the following must be made available:

1 http://www.w3.org/2000/09/xmldsig#

Listing 2.1: XMLDSIG namespace to be included at the top

Taking a top-down approach to the syntax of the signature, the simple format of a XMLDSIG

is the following signature XML element (the symbols "?", "+" and "*" are used to represent 0 or

1, 1 or more and 0 or more occurrences, respectively):

1 <Signature ID?>

2 <SignedInfo>

3 <CanonicalizationMethod/>

4 <SignatureMethod/>

5 (<Reference URI? >

6 (<Transforms>)?

7 <DigestMethod>

8 <DigestValue>

9 </Reference>)+

10 </SignedInfo>

11 <SignatureValue>

12 (<KeyInfo>)?

13 (<Object ID?>)*

14 </Signature>

Listing 2.2: XMLDSIG basic signature element

1 The ID is used to identify a particular signature. It’s important if more than one signatures

are used (i.e. a document that needs both the Head of Financial department’s and CEO of a

company’s signatures).

2-10 The SignedInfo element is about the data that the signatures is actually signing. Inside we

have:

– the method of canonicalization, as in, how data is compressed to a minimized format;

– the method or algorithm (SignatureMethod) that is used to turn the canonicalized data

into the actual signature;

– the reference to the data that is being signed, including any transformations that are to

be applied prior to the signing, the method to produce the hash that represents the data

and its value;

11 SignatureValue hold the actual signature.

8


12 KeyInfo will hold the key to verify the signature used. It can also contain X.509 certificates

that authenticate the signer, as well as a Certificate Revocation List that proves that the

certificate was valid at the time.

13 Finally, the Object element contains the data to be signed in the even that it is an enveloping

signature.

Further specification of the several elements listed before can be found at this document’s

appendix.

One of the main standards in long-term digital signatures builds on top of XMLDSIG, ex-

tending its functionality and syntax in order to provide such a feature. Hence the importance of

XMLDSIG.

2.5 Trusted Time-stamping

Another important concept necessary for the purpose of enabling long-time digital signatures is

of trusted time-stamping. Although digital certificates already enable the association between an

entity and a public-key, a user can still repudiate the time at which the signature was created. Hence

trusted time-stamping. This method was created as the standard for inserting into the signature the

concept of at which point in time was the data signed[ACPZ01]. Using the same syntax as CMS,

it can be deployed in the same PKI, which is makes it ideal to be added to the X.509 certificates

that CMS defines.

Trusted time-stamping requires the presence of a trusted time-stamping authority(TTA) in the

PKI that is used. This authority is the one in charge of providing the signature with the time-

stamping token. The signed data with the certificate is hashed, creating an unique representation

of the data. This is then sent to the TTA which in turn concatenates the hash with the time-stamp,

hashing the result and signing with its private key. The TTA then sends it back to the requester,

with the time-stamp itself, who can then store them with the original signed data.

Anyone wanting to verify the data in which the signature was created needs only to calculate

the same hash that was concatenated with the time-stamp and compare it with the decryption )of

the signed hash the TTA sent, using its public-key.

2.6 XAdES

As seen on the previous section (2.4), there is already a well established way for providing doc-

uments with a digital signature. What we could also see is that it’s time-frame is limited to the

validity of the certificates at the time of the signing event. In order to add long-term validity

to the signature, the W3C has developed the XAdES format[CKPR10]. This aims at providing

XMLDSIG with the tools necessary in order to comply with the European Directive for Electronic

Signatures[EU-DIR-SIG][EP99].

9


Figure 2.1: Basic XAdES diagram

There are six different levels of the XAdES (2.1) implementation, each building on top of the

previous one and increasing in functionality and security.

XAdES-BES The most basic format required to comply with legal directive for advanced electronic sig-

nature;

Figure 2.2: XAdES-BES, XAdES-T and XAdES-C diagram

XAdES-T Adds a time-stamp (T) to the signature for another level of non-repudiation;

XAdES-C Adds referrals to certificates (C) and revocation lists so that documents can be verified off-

line; 2.2

XAdES-X Extends (X) time-stamps to the certificates themselves in order to provide safety against

future compromise of the CAs that provided the certificates;

XAdES-X-L The actual certificates that are referred are added to the signature, which allows for their

verification in the future (L for Long-term), even if the original source no longer exists; 2.3

XAdES-A Adds the capability for renewing time-stamps after a period of time (A for Archival), safe-

guarding against the compromise signatures can suffer through the advancement of time

(i.e. broken cryptography algorithms).2.4

10


Figure 2.3: XAdES-X and XAdES-X-L diagram

Figure 2.4: XAdES-A diagram

For the purpose of long-term validation, the most relevant one is the last one, number 6,

XAdES-A (archival), since it’s the one whose syntax allows for a new entity to the PKI, where

the documents are archived, to renew the time-stamping on a signature. This is how a signature

"travels" through time using XAdES, from the initial time-stamp to the next, so that when a ver-

ification is needed, the time-stamping chain will provide the means to do so (assuming that the

correct syntax has been used as well). One issue with XAdES is that, although there are several

libraries and implementations, there was no ubiquitous software that does so[Sys09] and there still

isn’t.

2.7 CAdES

CAdES, or CMS Advanced digital Electronic Signature, is a method created by the ETSI (Euro-

pean Telecommunications Standards Institute) in order to provide CMS (PKCS #7) with the capa-

bility of long-term signature validation. This is very important for electronic commerce between a

client and a business, between businesses and even between a citizen and a government[PPR08].

11


It can also sign any type of data, regardless of what it is and can be implemented into any type of

hardware, such as a personal identity card, credit cards, USB tokens, etc. As well as XAdES, the

most basic form of CAdES also makes CMS compliant with the European Directive for Electronic

Signatures[EU-DIR-SIG][EP99].

There are several levels of CAdES, similarly to XAdES. They are defined as followed:

Figure 2.5: CAdES-BES diagram

CAdES-BES Basic form of CAdES, just enough added to CMS to comply with the European Directive;

2.5

Figure 2.6: CAdES-T diagram

CAdES-T Adds to the electronic signature a time-stamp token provided by a trusted third party or by

the signer himself. This token is not signed by the signature, however it is the first step

towards long-time verification.2.6

12


Figure 2.7: CAdES-T diagram

CAdES-C Adds references to certificates and verification lists that can be stored separately from the

signature, to reduce required space. By adding this, the signature can be verified by com-

paring if at the time marked by the time-stamp, the signature was verifiable under a valid

certificate.2.7

CAdES-X-L Adds the complete certification and revocation data to the message. This way, even if the

referenced ones are lost, there is still a known source.

CAdES-X-1 The entire CAdES-C format is given a time-stamp of the same type inside CAdES-C itself,

providing integrity and protection to the entire message.

CAdES-X-2 Serves the same purpose of CAdES-X type 1, but instead of time-stamping the entire mes-

sage it does it to the complete certificate and revocation references only. The usage of type

2 or type 1 depends entirely on the environment.

CAdES-X-L-1/2 Simply put, it’s the combination of one of the two previous types with the CAdES-X-L

format.

CAdES-A The most important of them all, as in XAdES (for our purposes), is this one. It adds an

archival time-stamp to CAdES-X-L-1/2, making it suitable for long-time storage. This sin-

gle time-stamp object (different from the previous ones used) protects the whole CAdES

object from weak hashing algorithms or the fall of the cryptographic methods used in the

signature.2.8

Like XAdES, although there are several CAdES libraries and implementations available, there

was no ubiquitous software that does so[Sys09] and there still isn’t.

2.8 PAdES

PDF (Portable Document Format) is the international standard for digital documentation[Iso08].

Given this, it makes complete sense that the issue of long-term validation of digital signatures has a

13


Figure 2.8: CAdES-A diagram

special case for PDFs, as they are what most closely resembles actual paper documents in a digital

format. The standard, though, already specifies how a PDF can be digitally signed. What it does

not is how it can be verified after the original time-stamp has expired. ETSI began tackling this

issue during 20081, and presented a five part document describing PAdES, whose overview is given

in part 1 [PC09a]. While part 2 is only about the already existing PDF signatures but associated

with PAdES and part 3 is the equivalent of CAdES-T, but for PDFs, part 4 [PC09b] specifies a

new format PAdES-LTV, which is the PAdES match for CAdES-X-L and -A and for XAdES-XL

and -A. This means that digital signatures associated with the PDF can then be validated not only

up until the original time-stamp expiration date, but also long after that. Finally, part 5 defines the

way that XML content that has been signed using XAdES can be included into a PDF [PC09c].

The sections of PAdES that actually give normal PDF signatures their long-term validation

enhancement is currently under evaluation from the ISO organization2, to be included in the new

PDF ISO, 3200-2.

1As seen in http://webapp.etsi.org/workProgram/Report_Schedule.asp?WKI_ID=285612http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=

63534

14

http://webapp.etsi.org/workProgram/Report_Schedule.asp?WKI_ID=28561

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63534

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63534


2.9 ASiC

When a signature is created for a file, it needs to be linked to the original data. As described

during the CAdES and PAdES specifications before, this can be done in two ways. Either having

the signature enveloping/enveloped by the file it is signing or by being detached, placing it in

a different location and having an external way of maintaining the connection (i.e. a database).

Despite the benefit of using detached signatures (the non-modification of the original files), there

is an increase in risk that the connection between the two is lost. While some developers already

dealt with this problem on their own, ETSI launched a standard called ASiC (Advanced Signature

Container)[CS13] so that a common way across the European Union is used to address this issue.

The ASiC standard proses the use of the ZIP 3 container format in conjunction with a prede-

fined file structure and metadata to group together the file and its signature (or time-stamp only).

This usage of metadata to link different file objects inside a ZIP container had already been ad-

dressed by several different formats, namely OCF(OEBPS Container Format)4, used originally for

eBooks but later adapted by ODF (Open Document Format - Open Office)5 and UCF (Universal

Container Format - Adobe Systems)6. The ASiC standard not only specifies the structure of the

metadata but also how they can be made compatible with the three mentioned formats as well.

ASIC can be used with either XAdES or CAdES detached signatures or even individual Time-

Stamp Tokens.

The ASiC can be deployed in two ways:

• ASIC-S - This is the Simple ASiC container. Its structure consists of a single data object

(can be either one file or another container with several files) placed at the root of the ASiC

container. A METAINFO folder also placed at the root, containing inside either a file named

signature.p7s with the CAdES signature, a signatures.xml with the XAdES signature (with

the element <asic:XAdESSignatures> at its root) or a timestamp.tst with the timestamp.

• ASIC-E - The Extended AsiC container allows for the inclusion of more than one data object

at the root, without the requirement of them being inside another container. In order to do

this, some modifications to the inside of the METAINF folder are required. In the event of

a XAdES signature, it should contain an xml file that has to have the word "signatures" in

its name (can have other words before or after). Inside, it recommended that the element

<asic:XAdESSignatures> is the root one. In the event of making the container compatible

with the ODF format, the root should be <document-signatures> or <signatures> if it’s to

be compatible with the OCF format. If what is being used in the container is a time-stamp

token or a CAdES signature, then inside the METAINF folder, in addition to the .p7m or .tst

3http://www.pkware.com/support/zip-application-note4http://idpf.org/epub/30/spec/epub30-ocf.html5OASIS: "Open Document Format for Office Applications (OpenDocument) Version 1.2; Part 3: Packages" 29

September 2011. OASIS Standard.6http://livedocs.adobe.com/navigator/9/Navigator_SDK9_HTMLHelp/%20Appx_Packaging.

6.1.html

15

http://www.pkware.com/support/zip-application-note

http://idpf.org/epub/30/spec/epub30-ocf.html

http://livedocs.adobe.com/navigator/9/Navigator_SDK9_HTMLHelp/%20Appx_Packaging.6.1.html

http://livedocs.adobe.com/navigator/9/Navigator_SDK9_HTMLHelp/%20Appx_Packaging.6.1.html


files related to the data in the root, additional xml files starting with ASiCManifest are to be

included, with the root element <ASiCManifest> and having inside the connection between

the signatures/time-stamps and the original files.

2.10 AdES-Baseline Profiles

AdES signatures are supposed to be used, not only inside one Member-State of the European

Union (EU), but internationally. One conclusion it can be taken from the three (mainly XAdES

and CAdES) is that their many levels and specifications can make this interoperability increasingly

difficult. To fight this, a new ETSI has been made for each AdES standard [PC13, IC13, IC10].

This Baseline profile aims at removing some of the unnecessary properties and levels from the

standards themselves, in order to make validation of signatures between two different Countries

easier.

One of the most visible changes (and perhaps the main one) is the merge of several levels.

There is no more distinction between -BES and -EPES, being the basic level the -B one, used for

a basic AdES signature, with no timestamps from a trusted third party, only the one generated

during the creation of the signature, usually the current time of the machine that creates it (which

is not supposed to be trusted). This level is the minimum requirement for digital signatures that are

to be officially used in a cross-border scenario inside the EU, as established in the decision issued

by the European Parliament concerning this issue [EP11]. The -T level is kept in order to provide

the basic signature with a trusted time-stamp, always after the declared signing time. The -C level

ceases to exist, being the new -LT level responsible for including all the material in the signature

necessary for the long-term validation (i.e. CRLs). The new level that incorporates the archive

time-stamps, previously the -A level, is now designed -LTA. The conformance of a signature to

this level is considered the appropriate preservation and transmission method for digital signatures.

2.11 SD-DSS - Digital Signature Service

In order to help Member States conform to its decision specified in [EP11], the European Com-

mission has commissioned to a third party entity the development of an open source framework

that Countries can use to develop their own software for signing and validating e-signatures, so

that all can follow the same validation and signing procedures. This framework developed, called

DSS ([RBB14]) utilizes AdES-Baseline profiles to create the signatures and the validation spec-

ifications they specify, using the information provided by the Member-States’ trusted lists, each

one references in trust list at a European level. The framework follows closely the validation re-

quirements for each standard, being one to be used by any entity in a Member-State that needs to

implement e-signature functionality.

It provides a lot of functionalities, the main ones being the communication with PKCS #11

hardware tokens (somewhat independent of its source), the validation service, with all the Internet

16


connections required and TSL validations and the capability to sign and extend for all the current

Baseline standards. It is used as the core framework for this Thesis’ project.

2.12 Conclusions

As far as how to provide long-term validation to electronically signed documents and data, the

three sections about the AdES type of standards (XAdES, CAdES and PAdES) shows that it can

be safely done. Although it requires the presence of new entities in the PKI (the time-stamping

and the archival authorities, trusted third parties that can be one and the same), we can conclude

that the use of effective time-stamping throughout the years in addition to the list of certificates

and revocations can, at any point in time, ensure the non-repudiation and verification required of

a conversion of traditional signatures into the digital world. Despite the fact that PAdES’ only

aim is to provide this functionality to PDFs, it seems to be the one that respects this symmetry the

best. On the other hand, if the object being signed is something other than a PDF, CAdES and/or

XAdES seem to be the best approach.

In order to facilitate the cross-border mandatory functionality between two Member-States

of the European Union, the best method seems to be to use the SD-DSS framework, since it’s a

project commission by the EU itself, it uses the Baseline profiles (that in themselves were created

to facilitate such requirement) and it provides the functionality of validating against the Member-

States’ trusted list of certificate authorities.

17


18

Chapter 3

LTDSIGS - Long-Term DigitialSignature Service

This chapter focuses mainly in describing the developed standard decision algorithm and the soft-

ware, named LTDSIGS - Long-Term Digital Signature Service, with all its different modules. It

presents the overall implementation of each module, its architecture and functionalities.

LTDSIGS consists of three main modules. The LTDSIGS-Core, the LTDSIGS-Server and the

LTDSIGS-Client. A brief preview of each module is given below, followed by an in-depth analysis

later on this chapter.

• LTDSIGS-Core - Aims at providing a core services module (library) for any software that

can use Java libraries, enabling an ubiquitous set of methods to sign digital files, whether

the developer wishes to do -B level signatures, extend to -LTA or simply straight away do

-LTA signatures. This module consists of smaller modules that will be addressed later on,

but the main goal was to provide a library that can be adapted to each developer’s wishes,

since it holds a set of interfaces from which can be developed alternate implementations of

LTDSIGS-Core.

• LTDSIGS-Client - Built on top of the LTDSIGS-Core, the client is a cross-platform Java

8 GUI interface that lets an end user monitor a set of files/directories for their signature’s

expiration dates. It does so by maintaining an internal database connecting each signature

with its expiring date and handling the re-extension as needed. It also provides a means for

first actually signing a file if it’s not yet signed using several methods.

• LTDSIGS-Server - A multi-threaded server also built using LTDSIGS-Core as its main

source, it answers requests from any client (not only LTDSIGS-Client) that respects its

set protocol. It provides a means for extending a signed file, validating it against the trusted

TSLs, fetching time-stamps from a trusted TSA and replying with the new signature and its

expiring date.

19

LTDSIGS - Long-Term Digitial Signature Service

3.1 AdES Selection Algorithm

As was explained during the introduction of the problem that makes the basis for this thesis, there

is no single analysis or discussion of which AdES standard should be used in detriment of others

and why. That being the case, in order to build a software application that the tries to provide

a consensual and universal way of signing and maintaining digital signature through time, this

study was a mandatory step in the developing of LTDSIGS. Even before any testing was made,

there were a couple of conclusions that were able to be made from the studying of the standards

themselves and by observing the industry. First, the main file that is being subjected to signatures

is the PDF format. This is how big companies tend to store the digital versions of their docu-

ments, inside document managing systems (i.e. Alfresco). Another is that the main software used

to open PDFs is the Adobe Reader, since this is the only mainstream software that can actually

read digital signatures on PDFs and show them to the user. One final conclusion is that, while

XAdES produces signatures in a readable XML format, one in which the reader can actually see

the attribute names and value, CAdES generates signatures in ASN.1, which text editors cannot

(generally) open in a readable format. Despite this, software that recognizes PKCS #7 signature,

like S/MIME supporting clients, can read the CAdES files and present them in a human-friendly

mode. Finally, while a CAdES signature that is enveloped into a file can sometimes be read as the

original file, not compromising its use (i.e. mp3), the XAdES standard, by using XML, can only

attach other files in the form of a digest, removing the original functionality of the non-xml file.

Data types AdES Detached Enveloped

XML XAdES Yes Yes

PDF PAdES No Yes

Default CAdES Yes Yes

Table 3.1: AdES use per packaging time per data type.

The table 3.1 illustrates how each standard should be used for each data type and for each

packaging format. First we have two different scenarios: either the signature is supposed to be

included with the file (enveloping or enveloped) or it’s supposed to be maintained separately (de-

tached). According to [MCS03], and as the test results further ahead also prove, the standard that

occupies the least space and is the fastest to produce is CAdES since it uses the ASN.1 notation

instead of XML. And so, as can be seen in the algorithm, the default signing standard to be used

is CAdES. There are two situations, however, where CAdES is not used. When signing PDF files

and the signature is supposed to be stored inside the file itself (making Adobe Reader able to show

the signature to the user) and when the file is in XML format. These exceptions were made purely

based on the usability aspect of the signature. When a user signs a PDF file and chooses to keep

the signature within the file, he is expecting that, when he opens the document with the mentioned

software, that it can recognize the signature and show it in a very traditional and user-friendly

20


1

2 private AdvancedESignature decide(String extension) {3 if (extension.equalsIgnoreCase("pdf")) {4 if (extension.equals("detached")) {5 return new CAdESB();6 } else {7 return new PAdESB();8 }9 }else if (extension.equalsIgnoreCase("xml")) {

10 return new XAdESB();11 }else {12 return new CAdESB();13 }14 }

Listing 3.1: AdEs standard decision algorithm

manner. Since PDF readers that can display signatures are only able to read the ones made with

the PAdES, a non-detached signature for a PDF file uses the PAdES standard. Similarly, an XML

file is supposed to be able to be read by users. Using XAdES ensures that this functionality of the

notation language itself is maintained in the ensuing signature, as well as the original XML file’s

specific usage.

The code listed in 3.1 is the representation in Java of the algorithm explained above.

3.2 Architecture

From a very high level, figure 3.1 represents the architecture of the developed solution. We have an

external module, LTDSIGS-Core, that is incorporated into both LTDSIGS-Client and LTDSIGS-

Server. The Client monitors individual files or all the files in a selected folder for unsigned files or

expiring signatures. It does so by maintaining a database with the relation between file-signature-

expiring_date and comparing with the current month. A signature is created for any unsigned

monitored file and all new and expiring signatures are sent to the LTDSIGS-Server for extension.

The Server asks the trusted TSA for either one (if extending a -LTA signature) or two (if extending

a -B signature) time-stamps, proceeding to verify with the OCSP server the certificate used to cre-

ate the signature and the time-stamp. If all is valid, it returns the extended signature to the Client.

The main reasoning to separate the Core from the rest is to make it possible to, not only incor-

porate the signing functionalities it provides (along with the decision making as to which standard

to use) with any other software that has as a requirement the digital signing of files but also to

facilitate, in the future, the addition of new standards and improved signing methodologies. The

Client is independent of the Core in a way that, if a new Core-2 module is created, the replacement

21


Figure 3.1: LTDSIGS General Architecture

is as simple as modifying the property that defines which Core is used. The Client itself it mod-

ularized so that new sources besides a file-based database can be used, new monitoring daemons

and even new protocols.

3.2.1 LTDSIGS-Core

The main module of LTDSIGS is the Core. It is responsible for providing the connection between

the upper level software that needs to sign any file with the underlying framework SD-DSS (see

2.11), which in turn connects to the provider of the key pair, signs and creates the proper structure

for the AdES standard being used. Since the main goal of LTDSIGS-Core is to provide a black

box for developers to use to sign files, it contains a top-level services layer that handles all the

necessary logic and signing procedures, from fetching time-stamps to building certificate-chains

and validating signatures.

3.2.1.1 Signature Services and Validation modules

The module of the Core that offers the signing services and implements the logic behind the

decision of what AdES standard to use. It provides different versions of three main services:

1. SignFileB is the function responsible for signing a file with the -B standard, returns the

signed file (or the signature only, depending on the packaging) in the appropriate standard.

22


2. SignFileLTA functions much similarly to SignFileB, except that, not only does it create the

-B level, but it automatically extends the signature to -LTA level.

3. ExtendSignatureLTA is, as the name indicates, the function responsible for receiving the

original document and the signature (if it is detached), verifying it is not compromised and

extending it to -LTA level or adding a new archive time-stamp to it.

All these functions can receive the document as an array of bytes, an InputStream, a String

encoded in Base64 or the custom representation of a file created by SD-DSS (a DSSDocument).

Another element of this module is the Validation service. This process has several steps. It

begins by first determining which standard was used, based on the differences of the formats. It

then either downloads or retrieves from cache all the European Trusted Services Lists, so as to have

a reference of what certificates that provide, for instance, the time-stamp service are supposed

to be trusted. Connections to the OCSP servers are also made in order to confirm the status

of the certificates that were used to either sign the file in the first place or to create the time-

stamps themselves. The files’ digests are also recreated, in order to verify that they were not

tampered with, along with the validation of the time-frame presented in the signature, for instance

a document that was signed in December 2014 is only valid if the certificate used to do so is valid at

that time or the archive time-stamp has to be placed after the signature time-stamp. It also verifies

if the signatures were well created according to its respective Baseline standard. As an example,

a CAdES signature must have the time-stamp signature-time-stamp as an unsigned attribute, but

PAdES, which used CAdES, does not, but can instead have it as a document-time-stamp.

3.2.1.2 Commons module

This module, as the name indicates, contains interfaces and utility classes that can be used com-

monly by all parts of LTDSIGS system. It provides several objects with different functions.

• ProviderConfigurationLoading - Used to get a map of String to String, the key being the

generic name of the provider (i.e. SafeNet) that is to appear on the interface, the second

the path to the library used for that provider (depends on the Operating System). It was

developed an implementation for reading these configurations out of a XML file, with a

defined syntax. Listing 3.2 is an example of the configuration of the SafeNet provider. It

defines the library paths for the provider for each operating system, the digest algorithm that

it supports and to be used and if it is enabled to be used by LTDSIGS.

• Utils - In this class there were implemented a set of auxiliary methods that are used all

across LTDSIGS. From file saving to extracting a file extension to generating a trusted

chain of X509 Certificates, it’s the main utilitarian class of the whole project. Two very

important methods that are present in the Utils class are the retrieval of an Object named

AbstractSignatureTokenConnection, that represents the connection between the software

23


1

2 <provider-settings>3 <providers>4 <provider>5 <name>Safenet</name>6 <library>7 <linux>8 <path>/usr/lib/libeTPkcs11.so</path>9 <path>/usr/lib64/libeTPkcs11.so</path>

10 </linux>11 <windows>12 <path>/Windows/System32/eTpkcs11.dll</path>13 </windows>14 <mac>15 <path>/usr/local/lib/libeToken.dylib</path>16 </mac>17 </library>18 <digestalgorithm>SHA512</digestalgorithm>19 <enabled>true</enabled>20 </provider>21 </providers>22 </provider-settings>

Listing 3.2: PKCS #11 provider configuration example

and the source of the cryptographic key-pair and the method responsible for retrieving the

key from the AbstractSignatureTokenConnection that will be used to sign a file.

• AdES - A very basic interface that forces all implementations of an AdES Object to have a

sign method that takes a byte array and returns the signed byte array and a way to define the

packaging method.

• AdvancedESignature - Extending AdES, it’s the interface responsible for defining the set of

methods that should be implemented to used on LTDSIGS, that make use of the SD-DSS

framework object types. The implementation developed makes use of this interface for the

benefit of the abstraction of the three AdES standards, since all of them require the setting

of the private key, the use of signature tokens and the digesting algorithm that should be

used.

• AdvancedLTASignature - Similarly, this interface forces implementations of LTA signatures

to have not only a way of directly signing a file with the -LTA extension but also to provide

a way for extending a previously signed document. The implementation removes from each

specific standard the logic of connecting to the defined TSA, the construction of CRLs and

verification of the previous signature.

24


3.2.1.3 AdES module

The three AdES standards (X/C/PAdES) were created as three different components, independent

of the Services layer and each extending, as fit, the implementations of AdvancedESignature and

AdvancedLTASignature. This allows for the future addition of yet another version of the standard

to be created with ease, not only for developers that wish to do so but also for the maintenance

of the Core module. If a new standard suddenly appeared, it would only be necessary to create

another project that extended the interfaces, since the logic underneath would have to be the same

(signing, extending, etc). Figure 3.2 illustrates perfectly well the architecture of the entire AdES

module and how each Object relates to the other.

Figure 3.2: AdES Architecture Diagram

Each AdES standard has three Objects inside. Taking CAdES as the example it is composed

of:

• CAdES - The parent class, where the SD-DSS Object CAdESService, required to create the

standard, is declared. It also provides a means for retrieving this object.

• CAdESB - Has CAdES as a parent and is responsible for the CAdES specific logic for

creating a digital signature in the CAdES-B level.

• CAdESLTA - It directly extends the LTA implementation mentioned above and provides the

specific parameter configuration for two functions: signing directly in -LTA level, delegating

25


the actual process of creating the signature to CAdESB and then extending it; receiving an

already signed file (-B or -LTA level) and adding a new -LTA layer.

3.2.2 LTDSIGS-Server

Figure 3.3: LTDSIGS-Server’s high-level diagram

One of the main goals of this dissertation was to provide, as a service, the means for any devel-

oper that needs to extend digital signatures to do so. This led to the development of a standalone

Java server application that should be running on a trusted entity and that can provide this service.

While the internal work of extending signatures was already done on LTDSIGS-Core, which is

used by the Server, a protocol for potential clients to speak to the Server needed to be developed,

as well as ensuring the connection remains secure and the information is not tampered with. One

other requirement was that, since the Server would need to be accessed by multiple clients at the

same time, it would have to support that. It is the Server (by ultimately delegating on LTDSIGS-

Core) that makes the connections to the TSA and OCSP servers in order to get the time-stamps

needed to extend the signature from -B to -LTA or to refresh a previous -LTA one and to validate

the Certificates with the signers public key.

As can be seen on figure 3.3, the last issue is solved by creating a multi-threaded server. This

means that, for each incoming new connection, a new thread, a Worker, is dispatched to answer

the request being made, leaving the server free to listen for new connections. The Worker then is

responsible for maintaining the link to the client, verifying the protocol, using LTDSIGS-Core to

extend the signature and answering the client, terminating the connection.

The exchange of messages between client and server has to be tamper-proof, otherwise an at-

tacker could intercept the signature being sent and alter it or answering in stead of the LTDSIGS-

Server. In order to provide security to this connection, the server only accepts connections on a

secure socket, encrypted with its public certificate, mimicking the HTTPS protocol. After the ini-

tial handshake is made, the client knows that it is speaking with the server and not another machine

impersonating it, hence they can safely transmit data.

26


The protocol (example on 3.4)created for the communication between the server and the clients

is pretty straightforward. After the initial handshake, the communication develops as followed

(values between squared brackets are variables while parentheses denote optionality):

1. EXTEND- -[EXTENSION]- -[SIZE]- -[PACKAGING](- - [SIZE]) - Sent by the client, it

informs the server of the type of file the signature relates to and the packaging used. If it’s

included with the original file, then the first SIZE is the file+signature. If the packaging is

detached, the first size is that of the original file and the second is from the signature itself.

2. SENDFILE - Sent by the server as a response, it informs the client that it is prepared to

receive the file related to the first SIZE from point 1. If the signature is not detached, the

protocol jumps to point 4.

3. SENDSIG - Sent by the server in order to inform the client that it is now ready to receive

the signature connected to the first file.

4. ARCHIVE- -[SIZE]- -[DATE] - After the Server runs the process of extending and validat-

ing the signature, it sends this message to the client so that it knows the size of the new

signature that is being sent and, most importantly, the date in which the signature expires

(meaning the date in which the certificate used by the TSA to create the Archive Time-stamp

expires).

5. SENDFILE - Now sent from the client to the server, it informs it that it can send the extended

signature.

6. END - Send from the client to the server, it terminates the connection.

Figure 3.4: Messaging Protocol

27


In case the initial message is not in the correct format, the server terminates the connection

and informs the client of the correct protocol. If the server encounters an error, it informs the

client there was an internal error and shuts the connection down. The protocol was developed to

be simple so that it can be easily interacted with and implemented by a client.

3.2.3 LTDSIGS-Client

After developing the Core module explained above, the need to provide an actual entity (individ-

ual or company) a way to use its functionalities resulted in the development of the Client module.

The concept of this Client (3.5) is that of a monitor, meaning that it is responsible for periodically

inspect if the signatures that were created are expiring anytime soon and, if so, to take the appro-

priate measures. As an auxiliary function, it also provides a means for actually signing a file, if

not previously signed. The user only needs to select the provider of the keys (i.e. the Portuguese

Citizen’s Card) and the packaging (if the signature is to be included with the file or separately).

Figure 3.5: LTDSIGS-Client High-level Architecture

The Client is comprised of four main sections: the GUI, providing a usable interface for the

user; the monitor daemon, responsible for periodically verifying if any signature is expiring; the

database, saving the meta-information of the signatures; the connection handler, which sets the

link between the Client and the Server, handling the protocol used for them to communicate.

3.2.3.1 GUI

As we can see in figure 3.6, the client is very simple and adapts its appearance to try and match

that of the Operating System in which it’s being used. The main interface has three parts (tabs):

28


Figure 3.6: LTDSIGS-Client GUI

1. Monitor - Where the user selects the file or directory to monitor.

2. Signature Options - Where the user selects the source of the cryptographic token. It can be

either a .p12 file or a PKCS #11 compliant hardware.

3. Options - Where the user can select the packaging type and the period in which the monitor

will run.

Since the monitor first checks if the file(s) are signed, it cannot be used without providing a

means to sign them. Only when the three components (artifact(s) to monitor, key provider and

password) are set will the Client allow the file(s) to be added to the database. The user can only

select .p12 files as the source of the keys or one of the enabled PKCS #11 providers that are

currently supported (with the attribute set to enabled, see 3.2). Even if a provider is enabled,

though, if not connected it will not show on the options lists. If more than one type of the same

provider are connected (i.e. two SafeNet USB tokens), then it will show both with a different

numeral (SafeNet #1, SafeNet #2, ...).

Figure 3.7: LTDSIG-Client Managing Interface

One functionality of the Client that was made obvious during the development was the need of

a managing interface for the monitored files. A user needed to be able to actually see the files that

are being watched and he should be able to remove them, if he no longer wishes to monitor them,

or force the re-extension before the set date, if, for instance, the algorithm used by the TSA was

compromised. As we can see in figure 3.7, this was accomplished in an also very user-friendly

interface, where the user can select the entry he wishes to edit or apply the changes to all files.

29


3.2.3.2 Monitor Daemon

Once every set period of time, the Client asks the database if there are any signatures expiring in

the next three months. This task is done by the MonitorDaemon. This daemon runs on a separate

thread on the user’s computer and, in the event of either expiring signatures or new files added, it

runs the corresponding task.

Each new file is first verified if they already contain a signature. If not, the monitor uses

LTDSIGS-Core to create a new signature for the file with the parameters set on the GUI (pack-

aging, token source) and sends it to the connection manager, waiting for its response. When he

receives the extended signature, it tells the database to save the location of the signature file and

the expiring date. In the event of a file that is already signed, the monitor handles it as an expiring

signature, bypassing the signing process and sending it directly to the connection manager.

In order to make each signing process independent from the other, to prevent the error of a file

compromising the process for another, each handled file is treated in its own independent thread.

3.2.3.3 Database Connection

The meta-information of files that are being monitored, their respective signature location and its

expiring date needed to be kept between the time-frames of two consecutive executions of the

Client. In order to provide this, instead of serializing the information into a file, it was decided to

use a relational database management system. But, since the Client needed to be presented to the

user as-is, without any further extender dependencies, after analyzing the available solutions, the

Apache Derby one seemed like the best, since it provided a means to deploy a database specific

to the Client, that runs with it and require nothing else from the outside. The ease of being able

to query this meta-information using SQL language made the handling of said information very

easy. Even though Derby was chosen, the Client is prepared to receive a new module for any other

method for saving data, since it implements a generic interface.

The interface (listing 3.3) requires a set of methods to be implemented, so that a new imple-

mentation can be used seamlessly with the other components. In addition to the obvious add,

delete and get all entries, each implementation must provide a means for getting all the expiring

signatures, all the new files being monitored, getting a specific signature location and updating it,

as well as updating the expiring date.

3.2.3.4 Connection Handler

Since the extension of the signature is done remotely by LTDSIGS-Server, a connection module

was created. It handles everything, from managing the initial handshake to the closing of the

socket. Like all the other modules, this one also consists of an interface and an implementation,

so that, if the means by which the connection is made changes, a new one can be "plugged in".

Every implementation of the connection handler must be able to do a set of things: connect and

disconnect, send and receive file and send information to the server (the details of the protocol will

be explained further ahead).

30


1 public interface WatchDBInterface {2 public int addEntry(String URI, int parent, Date expiringDate, String fileType);3 public ArrayList<String> getExpiring();4 public ArrayList<String> getNew();5 public String getSignature(String URI);6 public ResultSet getEntries();7 public boolean updateEntry(String URI, String signatureURI, Date expiringDate);8 public boolean updateParent(String URI, Date expiringDate);9 public boolean deleteEntry(String URI);

10 public void cleanDB();11 }

Listing 3.3: Database Interface

1 public interface ServerConnectionInterface {2 public void connect() throws ConnectException;3 public String[] sendToServer(byte[] file);4 public String[] sendToServer(byte[] originalFile, byte[] signature);5 public boolean sendInformationToServer(String extension, String size1, String

packaging, String size2);6 public byte[] receiveFile(int size);7 public void closeConnection();8 }

Listing 3.4: Connection Interface

31


The implementation of the interface on 3.4 shows the set of methods that were described

above. This particular implementation, though, assures that the connection is, in fact, being done

with LTDSIGS-Server by using RSA public-key cryptography and the TLS protocol. The Client

is loaded with the Server’s specific public key, then using it to validate the Server during the initial

handshake, during which a new key specific for that communication is generated.

3.2.4 Summary

Even though there are three different standards for AdES signatures accepted by the European

Commission as having legal and binding value, it was concluded that they have different uses,

with their own strengths and weaknesses. The PAdES standard is clearly the choice for PDFs

that incorporate the signature into the own document, while the CAdES is the de facto standard

to be used for its increased speed and smaller size. Even though XAdES is, generally, worse than

CAdES, it does provide the signature in a relatively more reader friendly manner, and, being XML

widely used for a lot of different ends, it was concluded to be the best for files in said language.

Three different software components were developed in order to provide the previous conclu-

sion and operations for signing and extending signature to different developers, LTDSIGS-Core,

a server-side application that can interact with clients that need to extend signatures from -B to

-LTA or renewing the previous -LTA signature, whilst verifying it in the process, LTDSIGS-Server

and finally a GUI interface for an end-user that wishes to sign and/or monitor files, providing dif-

ferent ways to sign such files, running in the background without bothering the user every time a

signature needs to be extended due to its expiring date, LTDSIGS-Client.

32

Chapter 4

Testing and Validation

Having presented the solution devised for the problem in the previous chapter, the present one fo-

cuses mainly on two things. First, to add to the bibliographic evidence that led to the development

of the algorithm created for the AdES choosing (3.1) via testing of the actual set of parameters

decided on the problem statement and second to speak about a European level initiative in which

the LTDSIGS program entered called e-Signature Validation Plugtest, hosted by the European

Telecommunications Standard Institute.

4.1 Comparing the AdES family

As we have seen on chapter 2, the AdES family seems to be "the way to go", as far as long-term

digital signatures are concerned, which is why ETSI is now invested in improving the individual

standards. But which one of the three to use in the context of this problem may not have been

completely clear.

In order to do this, the three must be compared according to a set of metrics, to try and under-

stand which one is the best in which situation. The following are to be the main characteristics to

be analyzed.

• Space - How much space does the resulting signature take, whether it is detached, enveloped

or enveloping the data. It will be used a 1-10 scale to describe this metric, where 1 is a lot

of space and 10 is very little (compared to the original file).

• Ease of Use - How easy it is to understand, implement and use the format for all stages of

the process (signing, verification and archival). It will be used a 1-10 scale to describe this

metric, where 1 is very hard and 10 is very easy.

• Performance - How efficient both the process of generating the signed data and verifying

the signature (and we assume it gets worse through time) are. It will be used a 1-10 scale to

describe this metric, where 1 is terrible performance and 10 is great performance.

33


• User Experience - How the end user (the signing entity) can interact with the signature,

mainly its visualization and correlation to a regular non-digital signature. It will be used

a 1-10 scale to describe this metric, where 1 is can’t even be read and 10 is very easy to

understand.

• Data Types - To what data types can the format be applied to. It will be used either all or a

detailed list of formats.

4.1.1 Testing Data and Analysis

To test these parameters for each standard, a basic test case was set up. Taking a pdf file (which

is the file format most widely used for digital documents), we generate two signatures, a -B level

one and a -LTA level and verify it. Since some of the steps in -LTA generation and verification

of both types require Internet access, to retrieve time-stamps from the TSA, OCSP responses and

revocation lists for the certificates being used, it was decided that a mean average between consec-

utive signatures done over 10 and 100 times, with a 5% margin of error was the correct approach,

to compensate for Internet lagging and server delays. More details about the testing environment

can be found on Appendix A. That said, two scenarios were tested: enveloped signatures, where

the signature was embedded into the pdf file and detached signatures, where it is stored separate

from the original document. This allows for comparison between each packaging method as well

as between each standard. Finally, to avoid constraints on hardware, a testing .p12 file is being

used as a the key pair source, so all the work is done by software.

AdES File type supported

Detached Enveloping Enveloped

CAdES All All None

XAdES All All XML formatted files

PAdES None PDF None

Table 4.1: Supported types for AdES standard per packaging

On a side note, and as we can see in table 4.1, there are a couple of restrictions that come from

the standards themselves and should be taken into account. First, it does not make sense to do a

detached PAdES test, since, in its essence, it would be a CAdES signature. PAdES only makes

sense if used inside a pdf file, as it adds to it a series of attributes that make the signature readable.

Second, it is not possible to create a XAdES signature enveloped into a pdf file, since they have

completely different structures and XML parsers do not recognize the pdf syntax. Same thing with

CAdES signatures. So, to provide the comparison of a signature with the original document, it

was decided to use XAdES and CAdES in enveloping mode (the signatures contain the document)

and PAdES in enveloped mode (the document contains the signature).

34


4.1.1.1 Enveloping/Enveloped Scenario

AdES Enveloping / Enveloped

Time Avg 10x (ms) Time Avg 100x (ms) Size (KB)

CAdES-B 6760.2 5888.7 5.332

XAdES-B 6778.9 6571.8 358.616

PAdES-B 8816.9 8876.6 20.174

Table 4.2: Comparison between non-detached AdES signatures in size and time

Analyzing table 4.2, which represents the results of a -B level signature included with the

document, we can take in a couple of conclusions. First, when comparing sizes we can see that,

as expected [MCS03], the CAdES signature is the one with the smallest size, since the ASN.1

format is, essentially, a binary encoding one. This is also why the second smallest one is PAdES.

The reason why this happens is because, even though a PAdES signature is, in its core, a CAdES

one, it needs additional data to be correctly represented by PDF readers. Last comes XAdES.

As we can see, it is significantly larger than the other (about 300KB), which can be explained by

the XML format taking a lot more space than ASN.1 (although more readable). Since XML is

essentially a text format, the file can’t be stored as bytes, so they are encoded into a Base 64 string

and added to the XML under the tag <ds:Object>.

Time wise, instead of focusing on the values themselves (as previously stated, Internet latency

can have some influence), it’s best if we analyze the actual tendencies. One first conclusion is that,

despite the margin of error, CAdES, on average, is faster than the other two. This derives, once

again, from the difference between converting the PDF document to ASN.1 notation instead of

XML (when comparing with XAdES-B). Another obvious conclusion is that PAdES-B is, albeit

not significantly, the slowest of the three, both on the 10x and the 100x averages. It makes sense

that it is bigger than the CAdES-B time, again for the same reason that explains the increase in

size, it being that additional information that it adds to the CAdES standard.

AdES Enveloping / Enveloped


CAdES-LTA 9209.6 8279.2 5,34

XAdES-LTA 9580.9 9386.7 417,5

PAdES-LTA 9956.8 8776.4 20,09

Table 4.3: Comparison between non-detached AdES signatures in size and time

For the sake of completion, table 4.3 presents the result of a 1226.46KB PDF file that was

signed and extended to -LTA level for each standard. Taking into account that these times can be

35


off by a one second margin due to Internet latency, even when doing the average of a 100 times

cycle, it is possible to strengthen the conclusion that CAdES is the fastest and the smallest of the

three AdES standards, while XAdES is the largest. PAdES remains competitive with CadES, size

related, bur still loses in terms of performance.

4.1.1.2 Detached Scenario

AdES Detached


CAdES-B 6072.5 6435.1 5.19

XAdES-B 7980.8 6138.7 8.30

PAdES-B N \A N \A N \A

Table 4.4: Comparison between detached AdES signatures in size and time

For the detached signature scenario, illustrated on table 4.4, the previous analytical method will

be used, but before it should be stated that the sizes of these signatures are completely independent

from the original document’s. The only thing inside these signatures that can vary are the public

certificates used to sign (one with a larger name, for instance, will take more space) and its trusted

chain, up to the root CA (excluding). More so, the certificate used to sign the documents was a

very simple one, with only one intermediate certificate before the CA. This set of results confirm

the previous analysis, as far as space is related. A simple CAdES-B signature takes as little space

as 5.19KB. This value is completely on par with the ASN.1 vs XML comparison done before,

when compared with the 8.30KB of the XAdES-B signature.

As far as the computation times are concerned, though, some inconsistencies were found.

First, it seems that, on the CAdES side, the 10x average is quite similar to the 100x one, which,

in itself, only means that the Internet connection between the two was fairly stable. However,

looking at the XAdES-B, the difference is too big to be attributed solely to latency. Not only

that, but it actually got faster than CAdES-B, on the 100x case. The only explanation possible

is that the libraries (Apache’s xmlsec and W3C’s dom) that are being used to handle the basic

building blocks below the XAdES standard store some information in memory that they can re-

use in subsequent requests while the library (BouncyCastle’s CMS) used below CAdES does not

implement the same efficiency methods.

That said, there is still the incongruence between the previous conclusion and the fact that, for

non-detached signatures, even on the 100x case CAdES was faster. This can only mean that the

advantage gained by the XAdES building is lost and actually turned around by the necessity of

having to encode the file into Base 64 format. This can also mean that, in the event of a faster

algorithm to do that, the two standards can become quite equal in terms of processing speed.

36


4.1.2 Metrics Comparison and Analysis

Following the metrics discussed at the start of this chapter and taking into account the previous

analysis of both detached and enveloping signature creation, table 4.5 is an attempt to summarize

them into discrete values. Space wise, CAdES has a clear advantage, it being the smallest one by

far, while PAdES and XAdES take second and third place respectively. So, if we take this factor

only in consideration, CAdES should be used in detriment of all the others.

All AdES standards are pretty much alike in terms of complexity and implementation diffi-

culty. To be fair, these values would be one or two points lower if the Baseline profile had not

been launched, which simplified a lot of the processes and steps necessary to construct a valid

AdES signature. The reason why PAdES’ value is a little lower is that a more careful attention

needs to be taken on the implementation side, since there’s a need to adapt CAdES to the PDF

standard itself. As such, if this was the sole parameter, it would’ve been between XAdES and

CAdES only, with nothing to differentiate them.

AdES Space Ease of use Performance User Experience Data types

XAdES 7 8 8 7 all

CAdES 10 8 10 3 all

PAdES 8 7 6 10 pdf

Table 4.5: Final evaluation between AdES standards

Performance wise CAdES has, again, the big advantage. As discussed above, it seems to have

a clear upper-hand over XAdES on the enveloping situation and only slightly losing to it on the

detached scenario when there are a lot of files to be signed. If only a small number of files are to

be signed, CAdES still wins by a big margin. PAdES seems, once again, to be the standard that

seems less optimal to be used. And so, again, if only this parameter was to be taken into account,

CAdES would be the winner for most situations while XAdES being used only if we had a lot of

files to sign and the signatures were to be stored on a separate location.

As far as supported file types, all of the CAdES functionalities can be used with any file. There

are even some files, such as PDFs or mp3s, that even though are enveloped into the signature, can

still be used by normally (a PDF will show exactly the same and the mp3 will still play). XAdES,

on the other hand, breaks functionality on all types when enveloping the file, but it does support

all data formats on both detached and enveloping modes. XAdES also allows to have the signature

being the one enveloped into the file (instead of the other way around), but this is restricted to XML

files. PAdES, as the name itself shows, only supports PDFs. And so, if the goal was only to support

the most number of file formats, it would be a somewhat even match between CAdES and XAdES.

37


Finally, concerning the user experience. This is where CAdES failed enormously compared

to the other two. Since it uses ASN.1 notation to create the AdES structure that contains all the

data, the resulting file is, essentially, binary and humans can’t read binary. There is some software

that can identify the resulting file as it being some sort of CMS signature, but shows very little

information and is nothing alike a normal signature. By using XML instead of ASN.1, XAdES is

able to show the actual structure of the signature to the user and, in the case of XML files, it can

actually be incorporated into the file itself very neatly. We can see the digests, the timestamps, the

certificates and the actual file (although encoded in Base 64) on the resulting XAdES signature

and, even though it stills falls short compared to the "analog" signature, it provides a much better

user experience. Finally, this is where PAdES shines. Since it was developed specifically for

PDFs, when a PAdES signature is coupled with one, even though it uses ASN.1 notation, it adds

additional fields to the structure that make it so that PDF readers that support digital signature are

able to show it perfectly, it being the closest approximation of a normal signature’s presentation

to its digital format. Although there aren’t a lot of readers that actually implement the signature

reading functionality, the Adobe’s Adobe Reader is able to show the signature in a very user

friendly manner.

4.1.3 Conclusions

Considering now all the previous analysis, it is safe to consider that the CAdES standard is the

best AdES one to use in most cases. It is smaller, faster (in most scenarios) and has a wide range

of supported files, since everything digital is, after all, binary data. And so, the only situation in

which CAdES should not be used is when the actual user experience is taken into consideration. If

the this requirement is on a low priority, as in, what matter is that the signature actually exists and

is valid, then CAdES is still used. Between XAdES and CAdES, the only plausible reason to use

the former in detriment of the later is when handling XML files. Since XAdES is itself XML, the

resulting signature, by being enveloped into the original data, does not even break functionality

(which is what happens when enveloping), and as such does not break the feeling of continuity

between the unsigned and signed versions. As far as PDFs are concerned, though, if the signature

is to be included with the PDF, then there is no standard that can beat PAdES. Even though it is

slower and takes more (not a lot more though) than CAdES, the sheer increase in user experience

that it provides is more than enough to compensate these flaws.

4.2 e-Signature Validation Plugtest

PlugtestsTMare events that ETSI organizes from time to time, since 1999, in order to provide essen-

tial feedback to ETSI standardization committees, so that the standards that are being worked on

come out the best possible. It also allows for companies and individuals that are developing prod-

ucts that use these standards to test their solutions, reducing their time-to-market and increasing

standardization speed.

38


The e-Signature Validation Plugtest is one the many launched and it ran between November

3rd and 14th December (initially November 21st), organized by the ETSI Center for Testing and

Interoperability, with the aim to check the actual e-signature interoperability and validation ca-

pacities of the participants so that they can detect possible implementation issues that can lead to

different validation results.

The main goal of this Plugtest was also to allow European Member States’ representatives or

other entities that act on their behalf (a company working in a Member State, for instance) to test

their e-Signature creating and validation tools, by cross-validating other e-Signatures created in

other Member States only relying on the Trusted List maintained on the European level for all

Member States.

4.2.1 Plugtest Specification

Going into more depth into how the Plugtest actually worked, each participant is attributed a code

consisting of their country’s representation (i.e. PT for Portugal) and their own (i.e. PT_MUL

for MULTICERT). This guarantees that there are no two participants with the same id. The entire

process relies on the interaction between the participants to work. Figure 4.1 illustrates an example

of two entities interacting with the Plugtest’s Portal.

Figure 4.1: Interaction and Cross-Validation

1. Each participant downloads the initial package containing AdES signatures and the ASiC

containers already uploaded by the Plugtest’s organization team, sorted intro a folder tree

that will be explained further below.

2. The user then generates a signature and/or a verification report and adds it to the container

that he downloaded on step 1.

39


3. He then uploads the container to the Portal, either as a signature upload or as a verification

upload.

Each time a user uploads a new container, the portal generates a new one containing the new

information submitted up to that point, including the most recent uploaded by the participant,

generating a link for it to be downloaded. It also updates, for each user, a matrix that maintains,

for easy reference, the result of the other participant’s verification reports of his signatures. Even

though there are two sides to the whole operation, it is not required to do both. A participant can

choose to either only create signatures or verify the other participant’s.

4.2.1.1 Package Structure

The package each participant downloads contains the file structure on figure 4.2. Inside it, on

the first level, are a set of folders named ESIG-X, where X is each of the AdES standard initial

(i.e. ESIG-P for PAdES). Each of these files contain another structure inside, with a sub-folder for

each of the participants, identifies with the code specified before, that contains that participant’s

submitted signatures and verification reports he generated for the other participants that correspond

to the X of the parent folder.

4.2.1.2 Signature Generation and Verification

When a user generates a signature, he needs to upload it to the Portal. The process is illus-

trated on figure 4.3 and, as we can see there, when the user submits it, the Portal places it on

the correct folder inside the package structure, doing so by examining the name of the file to a

standardized one. This is made easier if the participant gives a standardized name to the signature,

it being [PARTICIPANT]-[AdES]-Bp[LEVEL]-[STATE]-[CARDINAL].[EXTENSION]. A brief

example is PT_MUL-C-BpLTA-V-2.p7m, meaning it was submitted by PT_MUL, it’s a CAdES

signature, it follows the Baseline Profile (Bp), is a Long-term Archive level signature, it is declared

as valid and it’s the second CAdES signature submitted by that user. The extension is one some

programs can recognize as CMS signatures. Each file is then mapped to a more uniform name

(more accurately if the previous convention was followed): Signature-[AdES]-[PARTICIPANT]-

[CARDINAL].xml. Following the same example, it would be mapped to Signature-C-PT_MUL-

2.xml.

Finally, when a participant verifies another’s signature, he generates a report containing the

result (obligatory VALID, INVALID, INVALID.CRYPTO_CONSTRAINTS_FAILURE, ERROR

or INDETERMINATE). The report is then should be given a name following the convention Verifi-

cation_of_[PARTICIPANT]_[SIGNATURE].xml. Again, taking the same example, it would have

the name Verification_of_PT_MUL_Signature-C-PT_MUL-2.xml. The portal then examines the

contents, searching for the result, and updates the interoperability matrix for said participant.

40


Figure 4.2: Initial Package Structure

41


Figure 4.3: Signature Generation Process

4.2.1.3 Interoperability Issues

One of the Plugtest’s main goal was, as already stated, to find interoperability issues between the

different entities signing mechanisms and verification tools. As such, during the event, a number

of issues were detected. While some were due to faults on the signing process or of the verification

tool itself, like failing to add some field in the XAdES structure or not realizing that on a PAdES,

42


even though it uses CAdES inside, some of the structures are not mandatory and the value can be

somewhere else, others were established as actually doubts in the standards themselves and the

European Law’s interpretation when validating signatures. Next follows the final (version 9) list

of issues that were considered most relevant and its proposed solution.

1. A Proof of Existence for a revoked or expired certificate (meaning it can be proved that it

existed at a specific date/time in the past) must be provided for the VALID status.

2. In the case of SHA-1 should no longer be considered as a secure algorithm, it has been

decided that all algorithms are to be accepted during the Plugtest. However, in the event of

issues occurring, one of two indications should be used:

INVALID.CRYPTO_CONSTRAINTS_FAILURE if the signature is considered invalid due

to one of the algorithms used is no longer reliable and the validation tool can ascertain that

it was used after it started being considered insecure;

INDETERMINATE.CRYPTO_CONSTRAINTS_FAILURE_NO_POE if the tool cannot know

if the algorithm was considered secure at the date at which was used; ERROR if it cannot

deal with the algorithm.

3. INVALID.FORMAT_FAILURE should be returned if there is no signed reference to the

signing certificate.

4. The Baseline profile requires the presence of signing time. Should it not exists, a non-

conformance is to be expressed via warning.

5. Multiple signatures cannot be handled by the Plugtest Portal.

If validation returns INDETERMINATE, it should be added the indication INCONSIS-

TENT_MULTIPLE_ELEMENTS_VALIDATION.

6. If a PAdES does not have the Sub-filter indication (meaning it does not follow Baseline

profile), use non-conformance warning.

7. In order to obtain a VALID result, it must be possible to construct a certificate chain up to

a trusted anchor in a Member State’s TSL. Each certificate in the chain must be valid at

validation time (not necessarily current time). In the possibility of error, use the indication

INDETERMINATE.NO_CERTIFICATE_CHAIN_FOUND.

8. There were some nations whose TSL had issues (for instance not behind retrievable).

9. If a critical extension for a CRL is encountered and the validation tool can’t handle it, then

the CRL must be rejected.

10. In the European, cross-border context, if the Time-stamp does not have its provider in a

country’s TSL as a time-stamping generation service, it should not invalidate a signature and

it cannot be rejected. The absence of the trusted anchor should be expressed as a warning.

43


11. The presence of a CMS signing-time inside a PDF should not invalidate the signature, but it

should be expressed as a non-conformance warning.

12. Both BasicOCSPResponse or OCSPResponse can be used on CAdES.

13. In the event of an expired or revoked certificate in a TSL, the analysis of said certificate

must be ignored, maintaining the signature’s VALID status.

14. An inconsistency in the structure of a manifest file inside an ASiC container is not reason to

invalidate a signature, but it should be manifested via error or warning.

4.2.2 LTDSIGS Signatures Validation

During the Plugtest, several testing signatures, created by the LTDSIGS software, were submitted

to the Portal under PT_MUL’s name. These signatures were subject to the validation tools of sev-

eral participants from different countries. The signatures that were submitted were three following

the XAdES standard (one with the -B level and three with the -LTA level), two CAdES (one -B

and one -LTA) and three PAdES signatures (one -B and two -LTA).

AdES Plugtest Validation Result

VALID INDETERMINATE ERROR INVALID TOTAL %VALID

XAdES 30 6 4 2 42 71.4

CAdES 20 1 3 8 32 62.5

PAdES 13 5 11 7 36

Table 4.6: ETSI Plugtest Validation Results

• XAdES - Most participants declared the signatures created as VALID. However, there were

some issues found. First, there were fields that validation tools were searching for that

were not mandatory for that specific level (Signature Time-Stamp for a -B level) or couldn’t

find the MimeType attribute, which is mandatory and was in the signature. Second, some

considered the -LTA signatures as indeterminate due to the Time-Stamps that were generated

were not signed by a CA that had that service in the Portuguese TSL. Despite this, the

success rate for the interoperability of the XAdES signatures was 71.4% (meaning almost

three out of four considered them VALID, no restrictions).

• CAdES - Again, while most participants declared the signature as VALID (62.5%) there

were some issues mainly with the CA’s certificate not being found on the Portuguese TSL.

Interestingly enough, all reports of this time were issued by Italian participants, which may

indicate an issue with the interoperability specific to that Country. An issue with the time-

stamps arose again for some of the participants, but, unlike the XAdES issue, here some

reported a problem in an hash index attribute that had a different value than it was supposed

to (increased by one). This led to the discovery of a bug in LTDSIGS that fixed the issue.

44


• PAdES - This was the standard that had the biggest number of issues. The same Italian

participants reported the same problem, which was expected since the certificated used to

sign was the same. Others mis-interpreted the PAdES Baseline profile and were analyzing

the signature as if they were CAdES. Some couldn’t even find the signature itself inside the

PDF. even though Adobe Reader showed the signature perfectly well, which leads to the

conclusion that there must be some issues with the validation tools, conclusion reported to

the Plugtest’s participants. Here we had a 36.1% validation rate.

The low validation rate on PAdES, while may be somewhat alarming, since PDF files are the

most used form for digital documents and LTDSIGS applies PAdES to sign those files, it is not

that much concerning. After analyzing the errors that were provided, the issues seem to be mainly

on the validation tool’s side and not on the signature itself. And, since Adobe Reader launches no

error and can read the signatures and display them as expected, it was considered that LTDSIGS

had no bug in itself (although an update to the underlying tool that handles PDFs has been updated

recently after these tests which fixed some issues that were not reported, the main one being a

parsing error).

4.2.3 Conclusions

All things considered, the ETSI Plugtest for e-Signature validation was a very successful event and

the benefits for the LTDSIGS software was considerable. It allowed the resulting actual signatures

created to be tested in somewhat simulated environment that could very well be translated to the

real scenario of digital signatures being used to sign documents across Europe. Not only that,

it also allowed for the detection of some implementation issues of the LTDSIGS-Core (i.e. the

hash-index issue pointed above). To the community in general, the issues list that was detected

serves as a big help in maintaining interoperability, pointing out the aspects that led to the most

controversy between the different participants while said interoperability also benefited from the

other verification tool’s bug fixing. It was, from my point a view, a big success.

4.3 Summary

In order to test and validate the LTDSIGS implementation mentioned on chapter 3, two things

were done. First, a series of statistical testing were made, using the software developed, to provide

a hard, numbers-based evidence that supports the AdES signature selection algorithm. It was

verified that, indeed, the best solution was to use the CAdES standard as the default one, while

using PAdES for the specific case of enveloped signatures inside PDF files and XAdES for XML

files. Second, the signatures themselves were put to the test on a broader scale on the ETSI e-

Signature Validation Plugtest, by having other parties from the European Member States test the

interoperability of said signatures, which demonstrated that, for the most part, it would be safe for

a company working in Portugal to use LTDSIGS to manage the signing of its signatures, even if

the signed documents were to be used in another European country.

45


46

Chapter 5

Conclusion

This final chapter concludes the dissertation report, presenting the conclusions that were taken

from the completion of the objectives presented on Chapter 1. It presents the actual contributions

to the proliferation of the usage of digital signatures and, ultimately, addresses what future work

could be done to even greatly improve the solution developed during this dissertation.

5.1 Results and Objectives Analysis

Chapter 3 has the specification of a software that has the potential to become ubiquitous in long-

term digital signing while Chapter 4 describes two different testing scenarios that were described

and analyzed in detail. This section aims at connecting the obtained results and implementation to

the objectives that were proposed.

By looking at the results of the first test on Section 4.1, it is reasonable to conclude that there

is no definite clear best AdES standard for digital signatures. On the other hand, it was possible to

conclude that CAdES was the one that should be used on most situations, but, due to the poor user

experience it provides, and to maintain the correlation between to-be-signed file and the resulting

signature, on the even of an XML document, XAdES should be used. In the particular event

that said file is a PDF document, though, the PAdES standard should be the one applied, since

it can be presented to the user in a very friendly manner by compliant PDF readers. Therefore,

Objective 1 is considered as completed. The second Objective, which was the development of

a software that can use the previous conclusion to the benefit of the user, was, as can be seen

from Section 3.2 and forward, successfully completed. The software can not only analyze which

AdES standard should use for a specific file, but, by being built modularly, can be fitted into other

different applications as a service. Objective 3 was, as described on Section 3.2.3, completed by

connecting the Client module to the Core one, which in turn uses abstractions to provide a way for

different providers to be loaded, hardware and software based ones. The creating of a Client that

47

Conclusion

runs on a user’s computer and of a Server that runs remotely enabled the completion of Objective

4, by having the Client analyze is the date is expiring in the following three months and sending to

the Server, which in turn extends the signature and returns to the Client, as explained on Section

3.2.2. Finally, Objective 5 required that the application was to be tested in the community. In order

to do this, since the software itself was under a Non Disclosure Agreement, it was decide to test

the resulting signatures. As seen on Section 4.2, this was done by entering the ETSI e-Signature

Validation Plugtest, which, as explained, produced positive results as far as the interoperability and

validity of the produced signatures in the context of the European Union, which makes Objective

5 completed, the fifth out of five proposed.

5.2 Summary and Contributions

As described on the introduction to this dissertation, the importance and usage of digital signatures

has been increasing over the last few years. But, despite this increase, the fact that, by default, the

main method for digital signing, which is the generation of an hash on the data using a private-

key, does not provide all the characteristics that one would expect from a "real" signature. Hence

there have been many developments in trying to create ways to give a more real aspect to digital

signatures, developments that resulted in three main standards: CAdES, PAdES and XAdES. But,

despite these new ways to operate, one be left wondering which to use and, on a more layman

point of view, should I use this software the says uses CAdES or this other one that only uses

PAdES?

This dissertation successfully answers these questions in two ways.

First, by analyzing the differences between the three standards, comparing how much space

they take on disk, how fast they are to produce, how easy they are to implement, how they are

viewed by the user and which formats they support, it was concluded that, if the objective is to

sign PDF documents, then PAdES should be used, since it provides a closer approximation to what

a user is expecting to see in a digital signature. On the event of the document to be signed being

an XML file, then, to maintain the format relationship between file and signature, this dissertation

asserts that XAdES should be used. On every other scenario possible, then the de facto standard

is CAdES, since it is both faster and lighter than the other two and supports all file formats.

Second, the software developed through this dissertation, taking advantage of the previous

conclusion, is a software perfectly indicated for a user as generic as possible. The user that does

not want to know or care about standards, the user that just wants the job to be done and well done.

By abstracting most of the decisions from the user, the software does this job perfectly well. All

the user needs to do is select the file or folder that wants to monitor, tell the software which of

the available sources of signature providers to use, decide if he wants the signature with the file

or not and nothing more. From that point onwards, the software handles all the signing processes.

Not only that, it guarantees that the signature does not expire due to time constrictions, unless the

user explicitly decides so. This is the software artifact that is available to a user. The other is

48

Conclusion

one deployed as a server program that is responsible for extending the signatures provided, thus

making this functionality available as a service, not only for the developed Client but for any other

client that requires signature extension for long-term preservation. Finally, the module that was

developed which contains the decision algorithm and provides signing and extension of signatures

as a service can be incorporated into other softwares, thus contributing to the expansion of the

usage of digital signatures now not from an end-user perspective but by a software developer’s

one.

These are the main contributions to this field. The comparison between the three standards

can be crucial in deciding which one to implement and/or use, the Client/Server application is an

already functional and easy to use software that provides long-term digital signatures for any kind

of file, building on top of a a Core module that provides, as a Service, the signing and extension

functionalities that take into account the comparison between the three AdES standards.

5.3 Future Work

On this section some of the future work that could be done to improve what was done in this

dissertation. How they would actually impact the quality of the work can only be speculated upon,

but they seem promising.

5.3.1 Retesting with New/New Versions of AdES Standards

As the AdES standards get improved, a re-testing of the metrics should be done for each new

release, since the changes can make an impact on some of them. While it doesn’t seem viable for

the space variable, the speed and user experience ones can be greatly modified (like a software

that actually reads a CAdES signature and shows it very clearly, even when enveloped inside a

file). In addition to that, despite there being already three AdES standards, nothing stops another

from arising. This new one should also be subject to the testing to see how it behaves against the

current ones.

5.3.2 Improving LTDSIGS-Client’s GUI

The visual aspect of a GUI is one of the most important aspects of an application that is to be used

by as many people as possible. While the one implemented already tries to be at least visually

tolerated by using the native Operating System’s look and feel, it can always be improved. Some

of these improvements could be a better arrangement of the information, support for different

languages and more feedback for the user.

5.3.3 Implement Support for more Hardware Providers

While the current software already supports SafeNet’s USB Token and the Portuguese Citizen’s

Card, if to be deployed to other Countries or entities, in the event of them using different hardware

49

Conclusion

providers for the public-private key pair, these would have to be included and tested to the software.

While the addition of these devices would be fairly trivial if they followed the PKCS#11 standard,

if they do not, support for those protocols would need to be included, which would make the

software even more ubiquitous.

5.3.4 Use ASiC for Detached Signatures

By using ASiC (Section 2.9) to store the detached signatures with the original files, despite losing

some flexibility in the storage location of the mentioned signatures, it makes sure that the link

between them and files are not lost. This could be a feature to be implemented into LTDSIGS-

Core as a service and the option could be given to the user of LTDSIGS-Client if he wishes to

create the ASiC container or not, thus increasing the success of the entire maintenance of the

signatures during its long-term archival.

50

References

[ACPZ01] C. Adamn, P. Cain, D. Pinkas, and R. Zuccherato. Internet x.509 public key infras-tructure time-stamp protocol (tsp), August 2001.

[BBF+08] Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia, and Ed Simon. Xml signaturesyntax and processing (second edition). Available at W3C http://www.w3.org/TR/xmldsig-core/, June 2008.

[CKPR10] Juan Cruellas, Gregor Karlinger, Denis Pinkas, and John Ross. Xml advanced elec-tronic signatures (xades). Available at ETSI http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf, December 2010.

[CS13] A. Caccia and S.Compans. Electronic signatures and infrastructures (esi); associatedsignature containers (asic). Available at http://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.03.01_60/ts_102918v010301p.pdf, June 2013.

[EP99] Council of the European Union European Parliament. Directive 1999/93/ec of theeuropean parliament and of the council of 13 december 1999 on a communityframework for electronic signatures. Available at http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:31999L0093, December 1999.

[EP11] Council of the European Union European Parliament. Commission decision of25 february 2011 establishing minimum requirements for the cross-border process-ing of documents signed electronically by competent authorities under directive2006/123/ec of the european parliament and of the council on services in the in-ternal market. Available at http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32011D0130&from=EN, Februrary 2011.

[HS09] R. Hously and Vigil Security. Public-key cryptography standards (pkcs) #7: Cryp-tographic message syntax (cms), available at http://tools.ietf.org/html/rfc5652, September 2009.

[IC10] J. Ibarz and S. Compans. Electronic signatures and infrastructures (esi); xadesbaseline profile. Available at http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf,November 2010.

[IC13] J. Ibarz and S. Compans. Electronic signatures and infrastructures (esi); padesbaseline profile. Available at http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf, April2013.

51

http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/xmldsig-core/

http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.02_60/ts_101903v010402p.pdf






http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:31999L0093

http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:31999L0093

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32011D0130&from=EN

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32011D0130&from=EN

http://tools.ietf.org/html/rfc5652






REFERENCES

[Iso08] TC Iso. 171/sc 2: Iso 32000–1: 2008 document management-portable documentformat-part 1: Pdf 1.7, 2008.

[JK03] J. Jonsson and B. Kalisky. Public-key cryptography standards (pkcs) #1: Rsacryptography specifications version 2.1, available at http://tools.ietf.org/html/rfc3447, February 2003.

[KMRM14] S. Parkinson K. Moriarty, M. Nystrom, A. Rusch, and M.Scott. Pkcs #12: Per-sonal information exchange syntax v1.1. Available at https://tools.ietf.org/html/rfc7292, July 2014.

[Lar00] John Larmouth. ASN. 1 complete. Morgan Kaufmann, 2000.

[MCS03] Darren P Mundy, David Chadwick, and Andrew Smith. Comparing the performanceof abstract syntax notation one (asn. 1) vs extensible markup language (xml). InProceedings Terena Networking Conference. W3C, 2003.

[PC09a] Nick Pope and Sonia Compans. Etsi ts 102 778 pdf advanced electronic signa-ture profiles; part 1: Pades overview - a framework document for pades. availableat http://www.etsi.org/deliver/etsi_ts/102700_102799/102778/01.01.01_60/ts_102778v010101p.pdf, July 2009.

[PC09b] Nick Pope and Sonia Compans. Etsi ts 102 778 pdf advanced elec-tronic signature profiles; part 4: Pades long term - pades-ltv profile.available at http://www.etsi.org/deliver/etsi_ts/102700_102799/10277804/01.01.01_60/ts_10277804v010101p.pdf, December 2009.

[PC09c] Nick Pope and Sonia Compans. Etsi ts 102 778 pdf advanced electronic sig-nature profiles; part 5: Pades for xml content - profiles for xades signatures.available at http://www.etsi.org/deliver/etsi_ts/102700_102799/10277805/01.01.01_60/ts_10277805v010101p.pdf, December 2009.

[PC13] N. Pope and S. Compans. Electronic signatures and infrastructures (esi); cadesbaseline profile. Available at http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf, Jan-uary 2013.

[PPR08] D. Pinkas, N. Pope, and J. Ross. Cms advanced electronic signatures (cades).Available at http://tools.ietf.org/html/rfc5126.html#section-1,February 2008.

[RBB14] V. Bouckaert R. Bielecki and N. Bouillon. Sd-dss digital signature servicev4.2.0. Available at https://joinup.ec.europa.eu/asset/sd-dss/home, November 2014.

[RSA83] R.L. Rivest, A. Shamir, and L.M. Adleman. Cryptographic communications systemand method, September 1983. US Patent 4,405,829.

[Sal03] Rich Salz. Understanding xml digital signature. Available at MSDN http://msdn.microsoft.com/en-us/library/ms996502.aspx, July 2003.

52



https://tools.ietf.org/html/rfc7292

https://tools.ietf.org/html/rfc7292









http://tools.ietf.org/html/rfc5126.html#section-1

https://joinup.ec.europa.eu/asset/sd-dss/home

https://joinup.ec.europa.eu/asset/sd-dss/home

http://msdn.microsoft.com/en-us/library/ms996502.aspx

http://msdn.microsoft.com/en-us/library/ms996502.aspx

REFERENCES

[Sys09] Adobe Systems. The ades family of standards: Cades, xades, and pades. imple-mentation guidance for using electronic signatures in the european union. avail-able at http://blogs.adobe.com/security/91014620_eusig_wp_ue.pdf, September 2009.

[Vac04] John R Vacca. Public key infrastructure: building trusted applications and webservices, page 8. CRC Press, 2004.

[Woo03] M. Wood. Pkcs #11: Cryptographic token interface standard. Available at http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm, June 2003.

53

http://blogs.adobe.com/security/91014620_eusig_wp_ue.pdf

http://blogs.adobe.com/security/91014620_eusig_wp_ue.pdf

http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-11-cryptographic-token-interface-standard.htm



REFERENCES

54

Appendix A

Testing Environment

The testing environment in which the 10 and 100 consecutive averages were created was the fol-

lowing:

• Machine

– OS - Linux Mint Cinnamon 17 64-bit version (updated)

– RAM - 8GB

– CPU - Intel i5-3230M @ 2.60Ghz x 2

– Hard Drive - 110GB SSD

– Network Connection - Ethernet through HTTP/S Proxy

• Software

– Java - Version 1.8

– IDE - NetBeans 8.0.2

• Misc

– Computer was being used to access the Internet with Google Chrome.

– In the -LTA testing, the TSA was on the same Network.

55

Long-term digital signatures · 2019-07-13 · simple mp3 ﬁle. Which is not the case of a XAdES...

Documents

Transcript of Long-term digital signatures · 2019-07-13 · simple mp3 ﬁle. Which is not the case of a XAdES...