long-term digital signatures · 2019-07-13 · simple mp3 file. which is not the case of a xades...
TRANSCRIPT
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
ii
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
iv
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
vi
“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
viii
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
Related Work and State of the Art
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
LTDSIGS - Long-Term Digitial Signature Service
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
Testing and Validation
• 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
Testing and Validation
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
Time Avg 10x (ms) Time Avg 100x (ms) Size (KB)
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
Testing and Validation
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
Time Avg 10x (ms) Time Avg 100x (ms) Size (KB)
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
Testing and Validation
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
Testing and Validation
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
Testing and Validation
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
Testing and Validation
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
Testing and Validation
Figure 4.2: Initial Package Structure
41
Testing and Validation
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
Testing and Validation
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
Testing and Validation
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
Testing and Validation
• 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
Testing and Validation
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
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
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
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