• Nenhum resultado encontrado

Assinaturas de Longo Prazo

N/A
N/A
Protected

Academic year: 2021

Share "Assinaturas de Longo Prazo"

Copied!
75
0
0

Texto

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Long-term digital signatures

Pedro Cunha

D

ISSERTATION

Mestrado Integrado em Engenharia Informática e Computação Supervisor: Rui Maranhão, Ph.D.

(2)
(3)

Long-term digital signatures

Pedro Cunha

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

(4)
(5)

Abstract

Digital signatures are a requirement for the future.

Information in general and documents in particular (the standard being PDF) is increasingly becoming more about bits and bytes and less about paper. But the only way to ensure that this happens 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 to hand-written signatures. The next step is digitalization. However, simple digital signatures are not 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 standards that exist today, there is no clear way to define which one is the best. Hence, one of the goals is to demonstrate in which situation should each one be used and make it more definite which one is preferable. Since there is no single or "best" standard, there isn’t also a software that can be defined 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 digital signatures as the main method of signing documents and files. The main conclusions are that CAdES is the by-default standard to be used. It is both faster and occupies the least amount of space on disk, which, even though a one for one comparison with XAdES doesn’t seem a lot, if we consider thousands of files to be signed, it can reach significant savings. One main disadvantage is that CAdES signatures can’t be seen in the file. An mp3 file with a signature will appear as a simple 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 we save it for XML files, since it made sense to maintain the same formatting scheme of the original file. PAdES is used in one and only one circumstance: to sign PDF files in which the signature is to be included inside the PDF. PAdES uses CAdES as its main signature creation method, but it makes it so that PDF readers that show signatures can display the ones created using PAdES. This is specially important for enterprise use and official documents.

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

(6)
(7)

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 mais em bits e bytes e cada vez menos em papel. Mas a única forma de garantir que isto acontece com sucesso é através da criação de assinaturas digitais, em tudo equivalentes às tradicionais. O próprio conceito de assinatura sofreu alterações ao longo do tempo, desde selos com cera até às assinaturas manuscritas. O próximo passo é a digitalização. Contudo, assinaturas digitais simples não são suficientes, visto que têm um período de vida muito limitado. Esta tese aborda o método de assinaturas digitais de longo-prazo de uma forma através da qual se demonstra em que situações cada um dos standards deve ser usado e se define qual deles é preferível. Visto que, na falta de uma ou da melhor especificação, não haverá consequentemente um software definido como recomendá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 caso a caso, como também um software desenvolvido para ajudar no crescimento do uso de assinaturas digitais 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ço em disco. Sem prejuízo de numa comparação um para um com o XAdES a diferença não ser muita, se considerarmos milhares de ficheiros que precisam de ser assinados, o CAdES consegue atingir poupanças bastante significativas. Contudo, este standard tem uma principal desvantagem em relação ao XAdES: se a assinatura for incluída num ficheiro, não há maneira de saber (à "vista desarmada") que ela está lá. Isto é, um ficheiro mp3 continuará a pare- cer apenas um simples ficheiro 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á usado apenas em ficheiros já de si em XML, visto que, para estes, faz sentido manter tudo na mesma linguagem 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 que conseguem 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

(8)
(9)

Acknowledgements

Several people were fundamental in the development of this Thesis. I would like to thank Professor Rui Maranhão for all its guidance, Renato Portela for giving me the opportunity to work alongside all 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 the software and all the laughs, Rui Baeta for all the back and forth discussions about the technologies used in the Thesis and Robert Bielecki for his help and support in using core framework in which the Thesis stands.

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

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

(10)
(11)

“Secured Signing enables us to finalise deals and to sign contracts with our worldwide customers within minutes. Our ability to efficiently close these deals results in positive responses from our clients and therefore increased sales”

(12)
(13)

Contents

1 Introduction 1 1.1 Dissertation Context . . . 1 1.2 Motivation . . . 2 1.3 Goals . . . 2 1.4 Document’s Structure . . . 3

2 Related Work and State of the Art 5 2.1 Introduction . . . 5

2.2 PKCS . . . 5

2.2.1 PKCS #1 RSA Cryptography Standard . . . 5

2.2.2 PKCS #7 CMS . . . 6

2.2.3 PKCS #11 Cryptographic Token Interface Standard . . . 6

2.2.4 PKCS #12 . . . 6

2.3 PKI - Public Key Infrastructure . . . 7

2.4 XMLDSIG . . . 7 2.5 Trusted Time-stamping . . . 9 2.6 XAdES . . . 9 2.7 CAdES . . . 11 2.8 PAdES . . . 13 2.9 ASiC . . . 15 2.10 AdES-Baseline Profiles . . . 16

2.11 SD-DSS - Digital Signature Service . . . 16

2.12 Conclusions . . . 17

3 LTDSIGS - Long-Term Digitial Signature Service 19 3.1 AdES Selection Algorithm . . . 20

3.2 Architecture . . . 21

3.2.1 LTDSIGS-Core . . . 22

3.2.2 LTDSIGS-Server . . . 26

3.2.3 LTDSIGS-Client . . . 28

3.2.4 Summary . . . 32

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

4.1.1 Testing Data and Analysis . . . 34

4.1.2 Metrics Comparison and Analysis . . . 37

4.1.3 Conclusions . . . 38

(14)

CONTENTS

4.2.1 Plugtest Specification . . . 39

4.2.2 LTDSIGS Signatures Validation . . . 44

4.2.3 Conclusions . . . 45

4.3 Summary . . . 45

5 Conclusion 47 5.1 Results and Objectives Analysis . . . 47

5.2 Summary and Contributions . . . 48

5.3 Future Work . . . 49

5.3.1 Retesting with New/New Versions of AdES Standards . . . 49

5.3.2 Improving LTDSIGS-Client’s GUI . . . 49

5.3.3 Implement Support for more Hardware Providers . . . 49

5.3.4 Use ASiC for Detached Signatures . . . 50

References 51

A Testing Environment 55

(15)

List of Figures

2.1 Basic XAdES diagram . . . 10

2.2 XAdES-BES, XAdES-T and XAdES-C diagram . . . 10

2.3 XAdES-X and XAdES-X-L diagram . . . 11

2.4 XAdES-A diagram . . . 11

2.5 CAdES-BES diagram . . . 12

2.6 CAdES-T diagram . . . 12

2.7 CAdES-T diagram . . . 13

2.8 CAdES-A diagram . . . 14

3.1 LTDSIGS General Architecture . . . 22

3.2 AdES Architecture Diagram . . . 25

3.3 LTDSIGS-Server’s high-level diagram . . . 26

3.4 Messaging Protocol . . . 27

3.5 LTDSIGS-Client High-level Architecture . . . 28

3.6 LTDSIGS-Client GUI . . . 29

3.7 LTDSIG-Client Managing Interface . . . 29

4.1 Interaction and Cross-Validation . . . 39

4.2 Initial Package Structure . . . 41

(16)

LIST OF FIGURES

(17)

List of Tables

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

4.1 Supported types for AdES standard per packaging . . . 34

4.2 Comparison between non-detached AdES signatures in size and time . . . 35

4.3 Comparison between non-detached AdES signatures in size and time . . . 35

4.4 Comparison between detached AdES signatures in size and time . . . 36

4.5 Final evaluation between AdES standards . . . 37

(18)

LIST OF TABLES

(19)

Abbreviations

W3C World Wide Web Consortium PKCS Public Key Cryptographic Standards PKI Public Key Interface

HTTP Hypertext Transfer Protocol XML eXtendible Markup Language ASN.1 Abstrance Syntax Notation One CMS Cryptographic Message Syntax XMLDSIG XML Digital Signature

AdES Advanced digital Electronic Signature XAdES XML AdES

CAdES CMS AdES PAdES PDF AdES

CA Certificate Authority SSL Secure Sockets Layer

ANSI American National Standards Institute MIME Multipurpose Internet Mail Extensions DSA Digital Signature Algorithm

ETSI European Telecommunications Standard Institute CRL Certificate Revocation List

API Application Programming Interface OCSP Online Certificate Status Protocol

(20)
(21)

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

(22)

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

(23)

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. Chapter2describes 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 Chapter3, 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 Chapter4, the testing results are presented, both for the algorithm and to the end artifacts of the LTDSIGS software, the signatures themselves. Finally, Chapter5presents the conclusions of the work and the objectives proposed as well the contributions made and improvements that could be made in the future.

(24)

Introduction

(25)

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

(26)

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 public-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

(27)

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].

(28)

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

(29)

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].

(30)

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

(31)

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].

(32)

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

(33)

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 umes-sage 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

(34)

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 inhttp://webapp.etsi.org/workProgram/Report_Schedule.asp?WKI_ID=28561 2http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=

63534

(35)

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 ZIP3container 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)5and 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-note 4http://idpf.org/epub/30/spec/epub30-ocf.html

5OASIS: "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.

(36)

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 comCom-missioned 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

(37)

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.

(38)

Related Work and State of the Art

(39)

Chapter 3

LTDSIGS - Long-Term Digitial

Signature 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.

(40)

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 table3.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

(41)

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 in3.1is the representation in Java of the algorithm explained above.

3.2

Architecture

From a very high level, figure3.1represents the architecture of the developed solution. We have an external module, Core, that is incorporated into both 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

(42)

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.

(43)

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. Listing3.2is 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

(44)

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.

(45)

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). Figure3.2illustrates 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

(46)

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 figure3.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.

(47)

LTDSIGS - Long-Term Digitial Signature Service

The protocol (example on3.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.

(48)

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 figure3.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):

(49)

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 figure3.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.

(50)

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 (listing3.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).

(51)

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 }

(52)

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.

Referências

Documentos relacionados

Para tanto foi realizada uma pesquisa descritiva, utilizando-se da pesquisa documental, na Secretaria Nacional de Esporte de Alto Rendimento do Ministério do Esporte

São parte integrante do estágio profissionalizante os estágios parcelares em áreas fulcrais nomeadamente: Medicina Interna, Cirurgia Geral, Pediatria, Ginecologia e

1)Developing a rigorous assessment instrument capable of assessing mental health literacy and stigmatized perceptions towards mental disorders, and also to work as an outcome measure

No entanto a grande responsável pelo sucesso da Volvo foi a carrinha da série 140 (fig. Nas suas campanhas usavam a segurança como argumento principal.. Em Itália, na transição

reunir um pequeno grupo para falar sobre a morte, de uma forma leve e descontraída - falando sobre a morte, se fala sobre a vida, sobre as relações, sobre afeto e

For the index cases referred to the Portuguese FH Study, in 69% we have identified the cause of hypercholesterolaemia: 39.4% with monogenic hypercholesterolaemia (38.6% have FH

O próximo mapa esquematiza os principais focos alergénicos da Praça de Liège. Este jardim possui apenas uma espécie alergénica, com época de polinização no inverno.

Die dargestellten Ergebnisse rechtfertigen die Aussage, dass die Entwicklung der Handlung nicht anhand der chronologischen, sondern anhand der kausalen und