Universidade de Aveiro Departamento de Electrnica, Telecomunicaes e Informtica 2009

Marco Alexandre de Oliveira Matias

RTS-sec: Privacidade e Segurana em Redes Telemticas para a Sade

o jripresidente Prof. Dr. Jos Lus Guimares Oliveiraprofessor associado da Universidade de Aveiro

Prof. Dr. Carlos Nuno da Cruz Ribeiroprofessor auxiliar do Instituto Superior Tcnico da Universidade Tcnica de Lisboa

Prof. Dr. Andr Ventura Marnoto Zqueteprofessor auxiliar da Universidade de Aveiro

Prof. Dr. Joo Paulo Trigueiros da Silva Cunhaprofessor associado da Universidade de Aveiro

agradecimentos

Aos orientadores, especialmente ao professor Andr Zquete, pelo apoio, fornecimento de material para trabalhar com o Carto de Cidado, e documentos fornecidos. Ao Hlder Gomes, que fez o trabalho principal sobre a autenticao na RTS. Aos meus pais, que sempre me apoiaram. Aos meus amigos, que me incentivaram e debateram comigo algumas ideias. Muito Obrigado!

palavras-chave

Segurana informtica, privacidade de dados, redes telemticas de servios, sistemas de informao na Sade.

resumo

Este trabalho apresenta o estudo de uma soluo que permite a autenticao de profissionais na Rede Telemtica da Sade (RTS) com o Carto de Cidado. So definidas ligeiras alteraes numa arquitectura anteriormente definida de forma a adaptar o mecanismo de autenticao ao uso do Carto de Cidado. Uma Infra-Estrutura de Chave Pblica (PKI) serve de base para a soluo apresentada. descrito como se gera um certificado de chave pblica que aproveita o par de chaves de autenticao existente no Carto de Cidado.

keywords

Informatic security, data privacy, telematic service networks, health information systems.

abstract

This work presents a study of a solution which allows the authentication of health professionals to access a Telematic Health Information System (RTS Rede Telemtica de Sade) using the Citizens Card (Carto de Cidado). Some changes in a previous defined architecture are defined, in a way to adapt the authentication mechanism so it can use the Citizens Card. A Public Key Infrastructure provides the basis for the presented solution. Its described how to generate a public key certificate that can reuse the authentication key pair existing in the Citizens Card.

Indice1 Introducao 1.1 1.2 1.3 1.4 2 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposta de Solucao . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 2 4 5 5 6 7 7 7 8 9 13 14 16 17 17 18

Contexto 2.1 Rede Telem tica de Sa de . . . . . . . . . . . . . . . . . . . . . a u 2.1.1 2.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . .

Conceitos B sicos . . . . . . . . . . . . . . . . . . . . . . . . . . a 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 Assinaturas Digitais . . . . . . . . . . . . . . . . . . . . Criptograa de Chave P blica . . . . . . . . . . . . . . . u Infraestrutura de Chave P blica e Certicados Digitais . . u Entidades Certicadoras . . . . . . . . . . . . . . . . . . Cadeias de Certicacao e Vericacao . . . . . . . . . . . Chaveiros Protegidos e Ficheiros Certicados . . . . . . . Revogacao de Certicados . . . . . . . . . . . . . . . . . Autenticacao M tua (Cliente e Servidor) . . . . . . . . . u

2.3 2.4

PKCS#11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cart o de Cidad o . . . . . . . . . . . . . . . . . . . . . . . . . . a a i

INDICE 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.5 3 Como e Constituido o Cart o de Cidad o . . . . . . . . . a a Autenticacao Simples com o Cart o de Cidad o . . . . . . a a Middleware do Cart o de Cidad o . . . . . . . . . . . . . a a API eID Lib . . . . . . . . . . . . . . . . . . . . . . . . . Normas dos Leitores de Cart es . . . . . . . . . . . . . . o Cart o de Cidad o e Smart Card Gen rico . . . . . . . . . a a e 18 20 22 25 25 26 27 29 29 31 31 32 32 40 43 46 47 48 48 49 49 49 50 52

O Projecto OpenSSL . . . . . . . . . . . . . . . . . . . . . . . .

Trabalhos Relacionados 3.1 3.2 3.3 Alemanha - Electronic Health Card (eHC) e Health Professional Card (HPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uso de Smart Cards em Redes Telem ticas de Sa de . . . . . . . a u Arquitectura Denida pelo H. Gomes . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . Descricao da Arquitectura . . . . . . . . . . . . . . . . . Adaptacao da Arquitectura de Autenticacao para o Uso do Cart o de Cidad o . . . . . . . . . . . . . . . . . . . . . a a

4

Estudo da Solucao com C digo Activo o 4.1 Modo de Funcionamento das Credenciais . . . . . . . . . . . . . 4.1.1 4.1.2 4.1.3 4.1.4 4.2 Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . Ligacoes (Bindings) . . . . . . . . . . . . . . . . . . . . Pers . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAML e a RTS . . . . . . . . . . . . . . . . . . . . . . .

Tecnologias Abordadas . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . Java Applets . . . . . . . . . . . . . . . . . . . . . . . . ActiveX . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

INDICE 4.2.4 4.3 5 Macromedia Flash . . . . . . . . . . . . . . . . . . . . . 52 52 53 53 54 55 56 57 58 65 65 66 66 67 67 68 68 68 69 69 71 73 73 75

Avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Estudo da Solucao sem C digo Activo o 5.1 Wrapping do Cart o de Cidad o . . . . . . . . . . . . . . . . . . a a 5.1.1 5.1.2 5.1.3 5.1.4 5.2 Modo de Funcionamento . . . . . . . . . . . . . . . . . . Descricao dos Componentes Utilizados . . . . . . . . . . O M dulo PKCS#11 . . . . . . . . . . . . . . . . . . . . o Interaccao entre o browser Firefox e a PKCS#11 . . . . .

Exploracao de Tokens via PKCS#11 com o Firefox . . . . . . . .

6

Arquitectura Proposta 6.1 6.2 Apresentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . Certicados Digitais . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.3 6.4 Entidades com Certicados . . . . . . . . . . . . . . . . . Tipos de Certicados . . . . . . . . . . . . . . . . . . . . Formato dos Certicados . . . . . . . . . . . . . . . . . . Gest o de Certicados . . . . . . . . . . . . . . . . . . . a Emiss o/Renovacao . . . . . . . . . . . . . . . . . . . . a Armazenamento . . . . . . . . . . . . . . . . . . . . . . Cadeias de Certicacao . . . . . . . . . . . . . . . . . . .

Geracao de um Pedido de Certicado . . . . . . . . . . . . . . . Processo de Autenticacao . . . . . . . . . . . . . . . . . . . . . .

7

Avaliacao 7.1 Arquitectura Avaliada . . . . . . . . . . . . . . . . . . . . . . . .

8

Conclus es o

iii

Lista de Figuras2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4.1 4.2 4.3 Arquitectura da RTS [1] . . . . . . . . . . . . . . . . . . . . . . . SSL - Autenticacao M tua . . . . . . . . . . . . . . . . . . . . . u Cart o de Cidad o - Frente . . . . . . . . . . . . . . . . . . . . . a a Cart o de Cidad o - Verso . . . . . . . . . . . . . . . . . . . . . a a Informacao e Aplicacoes Residentes no Chip . . . . . . . . . . . Autenticacao Gen rica com o Cart o de Cidad o . . . . . . . . . e a a Interaccao entre aplicacoes e o m dulo PKCS#11 . . . . . . . . . o Cart o de Sa de do Prossional (HPC) . . . . . . . . . . . . . . . a u Cart o de Sa de do Utente (eHC) . . . . . . . . . . . . . . . . . a u Vis o Geral da Arquitectura da RTS . . . . . . . . . . . . . . . . a Modelo de Comunicacao e Autenticacao . . . . . . . . . . . . . . Modelo de Conanca Entre a RTS e as IS . . . . . . . . . . . . . Arquitectura Interna das EC . . . . . . . . . . . . . . . . . . . . Construcao de Cadeia de Conanca . . . . . . . . . . . . . . . . Comunicacao Segura Entre o Prossional e a RTS . . . . . . . . . Solucao com C digo Activo . . . . . . . . . . . . . . . . . . . . o Relacao entre a RTS e uma IS . . . . . . . . . . . . . . . . . . . Modelo de autenticacao SAML . . . . . . . . . . . . . . . . . . . v 6 12 19 19 20 21 22 30 31 33 35 37 38 39 40 44 45 47

LISTA DE FIGURAS 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 6.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Interaccao Entre o Browser e o Cart o de Cidad o usando o Wrapper 55 a a Caixa de di logo de insercao de PIN . . . . . . . . . . . . . . . . a Adicionar um M dulo - Parte 1 . . . . . . . . . . . . . . . . . . . o Adicionar um M dulo - Parte 2 . . . . . . . . . . . . . . . . . . . o Adicionar um M dulo - Parte 3 . . . . . . . . . . . . . . . . . . . o Gestor de Certicados do Firefox . . . . . . . . . . . . . . . . . . Seleccao de Certicado . . . . . . . . . . . . . . . . . . . . . . . Cadeias de Certicacao: IS - RTS . . . . . . . . . . . . . . . . . 57 59 59 60 62 63 70

vi

Lista de Tabelas2.1 5.1 5.2 Objectos Existentes no Cart o de Cidad o . . . . . . . . . . . . . a a Alguns Atributos da Cryptoki . . . . . . . . . . . . . . . . . . . . Atributos de um Certicado . . . . . . . . . . . . . . . . . . . . . 25 58 61

vii

Captulo 1 Introducao A Rede Telem tica da Sa de (RTS)1 implementa uma infra-estrutura de TIC para a u agilizar a comunicacao clnica na regi o de Aveiro. Desenvolvida no ambito do a projecto RTS hom nimo, a rede coloca novas possibilidades de acesso integrado o a Sistemas de Informacao existentes e de comunicacao electr nica entre pros o sionais de sa de. u A RTS lanca bases para quebrar as barreiras de isolamento entre as fontes de conhecimento clnico, disponveis na regi o e pertinentes para a continuidade de a cuidados. Utilizando a RTS, por exemplo, um m dico pode, atrav s de um Portal e e Regional de Sa de, aceder do seu posto de trabalho (e.g.: Centro de Sa de em u u ` Sever do Vouga) a informacao clnica do seu doente gerada em outras instituicoes (e.g.: consulta no Hospital Infante D. Pedro, Aveiro).

1.1

Motivacao

Anteriormente foi proposta pelo H. Gomes [2] uma arquitectura de autenticacao para a RTS com recurso ao uso de smart cards. Essa arquitectura resolve o problema de autenticacao, mas acarreta alguns custos para as Instituicoes de Sa de, em u cart es para os seus Prossionais, e mesmo para os Prossionais, pois e mais um o cart o que t m que trazer consigo (n o faz muito sentido transportar dois cart es a e a o capazes de efectuar as mesmas funcionalidades quando apenas um e o suciente). Esses custos podem ser minimizados efectuando um aproveitamento dos re1 http://www.rtsaude.pt/

1

1. INTRODUCAO cursos existentes no Cart o de Cidad o 2 , sendo isso a base da motivacao para a a este estudo. A substituicao de smart cards pelo Cart o de Cidad o traz algumas vantagens a a e desvantagens. Uma vantagem e que, por ser obrigat rio, torna-se mais barato o para uma organizacao aproveitar alguns recursos nele existentes. Al m disso, e outra vantagem do Cart o de Cidad o e a sua multifuncionalidade, permitindo a a que o seu uso possa ter v rios ns, tudo no mesmo cart o. a a Torna-se inc modo transportar varios documentos, cada um com a sua funo cionalidade. Da ter surgido a ideia de adicionar a funcionalidade de autenticacao na RTS ao Cart o de Cidad o. A principal desvantagem e que a introducao a a do Cart o de Cidad o na arquitectura existente n o e trivial, e implica algumas a a a alteracoes que v o ser mencionadas ao longo do texto. a Aproveitando o modelo de PKI denido anteriormente pelo H. Gomes, s o a estudadas diversas solucoes para a autenticacao na RTS com o uso do Cart o do a Cidad o. a

1.2

Problema

A criacao de uma infraestrutura que permite a autenticacao em sistemas telem ticos a biom dicos foi anteriormente abordada pelo H. Gomes [2]. O novo problema que e surge e a adaptacao dessa infraestrutura para que possa ser usada com o Cart o de a ` Cidad o, em vez de smart cards comuns, cando restrita as limitacoes impostas a pelo Cart o de Cidad o. a a A arquitectura do H. Gomes assume que um unico smart card e o suciente para autenticar o prossional perante a sua instituicao e a RTS. Isso n o e possvel a com o Cart o de Cidad o porque o mesmo n o permite que lhe sejam introduzidas a a a ` novas credenciais. Portanto a arquitectura do H. Gomes, a partida, n o permite a a utilizacao directa, simples, do Cart o de Cidad o. a a

1.3

Objectivos

O objectivo deste trabalho consistiu em estudar formas alternativas de adaptar o Cart o de Cidad o a arquitectura denida pelo H. Gomes. a a `2 http://www.cartaodecidadao.pt/

2

1. INTRODUCAO Apesar do Cart o de Cidad o permitir a autenticacao de um determinado a a cidad o, ele n o possui nenhuma funcionalidade nativa de denir de maneira sea a gura o cargo desempenhado por esse cidad o numa Instituicao de Sa de. a u O primeiro objectivo consistiu em efectuar uma an lise dos recursos disponveis a pelo Cart o de Cidad o e denir quais poderiam ser aproveitados. a a O segundo objectivo consistiu na denicao de um mecanismo para que a autenticacao pudesse ser efectuada com base no cargo desempenhado por um de terminado Prossional numa Instituicao de Sa de. u Para isso e necess rio denir credenciais com a informacao sobre o cargo do a Prossional e a Instituicao de Sa de a que pertence. Essas credenciais devem u estar relacionadas apenas com o cart o do Prossional que tem permiss o para as a a usar e serem inv lidas com qualquer outro. Isto n o deve impedir que um cart o a a a tenha v rias credenciais associadas a ele. Se for possvel, e desejada a inclus o a a das credenciais no cart o ao qual est o relacionadas. a a O terceiro objectivo seria a utilizacao das credenciais denidas nos objectivos anteriores por um browser. Uma alternativa consistiu em procurar solucoes que usassem c digo activo que o corre no browser, manipulando directamente o Cart o de Cidad o e as credenciais a a a ele associadas. A outra alternativa consistiu numa solucao que se serve do comportamento nativo do browser face ao protocolo SSL e que manipula o Cart o de Cidad o via a a PKCS#11. Por enquanto a autenticacao apenas funciona com o browser Firefox, que usa a interface PKCS#11. O Internet Explorer n o usa directamente a interface a PKCS#11, usa a interface Crypto API/CSP [3]. Apenas foi explorado o uso do browser Firefox, por ser um browser suportado por v rios sistemas operativos, permitindo aos prossionais que efectuem o a processo de autenticacao na RTS quer usem ambiente Windows ou Linux. Outra raz o pela qual o teste foi efectuado com este browser e a sua funcionalidade de a adicionar m dulos, podendo ser escolhido o m dulo do wrapper sempre que se o o quer efectuar um teste com um m dulo diferente. O Internet Explorer n o poso a sui essa opcao, no entanto existe a possibilidade de adicionar o wrapper como biblioteca PKCS#11 usada pelo CSP, mas essa opcao n o chegou a ser explorada. a O wrapper foi implementado conforme os requisitos do browser Firefox, e a sua adaptacao ao Internet Explorer ainda e uma area por explorar, mas que n o deve trazer diculdades. Neste documento s o feitas v rias refer ncias ao a a a e 3

1. INTRODUCAO browser, que em certos casos devem ser entendidas como browser Firefox. Assim basta introduzir o Cart o de Cidad o num leitor e aceder normalmente ao a a portal da RTS com o browser Firefox para que seja feita a autenticacao.

1.4

Proposta de Solucao

Neste trabalho s o estudadas algumas solucoes possveis. Uma solucao implica a c digo activo no browser usando uma applet Java que trata da vericacao e validacao o da associacao entre as credenciais de um determinado Prossional e o Cart o de a Cidad o pertencente a ele. Outra funcao da applet e o estabelecimento da ligacao a entre a m quina cliente usada pelo Prossional e o servidor da RTS. A outra a solucao tem o mesmo objectivo mas usa apenas as funcionalidades nativas do browser servindo-se da biblioteca PKCS#11 fornecida com o Cart o de Cidad o, a a com algumas funcionalidades adicionadas. Basicamente, consiste no uso de um wrapper para biblioteca PKCS#11. A solucao escolhida foi a mais promissora, que n o implica c digo activo, ape a o nas e preciso instalar um m dulo, al m do middleware do Cart o do Cidad o. Esse o e a a m dulo e designado por wrapper, que e carregado pelo browser permitindo que o seja importado outro certicado al m dos que v m no cart o, atrav s da interface e e a e criptogr ca PKCS#11 [4] possibilitando uma ligacao segura entre o prossional a e o servidor da RTS. Trata-se da solucao mais simples e f cil de implementar do que uma solucao a de c digo activo, pois n o requer c digo activo nem do lado do cliente nem do o a o lado do servidor. Traz menos carga de processamento aos servidores, que n o a necessitam de correr c digo extra, e a integracao com o modelo denido pelo H. o Gomes e quase directa, porque as credenciais j est o no formato de um certia a cado X.509 e os m todos para extrair as credenciais do certicado s o os mesmos. e a O wrapper foi implementado de raiz, aproveitando as funcionalidades da pteidlib.dll, que permite fazer o acesso ao bloco de notas do Cart o de Cidad o, a a aproveitando tamb m funcionalidades do m dulo da PKCS#11 fornecido no mide o dleware do Cart o de Cidad o e algumas funcoes da biblioteca de funcoes do a a OpenSSL que permitem manipular estruturas de dados de certicados X.509v3, facilitando a sua convers o para os modelos de estruturas pedidos pela norma a PKCS#11. O m todo de geracao de certicados X.509v3 foi implementado sobre o c digo e o do OpenSSL, adicionando a opcao de criacao de certicados para o Cart o de a Cidad o. a 4

Captulo 2 Contexto Este captulo descreve o que e a Rede Telem tica de Sa de. Tamb m e feito um a u e apanhado de algumas nocoes b sicas de termos que v o ser referidos em captulos a a seguintes e um resumo da arquitectura existente. Al m disso e feita uma descricao e do Cart o de Cidad o, e das APIs utilizadas. a a

2.1

Rede Telem tica de Saude a

A RTS (Rede Telem tica de Sa de) [1] e um projecto desenvolvido pela Unia u versidade de Aveiro com o objectivo de permitir a consulta de um conjunto de informacoes clnicas fornecidas por um grupo de Instituicoes de Sa de aderentes. u Cada instituicao usa o seu pr prio sistema para produzir dados clnicos, que po o dem ser procurados e apresentados de v rias maneiras pela RTS. O seu objectivo a substituir os sistemas existentes, mas sim fornecer uma vista global dos n o e a dados clnicos de um paciente independentemente da Instituicao de Sa de que u guarda os seus dados. A RTS fornece dois tipos de portais para aceder a registos electr nicos. S o o a eles o Portal do Prossional e o Portal do Utente. O Portal do Prossional consiste num servidor Web acedido atrav s da RIS (Rede Inform tica de Sa de), que e uma e a u rede privada a nvel nacional que faz a ligacao entre as v rias Instituicoes de Sa de a u inclusive as que fazem parte da RTS. ` Os prossionais t m assim acesso a informacao clinica fornecida pela RTS e ` usando um browser Web de um computador ligado a RIS. O Portal do Utente tem o objectivo de permitir aos utentes um meio de comunicacao entre eles e o seu 5

2. CONTEXTO

Figura 2.1: Arquitectura da RTS [1]

m dico de famlia e de gerir problemas de sa de como por exemplo a renovacao e u de receitas ou marcacao de consultas [5] [6].

2.1.1

Arquitectura

A arquitectura da RTS e apresentada na Figura 2.1, onde se podem ver Instituicoes de Sa de (IS) com os respectivos Prossionais, Utentes, outras Entidades Externas u e a base de dados da RTS. Os dados clnicos de pacientes s o produzidos e armazenados nas Instituicoes a de Sa de. Para permitir a partilha e integracao da informacao m dica, cada u e Instituicao de Sa de possui um Wrapper, que faz a interligacao entre os sistemas u de informacao da Instituicao de Sa de respectiva e o RTS Data Center. u Os Portais (do Utente e do Prossional) s o aplicacoes Web, vistas pelos utia lizadores como servidores HTTP aos quais acedem atrav s de um browser coe mum. A comunicacao interna entre Portais e Wrappers e baseada em Web Ser vices, utilizando-se objectos SOAP. 6

2. CONTEXTO

2.22.2.1

Conceitos B sicos aAssinaturas Digitais

Quando acontece uma transfer ncia electr nica de documentos importantes, nore o malmente e necess rio certicar de uma maneira vel quem e na verdade o remea a tente (autor) de um determinado documento. Uma abordagem para certicar a origem de documentos e cheiros e atrav s do uso de uma assinatura digital. A e assinatura digital de documentos usa a criptograa de chave p blica como base u matem tica. a

2.2.2

Criptograa de Chave Publica

A criptograa de chave p blica e uma ci ncia matem tica usada para fornecer u e a condencialidade e autenticidade na troca de informacao atrav s do uso de algo e ritmos criptogr cos que funcionam com chaves p blicas e privadas. Estes algoa u ritmos criptogr cos s o usados para assinar documentos digitalmente, vericar a a a assinatura digital, e cifra e decifra de documentos. As chaves p blicas e privadas s o um par de chaves criptogr cas matematiu a a camente relacionadas. A cada chave p blica corresponde exactamente uma chave u privada e vice-versa. Para usar a criptograa de chave p blica e preciso ter uma u chave p blica e a respectiva chave privada. u A Chave P blica e um n mero (sequ ncia de bits), que e normalmente atribuda u u e a uma pessoa. Uma chave p blica pode ser usada para vericar assinaturas digiu tais, criadas com a correspondente chave privada, tal como cifrar documentos que s podem depois ser decifrados pelo dono da respectiva chave privada. o As chaves p blicas n o s o segredo para ningu m e normalmente est o pubu a a e a licamente disponveis. A chave p blica de uma determinada pessoa A deve ser u conhecida por qualquer outra pessoa B que queira comunicar com a pessoa A usando a criptograa de chaves p blicas. u A Chave Privada e um n mero (sequ ncia de bits), conhecido apenas pelo seu u e dono. Com a sua chave privada, uma pessoa pode assinar documentos e decifrar documentos que foram cifrados com a respectiva chave p blica. De certa maneira, u as chaves privadas assemelham-se a palavras-chave de acesso bem conhecidas, que s o um m todo muito utilizado de autenticacao na Internet. A semelhanca e a e que com a chave privada, tal como com a palavra-chave, uma pessoa pode provar 7

2. CONTEXTO a sua identidade, ou seja, autenticar-se. Adicionalmente, como com as palavraschave, as chaves privadas s o supostamente secretas para todos excepto para o seu a dono. Ao contr rio das palavras-chave de acesso, as chaves privadas n o s o assim a a a t o pequenas que possam ser decoradas, e assim o seu local de armazenamento a necessita de cuidados especiais. Se uma chave privada cai nas m os de outra a pessoa, por exemplo, se for roubada, a comunicacao baseada na criptograa de chave p blica dependendo desta chave privada deixa de ter signicado. Em casos u como este, a chave comprometida deve ser anunciada como inv lida e ser suba stituda para que seja possvel comunicar novamente de forma segura com o dono da chave. Para este efeito, a criptograa de chave p blica usa tais algoritmos criptogr cos u a que e praticamente impossvel para a matem tica actual e para os computadores a actuais encontrarem a chave privada de uma pessoa, sabendo a sua chave p blica. u De facto, a descoberta de uma chave privada correspondente a uma chave p blica u e possvel na teoria, mas o tempo e o poder computacional necess rio tornam tais a operacoes insignicativas. De um ponto de vista matem tico e impossvel assinar um documento sem a saber a sua chave privada da pessoa que a assina. Tamb m e impossvel decifrar e um documento que foi cifrado com a chave p blica de uma certa pessoa sem saber u a respectiva chave privada. A assinatura digital permite certicar a origem e a integridade de informacao transmitida electronicamente. Durante o processo de assinatura digital, e adi cionada informacao ao documento (a assinatura digital), que e calculada baseada no conte do do documento e uma chave privada. Numa fase nal, esta informacao u pode ser usada para vericar a origem do documento assinado. A assinatura digital e um n mero (sequ ncia de bits), calculado matematicau e mente quando e assinado um determinado documento (mensagem). Este n mero u depende do conte do da mensagem, do algoritmo usado para assinar e da chave u privada usada para executar a assinatura. A assinatura digital permite que o recep tor verique qual e a origem da informacao e a sua integridade.

2.2.3

Infraestrutura de Chave Publica e Certicados Digitais

A Infraestrutura de Chave P blica (PKI) fornece a arquitectura, t cnicas de organizacao, u e pr ticas, e procedimentos que suportam, atrav s de certicados digitais, a aplicacao a e da criptograa de chave p blica com a nalidade de assegurar a troca de informacao u 8

2. CONTEXTO sobre redes inseguras. Para a emiss o e controlo desses certicados digitais, a PKI a depende das Entidades Certicadoras, que permitem a conanca entre diferentes organizacoes, que participam na comunicacao segura baseada em chaves p blicas u e privadas. Os certicados digitais associam uma certa chave p blica a uma pessoa. Eles u s o emitidos por uma autoridade especial (Entidade Certicadora, Certication a Authority - CA) com precaucoes de seguranca estritas, que garante autenticidade deles. Pode-se pensar num certicado digital como um documento electr nico, o que certica que uma chave p blica pertence a uma certa pessoa. Na pr tica, para u a efeitos de assinatura digital, os mais usados s o os certicados X.509. a X.509 e uma norma generalizada para certicados digitais. Um certicado digital X.509 contem a chave p blica de uma determinada pessoa, dados priu vados sobre esta pessoa (nome, organizacao, etc.), informacao sobre a entidade certicadora que emitiu o certicado, informacao sobre o perodo de validade, informacao sobre os algoritmos criptogr cos usados e outros detalhes variados. a

2.2.4

Entidades Certicadoras

A entidade certicadora (CA) e uma instituicao intitulada para emitir certicados digitais e para os assinar com a sua pr pria chave privada. A nalidade dos cero ticados e conrmar que uma dada chave p blica pertence a uma dada pessoa, e u a nalidade das entidades certicadoras e de conrmar que um dado certicado e v lido e de conanca. Neste sentido, as entidades certicadoras s o entidades tera a ceiras e imparciais que fornecem seguranca de alto nvel na troca de informacao baseada em sistemas computacionais. Se uma entidade certicadora emitiu um certicado digital a uma determinada ` pessoa e assinou que este certicado pertence realmente a pessoa em causa, pode` se acreditar que a chave p blica do certicado pertence de facto a pessoa, caso se u cone na entidade certicadora. Dependendo do nvel de seguranca necess rio, podem-se usar certicados com a diferentes nveis de conanca. Para a emiss o de alguns tipos de certicados, s e a o necess rio o endereco de e-mail do seu dono, enquanto para a emiss o de outros e a a necess ria a presenca pessoal do seu dono, que por exemplo assina um documento a em papel num escrit rio da entidade certicadora. o Nem todas as entidades certicadoras podem ser conadas porque e possvel que pessoas de m f se apresentem como pertencentes a uma entidade certia e cadora que n o existe ou que e falsa. Para se conar numa entidade certicadora, a 9

2. CONTEXTO esta tem que ser mundialmente reconhecida e aprovada. No mundo da seguranca digital as entidades certicadoras aprovadas mundial mente dependem de polticas muito estritas e procedimentos para emitir certica dos e, gracas a isso, elas mant m a conanca dos seus clientes. Para uma maior e seguranca, estas entidades usam obrigatoriamente hardware especial que garante a impossibilidade de fugas de informacao importante, como por exemplo, as chaves privadas. Entre as mais conhecidas entidades certicadoras mundiais encontram-se as seguintes companhias: VeriSign Inc., Thawte Consulting, GlobalSign NV/SA, Baltimore Technologies, TC TrustCenter AG, Entrust Inc., etc. Todas as entidades certicadoras possuem certicados e as correspondentes chaves privadas com as quais assinam os certicados emitidos aos seus clientes. Uma entidade certicadora pode ser raiz (root CA) ou num nvel subsequente. As entidades certicadoras raiz emitem certicados para elas pr prias no incio o da sua actividade, e assinam-no com o mesmo certicado. Estes certicados s o a chamados Certicados Raiz. Os certicados Raiz de entidades certicadoras de conanca mundiais est o a disponveis publicamente nos seus sites Web e podem ser usados para a vericacao de outros certicados. As entidades certicadoras interm dias dependem de ale guma autoridade de um nvel superior para lhes emitir um certicado, que lhes permite emitir e assinar certicados para os seus clientes. E tecnicamente possvel usar qualquer um certicado para assinar qualquer outro, mas na pr tica a possibilidade de assinar certicados est altamente limia a tada. Todos os certicados cont m informacao que n o pode ser alterada sobre e a se podem ser usados para assinar outros certicados. As entidades certicadoras emitem certicados para os seus clientes, e estes certicados n o podem ser a usados para assinar outros certicados. Os certicados que podem ser usados para assinar outros certicados s o emia tidos s a entidades certicadoras com precaucoes de seguranca muito fortes. Se o um cliente obt m um certicado de uma entidade certicadora e assina outro cere ticado com ele, o novo certicado assinado ser inv lido porque e assinado por a a um certicado no qual est especicado que n o pode ser usado para assinar outa a ros certicados. Um determinado certicado pode ser assinado por outro certicado (mais frequentemente, a propriedade de alguma entidade certicadora) ou ser assinado por 10

2. CONTEXTO si pr prio. Os certicados que n o s o assinados por outro certicado, mas sim o a a por si pr prios, s o chamados certicados auto-assinados. Especialmente, os Cero a ticados Raiz das entidades certicadoras raiz s o certicados auto-assinados. a Geralmente, um certicado auto-assinado n o pode certicar a relacao entre uma a chave p blica e uma determinada pessoa porque, usando o software apropriado, u qualquer um pode criar tal certicado para o nome da pessoa escolhida ou companhia. Apesar dos certicados auto-assinados n o poderem ser con veis, eles t m a a e a sua pr pria aplicacao. Por exemplo, dentro das fronteiras da infra-estrutura de o uma companhia, onde e possvel transferir certicados sicamente de um modo seguro entre empregados individuais e os sistemas da companhia, certicados auto-assinados s o um bom substituto de certicados emitidos por entidades cera ticadoras. Numa companhia deste g nero, n o e necess rio que uma entidade certie a a cadora conrme que uma determinada chave p blica pertence a uma pessoa em u particular, porque isto pode ser garantido pelo m todo de emiss o e transfer ncia e a e de certicados. Por exemplo, quando uma nova pessoa e empregada por uma de terminada companhia, e possvel para o administrador do sistema emitir, para si pr prio, um certicado auto-assinado e fornecer esse certicado ao novo empreo gado de forma segura. Assim o administrador pode transportar o certicado para todos os sistemas da companhia, de maneira segura e desta forma garante que todos os sistemas internos t m os certicados reais de todos os empregados. e O esquema de seguranca baseado em certicados auto-assinados pode ser mel horado se a companhia estabelecesse a sua pr pria autoridade de certicacao loo cal para os seus empregados. Para essa nalidade, a companhia deve inicialmente emitir um certicado auto-assinado para depois emitir certicados assinados com esse certicado para os seus empregados. Dessa forma, o certicado inicial da companhia e um certicado Raiz de conanca e a companhia e, ela pr pria, uma o entidade certicadora raiz. Em ambos os esquemas descritos, existe a possibilidade de mau uso pelo administrador do sistema que tem os direitos para emitir certicados. Este problema pode ser resolvido reforcando os procedimentos estritos da companhia para a emiss o e controlo dos certicados, mas a seguranca completa n o pode ser a a garantida. Em comunicacoes na Internet, onde n o h maneira segura de determinar se a a um dado certicado enviado pela rede foi ou n o alterado algures pelo caminho, a 11

2. CONTEXTO

Figura 2.2: SSL - Autenticacao M tua u

os certicados auto-assinados praticamente n o s o usados, apenas certicados a a emitidos por alguma entidade certicadora aprovada. Em tais redes, o protocolo SSL e mais frequentemente usado para assegurar as comunicacoes fornecendo canais seguros, chamados t neis SSL. u O protocolo SSL (Secure Socket Layer) baseia-se em criptograa de chave p blica e certicados para permitir a comunicacao entre duas entidades e que u elas criem um canal cifrado de comunicacao entre si. Ele garante que o canal e seguro apenas se os certicados usados na comunicacao forem de conanca. Por exemplo, se um servidor Web na internet tiver que comunicar com browsers Web sobre um canal de comunicacao seguro (t nel SSL), deve possuir um certicado u emitido por uma entidade certicadora bem conhecida. De outra forma, seria possvel que um canal de comunicacoes entre os clientes e o servidor Web fosse escutado por pessoas de m f . a e A Figura 2.2 descreve o modelo de autenticacao m tua entre um cliente e um u servidor. A aplicacao do cliente verica a identidade do servidor e a aplicacao do servidor verica a identidade do cliente. Os certicados emitidos por entidades certicadoras aprovadas permitem seguranca de alto nvel na comunicacao, independentemente de serem usados numa rede corporativa privada ou na internet. No entanto, os certicados auto-assinados por vezes s o usados porque os certicados emitidos por entidades certicadoras cusa tam dinheiro e requerem esforcos em nome do seu dono para a emiss o inicial, a renovacao peri dica e abilidade no armazenamento da chave privada correspon o dente. 12

2. CONTEXTO

2.2.5

Cadeias de Certicacao e Vericacao

Quando uma entidade certicadora topo-de-nvel emite um certicado para um cliente, ela assina-o com o seu certicado Raiz. Desta maneira, e criada uma cadeia de certicacao formada por dois certicados, o certicado da entidade cer ticadora que precede o certicado do cliente. Uma cadeia de certicados e a sequ ncia de certicados na qual cada certicado est assinado pelo seu predee a cessor. No inicio da cadeia normalmente ca um certicado emitido para um cliente nal, e no nal da cadeia est o certicado Raiz de uma entidade certicadora. a Pelo meio da cadeia est o os certicados de entidades certicadoras interm dias. a e A pr tica comum e que as entidades certicadoras topo-de-nvel emitam certia cados para as entidades certicadoras interm dias e que especiquem nestes cere ticados que eles podem ser usados para emitir outros certicados. As entidades certicadoras interm dias emitem certicados para os seus clientes e ou para outras entidades certicadoras interm dias. Os direitos atribudos ao e cliente nal n o os permitem utilizar os seus certicados para assinar outros cera ticados, mas esta restricao n o se aplica a entidades certicadoras interm dias. a e Um certicado no inicio da cadeia de certicacao pode ser de conanca s se o a sua cadeia de certicacao for vericada com sucesso. Neste caso, diz-se que se trata de um certicado vericado. A vericacao de uma cadeia de certicacao ver ica se todos os certicados na sua cadeia s o assinados pelo certicado seguinte a na cadeia. Quanto ao ultimo certicado, e vericado se ele se encontra numa lista de certicados Raiz de conanca. Qualquer sistema de software que efectue vericacao de certicados mant m e uma lista de certicados Raiz de conanca, na qual cona incondicionalmente. Estes s o os certicados Raiz das entidades certicadoras mundialmente recona ` hecidas. Por exemplo, o browser Web Internet Explorer, a partida, vem com uma lista de cerca de 150 certicados Raiz de conanca, e o browser Firefox na sua instalacao inicial cont m cerca de 70 certicados de conanca. e A vericacao da cadeia de certicacao n o inclui apenas a vericacao que a cada certicado e assinado pelo seguinte e que o certicado no nal da cadeia est a na lista de certicados Raiz de conanca. Tamb m e necess rio vericar que cada e a a certicado na cadeia ainda e v lido, e que todos os certicados com excepcao do primeiro t m o direito de ser usados para assinar outros certicados. Se a e vericacao da ultima condicao fosse omissa, seria possvel para os clientes nais a emiss o de certicados a quem eles quisessem e a vericacao do certicado a emitido seria sucedida. 13

2. CONTEXTO Na vericacao de uma determinada cadeia de certicados, e vericado tamb m e se algum certicado nela foi revogado. A nalidade da combinacao de todas as vericacoes descritas e vericar se um certicado e de conanca. Se a vericacao de uma cadeia de certicacao falha, n o signica que se trata de uma tentativa de a possvel que a o certicado Raiz da cadeia n o se encontre na lista falsicacao. E a de certicados de conanca. Geralmente, um certicado n o pode ser vericado se a sua cadeia de certicacao a n o est presente ou se o certicado Raiz n o se encontrar na lista de certicados a a a de conanca. A cadeia de certicacao de um determinado certicado pode ser construda programadamente em caso de n o estar presente, mas para isso, todos a os certicados nela t m que estar presentes. e

2.2.6

Chaveiros Protegidos e Ficheiros Certicados

Em sistemas com a assinatura electr nica de documentos, e usado armazenamento o protegido para chaves e certicados (chaveiro protegido). Este armazenamento pode conter tr s elementos, que s o: certicados, cadeias de certicacao e chaves e a privadas. Como a informacao guardada em armazenamento protegido e conden cial devido a consideracoes de seguranca, ela e acedida usando palavras-chave de dois nveis, uma palavra-chave para o chaveiro e palavras-chave diferentes para cada chave nele guardadas. Gracas a estas palavras-chave, em caso de um even tual roubo de um chaveiro protegido, a informacao que ele cont m n o pode ser e a facilmente lida. Na pr tica, as chaves privadas, como uma particularidade importante e peca a condencial de informacao, nunca s o armazenadas fora de chaveiros e est o sem a a pre protegidas com uma palavra-chave de acesso. Existem v rias normas desenvolvidas para chaveiros protegidos. A mais divula gada e a norma PKCS#12, na qual o armazenamento e um cheiro com a extens o a .PFX (ou a extens o usada mais raramente .P12). Um cheiro PFX normalmente a cont m um certicado, uma chave privada correspondente a ele, e uma cadeia de e certicacao provando a autenticidade do certicado. A presenca de uma cadeia de certicacao n o e necess ria e muitas vezes os a a cheiros PFX apenas cont m o certicado e a chave privada. Na maior parte dos e casos, para facilitar o utilizador, a palavra-chave para aceder a um cheiro PFX e ` ` igual a palavra-chave de acesso a chave privada nele armazenada. Por esta raz o, a quando se usam cheiros PFX muito frequentemente, apenas uma palavra-chave de acesso e necess ria. a 14

2. CONTEXTO Quando uma entidade certicadora emite um certicado digital a um cliente, o cliente recebe um chaveiro protegido, que contem o certicado emitido, a sua correspondente chave privada e toda a cadeia de certicacao, provando a autenti cidade do certicado. O armazenamento protegido e fornecido ao cliente, ou em forma de cheiro PFX ou de smart card, ou e directamente instalado no seu Web browser. Normalmente, quando um certicado e emitido pela Internet, independentemente de como o utilizador conrma a sua identidade, no procedimento de emiss o o browser Web do utilizador tem um papel importante. Num pedido de a emiss o de certicado enviado a uma certa entidade certicadora do seu Web site, a o browser Web do utilizador gera um par de chaves p blica/privada e envia a chave u p blica para o servidor da entidade certicadora. O browser guarda secretamente u a chave privada e n o a envia para a entidade certicadora. A entidade certia cadora, ap s vericar a autenticidade dos dados pessoais do seu cliente, emite-lhe o um certicado no qual grava a chave p blica recebida pelo browser Web do cliente u e os seus dados de identidade conrmados. Para alguns tipos de certicados, os dados de identidade podem consistir apenas num endereco de e-mail vericado, enquanto para outros os dados podem conter informacao completa sobre a pessoa: nome, endereco, n mero de bilhete u de identidade, etc. A vericacao dos dados pessoais e feita usando um procedi mento, determinado pela respectiva entidade certicadora. Depois do servidor da entidade certicadora emitir o certicado ao seu cliente, ele redireciona-o para a p gina Web da qual este certicado pode ser instalado no browser Web do cliente. a Na realidade, o utilizador recebe de alguma forma o seu novo certicado da entidade certicadora junto com a cadeia de certicacao completa. Entretanto, o browser Web armazenou a chave privada correspondente ao certicado e, por m, o utilizador obt m um certicado e a sua correspondente chave privada, junto da e cadeia de certicacao do certicado, instalado no seu Web browser. O m todo de armazenamento de chaves privadas varia com os diferentes browsers, e mas em qualquer dos casos essa informacao condencial e protegida pelo menos com uma palavra-chave. No mecanismo descrito para emiss o de um certicado, a a chave privada do utilizador permanece desconhecida para a entidade certicadora ` e dessa maneira o utilizador pode ter a certeza de que mais ningu m tem acesso a e sua chave privada. A maior parte dos browsers Web conseguem usar os certicados e chaves privadas armazenadas neles para autenticacao antes de assegurar os servidores SSL. Muitos clientes de e-mail tamb m usam os certicados armazenados nos e browsers Web para assinar, cifrar, e decifrar correio electr nico. No entanto, alo 15

2. CONTEXTO gumas aplicacoes n o conseguem usar directamente os certicados a partir dos a browsers Web dos utilizadores, mas conseguem lidar com chaveiros PFX. Nestes casos, os utilizadores podem exportar os seus certicados a partir dos browsers Web, juntamente com as respectivas chaves privadas para cheiros PFX, e assim us -los noutra aplicacao. a No Internet Explorer, o certicado e a chave privada s o exportados a partir a do menu principal usando os comandos Ferramentas Opcoes da Internet Conte do Certicados Exportar; e no Firefox usando os comandos Feru ` ramentas Opcoes Avancado Cifra Ver certicados Exportar. A partida, quando se exporta um certicado e a sua chave privada com o Internet Explorer para um cheiro PFX, a cadeia de certicacao n o e completamente in a cluda no cheiro de sada, mas o utilizador pode especicar que a quer numa opcao adicional. H v rias normas de armazenamento de certicados digitais X.509. A mais a a comum e a codicacao ASN.1 DER, na qual os certicados s o armazenados a em cheiros com extens o .CER (em raras situacoes com extens o .CRT, .CA, ou a a .PEM). Um cheiro CER cont m uma chave p blica, informacao sobre o seu dono e u e uma assinatura digital de alguma entidade certicadora, certicando que esta chave p blica pertence mesmo a esta pessoa. Um certicado no formato .PEM u n o e mais do que um certicado no formato DER, codicado em Base64, dentro a de duas linhas BEGIN CERTIFICATE e END CERTIFICATE. O tamanho ocupado por um certicado .PEM e cerca de 4/3 do tamanho de um certicado DER. As entidades certicadoras divulgam a partir dos seus sites os seus certicados Raiz em cheiros CER. Um cheiro CER pode ser armazenado em formato bin rio ou em formato de texto, codicado com Base64. a

2.2.7

Revogacao de Certicados

` As vezes, acontece a uma pessoa ou a uma companhia perder o controlo sobre os seus certicados e as chaves privadas correspondentes, e estes caem nas m os a de outras pessoas, que podem eventualmente tirar proveito deles. Nestes casos e necess rio revogar estes certicados (certicados revogados). a As entidades certicadoras periodicamente (ou em caso de emerg ncia) publie cam listas de certicados que est o temporariamente inactivos ou revogados antes a da sua data de expiracao. Estas listas s o assinadas digitalmente pela entidade a certicadora que as emite, e s o chamadas de listas de certicados revogados a 16

2. CONTEXTO (Certicate Revogation Lists - CRL). Nestas listas s o especicados o nome da entidade certicadora que emitiu o a certicado, a data de emiss o, a data da pr xima publicacao de uma nova lista, os a o n meros de s rie dos certicados revogados e as vezes especcas e raz es para a u e o revogacao.

2.2.8

Autenticacao Mutua (Cliente e Servidor)

A autenticacao m tua entre duas entidades e a capacidade de cada uma das enti u dades se poder certicar que a outra e quem diz ser. Normalmente e usada quando um cliente se quer autenticar perante um servidor e este tamb m se autentica pere ante o cliente de maneira a ambas terem a certeza da identidade do outro. Quando se lida com certicados de cliente contidos num smart card normalmente e apresentada uma lista de certicados que podem ser utilizados, em que o cliente escolhe o mais adequado, e introduz o c digo PIN do smart card. o

2.3

PKCS#11

A PKCS#11 [4] e uma norma que especica uma API (Application Programming Interface - Interface de Programacao de Aplicacoes) criada pelos RSA Labora tories e denominada por Cryptoki para dispositivos criptogr cos que executam a funcoes criptogr cas. A vers o actual e a PKCS#11 v2.20 mas existe um draft a a para a v2.30. O software distribuido juntamente com os dispositivos criptogr cos como por a exemplo smart cards, normalmente inclui uma implementacao da norma PKCS#11 o costuma ser uma biblioteca para o cart o e leitor especco. Essa implementaca a (.dll em Windows e .so em Linux e UNIX) que pode ser carregada dinamicamente e usada por qualquer aplicacao instalada na m quina local. a Nem todas as funcoes denidas na norma PKCS#11 s o implementadas pe a los vendedores de dispositivos criptogr cos, a maior parte opta por implementar a apenas as funcoes necess rias que permitem o uso adequado dos dispositivos. Por a exemplo, se um dispositivo e inicialmente concebido com certicados e chaves privadas respectivas em que n o e suposto criar novas chaves ou certicados, nora malmente s o omitidas as funcoes que permitem a criacao de chaves ou certicaa dos novos. A norma PKCS#11 n o permite a extraccao fsica das chaves privadas contidas a 17

2. CONTEXTO no smart card, mas e possvel usar essas chaves privadas para cifrar, decifrar, ou assinar dados. Mas para que uma operacao que use a chave privada seja executada, ` o utilizador necessita de introduzir o seu c digo PIN a partida. E isto que protege o o acesso ao cart o. a A norma PKCS#11 fornece uma interface para aceder a chaves protegidas e chaveiros que cont m certicados localizados num smart card. Por isso o e seu modo de operacao e semelhante ao modo de operacao da PKCS#12 com chaveiros. No entanto os smart cards possuem algumas propriedades embutidas que um cheiro PKCS#12 n o tem, como por exemplo a capacidade de efectuar a cifra ou assinatura.

2.4

Cart o de Cidad o a a

O Cart o de Cidad o e o documento que inclui o n mero de identicacao civil, a a u o n mero de identicacao scal, o n mero de utente dos servicos de sa de e o u u u n mero de identicacao da seguranca social. Al m disso, contem tamb m dados u e e o. Alguns destes dados s o os relevantes a cada cidad o para a sua identicaca a a mesmos contidos no Bilhete de Identidade com excepcao da data de emiss o e do a estado civil. Tamb m serve como cart o de viagem dentro da Uni o Europeia e e a a outros pases no ambito de convencoes internacionais [7].

2.4.1

Como e Constituido o Cart o de Cidad o a a

Este cart o possui um chip que contem informacao especca sobre o seu titular. a Com excepcao da assinatura digitalizada, todas as informacoes contidas no exte rior do cart o tamb m s o contidas no chip. As Figuras 2.3 e 2.4 descrevem cada a e a campo contido no Cart o de Cidad o [8]. a a O chip ainda inclui as seguintes funcionalidades: IAS - aplicacao respons vel pelas operacoes de autenticacao e assinatura a electr nica o EMV-CAP - aplicacao respons vel pela gest o de palavras-chave unicas a a por canais alternativos Match-On-Card - aplicacao respons vel pena informacao biom trica de a e impress es digitais o 18

2. CONTEXTO

Figura 2.3: Cart o de Cidad o - Frente a a

Figura 2.4: Cart o de Cidad o - Verso a a

19

2. CONTEXTO

Figura 2.5: Informacao e Aplicacoes Residentes no Chip A Figura 2.5 descreve a informacao e as aplicacoes residentes no chip do Cart o a de Cidad o. a O Cart o possui um espaco onde podem ser guardados dados pessoais, desiga nado por Area Pessoal ou por Bloco de Notas. Esse espaco pode conter cerca de 1KB (1000 caracteres).

2.4.2

Autenticacao Simples com o Cart o de Cidad o a a

Para que o servidor possa efectuar o pedido do certicado existente no CC, e preciso efectuar os seguintes passos: Congurar o servidor para ligacoes SSL o site em quest o deve possuir a um certicado instalado no servidor Web para que seja possvel estabelecer uma ligacao segura entre o servidor e as aplicacoes clientes. Congurar o servidor para aceitar certicados de clientes congura-se o servidor para que efectue o pedido de um certicado digital ao cliente. Congurar o servidor para pedir e aceitar o certicado do Cart o de Cidad o a a Normalmente os servidores est o congurados para pedir e aceitar cera ticados clientes emitidos pelo seu LDAP (Lightweight Directory Access Protocol). Aqui congura-se o servidor para que tamb m aceite certicae dos emitidos pelas Entidades Certicadoras emissoras dos certicados presentes no Cart o de Cidad o. a a 20

2. CONTEXTO

Figura 2.6: Autenticacao Gen rica com o Cart o de Cidad o e a a

Validacao aplicacional do certicado Para garantir que s s o aceites o a certicados presentes no CC, o c digo desenvolvido para autenticacao deve o validar um conjunto de par metros presentes no certicado, para garantir a a sua origem.

Validacao de validade do certicado A ultima validacao e feita pela en tidade emissora do certicado, para garantir que o certicado n o foi revoa gado, podendo ser usados dois m todos para esse efeito, CRL (Certicate e Revocation List) ou OCSP (Online Certicate Status Protocol).

O processo de validacao garante a associacao entre os dados do CC e o seu o do certicado digital na Entidade Certicadora permite vertitular. A vericaca ` icar se o certicado se encontra v lido. No entanto, cabe a Entidade que, ap s a o a vericacao no seu sistema de informacao, a denicao dos privil gios de acesso e para o utilizador. Este modelo de autenticacao n o e o suciente para autenticar um prossional a de sa de na RTS, porque o certicado de autenticacao do Cart o de Cidad o n o u a a a tem informacao relativa ao cargo desempenhado por um determinado prossional numa Instituicao de Sa de. A criacao de um novo certicado com essa informacao u e uma necessidade, e torna-se obrigat ria uma redenicao da arquitectura. o A Figura 2.6 descreve como funciona o mecanismo de autenticacao usando o certicado de autenticacao do Cart o de Cidad o. a a 21

2. CONTEXTO

Figura 2.7: Interaccao entre aplicacoes e o m dulo PKCS#11 o

2.4.3

Middleware do Cart o de Cidad o a a

O Cart o de Cidad o e fornecido com uma interface PKCS#11 que e utilizada por a a aplicacoes n o Microsoft. Para aplicacoes Microsoft seria usada a interface CSP. a A interface CSP n o foi analisada porque apenas est disponvel em ambientes a a Windows. A Figura 2.7 descreve as diferencas na interaccao do browser Internet Explorer (Aplicacao Microsoft) e o browser Firefox (Aplicacao n o Microsoft). a A interface PKCS#11 implementa as seguintes funcoes: Funcoes Gerais: C Initialize C Finalize C GetInfo C GetFunctionList Funcoes de gest o de Slot e Token: a 22

2. CONTEXTO C GetSlotList C GetSlotInfo C GetTokenInfo C GetMechanismList C GetMechanismInfo C WaitForSlotEvent (only non-blocking) C SetPin Funcoes de gest o de sess o: a a C OpenSession C CloseSession C CloseAllSessions C GetSessionInfo C Login C Logout Funcoes de gest o de objectos: a C FindObjectsInit C FindObjects C FindObjectsFinal C GetAttributeValue Funcoes de assinatura: C SignInit C Sign 23

2. CONTEXTO C SignUpdate C SignFinal

Funcoes de digest: C DigestInit C Digest C DigestUpdate C DigestFinal

Funcoes de geracao aleat ria: o C SeedRandom C GenerateRandom

As restantes funcoes denidas na norma PKCS#11 que n o aparecem na lista a n o foram implementadas pela interface fornecida. a Os mecanismos de assinatura suportados pelo cart o s o: a a Para assinaturas: - CKM RSA PKCS: ambos ASN.1-wrapped e hashes puros (MD5, SHA1, SHA1+MD5, RIPEMD160) - CKM RIPEMD160 RSA PKCS, CKM SHA1 RSA PKCS, CKM MD5 RSA PKCS Para digests: - CKM SHA 1, CKM RIPEMD160, CKM MD5 Os objectos incluidos no Cart o de Cidad o que podem ser manipulados pelas a a funcoes implementadas pelo m dulo da PKCS#11 fornecido com o middleware o s o descritos na Tabela 2.4.3, em que a primeira coluna refere o handle do objecto a e a segunda a sua designacao. 24

2. CONTEXTO 1 2 3 4 5 6 7 8 9 10 Authentication Private Key Authentication Certicate Authentication Public Key Authentication Sub CA Certicate Authentication Sub CA Public Key Signature Private Key Signature Certicate Signature Public Key Signature Sub CA Certicate Signature Sub CA Public Key

Tabela 2.1: Objectos Existentes no Cart o de Cidad o a a

2.4.4

API eID Lib

Esta aplicacao e dedicada a organizacoes cujo objectivo e desenvolver aplicacoes que utilizam o Cart o de Cidad o. Este kit de desenvolvimento lida apenas com a a dados identicativos do cart o, incluindo o Bloco de Notas, e n o com operacoes a a criptogr cas. a

2.4.5

Normas dos Leitores de Cart es o

O Cart o de Cidad o segue as normas internacionalmente recomendadas encontrandoa a se alinhado pelas orientacoes correntes da Uni o Europeia, nomeadamente as do a grupo de trabalho para o European Citizen Card (ECC), pelas normas denidas pela International Civil Aviation Organization (ICAO) para documentos de viagem internacionais (documento 9303) e os as normas 7501 e 7810 denidas pela International Organization for Standardization (ISO). Os leitores devem estar de acordo com as seguintes normas [9]: PC/SC vers o 1.0; a ISO/IEC 7816-1,2,3,4: IC Cards with Contacts; EMV Level 1; CT-API vers o 1.1; a CCID - Chip Card Interface Device 1.0; 25

2. CONTEXTO Suportar a norma ISO/IEC 7186 Class A, B e C (smart cards com voltagens de 5V, 3V, 1.8V); Suportar leitura e escrita para smart cards com microprocessadores alinhados com ISO/IEC 7816-1,2,3,4, protocolos T=0 e T=1; Suportar smart cards com frequ ncias de rel gio at 8Mhz; e o e

Microsoft Windows Hardware Quality Labs (WHQL) - caso o sistema operativo seja Windows; Microsoft Windows Logo Program WLP 2.0 - caso o sistema operativo seja Windows; EMV Level 1 (EMV2000);

Os leitores dever o suportar smart cards de formato ID-1. a

2.4.6

Cart o de Cidad o e Smart Card Gen rico a a e

O Cart o de Cidad o vem com 2 certicados de origem, e respectivos pares a a de chaves publica/privada. N o e possvel denir novos objectos no Cart o de a a Cidad o. Num smart card e possvel criar novos objectos, certicados e pares de a chave tendo apenas como limite o espaco fsico disponvel. ` A criacao de novos objectos no Cart o de Cidad o e impedida devido a funcao a a a C Create Object n o ter sido implementada. Obviamente que a falta de espaco disponvel tamb m e uma limitacao, mas mesmo sem espaco disponvel, a ex e ist ncia da funcao C Create Object iria permitir a criacao de objectos ao nvel da e sess o, caso tivesse sido implementada. a Tamb m n o e possvel a alteracao das credenciais j existentes no cart o e a a a porque essas credenciais se tratam de certicados assinados, e qualquer alteracao seria detectada durante o processo de vericacao dos pr prios, pois eles est o o a digitalmente assinados pela Entidade Certicadora que os emitiu. Adicionar extens es a certicados existentes est fora de quest o. o a a 26

2. CONTEXTO

2.5

O Projecto OpenSSL

O Projecto OpenSSL1 e um esforco colaborativo para desenvolver um conjunto de ferramentas completo a nvel comercial e em c digo aberto dos protocolos o SSL (Secure Sockets Layer) e TLS (Transport Layer Security) como tamb m uma e biblioteca criptogr ca. a O projecto e gerido por uma comunidade a nvel mundial de volunt rios que a usam a Internet para comunicar, planear, e desenvolver ferramentas para o OpenSSL. O OpenSSL possui ferramentas que permitem criar pedidos de certicados (CSR - Certicate Signing Request) de uma forma f cil apenas executando um a comando numa consola. Tamb m e possvel a criacao de Entidades Certicadoras e usando o conjunto de ferramentas fornecido pelo OpenSSL. Essas entidades podem validar pedidos de certicados, emitindo-os em v rios formatos diferentes, a como por exemplo DER ou PEM. Como se trata software de c digo aberto, tem a vantagem de se poder adaptar o a outras situacoes sendo sujeito a alteracoes no seu c digo. o

1 http://www.openssl.org/

27

Captulo 3 Trabalhos RelacionadosEste captulo descreve alguns projectos semelhantes ao projecto da RTS em que tamb m s o usados smart cards em infra-estruturas de chaves p blicas para a e a u autenticacao em redes telem ticas de sa de em v rios pases. Tamb m e feita a u a e uma breve descricao da arquitectura actual da RTS com o uso de smart cards e de v rios aspectos que devem ser considerados para a sua adaptacao ao uso do a Cart o de Cidad o. a a

3.1

Alemanha - Electronic Health Card (eHC) e Health Professional Card (HPC)

Durante os pr ximos anos o cart o de sa de alem o vai ser substitudo por um o a u a novo cart o de sa de (eHC). A introducao deste novo cart o visa melhorar a a u a eci ncia do sistema de sa de e dos direitos dos pacientes. Para reduzir os custos e u do sector p blico e criar bases de comunicacao homog neas foi criado um sistema u e a nvel nacional, a Infra-estrutura Telem tica de Sa de. a u O eHC n o s cont m dados administrativos mas tamb m informacao detala o e e hada sobre o paciente e os seus tratamentos. Esta informacao e pessoal e est sob a a obrigacao de segredo imposta pela relacao m dico/paciente e protegida por lei, e e agora armazenada numa base de dados central em funcao de melhorar os servicos para os pacientes[10]. Os prossionais de sa de possuem um cart o diferente, denominado por Health u a Professional Card (HPC), com funcionalidades especiais para os prossionais de sa de. O processo de criacao e semelhante ao do eHC, em que e gerado um certiu 29

3. TRABALHOS RELACIONADOS

Figura 3.1: Cart o de Sa de do Prossional (HPC) a u

cado e a sua chave privada ca armazenada num ambiente seguro. Possui funcoes CVC (Card-Veriable Certicate) que validam os dados pessoais do prossional contidos no cart o, para que estes n o possam ser forjados. A Figura 3.1 apresenta a a o HPC. Tal como a RTS, esta rede telem tica de sa de tamb m se trata de uma rede a a u e nvel nacional. Foi criado um projecto que visa introduzir o eHC na Alemanha. A infra-estrutura telem tica de sa de e composta por uma parte central, que consiste a u em centros de dados com bases de dados centralizadas, e as partes perif ricas, que e consistem em utilizadores do sistema, como por exemplo o prossional de sa de, u farm cias ou hospitais. Ambas as partes est o ligadas por um t nel VPN. a a u O eHC, mostrado na Figura 3.2 tem o mesmo tamanho de um cart o de cr dito a e ` comum, a frente tem informacao relativa ao indivduo a que pertence, e um micro chip. O eHC e um smart card, o que signica que cont m um processador pr prio, e o com o seu pr prio conjunto de instrucoes. E isto que o distingue do cart o actual, o a que apenas e um cart o de mem ria. a o E possvel emitir receitas electr nicas com este cart o, carregando a receita o a para o chip e assinando-a electronicamente. Essa informacao pode ser lida na farm cia, por exemplo. a Este projecto envolve uma das mais abrangentes infra-estruturas de chaves p blicas do mundo. A companhia encarregada de desenvolver o projecto e a u Gematik1 .1 http://www.gematik.de/

30

3. TRABALHOS RELACIONADOS

Figura 3.2: Cart o de Sa de do Utente (eHC) a u

3.2

Uso de Smart Cards em Redes Telem ticas de a Saude

Tal como a Alemanha, muitos outros pases optaram pelo uso de smart cards nas suas redes telem ticas de sa de. Alguns dos mais populares, neste momento, a u al m da Alemanha s o a Algeria, Austria, Austr lia, B lgica, Franca, Hungria, e a a e It lia, M xico, Eslov nia, Espanha, Tail ndia e Reino Unido, sendo a sua maioria a e e a 2. produzidos pela Gemalto No geral, o acesso e baseado usando uma infra-estrutura de chaves p blicas, da u mesma maneira que e descrita na seccao seguinte, que apresenta uma arquitectura para a RTS com o uso de smart cards.

3.3

Arquitectura Denida pelo H. Gomes

Esta arquitectura e a que serve de base para a adaptacao ao uso do Cart o de a Cidad o na RTS, pois foi pensada para ser usada com smart cards. Segue-se uma a breve descricao, que entra em detalhes mais t cnicos no Captulo 6, onde s o e a descritos os aspectos que devem ser alterados para o seu funcionamento com o Cart o de Cidad o. a a2 www.gemalto.com

31

3. TRABALHOS RELACIONADOS

3.3.1

Introducao

Esta arquitectura baseia-se numa infra-estrutura de chaves p blicas, de modelo u hbrido, onde cada Instituicao de Sa de (IS) e respons vel pela emiss o e gest o u a a a de certicados digitais para as suas entidades. Para isso, a RTS e cada uma das IS, constitui a sua pr pria PKI. Entre as PKI das v rias IS e a PKI da RTS s o o a a estabelecidas relacoes de conanca, baseadas em certicacao cruzada. Para o transporte e armazenamento seguro das credenciais de autenticacao dos Prossionais s o utilizados smart cards. Estes cart es permitem um nvel a o de autenticacao forte, baseado em dois factores, posse e senha, e al m disso um e elevado nvel de proteccao fsica dos dados guardados do seu interior. Tamb m e podem ser facilmente transportados pelo seu dono. As credenciais de autenticacao dos Prossionais s o constituidas por dois cer a ticados de chave p blica e correspondentes chaves privadas: (i) um certicado u ` para o acesso a RTS e (ii) um certicado para a autenticacao do Prossional na renovacao do seu certicado RTS perante a IS. O certicado RTS cumpre as ` funcoes de acesso a RTS e indicacao do seu perl na IS a que est vinculado. a ` Devido as alteracoes de perl poderem ser alteradas frequentemente, e denido um tempo de vida curto para os certicados RTS. Este tempo de vida curto permite a implementacao de uma PKI simplicada, pois deixa de ser obrigat ria a o ` exist ncia de CRLs na autenticacao para o acesso a RTS. e No modelo de conanca utilizado, cada entidade tem como ancora de conanca exclusivamente a EC raiz da instituicao a que est vinculada. Al m disso como a e os caminhos de certicacao s o curtos, o n mero de certicados de conanca a a u que cada entidade necessita de ter na sua posse, para validar os certicados que lhe s o apresentados, e reduzido, o que e uma vantagem dado o pouco espaco de a mem ria nos smart cards. o

3.3.2

Descricao da Arquitectura

Esta seccao descreve a arquitectura proposta pelo H. Gomes [5] A solucao apre sentada por esta arquitectura baseia-se em pares de chaves assim tricas e certie cados digitais das chaves p blicas. Esta tecnologia e suportada pelos navegadores u servidores Web mais populares. E utilizada uma infra-estrutura de chave p blica, PKI (Public Key Infrastrucu proposta uma PKI simplicada baseada numa arquitectura previamente ture). E proposta para resolver o problema de autenticacao de utilizadores em conjuntos 32

3. TRABALHOS RELACIONADOS

Figura 3.3: Vis o Geral da Arquitectura da RTS a de instituicoes universit rias. Esta arquitectura baseia-se em certicados digitais a com perodos de validade de curta duracao e certicacao cruzada entre instituicoes para a validacao de cadeias de certicacao. A Figura 3.3 apresenta uma vis o geral a da arquitectura da RTS [11]. S o utilizados smart cards para o armazenamento e proteccao das chaves pria vadas e certicados raiz con veis. Estes smart cards s o utilizados apenas na a a autenticacao dos Prossionais, para os Utentes a autenticacao e feita atrav s de e um nome de acesso e uma senha.

O Uso de Certicados A RTS e uma aplicacao que disponibiliza os seus servicos aos utilizadores atrav s e de Portais com interface Web. Esses servicos necessitam da autenticacao do Prossional, da instituicao a que pertence, e qual o seu cargo nessa instituicao. Os mecanismos disponveis para autenticacao do prossional utilizando um nave gador (browser), em servidores Web s o o nome e senha, ou certicados digitais. a O m todo mais vulgar e o da utilizacao de nome e senha. Este m todo tem e e 33

3. TRABALHOS RELACIONADOS v rias vulnerabilidades, porque geralmente, ou as senhas s o demasiado fracas a a para facilitar a memorizacao, ou s o demasiado complexas e necessitam de ser a anotadas, o que as pode comprometer. Al m disso, para o Portal obter a restante e informacao sobre o utilizador, seria necess rio um servico com a informacao de a todos os utilizadores da RTS, ou obter a informacao de um determinado utilizador na sua instituicao de origem. A primeira situacao estaria a replicar informacao de directoria de todas instituicoes ` participantes na RTS. A segunda implicaria que a RTS tivesse acesso online a informacao de directoria das v rias Instituicoes de Sa de. a u O uso de certicados permite que a autenticacao e sua validacao sejam feitas localmente. Para isso, e necess rio que o certicado possua a informacao do seu a propriet rio, informacao sobre a instituicao de origem e do cargo nela desempena hado, e de um perodo de validade que permita prescindir da vericacao da sua revogacao. Se a chave privada e o correspondente certicado digital forem armazenados num smart card protegido com um c digo de acesso, a seguranca torna-se mais o eciente, uma vez que para efectuar a autenticacao e necess ria a posse do smart a card, e de conhecer o seu c digo de acesso. o

Modelo de Comunicacao A Figura 3.4 descreve o modelo de comunicacao e autenticacao na RTS. O pros sional envia o seu certicado ao Portal da RTS. Depois da validacao do certicado, em funcao da informacao obtida nele, s o aplicadas as autorizacoes adequadas ao a seu perl. A comunicacao entre o Portal e outros servicos ou servidores e mediada, no o n o se autentica sentido em que o Prossional que fez o pedido de informaca a neste troco. O Portal e o respons vel pelo pedido e por garantir que n o fornece ao a a Prossional mais informacao do que a que ele pode aceder. No entanto continua a haver autenticacao das entidades envolvidas na comunicacao para garantir que a informacao n o e acedida por entidades n o credenciadas para o acesso. Para a a ` aceder a informacao pretendida, pode ser necess rio recorrer a v rios servicos em a a cadeia sendo aplicado sempre o mesmo modelo de autenticacao entre os servi dores. ` A identicacao subadjacente a autenticacao e feita atrav s da troca de certi e cados entre as entidades. Cada entidade valida o certicado da outra para que se possa continuar com a comunicacao. O Portal tem que garantir que o utilizador 34

3. TRABALHOS RELACIONADOS

Figura 3.4: Modelo de Comunicacao e Autenticacao

pertence a um tipo v lido. Ap s a autenticacao, e criado um canal de comunicacao a o seguro. No caso da comunicacao entre o Utente e o Portal, em que o Utente n o possui a um certicado, o modelo e semelhante, mas n o h o envio do certicado do a a Utente para o Portal. No entanto, o Utente recebe um certicado do Portal e ` deve proceder a sua validacao para que possa ser criado um canal de comunicacao seguro entre eles. Depois de criado um canal seguro e pedido ao utilizador o nome de acesso e a senha. A tecnologia utilizada para estabelecer uma ligacao entre um Prossional e o Portal RTS e HTTP sobre SSL/TLS (HTTPS), e entre os Servidores institucionais e HTTPS ou IPSec.

Requisitos dos Certicados Cada entidade, Prossional ou Servico/Servidor, deve possuir um par de chaves assim tricas e um certicado de chave p blica, emitido pela sua instituicao de e u origem, para que se possa autenticar na RTS. O certicado do Prossional deve conter a identicacao do seu possuidor, a sua instituicao de origem, e o cargo que desempenha na instituicao. E com base ` nesta informacao que s o denidas as permiss es de acesso a informacao gerida a o pela RTS. 35

3. TRABALHOS RELACIONADOS Tipos de Certicados de Prossionais S o utilizados certicados no formato X.509v3. Como para al m da identicacao a e da entidade emissora e necess rio denir o cargo desempenhado pelo prossional a na instituicao, e necess rio utilizar extens es previstas na vers o 3. Desta forma a o a e usada a extens o EKU (Extended Key Usage), e denidos OIDs (Object Identia ers) para cada tipo de Prossional existente no sistema. Armazenamento dos Certicados e Chaves Privadas As t cnicas de autenticacao s o baseadas naquilo que se sabe, naquilo que se e a possui, naquilo que se e, ou em combinacoes das tr s anteriores. e A utilizacao de smart cards para o armazenamento das chaves privadas e re spectivos certicados permitem a autenticacao baseada em dois factores, a posse do cart o e o conhecimento do c digo de activacao do mesmo. Outra vantagem a o dos smart cards e possurem um processador criptogr co que permite a geracao a e utilizacao do par de chaves no seu interior impedindo que a chave privada saia para o exterior. Os smart cards t m como desvantagem o aumento do custo da implementacao e do sistema uma vez que e necess rio equipar os computadores utilizados pelos a Prossionais de leitores de smart cards. Tempo de Vida dos Certicados Um dos aspectos fundamentais numa PKI e a gest o de listas de certicados revoa gados (CRL). Para simplicar a gest o da PKI a utilizar na RTS, optou-se pela a o de certicados com intervalos de tempo curtos para a autenticacao dos utilizaca Prossionais, e assim prescindir de CRLs, ou outros mecanismos, para lidar com a revogacao dos certicados dos prossionais. O seu tempo de vida deve resultar de uma ponderacao sobre o risco associado ao seu tempo de vida. A janela de risco do certicado e no m ximo igual ao seu tempo de vida, ou a seja, o m ximo intervalo de tempo em que o certicado se encontra v lido e pode a a ser usado em caso de transvio. No entanto, e necess rio ter em conta que a chave a privada correspondente de um certicado se encontra dentro de um dispositivo criptogr co que bloqueia ap s um determinado n mero de tentativas falhadas, o a o u que diculta a sua utilizacao mal intencionada. Uma das vantagens de certicados de curta duracao s o que torna mais simples a 36

3. TRABALHOS RELACIONADOS

Figura 3.5: Modelo de Conanca Entre a RTS e as IS fazer com que os prossionais facam pedidos de novos certicados e pares de chaves do que gerir a lista de certicados revogados. Uma outra vertente tem a ver com a utilizacao do certicado para a RTS inferir sobre a autorizacao. Por exemplo, caso o cargo de um prossional seja alterado, seria necess rio revogar o antigo certicado e emitir um novo. Com a utilizacao a de certicados de curta duracao este processo pode ser escolhido de forma a poder ter um grau de sincronismo adequado. Para os certicados emitidos para Servicos/Servidores n o s o aconselh veis a a a intervalos de validade curtos, porque como est o em ambiente controlado, o risco a de comprometimento e muito menor. Caso estes certicados fossem de curta o, havia o risco deles expirarem e os servicos ou servidores carem induraca acessveis. Isto implica que para este tipo de certicados seja necess rio gerir a uma CRL.

Modelo de Conanca A Figura 3.5 apresenta o modelo de conanca da RTS. Neste modelo, cada IS e respons vel pela emiss o e gest o dos certicados para as suas entidades. E a a a assim que s o denidas as instituicoes de origem da entidade possuidora de um a certicado. Para o estabelecimento de conanca m tua entre cada uma das IS e a RTS, u e possibilitar que os certicados emitidos por cada uma das IS sejam v lidos na a RTS, e vice-versa, constitui-se uma estrela de certicacoes cruzadas na qual a RTS ocupa a posicao central e as extremidades s o ocupadas pelas Instituicoes de a Sa de participantes na RTS. A certicacao cruzada e feita individualmente com u 37

3. TRABALHOS RELACIONADOS

Figura 3.6: Arquitectura Interna das EC

cada IS e consiste na emiss o de um certicado pela RTS para a IS e na emiss o a a de um certicado da IS para a RTS. Cada IS e respons vel pela emiss o dos certicados para as suas entidades. a a Caso alguma IS j possua alguma PKI em funcionamento preconiza-se a sua a o para a emiss o de certicados para a RTS. Para as restantes IS sugerereutilizaca a se a implementacao de uma hierarquia de ECs com pelo menos dois nveis tal como mostra a Figura 3.6. A certicacao cruzada para o estabelecimento de conanca entre a RTS e a IS e feita entre as EC Emissoras da RTS e da IS, que assinam os certicados uma da outra. As raz es para efectuar a certicacao cruzada ao nvel das EC Emissoras e n o o a da EC raiz s o limitar o ambito da conanca entre as entidades, que se pretende a apenas para os certicados a usar na RTS, e limitar danos em caso de quebra de conanca na outra instituicao, uma vez que a publicacao da CRL da EC Emissora e mais frequente que a da EC raiz, que est ofine. a 38

3. TRABALHOS RELACIONADOS

Figura 3.7: Construcao de Cadeia de Conanca Validacao dos Certicados Quando se inicia uma interaccao na RTS, as entidades devem-se autenticar atrav s e da troca dos seus respectivos certicados digitais. Cada entidade deve validar o certicado da outra e proceder com a comunicacao quando cada parte concluir que a outra e de conanca. Uma identidade deve fazer as validacoes de certicados tendo como unica ancora, ou raiz de conanca o certicado raiz da sua pr pria instituicao. Para isso o vai tentar construir o caminho ou cadeia de conanca que liga a entidade emissora do certicado a validar at ao certicado raiz da sua instituicao. A validacao e do certicado recebido implica a validacao de todos os certicados da cadeia de conanca constituda .A Figura 3.7 apresenta um exemplo da validacao de um certicado e respectiva cadeia de conanca. O problema com as certicacoes cruzadas e a diculdade em obter de forma recomend vel que todas as entiautom tica todos os certicados da cadeia. E a a 39

3. TRABALHOS RELACIONADOS

Figura 3.8: Comunicacao Segura Entre o Prossional e a RTS dades que participam na RTS estejam na posse dos certicados necess rios para a a construcao das cadeias de conanca dos certicados da IS com as quais interagem. Isto implica que um Prossional ter que transportar no seu smart card o seu cera ticado, os certicados da sua cadeia hier rquica, e o certicado da certicacao a cruzada em que a EC Emissora da sua IS assina a chave p blica da EC Emissora u da RTS. No caso dos Portais e restantes servidores da RTS que necessitem de validar certicados emitidos pelas IS, t m de possuir todos os certicados cruzados emie tidos pela RTS para as v rias IS, al m dos certicados da cadeia hier rquica da a e a RTS.

3.3.3

Adaptacao da Arquitectura de Autenticacao para o Uso do Cart o de Cidad o a a

E preciso encontrar uma maneira de introduzir ou associar as credenciais de um determinado Prossional a um cart o. Essas credenciais precisam de indicar a o cargo do Prossional, a que IS ele est vinculado, e o perodo de validade. a Tamb m deve ser garantido que essas credenciais s o genunas, e apenas v lidas e a a para o possuidor daquele cart o. a Mesmo que as credenciais n o estejam contidas no cart o, estas devem ser a a associadas a ele de alguma forma, de maneira a que o cart o sirva como prova de a ` posse complementar as credenciais. Entre o cliente e o servidor deve ser criada uma ligacao SSL, como apresenta a Figura 3.8. Do lado do cliente deve correr uma aplicacao que l o Cart o de e a Cidad o, para autenticar o utilizador com base nos dados contidos no cart o, e ao a a mesmo tempo, que valide as credenciais desse utilizador, certicando-se que estas apenas s o v lidas na presenca daquele cart o. a a a 40

3. TRABALHOS RELACIONADOS A informacao obrigat ria nas credenciais s o o Cargo desempenhado pelo o a Prossional e a Instituicao de Sa de ao qual est vinculado. Essa informacao u a tem que chegar ao servidor da RTS de uma forma segura. A emiss o dessas crea denciais ca a cargo das Instituicoes de Sa de. u Uso do CC como Smart Card de Autenticacao dos Prossionais O Cart o de Cidad o j foi descrito no captulo do Contexto. Nesta seccao s o a a a a mencionados os principais problemas que impedem que o Cart o de Cidad o seja a a utilizado sem problemas na arquitectura denida. A adaptacao da arquitectura de smart cards para o Cart o de Cidad o requer a a alguns cuidados. O Cart o de Cidad o n o e um smart card normal, devido ao a a a facto de estar limitado, sendo impossvel a geracao de novos certicados no seu interior. Impossibilidade de Adicionar Novas Credenciais O Cart o de Cidad o n o permite criar novos certicados. Com smart cards o a a a que se fazia era gerar no cart o um certicado para a RTS e outro para a IS, que a possvel vericar a autenticidade de uma pessoa mas agora n o e possvel. E a n o e possvel saber qual o cargo desempenhado por essa pessoa na IS a que a ` pertence pois a informacao relativa a IS a que est vinculado e ao seu cargo n o a a se encontram em nenhum certicado contido no cart o. a Aus ncia de Cargos e Sem a informacao sobre o cargo executado por um determinado Prossional n o a e possvel fornecer as permiss es adequadas para que o Prossional possa aceder o ` a area da sua especialidade, pois esta n o e conhecida. O Cart o de Cidad o n o a a a a possui meios de denir a informacao sobre o cargo do Prossional.

41

Captulo 4 Estudo da Solucao com C digo o ActivoNeste captulo s o estudadas v rias formas de colocar no browser dos prossion a a ais capacidades de extens o do Cart o de Cidad o usando c digo activo (i.e. cona a a o tido nos conte dos enviados da RTS para o browser). As extens es visam fundau o mentalmente a obtencao de forma dedigna na funcao prossional do cliente ao longo de uma sess o com a RTS mantendo parte da arquitectura de distribuicao e a ` validacao de credenciais igual a do H. Gomes. A Figura 4.1 apresenta uma solucao com c digo activo. o Uma solucao de c digo activo tem a vantagem de poder ser executada em o browsers que n o permitem o uso de m dulos de seguranca, e nesse caso o c digo a o o activo trata da implementacao dos mecanismos de seguranca entre o cliente e o servidor, permitindo um maior controlo sobre o nvel de seguranca que se deseja implementar. A unica area do Cart o de Cidad o onde e possvel escrever e o Bloco de Noa a a a tas. E por essa raz o que o acesso a esta area e t o importante no uso de solucoes de c digo activo. Uma alternativa ao Bloco de Notas seria uma base de dados o online que zesse o mapeamento entre a identicacao do cidad o e a informacao a extra relativa a ele, mas isso iria trazer outros custos, como por exemplo recursos de rede e denicao de permiss es para essa base de dados. o A abordagem escolhida foi o uso do Bloco de Notas para conter a informacao sobre as credenciais. N o e uma imposicao que elas estejam contidas no cart o, a a podem estar noutro tipo de suporte de m dia local ou at mesmo remoto, desde e e que apenas sejam v lidas na presenca fsica do Cart o de Cidad o, e essa validacao a a a 43

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO

Figura 4.1: Solucao com C digo Activo o

seja feita por c digo activo. o Considerou-se portanto, que para aumentar a mobilidade dos prossionais, as credenciais extra manipuladas por c digo activo seriam guardadas no Bloco de o Notas do Cart o de Cidad o de cada prossional, e n o num outro reposit rio a a a o avulso qualquer. A exist ncia de um mecanismo que vincule as credenciais de um Prossional e ao seu cart o de cidad o e crtico. A capacidade de usar a biblioteca eID Lib a a e importante para a vericacao da autenticidade das credenciais. As credenciais emitidas por uma Instituicao de Sa de devem conter informacoes relacionadas u com o certicado de autenticacao do cidad o para impedir que sejam copiadas e a ` utilizadas por por alguem n o autorizado. Para aceder a informacao contida no a o do cidad o e necess rio recorrer a biblioteca eID Lib ` certicado de autenticaca a a ` ou a PKCS#11. A biblioteca eID Lib possui funcoes CVC que permitem a vericacao da informacao pessoa de uma maneira segura, impedindo que os dados sejam for jados, pois foram assinados [3]. Esta API tamb m permite o acesso aos certicae dos X.509 contidos no CC. Alem disso, esta biblioteca e necess ria para aceder a ao Bloco de Notas, onde e colocada a informacao sobre as credenciais do Pros sional. Caso as credenciais n o sejam guardadas no Cart o de Cidad o, por falta de a a a espaco ou por uma quest o de facilidade na gest o das credenciais, mesmo assim a a elas devem estar vinculadas a um cart o. A maneira de vericar esse vnculo passa a 44

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO

Figura 4.2: Relacao entre a RTS e uma IS

pelo c digo activo. o ` Assume-se a partida que as entidades RTS e IS fazem parte de uma infraestrutura de chaves p blicas e que existe uma relacao de conanca entre elas. u Ambas as entidades tamb m devem conar na PKI do Cart o de Cidad o. e a a A Figura 4.2 descreve a relacao entre uma IS e a RTS. As linhas a tracejado simbolizam relacoes de conanca. Uma instituicao de sa de emite as credenciais u a um prossional, que mais tarde ele usa para se autenticar na RTS. Para aceder ao portal da RTS a primeira coisa a ser feita e a validacao do certi cado do Cart o de Cidad o do prossional, feito pelo browser, sem c digo activo a a o ainda, e de seguida a validacao das suas credenciais, para obter a informacao do cargo do prossional em causa, atrav s de c digo activo. e o 45

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO

4.1

Modo de Funcionamento das Credenciais

Para lidar com a quest o das credenciais emitidas pela RTS aos prossionais devea se usar uma tecnologia que permita a emiss o de credenciais por uma entidade e a a sua validacao perante outra entidade, como por exemplo a norma SAML (Se curity Assertation Markup Language). Esta norma e baseada em XML e a sua nalidade e fornecer dados sobre autenticacao e autorizacao entre um fornecedor de identidade e um fornecedor de servicos. SAML foi desenvolvido pelo comit t cnico dos servicos de seguranca da OAe e SIS (Organization for the Advancement of Structured Information Standards). E uma framework baseado em XML que serve para comunicar a autenticacao, ttulo e informacao adicional de um utilizador. SAML permite que entidades empre sariais emitam assertacoes relativas a entidade, atributos e ttulos de um sujeito (uma entidade que normalmente e um utilizador humano) a outras identidades, tais como uma empresa parceira ou outra aplicacao empresarial. SAML e um protocolo exvel e extensvel concebido para ser usado (e personalizado caso necess rio) por outras normas. a Algumas das vantagens do SAML s o que abstrai a framework de seguranca a da arquitecturas das plataformas e implementacoes de fornecedores particulares, n o necessita que a informacao do utilizador seja mantida e sincronizada entre a directorias, permite que os utilizadores facam logon numa entidade provedora e que depois estes se autentiquem perante provedores de servicos sem autenticacao adicional e reduz custos administrativos aos provedores de servicos. No caso de logon unico (Single Sign-On), um utilizador autentica-se perante um Web site e depois sem autenticacao adicional, est apto a aceder a recursos per a sonalizados por outro Web site. SAML activa o Web SSO atrav s da comunicacao e de uma assertacao de autenticacao do primeiro site para o segundo, que se conar no primeiro site pode escolher fazer o logon do utilizador como se este se tivesse autenticado directamente. O modelo e descrito na gura seguinte. Um utilizador autentica-se perante uma entidade que e reconhecida pela segunda identidade e lhe d o acesso correspondente. a As assertacoes podem ser usadas com mensagens SOAP para transportar informacoes sobre entidade e seguranca entre actores em transaccoes de servicos Web. O Perl de Testemunhos SAML (SAML Token Prole) da OASIS WS-Security TC especica como as assertacoes SAML devem ser usadas para este efeito. SAML e denido em termos de assertacoes, protocolos, ligacoes e pers. Assertacoes: Uma assertacao e o pacote de informacao que fornece uma ou 46

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO

Figura 4.3: Modelo de autenticacao SAML mais denicoes declaradas por uma autoridade SAML. SAML dene tr s tipos e diferentes de declaracoes de assertacao que podem ser criadas por uma autoridade SAML. Autenticacao (Authentication): O sujeito em quest o foi autenticado de a uma certa forma numa certa altura. Este tipo de declaracao e tipicamente criado por uma autoridade SAML chamada provedor de identidade, que e respons vel pela autenticacao de utilizadores e manter o controlo de outras a informacoes acerca deles. Atributo (Atribute): O sujeito em quest o e associado aos atributos fornecia dos. Decis o de Autorizacao (Authorization Decision): Um pedido para pera mitir que o sujeito em quest o tenha acesso a um determinado recurso e a permitido ou recusado.

4.1.1

Protocolos

SAML dene um n mero de protocolos de pedido/resposta que permitem aos u provedores de servicos: 47

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO Pedir a uma autoridade SAML uma ou mais assertacoes. Pedir que um provedor de identicacao autentique um utilizador e devolva a assertacao correspondente. Pedir que um identicador de nome seja registado. Pedir que o uso de um identicador termine. Devolver uma mensagem de protocolo que foi pedida atrav s de um artee facto. Pedir um logout quase simult neo de todas as sess es relacionadas. a o Pedir um mapeamento do identicador de nomes.

4.1.2

Ligacoes (Bindings)

Mapeamentos de trocas de mensagens de pedido-resposta SAML em mensagens padr o ou protocolos de comunicacao s o denominados por SAML Protocol Binda a ings. Por exemplo, SAML SOAP Binding dene como mensagens de protocolo SAML podem ser trocadas atrav s de mensagens SOAP, enquanto HTTP Redirect e Binding dene como passar mensagens de protocolo atrav s do redireccionamento e de HTTP.

4.1.3

Pers

Geralmente, um perl em SAML dene restricoes ou extens es que facilitam o o uso de SAML para uma determinada aplicacao. O perl Web SSO (Web SSO Prole) dene o uso do protocolo SAML Authentication Request/Response juntamente com diferentes combinacoes de HTTP Redirect, HTTP POST, HTTP Artifact e SOAP bindings. Outro tipo de perl SAML e um perl de atributo. SAML dene uma s rie de e de pers de atributo para fornecer regras especicas de interpretacao de atributos em assertacoes de atributos SAML (SAML attribute assertions). Um exemplo e o perl X500/LDAP, descrevendo como transportar atributos X.500/LDAP dentro de assertacoes de atributos SAML. 48

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO

4.1.4

SAML e a RTS

A Figura 4.3 est de certa forma relacionada com a Figura 4.2. O fornecedor de a identidade e a IS, e o fornecedor de servicos e a RTS. A mensagem que contem a assertacao e passada atrav s de um token, que e o Cart o de Cidad o. e a a

4.2

Tecnologias Abordadas

Foi abordado um conjunto de tecnologias normalmente utilizadas em sites Web capazes de lidar com a biblioteca PKCS#11. Entre elas encontram-se JavaScript, applets Java e ActiveX. Como para o