Assinatura Electrónica Qualificada
Daniel Tiago Nave Prata de Almeida
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente:
Orientador:
Co-Orientador:
Vogal:
Prof.
Prof.
Prof.
Prof.
Dr.
Dr.
Dr.
Dr.
José Carlos Martins Delgado
Fernando Henrique Corte Real Mira da Silva
Carlos Nuno da Cruz Ribeiro
Ricardo Jorge Fernandes Chaves
Outubro 2009
Agradecimentos
Ao Instituto Superior Técnico, a minha alma mater, e a todos os que nesta grande escola
contribuiram para a minha formação.
Quero agradecer ao meu irmão, Sérgio Almeida, pela paciência em ouvir-me explicar os
minuciosos detalhes da implementação. Aos meus colegas e amigos Telmo Rodrigues e André
Almeida, pelo insight e pelas discussões de diversos temas na área da segurança informática.
Agradeço aos meus colegas do Centro de Informática do Instituto Superior Técnico, André
Brioso, Angelina Silva, António Silva, Cláudio Martins e Jorge Matias pelo excelente ambiente
de trabalho e aprendizagem que me proporcionaram, e em especial ao Miguel Cabeça pelos seus
preciosos conselhos e ensinamentos.
Por fim, quero agradecer ao Prof. Fernando Silva e ao Prof. Carlos Ribeiro pela proposta do
desafio, pela orientação e por me disponbilizarem todos os meios necessários à realização deste
trabalho.
Lisboa, Outubro 2009
Daniel Tiago Nave Prata de Almeida
Aos meus pais
Resumo
À medida que os documentos vão sendo armazenados em suporte digital, a necessidade das
organizações gerirem documentos assinados electronicamente é uma realidade eminente. Esta
dissertação aborda este problema actual, propondo uma solução e demonstrando a sua exequibilidade através da implementação da solução proposta, um sistema de assinatura electrónica de
documentos.
Este sistema permite a realização de assinaturas electrónicas qualificadas de qualquer tipo de
documento passı́vel de representação digital, utilizando o recentemente criado cartão de cidadão,
o que confere às assinaturas produzidas propriedades fundamentais como o não-repúdio e a
validade legal em todos os Estados Membros da União Europeia.
As assinaturas produzidas incorporam outras propriedades qualificantes, como o compromisso do assinante relativamente ao documento assinado, ou o cargo (i.e a qualidade) do assinante numa organização. As assinaturas incorporam também mecanismos de protecção da sua
validade a longo prazo, no caso em que a segurança tenha sido comprometida, pelas mais diversas razões. O formato sugerido e adoptado para as assinaturas, é o formato XAdES uma
extensão das assinaturas XMLDsig, que se encontra normalizado.
O sistema de assinatura proposto é uma web application independente do sistema operativo, oferecendo uma boa facilidade de integração e implantação num qualquer contexto organizacional. Este sistema foi implementado recorrendo única e exclusivamente a tecnologia Open
Source.
Abstract
As documents are being stored in digital form, the need for organizations to manage documents electronically signed is an imminent reality. This thesis addresses this actual problem,
proposing a solution and demonstrating its feasibility through implementation of the proposed
solution, an electronic signature system for documents.
This system allows the creation of qualified electronic signatures of any document capable
of digital representation, using the newly created portuguese citizen’s card, which gives the
signatures produced fundamental properties such as non-repudiation and legal validity in all
European Union Member States.
The signatures produced incorporate other qualifying properties as the commitment of the
signer relative to the signed document, or the role of the signer in an organization. The signatures
also incorporate mechanisms to protect their validity in the long term, in the case where security
has been compromised, for any different reasons. The suggested and adopted format for the
signatures, is XAdES an extension of XMLDSIG signatures, which is a standard.
The signature system proposed is a web application that can be used regardless of operating
system, offering a good ease of integration and deployment in any organizational context. This
system was implemented using solely Open Source technology.
Palavras Chave
Keywords
Palavras Chave
Assinatura Electrónica Qualificada
Cartão de Cidadão
Certificados X.509
Documento Electrónico
Não Repúdio
Segurança Electrónica
XAdES
Keywords
Digital Qualified Signature
Cartão de Cidadão
X.509 Certificates
Electronic Document
Non repudiation
Electronic Security
XAdES
Índice
1 Introdução
1.1
1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2
Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.3
Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.4
Notas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 State of the Art
5
2.1
Certificados Digitais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Assinatura Electrónica Qualificada . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Funcionalidades Electrónicas . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.2
Legislação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.3
Certificados X.509 / PKIX . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.4
Certificado de Assinatura Digital Qualificada . . . . . . . . . . . . . . . .
12
XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.1
XML Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.2
XAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2.1
XAdES-BES (Basic) . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.2.2
XAdES-T (Time Stamped) . . . . . . . . . . . . . . . . . . . . .
17
2.4
i
2.4.2.3
XAdES-C (Complete) . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.2.4
XAdES-X (Extended) . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.2.5
XAdES-X-L (Extended Long term) . . . . . . . . . . . . . . . .
18
2.4.2.6
XAdES-A (Archival)
. . . . . . . . . . . . . . . . . . . . . . . .
18
Outras Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5
CAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.6
PAdES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.7
Trusted timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4.3
3 Proposta
3.1
23
Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1
Formato das assinaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.2
Temporalidade da assinatura . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.3
Assinaturas numa organização . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.4
Compromisso da assinatura . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.5
Validade a longo prazo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3
Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4 Implementação
31
4.1
Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2
AEQ Docs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.1
XAdESSigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.2
XAdESValidator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.2.3
XAdESSignatureTimeStamper . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2.4
XAdESCounterSigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
ii
4.2.5
Assinatura Electrónica Qualificada - Java Applet . . . . . . . . . . . . . .
40
4.2.6
Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5 Discussão
45
5.1
CAdES, PAdES ou XAdES? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.2
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3
Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.4
Integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.5
Objectivos atingidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6 Conclusões
49
6.1
Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2
Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
55
Bibliography
iii
iv
Lista de Figuras
2.1
Hierarquia de entidades de certificação (Certification Authorities) dos certificados
presentes no Cartão de Cidadão . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Modelo fı́sico do cartão de cidadão, frente e verso . . . . . . . . . . . . . . . . . .
7
2.3
Aplicações residentes no chip EMV do cartão de cidadão . . . . . . . . . . . . . .
8
2.4
Perfil de um certificado X.509 versão 3 . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
Extensão Key Usage dos certificados X.509 presentes no Cartão de Cidadão . . .
12
2.6
Data Section do certificado X.509 versão 3 de Assinatura Digital Qualificada de
um Cartão de Cidadão de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.7
Estrutura de uma assinatura XML . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.8
Utilização do elemento CounterSignature XAdES . . . . . . . . . . . . . . . . . .
19
2.9
Estrutura das assinaturas XAdES . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1
Componentes de um serviço de assinatura electrónica qualificada . . . . . . . . .
27
3.2
Arquitectura da solução proposta . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1
Invocação do XAdESSigner através da linha de comandos . . . . . . . . . . . . .
32
4.2
Assinatura XMLDsig gerada pelo XAdESSigner . . . . . . . . . . . . . . . . . . .
33
4.3
Extensão XAdES-BES da assinatura XMLDsig gerada pelo XAdESSigner . . . .
36
4.4
Invocação do XAdESValidator através da linha de comandos . . . . . . . . . . .
38
4.5
Invocação do XAdESSignatureTimeStamper através da linha de comandos
. . .
38
4.6
Extensão XAdES-T gerada pelo XAdESSignatureTimeStamper . . . . . . . . . .
39
v
4.7
Invocação do XAdESCounterSigner através da linha de comandos
. . . . . . . .
39
4.8
Invocação do XAdESCounterSigner através da linha de comandos
. . . . . . . .
40
4.9
Assinatura Electrónica Qualificada - Java Applet . . . . . . . . . . . . . . . . . .
41
4.10 AEQ Docs - Assinatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.11 AEQ Docs - Validador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.12 AEQ Docs - Notariado antes da realização da contra-assinatura . . . . . . . . . .
44
4.13 AEQ Docs - Notariado após a realização da contra-assinatura . . . . . . . . . . .
44
vi
Lista de Tabelas
2.1
Aplicações electrónicas residentes no Cartão de Cidadão . . . . . . . . . . . . . .
vii
8
viii
Abreviaturas
AEQ Assinatura Electrónica Qualificada
ASN Abstract Syntax Notation
CA Certification Authority
CAdES Cryptographic Message Syntax Advanced Electronic Signatures
CMS Cryptographic Message Syntax
CRL Certificate Revocation List
CRLF Carriage Return Line Feed
CSS Cascading Style Sheet
DER Distinguished Encoding Rules
ECEE Entidade Certificadora Comum do Estado
EMV Europay Mastercard Visa
ETSI European Telecommunications Standards Institute
GNS Gabinete Nacional de Segurança
HTML Hyper Text Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
ISO International Organization for Standartization
ITU International Telecommunication Union
JDK Java Development Kit
LDAP Lightweight Directory Access Protocol
MD5 Message-Digest Algorithm 5
MySQL My Structured Query Language
OCSP Online Certificate Status Protocol
ix
PAdES Portable Document Format Advanced Electronic Signatures
PDF Portable Document Format
PHP PHP Hypertext Preprocessor
PIN Personal Identification Number
PKCS Public Key Cryptography Standards
PKI Public Key Infrastructure
RFC Request For Comments
RSA Rivest, Shamir and Adleman
SCEE Sistema de Certificação Electrónica do Estado
SHA Secure Hash Algorithm
TSA Timestamp Authority
URI Uniform Resource Indentifier
W3C World Wide Web Consortium
WYSIWYS What You See Is What You Sign
XAdES Extensible Markup Language Advanced Electronic Signatures
XMLDsig Extensible Markup Language Signature
XML Extensible Markup Language
XSD Extensible Markup Language Schema
x
1
Introdução
It is far better to be silent than merely to increase the quantity of bad books.
– Voltaire
1.1
Introdução
Esta dissertação, inserida na área da segurança informática, apresenta uma solução no
âmbito das assinaturas electrónicas qualificadas e discute uma proposta de implementação de
um sistema de assinatura electrónica qualificada no contexto de uma organização.
1.1.1
Motivação
As assinaturas electrónicas são usadas numa vasta área de contextos e aplicações, dando
origem a novos requisitos de produtos e serviços relacionados com a assinatura electrónica.
Surgiram da necessidade de transpor a tradicional assinatura manuscrita para os documentos
electrónicos, colmatando as falhas de segurança existentes, uma vez que a tradicional assinatura
manuscrita não é segura, pois é facilmente falsificável e consequentemente não se pode garantir
a sua autenticidade nem a sua veracidade, podendo inclusive vir a ser repudiada pelo legı́timo
assinante.
Os sistemas de assinatura electrónica tipicamente utilizados, são sistemas proprietários dependentes do sistema operativo e do tipo de documento, oferecendo bastantes limitações quanto
à validação da assinatura, pois o receptor da assinatura terá que dispor dos mesmos meios que o
assinante de forma a que a possa validar. Esta validação é tipicamente realizada no sistema do
utilizador, pelo que o processo de validação poderá ser maliciosamente subvertido, apresentando
um estado erróneo de validade da assinatura, induzindo o utilizador em erro.
As organizações necessitam de assinaturas electrónicas seguras que permitam garantir a
2
CHAPTER 1. INTRODUÇÃO
autenticidade, a temporalidade e o não repúdio dos documentos assinados electronicamente,
assim como garantir que estes permaneçam válidos por longos perı́odos de tempo, mesmo que a
segurança de uma assinatura electrónica seja futuramente comprometida.
A interoperabilidade das assinaturas electrónicas tem vindo a ser promovida pela União
Europeia (e consequentemente pelo Estado Português), assim como a harmonização do critério
legal das assinaturas electrónicas, originando uma framework legislativa coerente, promovida
através da Directiva Europeia 1999/03/EC, de 13 de Dezembro de 1999 (15), e de outras decisões
da Comissão Europeia. Estas medidas pretendem contribuir para a aceitação geral dos métodos
de autenticação electrónica, de forma a garantir que as assinaturas electrónicas constituam prova
legal em todos os Estados Membros.
O recente surgido documento de identificação electrónica português, Cartão de Cidadão,
promove o desenvolvimento tecnológico e a modernização administrativa e organizacional. Na
sua vertente digital, promove o desenvolvimento das transacções electrónicas dando-lhes a segurança necessária através da autenticação forte e da assinatura electrónica.
1.1.2
Objectivos
O objectivo principal da proposta descrita neste documento é a concepção de um sistema
de assinatura de documentos electrónicos (i.e. um conjunto de bytes) através da utilização de
uma assinatura electrónica qualificada, que garanta o valor probatório dos documentos assinados
electronicamente de acordo com a Lei Portuguesa (11; 12; 10) e com a Directiva Europeia (15)
para as assinaturas electrónicas, de forma a que as assinaturas produzidas tenham validade legal
em todos os Estados Membros da União Europeia.
O sistema de assinatura que este documento descreve tem uma vasta aplicabilidade, podendo
ser adoptado por qualquer organização ou entidade que necessite de utilizar e gerir documentos
electrónicos assinados digitalmente, atestando a sua veracidade através da assinatura electrónica
qualificada de um indivı́duo e de uma contra-assinatura da organização.
Em traços gerais, os requisitos que este sistema deverá cumprir são os seguintes:
• Fornecer ao utilizador um mecanismo simples de criação de assinaturas electrónicas, necessitando apenas de um web browser, e utilizando mecanismos seguros que possam ser
mantidos sob o seu controlo.
1.1. INTRODUÇÃO
3
• Permitir ao utilizador realizar uma assinatura electrónica qualificada de um documento
electrónico, produzindo um documento num formato aberto, bem definido e normalizado
que contenha o documento electrónico assinado e a assinatura, assim como permitir ao
utilizador a sua validação (local e remota) e verificação WYSIWYS (What you see is what
you sign) do conteúdo assinado antes da sua submissão ou partilha electrónica.
• No contexto de uma organização, permitir ao utilizador a submissão electrónica do documento assinado num sistema de notariado da organização, que atestará as propriedades
qualificantes reclamadas pelo indivı́duo, contra-assinando a assinatura inicial e as propriedades qualificantes, produzindo uma assinatura que possa ser facilmente validada por
terceiros.
• Permitir à organização a validação temporal, o armazenamento, e a protecção a longo prazo
das assinaturas, recorrendo a carimbos temporais electrónicos (Trusted Timestamping), ou
outros mecanismos.
Um outro objectivo foi a implementação do sistema descrito recorrendo apenas a tecnologia
normalizada e a software Open Source, de modo a minimizar os seus custos e a obter um
elevado grau de portabilidade entre diferente arquitecturas/sistemas operativos, facilitando e
transparecendo todo o processo de produção e validação das assinaturas.
1.1.3
Estrutura do Documento
No capı́tulo 2 é apresentado o state of the art das assinaturas electrónicas.
No capı́tulo 3 são enumerados os problemas, requisitos e objectivos e é proposta uma solução
e apresentada a sua arquitectura.
No capı́tulo 4 são descritos os componentes do sistema proposto e os seus detalhes de implementação.
No capı́tulo 5 é apresentada uma discussão sobre diversos aspectos da implementação realizada.
No capı́tulo 6 são apresentadas as conclusões e o trabalho futuro.
4
CHAPTER 1. INTRODUÇÃO
1.1.4
Notas
Os termos digital e electrónico(a) utilizados ao longo deste documento são intercambiáveis,
tendo o mesmo significado.
A palavra “documento” refere-se não só a documentos textuais passı́veis de representação
escrita, mas também a documentos não passı́veis de representação escrita, como por exemplo,
vı́deo. Deverá ser entendida como um qualquer tipo de dados, passı́vel de representação digital.
2
State of the Art
The release of atomic energy has not created a new problem. It has merely made more
urgent the necessity of solving an existing one.
– Albert Einstein
2.1
Certificados Digitais
“Certificate: a signed instrument that empowers the Subject. It contains at least an Issuer
and a Subject.” (Ellison et al, 1999) (17)
Um certificado digital é um documento electrónico assinado criptograficamente por uma
autoridade de certificação, associando uma chave pública a uma entidade (13). Esta entidade
pode ser uma pessoa, uma organização, uma aplicação informática ou qualquer outra entidade
confiável pela autoridade de certificação. No certificado reside ainda um conjunto de atributos
que definem o propósito do mesmo (e.g. Assinatura) e que caracterizam a entidade certificada.
Uma autoridade de certificação é uma entidade que gere certificados, definindo polı́ticas,
mecanismos de geração e distribuição de certificados e listas de revogação de certificados (i.e.
certificados invalidados). Tipicamente estas autoridades dispõem de recursos técnicos e humanos
que satisfaçam elevados padrões de operacionalidade e de segurança (35; 8). As autoridades de
certificação podem utilizar hierarquias de certificação assinando certificados que contêm a chave
pública de outras autoridades de certificação. Na Fig.2.1 ilustra-se a hierarquia de entidades de
certificação dos certificados presentes no Cartão de Cidadão.
A segurança de um certificado digital baseia-se em criptografia de chave pública (27), de
forma a tentar impossibilitar ou dificultar ao máximo a sua falsificação. São documentos públicos
criptograficamente seguros que podem ser distribuı́dos através de canais inseguros, permitindo
a distribuição de chaves públicas de forma confiável.
6
CHAPTER 2. STATE OF THE ART
O receptor de um certificado pode verificar a validade da assinatura utilizando para isso a
chave pública da autoridade de certificação. Caso a assinatura esteja correcta e caso se confie
na(s) autoridade(s) de certificação, pode-se confiar no certificado, na entidade que este certifica
e na chave pública dessa mesma entidade. Adicionalmente deverão ser efectuadas verificações
em “tempo real” do estado do certificado, através de CRL (25) ou OCSP (32) para verificar se
este ainda se encontra válido, se este se encontra num estado desconhecido, ou se foi revogado
(i.e. invalidado) pela autoridade de certificação.
Figura 2.1: Hierarquia de entidades de certificação (Certification Authorities) dos certificados
presentes no Cartão de Cidadão
2.2
Assinatura Electrónica Qualificada
A assinatura electrónica qualificada de documentos é realizada recorrendo a certificados
digitais qualificados, isto é, certificados digitais assinados por uma entidade certificadora credenciada como é o caso da SCEE (Sistema de Certificação Electrónica do Estado) (40), sendo
essa assinatura realizada através de um dispositivo seguro de criação de assinatura (e.g. SmartCard, USB Token).
2.3. CARTÃO DE CIDADÃO
7
Estes certificados digitais qualificados são emitidos por outras entidades certificadoras do
estado, como a Entidade Certificadora Comum do Estado, Cartão de Cidadão, Passaporte
Electrónico Português, Rede Nacional de Segurança Interna e a Entidade Certificadora do Ministério da Justiça. No âmbito deste trabalho serão utilizados os certificados qualificados emitidos
pela entidade certificadora do cartão de cidadão (6).
Em Portugal, segundo o Gabinete Nacional de Segurança (GNS)(23), neste momento existem
apenas duas entidades privadas (i.e. não integrantes do SCEE) habilitadas a emitir certificados
electrónicos qualificados: a Multicert (31) e a DigitalSign (14) (uma empresa sub-contratada da
British Telecommunications PLC). Ambas as entidades podem emitir certificados electrónicos
qualificados em nome de pessoas singulares ou colectivas.
A assinatura electrónica tem o valor legal conferido pela lei, nomeadamente no Decreto-Lei
n.o 290-D/99 (11), de 2 de Agosto, republicado pelo Decreto-Lei n.o 62/2003 (12), de 3 de Abril
e alterado pelos Decretos-Lei n.o 165/2004 (10), de 6 de Julho e 116-A/2006 (9), de 16 de Junho.
2.3
Cartão de Cidadão
O cartão de cidadão (ver Fig.2.2) é o novo documento de identificação dos cidadãos
portugueses. É um documento autêntico que contém os dados de cada cidadão relevantes para
a sua identificação e inclui o número de identificação civil, o número de identificação fiscal, o
número de utente dos serviços de saúde e o número de identificação da segurança social.
Figura 2.2: Modelo fı́sico do cartão de cidadão, frente e verso
8
CHAPTER 2. STATE OF THE ART
2.3.1
Funcionalidades Electrónicas
As funcionalidades electrónicas do cartão de cidadão permitem provar a identidade do
cidadão perante terceiros através de autenticação electrónica e autenticar de forma unı́voca
através de uma assinatura electrónica qualificada a sua qualidade de autor de um documento
electrónico. No âmbito deste trabalho serão usadas as funcionalidades electrónicas do cartão
de cidadão, nomeadamente a aplicação residente no cartão, responsável pela autenticação e
assinatura electrónica.
Figura 2.3: Aplicações residentes no chip EMV do cartão de cidadão
O cartão de cidadão (ver Fig.2.3) está dotado de um circuito integrado (i.e. chip EMV)
onde residem todos os dados do cartão (exceptuando a tradicional assinatura digitalizada), e as
aplicações electrónicas (ver Tab.2.1).
Aplicação
Descrição
IAS
Aplicação responsável pelas operações
de autenticação e assinatura electrónica
EMV-CAP
Aplicação responsável pela geração
de palavras-chave únicas por canais alternativos
Match-on-card
Aplicação responsável pela
verificação biométrica da impressão digital
Tabela 2.1: Aplicações electrónicas residentes no Cartão de Cidadão
2.3. CARTÃO DE CIDADÃO
2.3.2
9
Legislação
A Lei Portuguesa n.o 7/2007, de 5 de Fevereiro (30), cria o cartão de cidadão e rege a sua
emissão, substituição, utilização e cancelamento. Acerca da identificação electrónica e assinatura
electrónica destacam-se os seguintes artigos:
Artigo 4.o
Eficácia
O cartão de cidadão constitui tı́tulo bastante para provar a identidade do titular perante
quaisquer autoridades e entidades públicas ou privadas, sendo válido em todo o território nacional, sem prejuı́zo da eficácia extraterritorial reconhecida por normas comunitárias, por convenções internacionais e por normas emanadas dos órgãos competentes das organizações internacionais de que Portugal seja parte, quando tal se encontre estabelecido nos respectivos tratados
constitutivos.
Artigo 6.o
Estrutura e funcionalidades
1 - O cartão de cidadão é um documento de identificação múltipla que inclui uma zona
especı́fica destinada a leitura óptica e incorpora um circuito integrado.
2 - O cartão de cidadão permite ao respectivo titular:
a) Provar a sua identidade perante terceiros através da leitura de elementos visı́veis, coadjuvada pela leitura óptica de uma zona especı́fica;
b) Provar a sua identidade perante terceiros através de autenticação electrónica;
c) Autenticar de forma unı́voca através de uma assinatura electrónica qualificada a sua
qualidade de autor de um documento electrónico.
Artigo 18.o
Certificados digitais
1 - Com o cartão de cidadão é emitido um certificado para autenticação e um certificado
qualificado para assinatura electrónica qualificada necessários à sua utilização electrónica.
10
CHAPTER 2. STATE OF THE ART
2 - O certificado de autenticação é sempre activado no momento da entrega do cartão de
cidadão.
3 - O certificado qualificado para assinatura electrónica qualificada é de activação facultativa,
mas só pode ser activado e utilizado por cidadão com idade igual ou superior a 16 anos.
4 - Também não há lugar à activação do certificado qualificado para assinatura electrónica
qualificada se o titular do pedido de cartão de cidadão se encontrar interdito ou inabilitado.
5 - De cada vez que pretenda utilizar alguma das funcionalidades de comunicação electrónica
activadas no cartão de cidadão, o respectivo titular tem de inserir previamente o seu código
pessoal (PIN) no dispositivo de leitura pertinente.
6 - Os certificados são revogáveis a todo o tempo e, após revogação, a emissão de novos
certificados associados ao cartão de cidadão só é possı́vel com a respectiva substituição.
7 - Ao certificado para autenticação e ao certificado qualificado para assinatura electrónica
qualificada aplica-se o disposto no Decreto-Lei n.o 290-D/99, de 2 de Agosto, republicado pelo
Decreto-Lei n.o 62/2003, de 3 de Abril, e alterado pelos Decretos-Leis n.os 165/2004, de 6 de
Julho, e 116-A/2006, de 16 de Junho, estando aqueles certificados sujeitos às regras legais e
regulamentares relativas ao Sistema de Certificação Electrónica do Estado.
2.3. CARTÃO DE CIDADÃO
2.3.3
11
Certificados X.509 / PKIX
Os certificados X.509 versão 3 (ver Fig.2.4) são o standard de Public Key Infrasctructure
(PKI) mais utilizados. Encontram-se definidos pela ITU-X Recommendation X.509 (28), e
incluem mecanismos de extensão para aumentar a sua flexibilidade. PKIX é a PKI adoptada
na Internet (Housley et al., 2002) (25), adaptando os certificados X.509 v3 à Internet e
especificando as extensões apropriadas.
Figura 2.4: Perfil de um certificado X.509 versão 3
Os certificados presentes no cartão de cidadão são certificados X.509 versão 3, sendo
utilizado este mecanismo de extensão, por exemplo, para diferenciar o tipo de utilização da
chave pública presente (X509v3 Key Usage) . No certificado de Assinatura Digital Qualificada
do cartão de cidadão encontra-se presente a extensão Key Usage (ver Fig.2.5) que garante o
não-repúdio da assinatura.
12
CHAPTER 2. STATE OF THE ART
[Certificado de Assinatura Digital Qualificada]
X509v3 Key Usage : c r i t i c a l
Non R e p u d i a t i o n
[Certificado de Autenticação]
X509v3 Key Usage : c r i t i c a l
D i g i t a l S i g n a t u r e , Key Agreement
Figura 2.5: Extensão Key Usage dos certificados X.509 presentes no Cartão de Cidadão
“The nonRepudiation bit is asserted when the subject public key is used to verify digital
signatures used to provide a non-repudiation service which protects against the signing entity
falsely denying some action, excluding certificate or CRL signing. In the case of later conflict,
a reliable third party may determine the authenticity of the signed data.” (25)
No certificado de Autenticação do cartão de cidadão também se encontra presente a
extensão Key Usage (ver Fig.2.5) mas a sua utilização difere:
“The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing
(bit 6). Digital signature mechanisms are often used for entity authentication and data origin
authentication with integrity.” (25)
Apesar de ambos os certificados poderem ser utilizados para a realização de uma assinatura
electrónica de documentos (uma vez que os seus mecanismos criptográficos são idênticos), apenas
o certificado de assinatura digital qualificada garante o não-repúdio, permitindo, segundo a Lei
Portuguesa (12), a realização de uma assinatura electrónica qualificada.
2.3.4
Certificado de Assinatura Digital Qualificada
A tı́tulo de exemplo ilustra-se na Fig.2.6 a Data Section de um certificado X.509 de Assinatura Digital Qualificada presente num Cartão de Cidadão de teste, onde se podem observar
2.3. CARTÃO DE CIDADÃO
13
diversos atributos, descritos de seguida.
No campo Version é indicada a versão do certificado X.509, neste caso a versão 3.
No campo Serial Number é indicado o número de série, que é um inteiro atribuı́do por uma
CA, devendo ser único para cada certificado emitido por essa CA. A combinação do Issuer e do
Serial Number identificam inequivocamente um certificado.
O campo Signature Algorithm indica o método de assinatura utilizado pela CA para assinar
o certificado. No campo Issuer encontra-se a entidade que emitiu e assinou o certificado.
A validade do certificado encontra-se no campo Validity, sendo especificada uma data de
ı́nicio de validade Not Before e uma data de térmito Not After. O espaço de tempo entre estas
duas datas define o perı́odo de validade do certificado, em que este pode ser utilizado para a
realização de assinaturas.
O campo Subject identifica a entidade associada à chave pública presente no campo Subject
Public Key, no caso do cartão de cidadão, a entidade associada à chave pública é um cidadão
português.
No campo X509v3 Extensions podem-se encontrar as extensões X.509, incluindo a extensão
Key Usage, que define o tipo de utilização da chave pública.
As polı́ticas de certificação encontram-se no campo X509v3 Certificate Policies, e incluem
hyperlinks para informação textual sobre as polı́ticas de certificação utilizadas.
A verificação em tempo real do estado actual de certificados através de CRL e OCSP é
realizada recorrendo aos campos X509v3 CRL Distribution Points e Authority Information
Access respectivamente.
14
CHAPTER 2. STATE OF THE ART
Certificate :
Data :
V e r s i o n : 3 ( 0 x2 )
S e r i a l Number :
5 2 : c0 : 9 0 : 8 4 : f 7 : 9 a : 4 5 : 7 e
S i g n a tu r e Algorithm :
sha1WithRSAEncryption
I s s u e r : CN=( T e s t e ) EC de A s s i n a t u r a
Digital
Q u a l i f i c a d a do C a r t ã o de Cidadão 0 0 0 2 , OU=
subECEstado , O=C a r t ã o de Cidadão , C=PT
Validity
Not B e f o r e : Mar 28 1 6 : 3 3 : 1 7 2008 GMT
Not A f t e r
: Mar 28 0 0 : 0 0 : 0 0 2013 GMT
S u b j e c t : CN=Paula A n d r e i a da C o n c e i ç ã o Á v i l a / s e r i a l N u m b e r=BI85111111 , GN=Paula Andreia , SN=da
C o n c e i ç ã o Á v i l a , OU=( T e s t e )
Assinatura
Q u a l i f i c a d a do Cidadão , OU=Cidadão P o r t u g uê s , O=
C a r t ã o de Cidadão , C=PT
Subject
P u b l i c Key I n f o :
P u b l i c Key A l g o r i t h m :
rsaEncryption
RSA P u b l i c Key :
bit )
(1024
Modulus ( 1 0 2 4
bit ) :
0 0 : d5 : 6 4 : 8 3 : 9 e : 9 5 : 2 7 : 9 6 : b2 : e a : 2 5 : 5 5 : 1 c : f a : a6 :
e 4 : 2 e : 5 3 : 4 d : c 3 : 7 5 : 6 3 : 8 8 : 5 9 : e 7 : 4 f : 9 c : 8 6 : a7 : a5 :
7 2 : 8 1 : 9 d : b8 : d4 : ad : e 6 : 3 0 : f e : 5 f : 6 6 : 9 a : 6 1 : 0 3 : 2 e :
0 5 : dd : 3 d : 8 9 : ed : c 1 : 8 9 : 2 a : e 4 : 4 6 : 9 5 : 3 7 : 3 b : 5 9 : 6 c :
c e : e 4 : 2 a : 3 6 : 6 2 : 0 0 : 5 c : b8 : 5 2 : c c : 0 7 : 5 e : 9 3 : 7 b : 6 8 :
7 0 : 5 9 : cd : b4 : d8 : 7 0 : 9 9 : 0 a : 2 a : 6 c : 2 b : 8 b : f a : 2 6 : 3 7 :
1 6 : 7 a : 1 3 : 6 5 : 7 f : a f : 4 1 : 1 e : 2 c : d7 : d0 : 1 4 : 1 f : 1 f : bc :
9 f : c 0 : 6 3 : aa : 7 3 : 3 a : 9 4 : da : 7 6 : 9 9 : 1 d : aa : f 2 : db : 6 5 :
0b : 2 b : 2 9 : c 7 : 1 d : 2 4 : 1 4 : a e : 5 b
Exponent :
6 5 5 3 7 ( 0 x10001 )
X509v3 e x t e n s i o n s :
X509v3 B a s i c
Constraints :
critical
CA: FALSE
X509v3 Key Usage :
critical
Non R e p u d i a t i o n
X509v3 S u b j e c t Key I d e n t i f i e r :
FF : CF :DC: 9 0 : D5 : 3 7 : 7 C : 3 3 : 2 A : BE : 5 7 : 7 3 : 3 E : 7 9 : F1 : 2 B : 7 F : F7 : BB: 4 1
X509v3 A u t h o r i t y Key I d e n t i f i e r :
k e y i d : 9 7 : 9 A : D5 : F7 : 5 7 : 8 3 : 4 5 : 8 7 : 1 7 : 7 4 : 3 8 : 4 C : 4 5 : 2 3 : 2 3 : 6 9 : D3 : 4 7 : 9 F : 0 4
X509v3 C e r t i f i c a t e
Policy :
Policies :
2.16.620.1.1.1.2.4.1.0.1.1
h t t p : / / p k i . t e s t e . c a r t a o d e c i d a d a o . p t / p u b l i c o / p o l i t i c a s / pc / c c s u b −
CPS :
e c c i d a d a o a s s i n a t u r a p c . html
Policy :
2.16.620.1.1.1.2.4.1.0.7
h t t p : / / p k i . t e s t e . c a r t a o d e c i d a d a o . p t / p u b l i c o / p o l i t i c a s / dpc / c c s u b −
CPS :
e c c i d a d a o a s s i n a t u r a d p c . html
Policy :
CPS :
2.16.620.1.1.1.2.10
h t t p : / /www. s c e e . gov . p t / p c e r t
User N o t i c e :
E x p l i c i t Text :
X509v3 CRL D i s t r i b u t i o n
Points :
URI : h t t p : / / p k i . t e s t e . c a r t a o d e c i d a d a o . p t / p u b l i c o / l r c / c c s u b −
ec cidadao assinatura crl0002 . crl
2.5.29.46:
0 f0d . b . ‘ . ˆ http : / / pki . t e s t e . c a r t a o d e c i d a d a o . pt / p u b l i c o / l r c / cc sub −
ec cidadao assinatura crl0002 delta . crl
Authority
Information
Access :
OCSP − URI : h t t p : / / o c s p . a s c . t e s t e . c a r t a o d e c i d a d a o . p t / p u b l i c o / o c s p
Figura 2.6: Data Section do certificado X.509 versão 3 de Assinatura Digital Qualificada de um
Cartão de Cidadão de teste
2.4. XML
2.4
15
XML
Desde a sua normalização pelo W3C, a linguagem XML (Extensible Markup Language) (22)
tem vindo a ser adoptada por um grande número de organizações como formato base para os
documentos e mensagens utilizados nas aplicações. No âmbito deste trabalho será dado ênfase
às assinaturas digitais em formato XML.
2.4.1
XML Signatures
XML Signatures (também apelidadas de XMLDsig, XML-DSig, XML-Sig) (43) são assinaturas digitais definidas em formato XML (22) (ver Fig.2.7). A sua especificação inclui regras de
sintaxe e de processamento para a criação e representação de assinaturas digitais.
As assinaturas digitais XML fornecem serviços de integridade, autenticação da mensagem
e/ou autenticação do assinante para qualquer tipo de documentos electrónicos (i.e.
data
objects, conjunto de bytes). Estas são aplicadas ao data object através de uma indirecção, isto
é, é realizado um resumo do data object, o valor resultante é colocado num elemento (com
informação adicional) e esse elemento é novamente resumido e assinado criptograficamente.
<S i g n a t u r e ID?>
<S i g n e d I n f o >
<C a n o n i c a l i z a t i o n M e t h o d/>
<SignatureMethod/>
(< R e f e r e n c e URI? >
(<Transforms >)?
<DigestMethod>
<D i g e s t V a l u e >
</R e f e r e n c e >)+
</ S i g n e d I n f o >
<S i g n a t u r e V a l u e >
(<KeyInfo >)?
(< O b j e c t ID?>)∗
</S i g n a t u r e >
Figura 2.7: Estrutura de uma assinatura XML
16
CHAPTER 2. STATE OF THE ART
O documento electrónico pode estar dentro da própria assinatura ou noutro local. Enveloped
ou enveloping signatures têm o documento dentro do mesmo documento XML que a assinatura.
Detached signatures contêm uma referência externa para o documento que assina, usualmente
URI (Uniform Resource Identifier ) (3).
2.4.2
XAdES
XAdES (XML Advanced Electronic Signatures) (20) é uma especificação que estende as
XML Signatures utilizando os seus mecanismos de extensão, através da utilização do elemento
XML <ds:Object>. A assinatura XAdES continua a ser uma XML Signature válida. Esta
especificação surgiu da necessidade de ir ao encontro da Directiva Europeia 1999/03/EC (15),
de forma a preencher um número de requisitos como a validade de longo termo da assinatura,
o não repúdio, e a inclusão na assinatura de outra informação qualificante (e.g. data e hora
da assinatura), de forma a que as assinaturas geradas possam ser consideradas assinaturas
electrónicas avançadas.
A especificação XAdES define várias polı́ticas de assinatura de forma a que possa ser estabelecida consistência técnica aquando da validação das assinaturas. Quando uma assinatura
é validada, esta polı́tica tem que estar especificada pelo assinante ou pelos dados a assinar, de
modo a que o resultado obtido na validação da assinatura electrónica seja consistente. A utilização de polı́ticas de assinatura compreensivas é necessária para a obtenção de consistência na
validação da assinatura, devendo ser utilizadas por ambas as partes, isto é, por quem assina e
por quem valida. A especificação do conteúdo das polı́ticas de assinatura encontram-se definida
no relatório da ETSI TR 102 038 (18).
Na especificação XAdES são definidos vários perfis de assinatura electrónica como Basic
Electronic Signature (XAdES-BES), Explicit Policy based Electronic Signature (XAdES-EPES)
e Electronic Signature with Validation Data (XAdES-T e XAdES-C), que satisfazem diferentes
requisitos. Para uma assinatura estar de acordo com a especificação XAdES, ela tem que usar
um destes perfis.
2.4. XML
2.4.2.1
17
XAdES-BES (Basic)
Para que uma assinatura XML seja considerada uma assinatura XAdES-BES esta tem que
incluir a data na qual o assinante terá supostamente criado a assinatura, uma referência não
ambı́gua para o certificado do assinante (uma vez que é possı́vel um assinante utilizar o mesmo
par de chaves pública e privada em diferentes certificados), e opcionalmente uma referência para
a polı́tica de assinatura.
2.4.2.2
XAdES-T (Time Stamped)
Uma assinatura de longo prazo implica que, uma vez sendo a assinatura considerada válida,
ela tem que permanecer válida durante meses ou anos. Este perfil de assinatura contempla
a adição de um carimbo temporal a toda a assinatura, produzido por uma entidade externa
Time Stamp Authority (TSA) (1), produzindo deste modo uma prova não repudiável de que a
assinatura foi realizada antes daquela data, e atestando a veracidade temporal da assinatura.
Este perfil permite também que uma assinatura permaneça válida no caso em que a segurança
criptográfica da assinatura inicial seja comprometida.
2.4.2.3
XAdES-C (Complete)
Este perfil de assinatura contem referências para toda a informação necessária à validação da
assinatura. Inclui referências para os diversos certificados necessários para validar a assinatura,
de modo a que a cadeia de certificação possa ser validada, e referências para a informação do
estado dos certificados (CRL, OCSP) de modo a que possa ser verificado o seu estado num
determinado momento.
2.4.2.4
XAdES-X (Extended)
É semelhante à combinação do perfil XAdES-C com o perfil XAdES-T, adicionando um
carimbo temporal a toda a assinatura, ou apenas às referências para a validação da assinatura,
de modo a provar que o estado da cadeia de certificação e da informação de revogação se
encontrava válido no momento da assinatura. A assinatura poderá assim permanecer válida
18
CHAPTER 2. STATE OF THE ART
mesmo que a segurança de uma entidade de certificação emissora de um certificado presente na
assinatura seja comprometida.
2.4.2.5
XAdES-X-L (Extended Long term)
No futuro poderá não ser possı́vel obter a informação de validação referenciada no perfil XAdES-X, em parte devido à não perenidade dos URIs (3). Neste perfil de assinatura é
adicionada à assinatura toda a informação referenciada pelo perfil XAdES-X.
2.4.2.6
XAdES-A (Archival)
Este perfil de assinatura tem como objectivo o arquivamento da assinatura a longo prazo,
protegendo-a contra algoritmos de segurança que se tornem fracos no futuro e contra pares de
chaves criptográficas cuja segurança tenha sido comprometida. Este método passa pela adição
de carimbos temporais sucessivos a toda a informação incluı́da no perfil XAdES-X-L sempre
que seja necessário, de modo a proteger carimbos temporais anteriores.
2.4.3
Outras Propriedades
Todos este perfis de assinatura suportam contra-assinaturas, suportam a inclusão do papel do indivı́duo assinante na organização, uma descrição do documento, e o compromisso do
assinante perante o documento, respectivamente através dos elementos CounterSignature, SignerRole, DataObjectFormat e CommitmentTypeIndication.
O elemento CounterSignature permite a criação de uma assinatura sobre outra assinatura,
sendo esta funcionalidade particularmente útil para a realização de um serviço de notariado, em
que a entidade que realiza esse serviço atesta as informações que constam na assinatura inicial.
Desta forma é possı́vel atestar a veracidade de propriedades como o papel do assinante (SignerRole) dentro da organização, e a suposta data de criação da assinatura. Esta funcionalidade
também poderá ser utilizada na produção de uma assinatura que contenha vários assinantes.
O elemento SignerRole permite ao indivı́duo assinante dizer em que qualidade(s) de assinante (devido ao facto de um indivı́duo poder desempenhar diferentes cargos numa organização)
2.4. XML
19
é que realiza a assinatura do documento. Isto é realizado através da utilização do elemento
ClaimedRoles.
O elemento DataObjectFormat permite descrever o conteúdo do documento a assinar, através
dos sub-elementos Description MimeType e Encoding, onde são especificados respectivamente
comentários sobre o documento a assinar, o tipo de ficheiro e o tipo de codificação.
O elemento CommitmentTypeIndication permite descrever textualmente e de forma inteligı́vel o compromisso do assinante perante o documento assinado.
Como se pode observar na Fig.2.9, os elementos SignerRole, DataObjectFormat e CommitmentTypeIndication são sub-elementos das SignedProperties, pelo que são também assinados
quando é realizada a assinatura do documento.
Figura 2.8: Utilização do elemento CounterSignature XAdES
As assinaturas XAdES suportam também outras propriedades qualificantes da assinatura,
como por exemplo o local geográfico onde a assinatura foi criada através do elemento SignatureProductionPlace. Esta propriedade assinada é especialmente interessante quando uma
organização ou entidade possui diferentes localizações geográficas e deseja diferenciar e atestar
o local onde as assinaturas foram criadas.
20
CHAPTER 2. STATE OF THE ART
Figura 2.9: Estrutura das assinaturas XAdES
2.5. CADES
2.5
21
CAdES
CMS Advanced Electronic Signatures (CAdES) (19) é um conjunto de extensões da Cryptographic Message Syntax (CMS) (26) de forma a contemplar as propriedades da assinatura
electrónica avançada, de acordo com a Directiva Europeia 1999/03/EC (15). Estas extensões
definem diferentes perfis de assinaturas, similares aos perfis XAdES. À semelhança das assinaturas XAdES, as assinaturas CAdES também contemplam Timestamping e outros mecanismos
de forma a proteger a validade das assinaturas a longo prazo.
2.6
PAdES
PDF Advanced Electronic Signatures (PAdES) (21) é uma proposta de extensão dos documentos no formato PDF v1.7 definido no ISO 32000-1, de forma a contemplar as propriedades
da assinatura electrónica avançada, e à semelhança do CAdES e XAdES, estar de acordo com a
Directiva Europeia 1999/03/EC (15) . O formato PDF é um ISO International Standard desde
Julho de 2008 tendo sido delegado pela Adobe Systems Incorporated à International Organization for Standartization. À semelhança das assinaturas CAdES e XAdES propõe diferentes
perfis de assinatura. Esta proposta define perfis de inclusão de assinaturas CAdES e XAdES
nos documentos PDF, em deterimento das assinaturas PKCS#7 utilizadas. Esta proposta de
extensão irá ser sugerida para integrar o próximo PDF standard, o ISO 32000-2.
2.7
Trusted timestamping
O trusted timestamping é um processo seguro que permite provar a temporalidade de um
documento, isto é, a existência de certos dados antes de uma determinada data.
“À medida que os certificados são revogados devido a perda ou perda de validade, as assinaturas feitas não podem de repente ficar inválidas.” (36). De forma a garantir a validade a
longo prazo das assinaturas, é necessário recorrer a um serviço de timestamping confiável.
Este processo é realizado por uma Time Stamp Authority (TSA) que é responsável pela
geração de carimbos temporais através do Time Stamp Protocol (1). O processo de produção de
carimbos temporais é relativamente simples, a entidade que deseja atestar a temporalidade de
22
CHAPTER 2. STATE OF THE ART
um documento realiza uma operação de hashing sobre o documento obtendo um digest, envia
o conjunto de bytes do digest para a TSA, a TSA adiciona a esse conjunto de bytes a data
actual (data e hora), e assina o resultado, devolvendo à entidade o resultado da assinatura e o
certificado da TSA num Time Stamp Token. Desta forma o conteúdo do documento nunca é
enviado para a TSA, salvaguardando a confidencialidade do conteúdo.
Após a adição de carimbo temporal ninguém, incluindo o autor do documento, poderá
alterá-lo sem comprometer a integridade do carimbo temporal.
3
Proposta
This is my answer to the gap between ideas and action - I will write it out.
– Hortense Calisher
3.1
Problemas
Nesta secção descrevem-se os problemas que o sistema de assinatura electrónica proposto
pretende resolver.
3.1.1
Formato das assinaturas
Os sistemas de assinatura electrónica tipicamente utilizados, são sistemas (i.e. software)
proprietários dependentes do sistema operativo e do tipo de documento, cuja especificação tem
um mecanismo especı́fico de inclusão da assinatura e que difere em cada formato de documento.
Este facto impõe uma forte limitação tanto no processo de validação da assinatura como no
seu processo produção, pois na maioria dos casos não estão disponı́veis mecanismos de contraassinatura e/ou de Timestamping. Nestas situações o receptor da assinatura terá que dispor
dos mesmos meios (i.e. mesmo software) que o assinante de forma a que a possa validar, não
sendo este processo transparente e confiável, na medida em que os formatos dos documentos são
proprietários.
Esta validação é tipicamente realizada no sistema do utilizador, pelo que o processo de
validação poderá ser maliciosamente subvertido, apresentando um estado erróneo de validade
da assinatura, induzindo o utilizador em erro.
O formato da assinatura produzida é frequentemente dependente do tipo de documento e
do software que se utiliza, isto é, não existindo na especificação do formato de um determinado
24
CHAPTER 3. PROPOSTA
tipo de documento um mecanismo de assinatura, como por exemplo um ficheiro de áudio, vı́deo
ou imagem, a assinatura electrónica deste tipo de documentos fica bastante limitada.
3.1.2
Temporalidade da assinatura
Mesmo estando na posse de um certificado revogado ou expirado, é possı́vel realizar uma
assinatura forjada temporalmente, realizada no espaço de tempo em que o certificado se encontrava válido, subvertendo desta forma os mecanismos de validação da assinatura. Isto deve-se
ao facto de a assinatura ser gerada usando o relógio do sistema operativo da máquina local, cujo
valor pode ser manipulado.
3.1.3
Assinaturas numa organização
Tipicamente uma organização não assina documentos, estes são assinados por um indivı́duo
pertencente à organização, de forma a que este tenha a responsabilidade inerente à sua concordância.
Embora o nome do assinante seja importante, o cargo do assinante dentro de uma empresa
ou organização é tão ou mais importante. Alguns contratos poderão apenas ser válidos se o
assinante tiver um determinado cargo dentro da organização (e.g. Director de Compras), ou se
o assinante tiver autoridade para assinar determinado tipo de documento.
3.1.4
Compromisso da assinatura
Outro problema reflecte-se com a manifestação explı́cita do compromisso do assinante relativo ao documento que assina quando este não se encontra evidenciado no próprio documento.
Uma assinatura deverá ser passı́vel de inclusão do compromisso a que o indivı́duo se compromete ao assinar o documento (e.g. aprovo o conteúdo do documento, tomei conhecimento, etc...),
para que em caso de disputa não haja dúvidas da intenção do assinante.
3.1.5
Validade a longo prazo
Um algoritmo criptográfico considerado seguro no presente, pode no futuro vir a ser comprometido através do aumento da capacidade de computação ou da descoberta de pontos de falha
3.2. OBJECTIVOS
25
no algoritmo que permitam obter colisões num espaço mais pequeno. Este ponto é particularmente crı́tico nas funções de resumo (cryptographic hash functions), uma vez que as assinaturas
(e.g. RSA) são realizadas sobre o resultado da função de resumo, o que permite a troca do
documento por um diferente, mas manipulado, para que a função de resumo produza o mesmo
resultado. Neste momento duas das funções de resumo bastante utilizadas são consideradas
inseguras, como é o caso do MD5 (42) e do SHA-1 (5).
A geração de pares de chaves criptográficas poderá também comprometer as assinaturas,
por exemplo, um erro de inicialização do gerador de números aleatórios levou a que as chaves
geradas entre Setembro de 2006 e Maio de 2008 no OpenSSL do sistema operativo Debian Linux
(e derivados) a produzir um número limitado e previsı́vel de pares de chaves, independentemente
do tamanho das chaves geradas. (7)
De forma a proteger as assinaturas contra o enfraquecimento dos algoritmos utilizados na
sua produção, as assinaturas deverão ser contra-assinadas periodicamente com algoritmos mais
fortes, de forma a proteger no futuro a sua validade.
3.2
Objectivos
A proposta apresentada pretende propor um sistema de assinatura de documentos
electrónicos independentemente do seu formato, sejam eles documentos de texto, imagem, vı́deo,
logs, executáveis, etc... Isto é, todos os conjuntos de bytes deverão ser passı́veis de uma assinatura
electrónica qualificada, de forma transparente, num formato aberto, bem definido e normalizado,
como é o caso do formato XAdES (20).
A utilização de uma assinatura electrónica qualificada, deve-se ao facto de ser necessário
garantir o valor probatório dos documentos assinados electronicamente de acordo com a Lei
Portuguesa (11; 12; 10) e com a Directiva Europeia (15) para as assinaturas electrónicas, de
forma a que as assinaturas produzidas tenham validade legal em todos os Estados Membros da
União Europeia.
Um dos objectivos deste sistema de assinatura de documentos electrónicos, é a criação de
uma assinatura electrónica que inclua nas propriedades qualificantes o cargo na organização e o
compromisso relativo ao documento do indivı́duo que assina o documento, atestando-o através
26
CHAPTER 3. PROPOSTA
da aposição de uma contra-assinatura da organização sobre a assinatura do indivı́duo e das
propriedades qualificantes.
Um outro objectivo deste sistema é atestar a veracidade temporal das assinaturas realizadas,
recorrendo a mecanismos seguros de certificação temporal. Tem também como objectivo assegurar a validade das assinaturas por longos perı́odos de tempo, mesmo que a segurança das chaves
criptográficas seja mais tarde comprometida.
Os requisitos a que este sistema deverá obedecer são os seguintes:
• Fornecer ao utilizador um mecanismo simples de criação de assinaturas electrónicas, necessitando apenas de um web browser, e utilizando mecanismos seguros que possam ser
mantidos sob o seu controlo.
• Permitir ao utilizador realizar uma assinatura electrónica qualificada de um documento
electrónico, produzindo um documento num formato bem definido e normalizado que contenha o documento electrónico assinado e a assinatura, assim como permitir ao utilizador
a sua validação (local e remota) e verificação WYSIWYS (What you see is what you sign)
do conteúdo assinado antes da sua submissão ou partilha electrónica.
• No contexto de uma organização, permitir ao utilizador a submissão electrónica do documento assinado num sistema de notariado da organização, que atestará as propriedades
qualificantes reclamadas pelo indivı́duo, contra-assinando a assinatura inicial e as propriedades qualificantes, produzindo uma assinatura que possa ser facilmente validada por
terceiros.
• Permitir à organização a validação temporal, o armazenamento, e a protecção a longo
prazo da veracidade das assinaturas, recorrendo a carimbos temporais electrónicos (Trusted
Timestamping).
Um outro objectivo foi a implementação do sistema descrito recorrendo apenas a tecnologia
normalizada e a software Open Source, de modo a minimizar os seus custos e a obter um
elevado grau de portabilidade entre diferente arquitecturas/sistemas operativos, facilitando e
transparecendo todo o processo de produção e validação das assinaturas.
3.3. ARQUITECTURA
3.3
27
Arquitectura
“Para a realização de uma assinatura electrónica qualificada é necessário que a assinatura
identifique de forma unı́voca o titular como autor do documento, que a aposição da assinatura ao
documento dependa da vontade do titular, que a assinatura seja criada com meios que o titular
pode manter sob o seu controlo exclusivo, que a sua conexão com o documento permita detectar
toda e qualquer alteração superveniente do conteúdo deste, e que a realização da assinatura seja
baseada num certificado qualificado sendo realizada através de um dispositivo seguro de criação
de assinatura” (12)
Figura 3.1: Componentes de um serviço de assinatura electrónica qualificada
Na solução proposta (Fig. 3.1), o indivı́duo titular de um certificado qualificado para
assinatura electrónica qualificada de documentos, presente no seu Cartão de Cidadão, utiliza-o
de forma a assinar electronicamente um documento mediante a sua vontade, utilizando o seu
PIN pessoal da assinatura digital. Este processo é realizado numa aplicação segura de criação
de assinatura que se executa no computador do indivı́duo, onde este escolhe qual o documento
a assinar, podendo visualizar o seu conteúdo (WYSIWYS), escolhendo a qualidade (i.e. o
28
CHAPTER 3. PROPOSTA
cargo do indivı́duo na organização) em que deseja assinar o documento e outras propriedades
qualificantes, assinando-o (i.e. criando uma assinatura XAdES). Opcionalmente poderá incluir
na assinatura um carimbo temporal, de forma a atestar a temporalidade da mesma. Todo
este processo é realizado no componente assinatura electrónica qualificada (Fig.3.2). Deverá
opcionalmente, validar pelos seus meios o valor da assinatura do documento e do conteúdo
assinado, e/ou poderá efectuar uma validação on-line. De seguida deverá submeter a assinatura
para o sistema de notariado da organização, de forma a que esta possa atestar as suas qualidades.
Figura 3.2: Arquitectura da solução proposta
O sistema de notariado da organização (Fig.3.2) aceita documentos assinados electronicamente no formato XAdES por indivı́duos pertencentes à organização, e efectua a validação da
assinatura e das suas propriedades, atestando a sua veracidade através da realização de uma
3.3. ARQUITECTURA
29
contra-assinatura. Este sistema é responsável pela validação da assinatura, do certificado utilizado na assinatura e da sua hierarquia de certificação, pela validação temporal da assinatura
validando a data na qual o assinante diz ter criado a assinatura, e pela validação das propriedades qualificantes reclamadas pelo assinante, como o cargo do indivı́duo na organização e
o seu compromisso relativamente ao documento assinado.
Este sistema de notariado recorre a um sistema de certificação temporal, uma TSA (1),
de forma a acrescentar à assinatura um carimbo temporal, isto é, uma prova temporal não
repudiável. A produção da contra-assinatura da organização poderá ser realizado através de um
processo manual, dependendo dos requisitos existentes para o tipo de assinatura em questão.
O sistema de arquivamento tem como função arquivar os documentos e as suas assinaturas,
protegendo-as a longo prazo contra algoritmos de segurança que no futuro se tornem fracos e
contra pares de chaves criptográficas cuja segurança tenha sido comprometida. Este processo
realiza-se através da adição de sucessivos carimbos temporais à assinatura, periodicamente ou
sempre que seja necessário, de modo a proteger carimbos temporais anteriores. À semelhança
do sistema de notariado recorre também a um sistema de certificação temporal.
Uma assinatura electrónica de um documento no contexto organização poderá ser considerada válida numa das seguintes situações, dependendo dos requisitos organizacionais:
• Quando o documento se encontra assinado por um indivı́duo através de uma assinatura
digital qualificada, e quando existe uma contra-assinatura da organização que ateste as propriedades qualificantes da assinatura inicial. Esta contra-assinatura da organização deverá
ser certificada por uma entidade externa confiável a terceiros que efectuem a validação, ou
deverá ser estabelecida uma relação de confiança com a organização e consequentemente
com o certificado utilizado pela mesma na realização da contra-assinatura. A aposição de
pelo menos um carimbo temporal não repudiável é essencial para garantir a temporalidade
da assinatura.
• Quando o documento se encontra assinado por um indivı́duo através de uma assinatura
digital qualificada, e quando existe na assinatura um carimbo temporal não repudiável
(e da confiança da organização) que ateste a data de criação da assinatura. Em caso de
litı́gio entre o assinante e a organização, as disputas sobre a validade ou não da assinatura
terá que ser feita à posteriori, verificando se na data em que foi realizada a assinatura o
30
CHAPTER 3. PROPOSTA
assinante teria poderes para tal. Este tipo de assinatura simplifica o processo de assinatura
na medida em que dispensa um serviço de notariado. É particularmente útil para assinaturas de documentos utilizados apenas dentro da organização, isto é, não partilhados com
terceiros (i.e. entidades externas).
4
Implementação
Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the
Universe is winning.
– Rick Cook
4.1
Protótipo
O sistema de assinatura electrónica qualificada de documentos descrito no capı́tulo anterior
foi implementado, dando origem a um protótipo funcional baptizado de AEQ Docs. A utilização
deste sistema requere apenas o uso de um web browser com suporte para Java SE 6 (29) e da
Aplicação do Cartão de Cidadão instalada (i.e. middleware do cartão de cidadão) (6), sendo
compatı́vel com os sistemas operativos Windows, MacOSX e Linux. Necessita também de um
leitor de SmartCards compatı́vel com a norma ISO 7816.
4.2
AEQ Docs
A implementação do sistema proposto foi realizada utilizando vários módulos standalone,
sendo cada um deles responsável por uma parte das funcionalidades. Todos estes módulos, à
excepção da Interface Web foram implementados na linguagem de programação Java.
4.2.1
XAdESSigner
O módulo XAdESSigner é responsável pela produção de assinaturas electrónicas qualificadas no formato XAdES-BES, isto é, uma assinatura que inclui a data na qual o assinante
terá supostamente criado a assinatura e uma referência não ambı́gua para o certificado do assinante. Inclui ainda outras propriedades qualificantes opcionais, como o cargo do assinante na
32
CHAPTER 4. IMPLEMENTAÇÃO
organização, o compromisso do assinante relativamente ao documento assinado e uma descrição
do documento assinado. Todas estas propriedades qualificantes são assinadas.
Este módulo utiliza um sub-módulo chamado CartaoCidadaoPKCS11, que é responsável
pela identificação do sistema operativo em utilização, efectuando a ligação entre a biblioteca
PKCS#11 (37) do cartão de cidadão e o XAdESSigner, permitindo a utilização das funcionalidades criptográficas do cartão de cidadão.
O XAdESSigner pode ser invocado na linha de comandos, e recebe como argumentos
o documento a assinar FileToSign, o nome do documento na assinatura XMLFilename, o
cargo/qualidade do indivı́duo Role, uma descrição do ficheiro FileDescription e o compromisso
relativo ao documento assinado Commitment. O resultado da execução do XAdESSigner é a
produção de uma assinatura XML com o nome do documento mas com a extensão .xml.sig, que
contém o documento e a assinatura XAdES.
$ j a v a XAdESSigner F i l e T o S i g n XMLFilename Role F i l e D e s c r i p t i o n Commitment
Figura 4.1: Invocação do XAdESSigner através da linha de comandos
As assinaturas realizadas por este módulo são do tipo Enveloped, isto é, a assinatura
encontra-se dentro do elemento que contém o documento a assinar. Na Fig.4.2 pode-se observar
um exemplo de uma assinatura gerada pelo XAdESSigner. O elemento de raiz <SignedFile>
contém dois sub-elementos <FileContent> e <ds:Signature>. No elemento <FileContent>
encontra-se o conteúdo do documento assinado, codificado em Base64 (39), sendo o nome do
documento definido pelo atributo Id. No elemento <ds:Signature> encontra-se a assinatura
XMLDsig, com as referências para o conteúdo assinado e o respectivo valor da assinatura.
A
assinatura
XMLDsig
produzida
tem
4
sub-elementos
<ds:SignedInfo>,
<ds:SignatureValue>, <ds:KeyInfo> e <ds:Object>.
O elemento <ds:SignedInfo> representa a informação que está assinada. Contém o método
de canonização utilizado <ds:CanonicalizationMethod>, isto é, o algoritmo utilizado para
estruturar a informação, numa forma comum e reconhecida.
Este método é de extrema
importância, pois define o algoritmo aplicado ao elemento <ds:SignedInfo> antes da realização
dos cálculos da assinatura, podendo definir regras para a transformação dos terminadores
4.2. AEQ DOCS
33
de linha (i.e. CRLF), para a normalização do mapa de caracteres, para a remoção ou não
de comentários, ou outra qualquer manipulação que possa ser necessária, de forma a que o
elemento <ds:SignedInfo> seja processado independentemente da implementação, de forma a
que possa haver consistência no processo de validação da assinatura.
<?xml v e r s i o n =”1.0” e n c o d i n g =”UTF−8” s t a n d a l o n e =”no”?>
<S i g n e d F i l e >
<F i l e C o n t e n t I d=”exemplo . t x t ”>SXN0byDDqSB1bSBmaWNoZWlybyBkZSBleGVtcGxvCg==</F i l e C o n t e n t >
<d s : S i g n a t u r e xmlns : d s=”h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g#” I d=” i d S i g n a t u r e ”>
<d s : S i g n e d I n f o >
<d s : C a n o n i c a l i z a t i o n M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g /TR/ 2 0 0 1 /REC−xml−c14n −20010315#
WithComments”/>
<d s : S i g n a t u r e M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g#r s a −s h a 1 ”/>
<d s : R e f e r e n c e URI=”#exemplo . t x t ”>
<d s : T r a n s f o r m s>
<d s : Transform A l g o r i t h m=”h t t p : / /www. w3 . o r g /TR/ 2 0 0 1 /REC−xml−c14n −20010315#WithComments”/>
</d s : T r a n s f o r m s>
<d s : D i g e s t M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 1 / 0 4 / xmlenc#s h a 2 5 6 ”/>
<d s : D i g e s t V a l u e > . . . < / d s : D i g e s t V a l u e >
</d s : R e f e r e n c e >
<d s : R e f e r e n c e URI=”#i d S i g n e d P r o p e r t i e s ”>
<d s : T r a n s f o r m s>
<d s : Transform A l g o r i t h m=”h t t p : / /www. w3 . o r g /TR/ 2 0 0 1 /REC−xml−c14n −20010315#WithComments”/>
</d s : T r a n s f o r m s>
<d s : D i g e s t M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 1 / 0 4 / xmlenc#s h a 2 5 6 ”/>
<d s : D i g e s t V a l u e > . . . < / d s : D i g e s t V a l u e >
</d s : R e f e r e n c e >
</d s : S i g n e d I n f o >
<d s : S i g n a t u r e V a l u e I d=” i d S i g n a t u r e V a l u e ” >... </ d s : S i g n a t u r e V a l u e >
<d s : K eyInfo>
<d s : KeyValue>
<d s : RSAKeyValue>
<d s : Modulus > . . . < / d s : Modulus>
<d s : Exponent>AQAB</d s : Exponent>
</d s : RSAKeyValue>
</d s : KeyValue>
<d s : X509Data>
<d s : X509SubjectName>C=PT, O=C a r t ã o de Cidadão , OU=Cidadão P o r t u g uê s , OU=( T e s t e )
Assinatura
Q u a l i f i c a d a do Cidadão , SURNAME=da C o n c e i ç ã o Á v i l a , GIVENNAME=Paula Andreia , SERIALNUMBER=
BI85111111 , CN=Paula A n d r e i a da C o n c e i ç ã o Á v i l a </d s : X509SubjectName>
</d s : X509Data>
<d s : X509Data>
<d s : X 5 0 9 C e r t i f i c a t e > . . . < / d s : X 5 0 9 C e r t i f i c a t e >
</d s : X509Data>
</d s : KeyInfo>
<d s : O b j e c t I d=” i d O b j e c t ”>
...
</d s : O b j e c t>
</d s : S i g n a t u r e >
</ S i g n e d F i l e >
Figura 4.2: Assinatura XMLDsig gerada pelo XAdESSigner
As referências ao conteúdo que se deseja assinar encontram-se nos sub-elementos
34
CHAPTER 4. IMPLEMENTAÇÃO
<ds:Reference>.
Cada um destes elementos contém uma referência para o conteúdo
que deseja assinar, o digest algorithm utilizado (e.g.
SHA-256) e o digest value re-
sultante da aplicação do digest algorithm ao conteúdo referenciado após a aplicação do
método de transformação especificado <ds:Transform>, cujo objectivo é o mesmo do
<ds:CanonicalizationMethod>. Na Fig.4.2 existem duas referências, uma para o ficheiro a
assinar <ds:Reference URI=”#exemplo.txt”> e outra para as <SignedProperties> da extensão
XAdES (Fig.4.3) <ds:Reference URI=”#idSignedProperties”>.
O valor da assinatura codificado em Base64 encontra-se no elemento <ds:SignatureValue>,
sendo resultante da aplicação do método de assinatura <ds:SignatureMethod> ao elemento
<ds:SignedInfo> após a aplicação do método de canonização.
O elemento <ds:KeyInfo> contém a informação sobre a chave pública no elemento
<ds:KeyValue>, de forma a que o receptor da assinatura a possa validar. Inclui também o
sub-elemento <ds:X509Data> onde é incluı́do certificado X.509 no formato DER (Distinguished
Encoding Rules) codificado em Base64 no sub-elemento <ds:X509Certificate>. Contém também
o subject name do certificado utilizado no sub-elemento <ds:X509SubjectName>.
A extensão XAdES encontra-se no elemento <ds:Object Id=”idObject”>, mais precisamente
no sub-elemento <QualifyingProperties> representado na Fig.4.3. Este elemento engloba todas
as propriedades qualificantes da assinatura, e contêm uma referência para a assinatura a que se
refere no atributo Target=”idSignature”, ou seja, a XMLDsig da Fig.4.2.
O elemento <SignedProperties Id=”idSignedProperties”> é o elemento referenciado pela
XMLDsig e engloba todo o conteúdo a ser digested e assinado. Como sub-elementos tem as
propriedades qualificantes da assinatura no elemento <SignedSignatureProperties> e as propriedades do objecto assinado no elemento <SignedDataObjectProperties>.
No elemento <SignedSignatureProperties> encontram-se os sub-elementos <SigningTime>
e <SigningCertificate>, necessários para que a assinatura seja considerada um assinatura
electrónica qualificada, e para que tenha o valor respectivo valor legal.
O elemento
<SigningTime> inclui a data em que o assinante supostamente realizou a assinatura, esta data
é obtida a partir do relógio do sistema operativo máquina do utilizador.
O elemento <SigningCertificate> contém as referências não ambı́guas para o certificado
utilizado na realização da assinatura, contendo o digest do certificado (presente no elemento
4.2. AEQ DOCS
35
<ds:X509Certificate> da XMLDsig) no sub-elemento <CertDigest>. Outras referências ao
certificado encontram-se no elemento <IssuerSerial>, nomeadamante o nome do emissor do
certificado no sub-elemento <ds:X509IssuerName>, e o número de série do certificado no
sub-elemento <ds:X509SerialNumber>. Estas referências são necessárias para impossibilitar
(ou dificultar) a substituição do certificado presente na XMLDSig, uma vez que o elemento
<ds:X509Certificate> não é uma propriedade assinada, podendo o certificado ser substituı́do
por outro que tenha a mesma chave pública.
36
CHAPTER 4. IMPLEMENTAÇÃO
<d s : O b j e c t I d=” i d O b j e c t ”>
<Q u a l i f y i n g P r o p e r t i e s xmlns=”h t t p : / / u r i . e t s i . o r g / 0 1 9 0 3 / v1 . 3 . 2 # ” T a r g e t=” i d S i g n a t u r e ”>
<S i g n e d P r o p e r t i e s
I d=” i d S i g n e d P r o p e r t i e s ”>
<S i g n e d S i g n a t u r e P r o p e r t i e s >
<S i g n i n g T i m e >2009−10−20T02 : 5 8 : 3 0 + 0 1 : 0 0 < / S i g n i n g T i m e>
<S i g n i n g C e r t i f i c a t e >
<Cert>
<C e r t D i g e s t >
<d s : D i g e s t M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g#s h a 2 5 6 ”/>
<d s : D i g e s t V a l u e >+6GAx9PsKhKhBf2Cr0qU5HLpapZ6z9juUZyyhNFDJ9M=</d s : D i g e s t V a l u e >
</ C e r t D i g e s t >
<I s s u e r S e r i a l >
<d s : X509IssuerName>C=PT, O=C a r t ã o de Cidadão , OU=subECEstado , CN=( T e s t e ) EC de
Assinatura
Digital
Q u a l i f i c a d a do C a r t ã o de Cidadão 0002</ ds : X509IssuerName>
<d s : X509SerialNumber >5962924807402702206 </ d s : X509SerialNumber>
</ I s s u e r S e r i a l >
</Cert>
</ S i g n i n g C e r t i f i c a t e >
<S i g n e r R o l e >
<C l a i m e d R o l e s >
<ClaimedRole>D i r e c t o r de Compras</ClaimedRole>
</C l a i m e d R o l e s >
</ S i g n e r R o l e >
</ S i g n e d S i g n a t u r e P r o p e r t i e s >
<S i g n e d D a t a O b j e c t P r o p e r t i e s >
<DataObjectFormat O b j e c t R e f e r e n c e=”#exemplo . t x t ”>
<D e s c r i p t i o n >F i c h e i r o de exemplo </ D e s c r i p t i o n >
<MimeType>t e x t / p l a i n </MimeType>
<Encoding>b a s e 6 4 </Encoding>
</DataObjectFormat>
<CommitmentTypeIndication>
<CommitmentTypeId>
< I d e n t i f i e r />
</CommitmentTypeId>
<A l l S i g n e d D a t a O b j e c t s />
<C o m m i t m e n t T y p e Q u a l i f i e r s>
<CommitmentTypeQualifier>Aprovo o c o n t e ú d o do documento a s s i n a d o </
CommitmentTypeQualifier>
</C o m m i t m e n t T y p e Q u a l i f i e r s>
</CommitmentTypeIndication>
</ S i g n e d D a t a O b j e c t P r o p e r t i e s >
</ S i g n e d P r o p e r t i e s >
</ Q u a l i f y i n g P r o p e r t i e s >
</d s : O b j e c t>
Figura 4.3: Extensão XAdES-BES da assinatura XMLDsig gerada pelo XAdESSigner
O cargo do indivı́duo na organização (ou a sua qualidade de assinante) encontra-se
no elemento <SignerRole>, nomeadamente numa lista de ClaimedRoles, no sub-elemento
<ClaimedRole>. No exemplo da Fig.4.3 a assinatura é realizada na qualidade de Director
de Compras.
A descrição do documento assinado encontra-se no elemento <SignedDataObjectProperties>,
4.2. AEQ DOCS
37
onde existe uma referência para o documento assinado no sub-elemento <DataObjectFormat
ObjectReference=”#exemplo.txt”>,
uma
descrição
do
documento
no
sub-elemento
<Description>, o mime type (4) do documento no sub-elemento <MimeType> e o seu
método de codificação no sub-elemento <Encoding>.
O compromisso do assinante perante o documento assinado encontra-se definido
no
elemento
<CommitmentTypeIndication>,
<CommitmentTypeQualifier>.
mais
precisamente
no
sub-elemento
A existência do elemento <AllSignedDataObjects/> implica
que todos os data objects assinados partilhem o mesmo compromisso.
4.2.2
XAdESValidator
O módulo XAdESValidator é responsável pela validação das assinaturas em diversos aspectos. À semelhança do XAdESSigner pode ser invocado através da linha de comandos (Fig.4.4).
As validações que o XAdESValidator pode efectuar são a combinação de 4 validações possı́veis:
• Schema - Valida o documento XML fornecido mediante o esquema XSD XAdES 1.3.2
que define as regras a que a assinatura tem que obdecer para que seja considerada bem
definida.
• Assinatura - Percorre o documento XML à procura de qualquer tipo de assinatura XMLDsig com ou sem a extensão XAdES e procede à sua validação assim como à validação de
todas as referências e digests.
• Revogação - Verifica on-line e em tempo-real através da validação OCSP o estado do
certificado na suposta data de produção da assinatura, de forma a identificar certificados
revogados ou em estado inválido.
• Validade - Verifica se na suposta data de produção da assinatura o certificado utilizado
para realizar a assinatura se encontrava válido, isto é, dentro do seu perı́odo de validade.
38
CHAPTER 4. IMPLEMENTAÇÃO
$ j a v a XAdESValidator XMLtovalidate . xml o p t i o n s
Options :
−xsd
V a l i d a t e s i g n a t u r e s a g a i n s t XAdES schema d e f i n i t i o n
−s i g
V a l i d a t e XML s i g n a t u r e s
−r e v
Check f o r r e v o c a t e d c e r t i f i c a t e s w h i l e v a l i d a t i n g s i g n a t u r e s
−v a l
Check f o r c e r t i f i c a t e v a l i d i t y on t h e SigningTime
Figura 4.4: Invocação do XAdESValidator através da linha de comandos
A execução do XAdESValidator devolve como resultado SUCCESS no caso em que todas
as validações passadas como argumentos tenham sido realizadas correctamente, ou ERROR no
caso em que uma das validações tenha falhado. No sistema AEQ Docs na validação de qualquer
assinatura são utilizadas todas as validações descritas.
A implementação do XAdESValidator utiliza a biblioteca Apache XML Security 1.4.3 (2)
para validar as assinaturas XML. Utiliza também uma Java Keystore (cc-keystore) que contém
os certificados de toda a hierarquia de certificação do cartão de cidadão (incluindo a hierarquia
de testes), de forma a que se possa validar toda a hierarquia de certificação de um certificado.
4.2.3
XAdESSignatureTimeStamper
O módulo XAdESSignatureTimeStamper é responsável pela adição de um carimbo temporal a uma assinatura XAdES já existente. Este carimbo temporal é produzido por uma TSA(1)
via HTTP. À semelhança dos outros módulos também pode ser invocado na linha de comandos
(Fig.4.5). Recebe como argumentos o ficheiro de assinatura ou de contra-assinatura ao qual
deverá adicionar o carimbo temporal.
$ j a v a XAdESSignatureTimeStamper XAdESSignatureToTimeStamp . xml
TimeStampAuthorityURL
Figura 4.5: Invocação do XAdESSignatureTimeStamper através da linha de comandos
O resultado da execução é a adição de um carimbo temporal à assinatura XAdES-BES
transformando-a numa assinatura do tipo XAdES-T (Fig.4.6).
Este carimbo temporal é
4.2. AEQ DOCS
39
produzido sobre o digest SHA-1 do elemento <ds:SignatureValue> que é enviado para a TSA. O
Time Stamp Token obtido na resposta da TSA (no formato ASN.1 DER-encoded ) é codificado
em Base64 e é guardado no elemento <EncapsulatedTimeStamp>.
<U n s i g n e d P r o p e r t i e s >
<U n s i g n e d S i g n a t u r e P r o p e r t i e s >
<SignatureTimeStamp>
<EncapsulatedTimeStamp>MIIDRgYJK . . .
5 SVUlgZk=</EncapsulatedTimeStamp>
</SignatureTimeStamp>
</ U n s i g n e d S i g n a t u r e P r o p e r t i e s >
</ U n s i g n e d P r o p e r t i e s >
Figura 4.6: Extensão XAdES-T gerada pelo XAdESSignatureTimeStamper
A execução do XAdESSignatureTimeStamper devolve como resultado SUCCESS no caso
em que obteu e incluiu correctamente um carimbo temporal na assinatura e devolve ERROR
caso contrário.
Este processo de time stamping pode ser realizado o número de vezes que for necessário, o
que resulta na adição de sucessivos carimbos temporais. Desta forma a assinatura contém uma
prova não repudiável de que a assinatura foi realizada antes da data atestada pela TSA.
4.2.4
XAdESCounterSigner
O módulo XAdESCounterSigner é responsável por realizar a contra-assinatura da organização sobre a assinatura qualificada do indivı́duo. Este módulo pode ser invocado na linha de
comandos, e recebe como argumentos a assinatura XML, o ficheiro PKCS#12 (38) que contém
o par de chaves e o certificado da organização correspondente, a password para aceder ao
ficheiro PKCS#12 e a password para aceder à chave privada (Fig.4.7). O resultado da execução
do XAdESCounterSigner é a produção de uma assinatura XML com o nome do ficheiro da
assinatura mas com a extensão .xml.cssig, que contém o documento, a assinatura XAdES e a
contra-assinatura da organização.
$ j a v a XAdESCounterSigner XAdESSignatureToCounterSign . xml p k c s 1 2 F i l e
pkcs12Password pkcs12KeyPassword
Figura 4.7: Invocação do XAdESCounterSigner através da linha de comandos
40
CHAPTER 4. IMPLEMENTAÇÃO
A contra-assinatura produzida (Fig.4.8) é uma XMLDsig, e inclui uma referência <Reference
URI=”#idSignatureValue”> para o elemento <ds:SignatureValue Id=”idSignatureValue”> da
assinatura inicial, assinando-o. Inclui também o elemento <X509Data> onde é incluı́do o certificado utilizado para realizar a contra-assinatura.
A execução do XAdESCounterSigner devolve como resultado SUCCESS no caso em que
realizou correctamente a contra-assinatura e devolve ERROR caso contrário.
<U n s i g n e d P r o p e r t i e s >
<U n s i g n e d S i g n a t u r e P r o p e r t i e s >
<C o u n t e r S i g n a t u r e >
<S i g n a t u r e xmlns=”h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g#”>
<S i g n e d I n f o >
<C a n o n i c a l i z a t i o n M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g /TR/ 2 0 0 1 /REC−xml−c14n −20010315#
WithComments”/>
<S i g n a t u r e M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 0 / 0 9 / x m l d s i g#r s a −s h a 1 ”/>
<R e f e r e n c e URI=”#i d S i g n a t u r e V a l u e ”>
<D i g e s t M e t h o d A l g o r i t h m=”h t t p : / /www. w3 . o r g / 2 0 0 1 / 0 4 / xmlenc#s h a 2 5 6 ”/>
<D i g e s t V a l u e >6JOM/ 1 9 8 8 zLHl4HnxLhoB+OVhQqMpcI5fCZWBJg/HnY=</D i g e s t V a l u e >
</ R e f e r e n c e >
</ S i g n e d I n f o >
<S i g n a t u r e V a l u e >VGzZ4p
. . . Aaw==</S i g n a t u r e V a l u e >
<KeyInf o>
<KeyValue>
<RSAKeyValue>
<Modulus>y6S4
. . . W/Q==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
<X509Data>
<X509SubjectName>CN=N o t a r i o , OU=A s s i n a t u r a
Electronica
Q u a l i f i c a d a , O=I n s t i t u t o
S u p e r i o r T e c n i c o , L=L i s b o n , ST=L i s b o n , C=PT</X509SubjectName>
</X509Data>
<X509Data>
<X 5 0 9 C e r t i f i c a t e >MIIEpzCCA4+ . . .
9PmlpmA==</X 5 0 9 C e r t i f i c a t e >
</X509Data>
</KeyI nfo>
</ S i g n a t u r e >
</C o u n t e r S i g n a t u r e >
</ U n s i g n e d S i g n a t u r e P r o p e r t i e s >
</ U n s i g n e d P r o p e r t i e s >
Figura 4.8: Invocação do XAdESCounterSigner através da linha de comandos
4.2.5
Assinatura Electrónica Qualificada - Java Applet
A java applet Assinatura Electrónica Qualificada, como o seu nome indica, permite realizar
assinaturas electrónicas qualificadas no formato XAdES, utilizando o cartão de cidadão. Utiliza
4.2. AEQ DOCS
41
o módulo XAdESSigner e o módulo XAdESSignatureTimeStamper de forma a produzir as
assinaturas. A inclusão de carimbos temporais é opcional, de modo a que as assinaturas possam
ser realizadas offline. As assinaturas produzidas são portanto do tipo XAdES-BES ou do tipo
XAdES-T se tiverem pelo menos um carimbo temporal.
Figura 4.9: Assinatura Electrónica Qualificada - Java Applet
Esta aplicação permite a realização de uma assinatura que inclua as propriedades qualificantes. Para a utilizar bastará inserir o cartão de cidadão no leitor, escolher o documento a
assinar, escolher o nome que se deseja atribuir ao documento dentro da assinatura, elaborar
uma pequena descrição do documento, digitar o cargo/qualidade em que desejamos assinar o
documento, digitar o nosso compromisso relativamente ao documento assinado e escolher assinar. De seguida é-nos pedido o PIN de Assinatura do cartão de cidadão. Após a sua inserção
temos uma assinatura digital qualificada no formato XAdES, com o mesmo nome do ficheiro do
documento assinado, mas com a extensão .xml.sig.
42
CHAPTER 4. IMPLEMENTAÇÃO
4.2.6
Web Application
A Web Application AEQ Docs integra todos os módulos descritos, implementando a arquitectura proposta no capı́tulo anterior. Foi implementada utlizando HTML/CSS na camada de
apresentação e PHP na camada lógica, utlizando uma base de dados MySQL de forma a garantir
a persistência das assinaturas do serviço de notariado.
Esta aplicação permite a realização de assinaturas electrónicas qualificadas na secção
Assinatura (Fig.4.10), onde é utilizada a applet Assinatura Electrónica Qualificada para realizar
a assinatura de documentos.
Figura 4.10: AEQ Docs - Assinatura
4.2. AEQ DOCS
43
Na secção Validador (Fig.4.11) é possı́vel realizar a validação das assinaturas produzidas,
isto é, após o envio da assinatura é executado do lado do servidor o XAdESValidator validando
ou não a assinatura submetida. Pode adicionalmente efectuar-se o download do documento
contido na assinatura, de modo a que se possa verificar o conteúdo do documento assinado.
Figura 4.11: AEQ Docs - Validador
O serviço de notariado encontra-se disponı́vel na secção Notariado (Fig.4.12). Este serviço
permite a submissão de assinaturas para o serviço de notariado da organização.
Após a
submissão de uma assinatura é possı́vel atestar as propriedades qualificantes e realizar o serviço
de notariado da organização, produzindo uma contra-assinatura. Adicionalmente este serviço
permite a adição de carimbos temporais às contra-assinaturas já realizadas (Fig.4.13).
44
CHAPTER 4. IMPLEMENTAÇÃO
Figura 4.12: AEQ Docs - Notariado antes da realização da contra-assinatura
Figura 4.13: AEQ Docs - Notariado após a realização da contra-assinatura
5
Discussão
The ideal engineer is a composite ... He is not a scientist, he is not a mathematician, he
is not a sociologist or a writer; but he may use the knowledge and techniques of any or all
of these disciplines in solving engineering problems.
– N. W. Dougherty
5.1
CAdES, PAdES ou XAdES?
O formato de assinatura PAdES apenas permite assinar documentos no formato PDF, o
que vai contra o objectivo de se poder realizar uma assinatura electrónica qualificada sobre um
qualquer conjunto de bytes. Apesar dos documentos do tipo PDF proliferarem no dia a dia das
organizações, este não será o único tipo de documentos que será desejável assinar. Além do facto
de ser um formato de assinatura bastante recente e ainda pouco suportado.
A utilização do formato das assinaturas XAdES, ao invés do formato CAdES deveu-se não
só ao facto da implementação ter um esforço bastante mais elevado, mas também ao facto das
assinaturas CAdES terem uma extensibilidade e modificabilidade bastante reduzida. Se surgir
a necessidade de adicionar novas propriedades a uma assinatura XAdES, uma assinatura neste
formato pode ser facilmente modificada, migrando o seu perfil de assinatura por exemplo de
XAdES-BES para XAdES-A. Em CAdES apesar de também ser possı́vel alterar as propriedades
não assinadas modificando o perfil de assinatura, esta seria bastante mais complexa. Além disso
as assinaturas no formato CAdES não são human readable.
As assinaturas XAdES continuam a ser assinaturas XMLDsig, podendo ser validadas em
qualquer validador compatı́vel com XMLDsig, não sendo necessário um suporte especı́fico para
as extensões da norma XAdES.
46
CHAPTER 5. DISCUSSÃO
5.2
Implementação
Na implementação do protótipo descrito no capı́tulo anterior, não foi utilizada qualquer
biblioteca Java de XAdES , devido ao facto das bibiliotecas open source existentes estarem
num estado de desenvolvimento prematuro, estando incompletas/incorrectas, ou estando orientadas para diferentes requisitos de assinatura utilizando polı́ticas de assinatura especı́ficas.
Uma análise das bibliotecas XAdES existentes pode ser encontrada em (24), o panorama actual é o mesmo. No entanto existem boas bibliotecas XAdES proprietárias, mas são comerciais e como tal têm custos de licenciamento associados. De forma a evitar a utilização
de bibliotecas proprietárias, foi implementado um sub-set da especificação XAdES de forma
a satisfazer os requisitos da assinatura que se desejou produzir. Por exemplo, o elemento
<SignedDataObjectProperties> apesar de opcional foi implementado de forma a incluir uma
descrição do conteúdo do ficheiro assinado e o seu mime type, de forma a facilitar a extracção
do documento do ficheiro de assinatura.
No protótipo implementado, o sistema de arquivamento encontra-se integrado com o sistema
de notariado. Numa utilização prática isto poderá não ser desejável, pelo que deverão ser
devidamente separados. Este sistema de arquivamento, poderá realizar periodicamente (i.e.
uma ou duas vezes por ano) a adição de carimbos temporais às assinaturas já realizadas, ou
uma contra-assinatura de forma a proteger a validade da assinatura a longo prazo. Deverá
também estender o perfil das assinaturas realizadas, idealmente até ao perfil XAdES-A.
5.3
Segurança
As assinaturas em si realizadas pelo sistema implementado são RSA-SHA1, isto é, uma
assinatura RSA sobre o resumo SHA1 do elemento <ds:SignedInfo>. Uma vez que o algoritmo
SHA1 tem falhas conhecidas (5), deveria ter sido utilizado um método de assinatura RSASHA256 ou superior, mas este método não se encontra disponı́vel no Java 6 apesar da sua
previsão de inclusão futura (41). De forma a contornar este problema poderá utilizar-se a
biblioteca Apache XML Security (2) na produção das assinaturas, que suporta este e outros
métodos de assinatura mais fortes. Todos os restantes digests das assinaturas são realizados
com SHA256 podendo ser facilmente alterados para uma função de resumo mais forte, como
SHA512.
5.4. INTEGRAÇÃO
47
Para uma maior segurança na realização das assinaturas com o cartão de cidadão, deverá ser
utilizado um leitor de SmartCards com pinpad de forma a evitar a inserção do PIN com teclado,
uma vez que o PIN pode ser maliciosamente interceptado e utilizado para realizar assinaturas
sem o consentimento expresso do utilizador, bastando que o cartão de cidadão se encontre no
leitor.
5.4
Integração
O sistema proposto oferece uma boa facilidade de integração, podendo (com ligeiras modificações) ser facilmente integrado com repositórios digitais de documentos, com sistemas de
gestão documental, ou com outros sistemas.
O protótipo implementado não contempla autenticação nem autorização, numa utilização
prática deveria utilizar um sistema de autenticação e realizar a autorização, de forma a distinguir
quais os utilizadores que têm autorização para submeter documentos assinados no serviço de
notariado, quais os utilizadores que podem realizar o serviço de notariado etc... Adicionalmente
deverá ser mantido um registo (i.e. log) de todas as operações realizadas e o seu autor.
Idealmente, numa utilização prática deste sistema, o serviço de notariado deverá ser realizado
recorrendo também a certificados electrónicos qualificados emitidos para entidades colectivas, de
forma não só às contra-assinaturas terem o valor legal equiparado às assinaturas realizadas com
o cartão de cidadão, mas também para promover a confiança de entidades externas que venham
a ter que atestar a validade de assinaturas produzidas pela organização.
5.5
Objectivos atingidos
O protótipo do sistema implementado, AEQ Docs, atingiu todos os objectivos propostos e
satizfez os requisitos enunciados, resultando num sistema de assinatura qualificada de documentos com aplicabilidade numa organização. Os seus componentes, nomeadamente a Java applet
Assinatura Electrónica Qualificada fornece também a possibilidade de realizar assinaturas fora
de um contexto organizacional (i.e. pessoal), realizando assinaturas electrónicas qualificadas de
qualquer tipo de documento utilizando o cartão de cidadão, tendo essas assinaturas valor legal
em todos os estados membros da União Europeia.
48
CHAPTER 5. DISCUSSÃO
6
Conclusões
Good ideas are not adopted automatically. They must be driven into practice with courageous patience.
– Hyman Rickover
6.1
Conclusões
De um modo geral, esta dissertação identificou e abordou um problema actual, a gestão
de documentos assinados electronicamente no contexto organizacional e alguns dos problemas
adjacentes a este tipo de gestão documental. A análise dos problemas identificados, permitiu
conceber um sistema de assinatura electrónica de documentos, que tivesse em conta os problemas
identificados e apresentasse soluções para os mesmos. Desta forma foi possı́vel propor um sistema seguro de assinatura electrónica de documentos, cujas assinaturas garantam propriedades
fundamentais como o não repúdio, a autenticidade, a validade a longo prazo e a sua veracidade
temporal. A utilização do recente criado cartão de cidadão permitiu a utilização de certificados
digitais qualificados na produção das assinaturas, o que confere às assinaturas validade legal em
todos os Estados Membros da União Europeia.
Concluı́-se que o formato XAdES, apesar de ser ainda pouco adoptado, reúne todas as
condições necessárias à produção de assinaturas electrónicas que englobem um diversificado
leque de propriedades qualificantes. A extensibilidade do XAdES é o seu ponto forte, podendo
uma assinatura com o perfil XAdES-BES ser actualizada até ao perfil XAdES-A, uma vez que
as propriedades que mudam o perfil da assinatura são propriedades não assinadas. Isto permite
a protecção da validade das assinaturas a longo prazo, quer pela adição de sucessivos carimbos
temporais e/ou de contra-assinaturas, e simplifica o processo de validação através da inclusão
dos certificados da cadeia de certificação e das respostas CRL e OCSP, permitindo uma validação
off-line confiável.
50
CHAPTER 6. CONCLUSÕES
Apesar do RSA ser um algoritmo seguro para a realização de criptografia de chave pública,
é necessário ter especial cuidado com as funções de resumo utilizadas (e.g. SHA1) e com a
sua segurança. Isto deve-se ao facto de apenas o resumo do documento ser assinado, e não
o documento em si, o que pode levar à criação de um documento diferente mas que produza
um resumo igual. Este facto iria permitir a substituição do documento por um diferente, sem
comprometer a validade da assinatura, o que não é de todo desejável.
Concluı́-se que o sistema proposto é exequı́vel, o que foi demonstrado através da implementação do protótipo AEQ Docs, mas que para ser colocado em produção necessita de algumas
modificações, por exemplo, para contemplar a autenticação e a autorização dos seus utilizadores,
e adicionalmente manter um registo seguro de todas as acções realizadas pelo sistema e qual o
seu autor. Este sistema tenta transparecer todo o processo de produção e validação de assinaturas no formato XAdES, de forma a eliminar o conceito de black box existente no processo de
assinatura de documentos, permitindo uma melhor compreensão de todo este processo.
6.2
Trabalho Futuro
Implementação Open Source em Java de uma biblioteca XAdES, de forma a promover a
norma e de forma a contribuir para a sua maior aceitação. As bibliotecas XAdES em Java
existentes neste momento são ou proprietárias ou deficitárias como analisado em (24).
Criação de um serviço de TSA confiável ao Instituto Superior Técnico, através da utilização
de software open-source. O projecto OpenTSA (34) foi recentemente integrado no projecto
OpenSSL (33) a partir da versão 1.0, que à data de redação deste documento se encontrava na
versão 1.0.0 Beta 3. O projecto OpenTSA inclui um módulo de TimeStamp para o Apache Web
Server, de forma a que possam ser pedidos carimbos temporais através dos protocolos HTTP e
HTTPS.
Implementar e integrar no Instituto Superior Técnico um sistema de assinatura electrónica
qualificada, mediante os requisitos organizacionais existentes, de forma a resolver a necessidade
de gestão de documentos assinados electronicamente. Disponibilizar este sistema (ou parte dele)
a toda a sua comunidade, de forma a que se possam produzir assinaturas electrónicas qualificadas no formato XAdES com o cartão de cidadão, idealmente utilizando a TSA descrita no
ponto anterior de forma a garantir a temporalidade das assinaturas. Integrar este sistema com
6.2. TRABALHO FUTURO
51
repositórios digitais de documentos (e.g. DSpace (16)), produzindo assinaturas sobre documentos contidos no repositório, isto é, realizando assinaturas por referência. Integrar este sistema
com outros, como é o caso do LDAP, de forma a obter os cargos do assinante na organização,
ou outras propriedades qualificantes necessárias.
52
CHAPTER 6. CONCLUSÕES
Bibliography
[1] Adams, et al. , RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol
(TSP), 2001.
[2] Apache XML Security [On-Line] http://santuario.apache.org/.
[3] Berners-Lee, et al. , RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax, January 2005, IETF.
[4] Borenstein, N., and Freed, N., Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies, RFC 2045, November 1996.
[5] Cameron McDonald and Philip Hawkes and Josef Pieprzyk, Differential Path for SHA-1
with complexity O(252 ), 2009.
[6] Cartão de Cidadão, [Online] http://www.cartaodecidadao.pt.
[7] Debian Security Advisory 1571, [On-Line] http://www.debian.org/security/2008/dsa-1571.
[8] Declaração de Práticas de Certificação da ECEE (Entidade Certificadora Comum do Estado), [Online] http://www.scee.gov.pt/ECEE/pt/pcerti/.
[9] Decreto-Lei n. 116-A/2006, 16 de Junho, Cria o Sistema de Certificação Electrónica do
Estado, Diário da República - I Série-A.
[10] Decreto-Lei n. 165/2004, 6 de Julho, Compatibilização do Decreto-Lei n. 62/2003 com o
quadro legal comunitário para as assinaturas electrónicas, Diário da República - I SérieA.
[11] Decreto-Lei n. 290-D/99, 2 de Agosto, Regime jurı́dico dos documentos electrónicos e da
assinatura electrónica, Diário da República - I Série-A.
[12] Decreto-Lei n. 62/2003, 3 de Abril, Compatibilização do Decreto-Lei n. 290-/99 com a
Directiva 1999/93/CE, Diário da República - I Série-A.
[13] Dieter Gollmann, Computer Security 2nd ed., pp. 224-229, John Wiley & Sons(2006).
[14] DigitalSign - Certificadora Digital, Lda. [Online] http://www.digitalsign.pt.
53
54
CHAPTER 6. CONCLUSÕES
[15] Directive 1999/93/CE of the European Parliament and the Council of 13 December 1999
on a Community Framework for Electronic Signatures.
[16] DSpace [On-Line] http://www.dspace.org.
[17] Ellison, et al. , RFC 2693 - SPKI Certificate Theory, September 1999, IETF.
[18] ETSI TR 102 038 v1.1.1 (2002-04), TC Security - Electronic Signatures and Infrastructures
(ESI); XML format for signature policies.
[19] ETSI TS 101 733 V1.7.4 (2008-07), Electronic Signatures and Infrastructures (ESI); CMS
Advanced Electronic Signatures (CAdES).
[20] ETSI TS 101 903 V1.3.2 (2006-03), XML Advanced Electronic Signatures (XAdES).
[21] ETSI TS 102 778-1 V1.1.1 (2009-07), Electronic Signatures and Infrastructures (ESI) PDF
Advanced Electronic Signature Profiles (PAdES).
[22] Extensible Markup Language (XML) 1.0 (Fourth Edition) W3C Recommendation 16 August 2006, edited in place 29 September 2006.
[23] Gabinete Nacional de Segurança (GNS) [Online] http://www.gns.gov.pt.
[24] Guedes, Nuno - Implementação de Solução de Assinaturas Digitais - Dissertação para
obtenção do Grau de Mestre em Engenharia Informática e de Computadores, Abril
2008.
[25] Housley, et. al. , RFC 3280 - Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile, April 2002, IETF.
[26] Housley, R. RFC3852 - Cryptographic Message Syntax (CMS).
[27] IEEE 1363-2000: Standard Specifications For Public Key Cryptography.
[28] ITU-X Recommendation X.509 : Information technology - Open Systems Interconnection
- The Directory: Public-key and attribute certificate frameworks.
[29] Java Platform, Standard Edition 6 [On-Line] http://java.sun.com/javase/6/.
[30] Lei n. 7/2007, 5 de Fevereiro, Cria o cartão de cidadão e rege a sua emissão e utilização,
Diário da República n.25 - Série I.
[31] MULTICERT
-
Serviços
https://www.multicert.com.
de
Certificação
Electrónica,
S.A.
[Online]
6.2. TRABALHO FUTURO
55
[32] Myers, et al. , RFC 2560 - X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP, June 1999, IETF.
[33] OpenSSL Project [On-Line] http://www.openssl.org/.
[34] OpenTSA [On-Line] http://www.opentsa.org/.
[35] Polı́tica de Certificados da SCEE (Sistema de Certificação Electrónica do Estado), [Online]
http://www.scee.gov.pt/ECEE/pt/pcerti/.
[36] Ribeiro, Carlos - Slides da disciplina Algoritmos e Aplicações de Segurança - Gestão de
Chaves Secretas.
[37] RSA Laboratories, PKCS #11 v2.30: Cryptographic Token Interface Standard, April 2009
.
[38] RSA Laboratories, PKCS #12 v1.0: Personal Information Exchange Syntax, June 1999 .
[39] S. Josefsson, RFC 4648 - The Base16, Base32, and Base64 Data Encodings, October 2006,
IETF.
[40] Sistema de Certificação Electrónica do Estado, [Online] http://www.scee.gov.pt.
[41] Using
stronger
XML
Signature
Algorithms
in
JDK
7
[On-Line]
http://blogs.sun.com/mullan/entry/using stronger xml signature algorithms.
[42] Xiaoyun Wang and Hongbo Yu, How to Break MD5 and Other Hash Functions, Shandong
University 2005.
[43] XML Signature Syntax and Processing (Second Edition), W3C Recommendation, 10 June
2008.