Você está na página 1de 85

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 jri
presidente Prof. Dr. Jos Lus Guimares Oliveira
professor associado da Universidade de Aveiro

Prof. Dr. Carlos Nuno da Cruz Ribeiro


professor auxiliar do Instituto Superior Tcnico da Universidade Tcnica de Lisboa

Prof. Dr. Andr Ventura Marnoto Zquete


professor auxiliar da Universidade de Aveiro

Prof. Dr. Joo Paulo Trigueiros da Silva Cunha


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

Indice
1 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

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

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

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

Conclus es o

iii

Lista de Figuras
2.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 Tabelas
2.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. 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/

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.2
2.2.1

Conceitos B sicos a
Assinaturas 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 Relacionados


Este 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 a
2 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 Activo


Neste 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 uso do c digo activo e necess rio usar a o a biblioteca eID Lib, interessam tecnologias que permitam o uso de bibliotecas din micas do sistema. a

4.2.1

JavaScript

Esta linguagem por si s n o suporta as funcionalidades necess rias para lidar com o a a certicados nem com assinaturas digitais. Al m disso n o consegue ter acesso a e a certicados instalados no browser o que iria complicar a validacao de cadeias de certicacao, ou o acesso a chaveiros protegidos. O acesso ao sistema local de cheiros tamb m e bastante limitado, caso se quisessem adicionar funcionalidades e para ler certicados a partir de cheiros, fora do cart o, n o seria possvel ter a a acesso a eles. O Firefox dene um objecto em JavaScript para permitir que as paginas Web possam aceder a certos servicos criptogr cos 1 Estes servicos est o balanceados a a entre a funcionalidade necess ria de uma p gina e a proteccao dos utilizadores de a a software maligno. Os servicos fornecidos permitem a geracao de pedidos de certi cados, importacao de certicados de utilizadores, geracao de n meros aleat rios u o e assinatura de texto. Devido a raz es de seguranca, o JavaScript tamb m n o pode carregar bibo e a liotecas din micas (salvo raras excepcoes como e o caso de carregar um m dulo a o PKCS#11, mas a o browser imp e as limitacoes necess rias) para proteger os o a utilizadores. Desta forma o acesso ao bloco de notas do Cart o de Cidad o estaria a a impedido, impossibilitando que as credenciais dos prossionais fossem usadas.
1 https://developer.mozilla.org/en/JavaScript

crypto

49

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO O uso de JavaScript tamb m n o e uniforme entre os browsers. Funcoes que e a s o permitidas num browser podem n o ser permitidas noutro, o que implica uma a a adaptacao do c digo a cada tipo de browser que se quer utilizar. A qualquer o altura pode ser lancada uma nova vers o de um browser que considera que uma a determinada funcao de JavaScript tem problemas de seguranca e impedir o seu funcionamento, implicando uma nova restruturacao no c digo de quem fornece a o aplicacao. Isso torna-se inc modo tanto para os utilizadores, que t m que esperar o e por uma actualizacao da aplicacao, como para quem a desenvolve. Em vers es mais antigas dos browsers, era possvel aceder ao sistema de o cheiros local usando JavaScript para ler cheiros, mas com a evolucao dos browsers e devido a quest es de seguranca, esses privil gios foram terminados. o e Uma maneira de resolver esta limitacao usando a tecnologia JavaScript seria in troduzir um campo num formul rio em que o utilizador colocasse as credenciais a manualmente, usando um m todo que validasse a autenticidade dessas mesmas e credenciais embutido no c digo. o Apesar das limitacoes do JavaScript, esta tecnologia pode ser considerada (por exemplo como complemento a outra), pois mesmo sem conter todos os requisitos necess rios para a concretizacao dos objectivos propostos, fornece bastantes a mecanismos de suporte para o uso de certicados em smart cards. Mesmo assim, n o traz vantagens sobre o uso de um m dulo de seguranca cara o regado no browser, pois n o permite que sejam chamadas funcoes de bibliotecas a do sistema, por quest es de seguranca. o

4.2.2

Java Applets

As applets java t m a vantagem de funcionar em qualquer tipo de browser, ine dependentemente do sistema operativo onde se encontram. O acesso ao sistema de cheiros locais pode estar limitado nas denicoes de seguranca do JRE (Java Runtime Enviorment), mas isso pode ser redenido. Continuam a depender de outros m dulos para poder aceder aos certicados do cart o, como por exemplo o o a ` m dulo pteidpkcs11.dll para aceder as funcionalidades da PKCS#11 e o m dulo o o pteidlibj.dll para aceder ao bloco de notas do Cart o. a Em applets Java j e possvel carregar bibliotecas din micas, tal n o acontecia a a a com JavaScript. Neste caso, a poltica de seguranca e denida pela Java Virtual ` Machine. A partida, qualquer applet assinada tem permiss es para aceder ao o sistema de cheiros local se o browser conar no certicado que assinou a applet. Se a applet for assinada por um certicado no qual o browser n o cona, como por a 50

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO exemplo, um certicado auto assinado, e perguntado ao utilizador se este aceita conar na entidade que fornece aquela aplicacao. Uma applet em java pode usar qualquer biblioteca denida em Java. A linguagem Java fornece bibliotecas que simplicam o uso de m dulos PKCS#11 o ` permitindo efectuar o acesso a informacao contida num smart card de uma forma ` abstracta a biblioteca PKCS#11 usando wrapping. O m dulo PKCS#11 pode ser o carregado pela applet e depois podem ser usadas funcoes contidas na Java Cryp tography Architecture (JCA). O objectivo da JCA e fornecer mecanismos de assinatura de documentos, vericacao de assinaturas digitais e manipulacao de certicados. A JCA foi criada para permitir diferentes implementacoes de v rios servicos de diferentes criadores a de software. S o fornecidas classes e interfaces para lidar com chaves p blicas e privadas, a u certicados digitais, assinaturas de mensagens, vericacao de assinaturas, acesso a chaveiros protegidos e outros mecanismos. Estas classes e interfaces s o fornecia das pelos pacotes java.security e java.security.cert. Uma applet Java funciona em qualquer sistema operativo que possua o Java Runtime Enviorment. Al m disso, para correr as applets em browsers e necess rio e a ter um plug-in instalado. Em alternativa, existe a possibilidade de correr a applet fora de um browser, usando a tecnologia JNLP. Para isso e criado um cheiro JNLP que pode ser descarregado, e contem o caminho para a localizacao da applet e as bibliotecas do qual a applet depende, no seu c digo. o Ao executar um cheiro JNLP, e lancada uma aplicacao fornecida com o JRE chamada Java Web Start. Esta tecnologia permite correr uma applet fora de um browser como se fosse uma aplicacao que estivesse a correr na maquina local. Tem a vantagem de ser independente do browser ou do sistema operativo e tem a capacidade de aceder ao sistema local de cheiros e de carregar bibliotecas din micas do sistema ou exteriores ao sistema, se estiver assinado por uma entia dade de conanca. O facto de um browser ser incapaz de lidar com a PKCS#11, como e o caso do Opera (at a vers o 10 n o suporta a instalacao de m dulos e ` a a o ` PKCS#11), n o impede que a applet a use, devido a sua independ ncia. a e As desvantagens s o que necessita do JRE instalado, em certos casos pode ser a necess rio redenir permiss es para a sua execucao, e se tiver que carregar muitos a o cheiros que existem no servidor pode consumir algum tempo sempre que e feito o download desses cheiros. A sua aplicacao na RTS iria implicar uma nova implementacao da interface 51

4. ESTUDO DA SOLUCAO COM CODIGO ACTIVO ` dos prossionais adaptada a applet. Iria implicar tamb m a exist ncia de c digo e e o do lado do servidor para que as credenciais dos prossionais podessem ser exploradas, o que tornaria a sua implementacao de alguma forma complexa.

4.2.3

ActiveX

` O ActiveX a partida e uma solucao v lida, mas est limitada ao Internet Explorer, a a consequentemente, a sistemas Microsoft Windows. Apesar de outros browsers suportarem controles ActiveX, esta tecnologia s funciona em ambiente Microsoft o Windows. Foi por esta raz o que esta solucao foi tamb m colocada de parte. a e

4.2.4

Macromedia Flash

Esta tecnologia n o permite o uso de certicados ou assinaturas digitais, e tamb m a e n o pode aceder ao sistema de cheiros local ou ao Bloco de Notas do Cart o de a a Cidad o. a

4.3

Avaliacao

Dadas as v rias tecnologias analisadas, e os requisitos para o sistema sendo a sima plicidade entre a interaccao do prossional com o portal, independentemente do sistema operativo ou do browser, a melhor solucao de c digo activo seria o uso da o applet, pois permite uma maior exibilidade entre as plataformas e a manipulacao da informacao contida no Cart o de Cidad o. a a No entanto a sua implementacao n o foi concretizada, porque esta solucao a implica c digo activo do lado do cliente e do lado do servidor. Mesmo assim, e o uma solucao com bastante potencialidade.

52

Captulo 5 Estudo da Solucao sem C digo o Activo


Neste captulo estuda-se um m todo que coloca um certicado contido no Bloco e de Notas do Cart o de Cidad o no browser do prossional usando um wrapper. a a Esse certicado cont m extens es relativas ao cargo do prossional, denidas e o da mesma maneira que na arquitectura concebida pelo H. Gomes, ou seja, com um OID (Object ID) relativo ao cargo desempenhado por um determinado prossional. Na Figura 5.1 e descrito o modo como e feita a emiss o de um certicado por a uma Instituicao de Sa de. Esse certicado ca guardado no Bloco de Notas do u Cart o de Cidad o e usa o mesmo par de chaves do certicado de autenticacao do a a Cart o de Cidad o. a a

5.1

Wrapping do Cart o de Cidad o a a

Este wrapper funciona como um proxy entre o browser e o m dulo PKCS#11 o fornecido no software do middleware do Cart o de Cidad o. a a Um dos seus objectivos iniciais era construir um Log para perceber quais eram as funcoes do m dulo PKCS#11 chamadas pelo browser e a partir da se perceber o como e que o browser lida com um m dulo PKCS#11. o O principal objectivo e acrescentar a funcionalidade para que possa ser lido um certicado contido no Bloco de Notas do Cart o de Cidad o que usa o par de a a chaves de autenticacao j existente no cart o, criando a ilus o ao browser de que a a a 53

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.1: Arquitectura se trata de outro par de chaves. Depois de perceber como e que o browser lida com a PKCS#11, procedeu` se a implementacao dos m todos necess rios para adicionar o certicado contido e a no bloco de notas do Cart o de Cidad o no browser. Na maior parte dos caa a sos, sempre que uma funcao do wrapper e invocada, e chamada a funcao corre spondente da PKCS#11 contida no modulo fornecido no middleware do Cart o a de Cidad o. Isto nem sempre acontece no caso das funcoes C GetFunctionList, a C GetAttributeValue e C FindObjectsInit, como vai ser explicado posteriormente.

5.1.1

Modo de Funcionamento

O wrapper actua entre o browser e o m dulo fornecido no middleware do Cart o o a es de Cidad o, como se pode ver na Fig. 5.2 fazendo o encaminhamento das funco a que o browser pede ao m dulo da PKCS#11. o A primeira funcao executada pelo browser e a C GetFunctionList, que faz o pedido ao m dulo da lista de funcoes e guarda os enderecos das funcoes nele o contidas. Esta funcao n o pode ser mapeada directamente, porque caso o fosse, a iria conter os enderecos das funcoes do m dulo pteidpkcs11.dll, e o que se quer o e que os enderecos obtidos pelo browser sejam os das funcoes do wrapper. S o assim se pode enviar a lista das funcoes chamadas pelo browser para um cheiro. O Log consiste numa lista de todas as funcoes invocadas pelo browser exacta mente pela mesma ordem. Foi atrav s da an lise desta lista que se percebeu quais e a eram os pedidos feitos pelo browser ao m dulo da PKCS#11. Depois de perceo 54

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.2: Interaccao Entre o Browser e o Cart o de Cidad o usando o Wrapper a a ber essa ordem e o que signica cada pedido facilmente se engana o browser fornecendo-lhe a informacao do novo certicado que se quer adicionar. Um m todo mais eciente seria em vez do uso do wrapper, apenas um m dulo e o que tivesse todas as funcionalidades da PKCS#11 e al m disso permitisse a leitura e de certicados do Bloco de Notas. Para a implementacao de um m dulo desses o seria necess ria a colaboracao da entidade respons vel pela producao do software a a do middleware do Cart o de Cidad o. Nessa solucao podiam ser eliminadas as a a depend ncias da biblioteca din mica do OpenSSL. e a

5.1.2

Descricao dos Componentes Utilizados

O wrapper usa a API do OpenSSL, para poder extrair certos campos do certi cado que est no formato PEM usando funcoes especcas relativas ao que e pea dido. Por exemplo, para passar um certicado no formato PEM para uma estrutura de certicado X509 [12], e possvel usar a funcao PEM read bio X509 fornecida pela API do OpenSSL. A depend ncia da biblioteca din mica do OpenSSL n o e a e a a melhor ideia, e deveria ter sido evitada, o custo seria reectido na implementacao do wrapper, mas a sua instalacao seria mais simples, diminuindo a lista de de pend ncias. e Por uma quest o de facilidade na implementacao, as raz es principais pelas a o quais foram usadas funcoes do OpenSSL foram a exist ncia de estruturas de cer e ticados X.509, e funcoes uteis que manipulam esses dados. O uso do formato PEM foi ponderado, porque tamb m traz alguns custos e alguns benefcios. Um e dos custos e o espaco que ocupa em relacao ao espaco ocupado por um certicado no formato DER. 55

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO Um certicado no formato PEM ocupa cerca de quatro tercos do tamanho de um certicado no formato DER. De qualquer maneira seria quase impossvel incluir dois certicados em formato DER incluindo algo que permitisse ver a separacao entre os dois no espaco disponvel do cart o. a Um utilizador pode ver onde comeca e termina um certicado no formato PEM e facilmente copi -lo para dentro ou para fora do Bloco de Notas usando a apenas a aplicacao fornecida pelo software do middleware do Cart o de Cidad o. a a Caso seja um prossional que pertence a v rias Instituicoes de Sa de, e possua a u v rios certicados cada um correspondente a uma Instituicao, pode geri-los apea nas com um cheiro de texto, copiando para o cart o o certicado que precisa a quando se quer autenticar na a RTS. O wrapper tamb m usa a biblioteca din mica pteidlib.dll para aceder ao bloco e a de notas do Cart o de Cidad o e extrair o certicado l existente. a a a Como n o podia deixar de ser, o wrapper tamb m usa a API da PKCS#11 a e que faz a interaccao com o browser, e com o m dulo fornecido pelo Cart o de o a Cidad o, para poder manipular as estruturas dos dados pedidos pelo browser que a s o modicados no wrapper, para enganar o browser. a

5.1.3

O M dulo PKCS#11 o

A PKCS#11 e composta por um conjunto de 68 funcoes denidas conforme a norma em [4]. Dessas funcoes apenas 31 foram implementadas no middleware do Cart o de a a Cidad o, descrito na seccao 2.4. A funcao C CreateObjects n o foi implemena tada, o que limitou o uso dos novos objectos ao nvel do wrapper. Uma solucao melhor seria a criacao de um novo par de chaves no cart o e o uso desse par de a chaves no certicado adicionado. Como tal n o e possvel, os novos objectos s o a a simulados pelo wrapper. Quatro das principais funcoes alteradas no wrapper para fazer a interaccao e com o browser s o a C GetAttributeValue, que obt m um valor para um dea terminado atributo de um determinado objecto. As outras tr s funcoes s o a e a C FindObjectsInit que inicia uma pesquisa por um objecto de um determinado tipo, e seguida da funcao C Findobjects que devolve o handle para o objecto caso ele seja encontrado, assim como o n mero de objectos encontrados, e assim que a u busca por novos objectos termina e chamada a funcao C FindObjectsFinal. 56

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.3: Caixa de di logo de insercao de PIN a

5.1.4

Interaccao entre o browser Firefox e a PKCS#11

Nem todas as funcoes chamadas pelo browser devolvem o c digo CKR OK (0). o S o elas a C WaitForSlotEvent, que devolve o c digo 8, que corresponde ao erro a o CKR NO EVENT e C GetAttributeValue, que devolve o c digo 18 e corresponde o ao erro CKR ATTRIBUTE TYPE INVALID. Estes c digos, apesar de n o serem o a 0, n o signicam que tenha ocorrido algum erro. a a No caso do CKR NO EVENT, signica que nenhum cart o foi retirado ou inserido durante a vericacao. No caso do CKR ATTRIBUTE TYPE INVALID, acontece porque foi declarado um atributo que n o e suportado pelo m dulo ou o a o objecto n o possui o tal atributo. a a A funcao C Login n o aparece porque se pode fazer um C Sign sem se fazer um Login, a biblioteca PKCS#11 e que decide o que faz, se rejeita ou se aceita o PIN atrav s de uma interface pr pria (Figura 5.3). O browser arrisca, n o faz e o a Login, e a biblioteca apresenta a caixa de di logo do PIN. a Para contextualizar, e resumidamente descrita a interface da funcao C GetAttributeValue. Esta leva como par metros de entrada um handle para a sess o (hSession), um a a handle para o objecto (hObject), um ponteiro para um template com tipo de atributo obtido (pTemplate), e o n mero de atributos no template (ulCount). Esse temu plate e composto por um ou mais atributos. Cada atributo tem um tipo denido, um valor, e o tamanho ocupado pelo valor. A funcao CC GetAttributeValue e sempre executada duas vezes seguidas pelo browser, sendo que na primeira apenas e devolvido o tamanho que o valor do atributo ocupa, para que o browser reserve o espaco necess rio em mem ria. Por a o isso, na primeira invocacao, o valor do campo pValue do atributo vai com o valor NULL e na segunda vez j vai com o valor da zona de mem ria reservada para a o 57

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO 0 1 2 3 17 128 129 130 256 257 258 288 CKA CKA CKA CKA CKA CKA CKA CKA CKA CKA CKA CKA CLASS: TOKEN: PRIVATE: LABEL: VALUE: CERTIFICATE TYPE: ISSUER: SERIAL NUMBER: KEY TYPE: SUBJECT: ID: MODULUS: CK OBJECT CLASS (CK ULONG) CK BBOOL CK BBOOL RFC2279 String Byte Array CK CERTIFICATE TYPE (CK ULONG) Byte Array Byte Array CK KEY TYPE (CK ULONG) Byte Array Byte Array Big Integer

Tabela 5.1: Alguns Atributos da Cryptoki

guardar os dados do atributo. Os v rios tipos de atributos detectados no log s o descritos na Tabela 5.1.4: a a A 1a coluna cont m o c digo do atributo em formato decimal, a 2a coluna e o cont m a designacao do tipo de atributo e a terceira coluna cont m o tipo de e e dados.

5.2

Exploracao de Tokens via PKCS#11 com o Fire fox

O browser Firefox possui a funcionalidade de adicionar m dulos de seguranca. o E assim que e adicionado o modulo do wrapper ao browser. Para adicionar um m dulo ao Firefox deve-se abrir o menu Ferramentas, seleccionar Opcoes, a o aba de Cifra e Dispositivos de Seguranca, Figura 5.4. Depois seleciona-se o bot o Carregar, Figura 5.5, e aparece uma nova caixa de di logo, Figura 5.6, a a onde se escolhe o nome do m dulo e o caminho para o cheiro. o O Firefox tamb m permite importar certicados PKCS#12, cuja chave prie vada e guardada num cheiro. Como e impossvel extrair a chave privada contida no Cart o de Cidad o para um cheiro, essa opcao cou logo excluida, e se se a a optasse por usar um par de chaves gerado apenas com o prop sito de autenticar o um prossional na RTS, o Cart o de Cidad o deixava de ser preciso, podendo o a a 58

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.4: Adicionar um M dulo - Parte 1 o

Figura 5.5: Adicionar um M dulo - Parte 2 o

59

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.6: Adicionar um M dulo - Parte 3 o certicado ser guardado num Token. Mesmo que se quisesse aproveitar o Cart o de Cidad o apenas para guardar a a a informacao do certicado e a sua chave privada isso tamb m n o seria possvel e a devido ao escasso espaco nele disponvel. Foram estas as raz es principais que o levaram por optar pela solucao do uso da PKCS#11 que consiste em fornecer ao browser a informacao sobre um novo certicado existente no cart o da forma a a seguir descrita. O processo utilizado pelo Firefox para procurar certicados em tokens que usam a PKCS#11 muito resumidamente consiste no seguinte: Procurar um token disponvel. Iniciar uma sess o nesse token, caso tenha sido encontrado um. a Procura por objectos do tipo Certicado. Verica o label dos certicados e se t m o atributo token denido como e TRUE. Obt m o valor do atributo CKA VALUE de cada certicado. e Obt m o valor de todos atributos de cada certicado. e Verica o valor do atributo CKA ID de cada certicado e efectua uma pesquisa por objectos do tipo Chave Privada com o mesmo valor do atributo CKA ID. Os objectos existentes no cart o s o de 3 tipos diferentes, ou s o do tipo Pria a a vate Key, ou do tipo Certicate, ou do tipo Public Key. Podem haver objectos de outros tipos, como por exemplo do tipo Data, mas apenas estes descritos anteriormente na seccao 2.4, na Tabela 2.4.3, existem no cart o. a 60

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO CKA CKA CKA CKA CKA CKA CKA CKA CKA CLASS: TOKEN: LABEL: CERTIFICATE TYPE: ID: VALUE: ISSUER: SERIAL NUMBER: SUBJECT: A classe do objecto Se o objecto e token ou objecto de sess o a Cont m o nome designado ao certicado e De que tipo se trata O ID do objecto O valor do certicado (o seu conte do) u A entidade emissora do certicado O n mero de s rie u e Informacao sobre o sujeito do certicado

Tabela 5.2: Atributos de um Certicado

Todos os objectos do tipo Certicado que t m um objecto do tipo Chave e Privada associado s o adicionados ao browser e e possvel ver os seus atributos a do seguinte modo: Ferramentas Opcoes Avancado Ver certicados Os seus certica dos No entanto isto n o signica que seja possvel us -los para efectuar uma a a ligacao SSL. Se 2 certicados partilharem a mesma chave privada, ou seja, se o handle do objecto for o mesmo, apenas aparece um certicado disponvel quando a escolha de certicados e solicitada pelo browser. O Cart o de Cidad o possui alguns object handles denidos no m dulo fornecido a a o por ele, relativos aos certicados nele contidos, chaves privadas e chaves p blicas u correspondentes. Tiveram que ser criados 2 objectos novos, um correspondente ao novo certi` cado, e outro correspondente a sua chave privada, que funcionam ao nvel do wrapper. Um objecto do tipo certicado deve incluir os atributos indicados na Tabela 5.2. O atributo CKA ID do certicado deve ter o mesmo valor que o atributo CKA ID da chave privada correspondente para efeitos de pesquisa de objecto. Ora, caso seja detectada a pesquisa por um objecto do tipo PRIVATE KEY cujo valor de CKA ID e igual ao valor de CKA ID do novo certicado, pode-se devolver um handle para a nova chave privada, que n o e mais do que a chave a privada do certicado de autenticacao mascarada. Os novos objectos oram denidos como 101 para o Certicado e 102 para a chave privada. Na verdade, o unico objecto mesmo criado e o certicado, porque 61

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.7: Gestor de Certicados do Firefox a chave privada e a mesma, apenas teve que se denir um handle diferente para ela para que o browser detectasse uma chave privada diferente e permitisse que o novo certicado pudesse ser utilizado. Caso esse handle para a chave privada n o fosse criado, o que acontecia era que se poderia ver que o novo certicado se a encontrava instalado mas n o era possvel utiliz -lo para iniciar uma sess o segura a a a com um servidor. Na Figura 5.7 pode-se ver o novo certicado instalado no browser Firefox. Agora e possvel aceder ao portal e efectuar a autenticacao usando o certi ` cado da RTS. A Figura 5.8 mostra os dois certicados a escolha.

62

5. ESTUDO DA SOLUCAO SEM CODIGO ACTIVO

Figura 5.8: Seleccao de Certicado

63

Captulo 6 Arquitectura Proposta


Neste captulo prop e-se uma arquitectura para a autenticacao de prossionais que o ` pertencem a RTS. Esta arquitectura baseia-se nos pressupostos denidos pelo H. Gomes, ou seja, na utilizacao de pares de chaves assim tricas e certicados digi e tais de chave p blica enquadrados numa infra-estrutura de chave p blica (Public u u Key Infrastructure, PKI). Ao longo do texto e feita uma comparacao com o que tinha sido feito pelo H. Gomes bem como a sua adaptacao para o uso do Cart o a do Cidad o a

6.1

Apresentacao

Cada Instituicao de Sa de (IS), e respons vel pela emiss o e gest o de certicados u a a a para as suas entidades - servicos/servidores e Prossionais. A RTS deve incluir os certicados das Entidades Certicadoras (EC) das IS emissoras na sua lista de entidades de conanca, permitindo que um Prossional que possua um certicado v lido tenha acesso ao portal da RTS. a Em vez dos smart cards utilizados na arquitectura denida pelo H. Gomes, o transporte e armazenamento das credenciais dos prossionais e feito com o Cart o a de Cidad o, usando um certicado emitido pela IS a que pertence o prossional, a e que se serve do par de chaves do certicado de autenticacao contido no cart o. a Este cart o, tal como um smart card comum, permite um nvel de autenticacao a forte (posse e senha), sendo necess ria a introducao de um c digo PIN quando e a o feita a autenticacao perante o portal da RTS. Como o par de chaves utilizado na autenticacao e o que vem com o certicado 65

6. ARQUITECTURA PROPOSTA do Cart o de Cidad o, a sua renovacao est fora de quest o, pois o cart o n o a a a a a a permite a criacao de novos pares de chaves. Sendo assim, n o faz sentido usar 2 a certicados, um para renovacao de chaves e outro para a autenticacao. E usado um unico certicado de autenticacao emitido pela IS. Este certicado tem a funcao de autenticar um determinado Prossional na RTS, indicando o cargo desempenhado por esse mesmo Prossional. Deve ser usada uma CRL usada na validacao dos certicados, pois estes ter o um tempo de vida relativamente longo. a A emiss o teria que ser validada por um funcion rio respons vel, que iria vericar a a a se um determinado funcion rio est apto a executar o cargo pretendido no pedido a a de certicado. Em alternativa, existe a opcao de usar certicados de curta duracao, elimi nando a exist ncia de CRLs, mas obrigando a que os prossionais facam uma e renovacao de certicados mais frequente, tal como acontecia na denicao pro posta pelo H. Gomes. Isso iria libertar a carga do sistema, mas traria outros custos, como por exemplo a exist ncia de uma lista de roles disponveis para cada Prose sional mapeada ao certicado do Cart o de Cidad o do Prossional. A sua gest o a a a ` caberia as IS. Isto n o eliminaria a exist ncia de um funcion rio respons vel pela a e a a gest o de permiss es das funcoes dos Prossionais. a o Tal como na arquitectura de denida pelo H. Gomes, no modelo de conanca utilizado, cada entidade tem como ancora de conanca a entidade certicadora de raiz da instituicao a que est vinculada. a O Cart o de Cidad o n o possui espaco disponvel para guardar as cadeias de a a a certicacao. Estas devem ser obtidas online e instaladas manualmente no browser ` utilizado para aceder a RTS, para que a validacao das cadeias de certicacao seja realizada e consequentemente a autenticacao do Prossional.

6.2

Certicados Digitais

O formato dos certicados digitais a utilizar na autenticacao entre as entidades nos ` acessos a RTS obedece ao perl de certicados X.509 para utilizacao na Internet, recomendado pelo IETF no RFC 3280 [13]

6.2.1

Entidades com Certicados

Os certicados digitais de chave p blica utilizados, servem para autenticar as enu tidades que comunicam no ambito RTS. Estas entidades podem ser de dois tipos, 66

6. ARQUITECTURA PROPOSTA Utilizadores ou Servidores/Servicos.

6.2.2

Tipos de Certicados

Os tipos de certicados para Servidores/Servicos t m como nalidade a autenticacao. e Os certicados dos Prossionais, al m de tamb m servirem para a autenticacao, e e t m a funcao de fornecer ao Portal a informacao sobre o cargo desempenhado pelo e Prossional. ` Ir o haver dois tipos de certicados para autenticacao no acesso a RTS, um a tipo para os Prossionais e outro tipo para os Servidores/Servicos.

6.2.3

Formato dos Certicados

Os campos obrigat rios que devem ser denidos nos certicados s o: o a Sujeito (Subject): Contem o nome da entidade para quem o certicado foi emitido e da IS a que pertence. A informacao e especicada usando etiquetas (tags), em que CN indica o nome do Prossional, O ou DN identicam a IS. N o conv m usar mais do que as etiquetas necess rias para a e a que o tamanho do certicado n o exceda os 1000 bytes para os certicados a dos Prossionais. Emissor (Issuer): Identicacao da EC que emitiu o certicado. a Validade: Intervalo de tempo em que o certicado e v lido. Extens o EKU: Aqui e denida a nalidade do certicado. No caso dos a certicados dos Prossionais, este campo deve conter um OID (Object Identier) de Autenticacao de Cliente e outro de identicacao do perl do Pros sional na IS a que est vinculado. No caso dos certicados de Servidores/Servicos, a devem ser denidos os OIDs Autenticacao de Cliente e Autenticacao de Servidor. CRL Distribution Point (CDP): Aqui e denido o endereco electr nico do o local onde e emitida a lista de certicados revogados (CRL). 67

6. ARQUITECTURA PROPOSTA

6.2.4

Gest o de Certicados a

A gest o e feita por cada IS, que sendo instituicoes aut nomas, devem fazer cada a o uma a pr pria gest o das listas de certicados revogados. Se um certicado for o a v lido e n o estiver na lista de certicados revogados emitida pela IS que emitiu a a esse certicado, ent o ele e aceite pela RTS. a Um prossional que esteja vinculado a mais do que uma Instituicao de Sa de u pode ter mais do que um certicado, mas o cart o apenas permite conter um cera ` ticado nele guardado, devido a limitacao do espaco. Nesse caso, a gest o dos a certicados deve ser feita pelos pr prios Prossionais. Devem manter os seus o certicados guardados noutro local, e sempre que quiserem usar um determinado certicado, podem usar a aplicacao fornecida com o Cart o de Cidad o para o a a copiar para o bloco de notas. Sempre que e feita alguma alteracao no Bloco de Notas e obrigat rio introduzir o c digo PIN. o o

6.2.5

Emiss o/Renovacao a

Em caso de perda do Cart o de Cidad o ou danos no chip, que impecam o seu a a funcionamento, e necess rio emitir um cart o novo, que vem com um novo par a a de chaves. Nesse caso a IS deve emitir um novo certicado com o novo par de chaves. Caso haja alguma alteracao no perl do Prossional, tamb m e necess ria e a a emiss o de um novo certicado. a O pedido de certicado (CSR) tem que ser assinado com a chave privada do certicado de autenticacao do Cart o de Cidad o do Prossional. Isso implica a a a presenca do pr prio, pois e necess rio introduzir o c digo PIN. o a o O pedido de certicado pode ser feito perante a Instituicao de Sa de, ou us u ando um mecanismo online, que pode ser concebido para efectuar esse pedido. No pedido o prossional deve introduzir os dados obrigat rios denidos em 6.2.3 o e esperar que lhe seja enviado o certicado.

6.2.6

Armazenamento

O Prossional, depois de obter o seu certicado deve usar a aplicacao fornecida com o Cart o de Cidad o para aceder ao Bloco de Notas e a inserir o seu certia a cado. ` N o cabe a RTS impor regras. A emiss o dos certicados aos prossionais, a a 68

6. ARQUITECTURA PROPOSTA e feita pelas Instituicoes de Sa de, mas para que o Cart o do Cidad o possa ser u a a usado como meio de autenticacao, as IS devem cumprir alguns requisitos como por exemplo minimizar a informacao contida no certicado para que este n o a exceda os 1000 bytes.

6.2.7

Cadeias de Certicacao

Tanto a RTS como as IS t m as suas pr prias cadeias de certicacao. No entanto, e o existe uma relacao de conanca entre a RTS e a IS. Para a RTS, existe uma EC raiz que emite certicados para a(s) EC emissora(s) da RTS, que por sua vez emitem os certicados para o Portal e Servicos. Para as IS, o processo e semelhante, existe uma IS raiz que emite certicados para a(s) EC emissora(s) das IS respectivas, e estas emitem certicados aos Prossionais que t m o direito de lhes aceder atrav s do Portal da RTS. e e O Portal da RTS deve conar nas EC raiz das IS que colaboram com a RTS, ` para que a autenticacao de cada Prossional pertencente a IS colaboradora seja validada. As entidades da RTS e da IS que comunicam entre si devem ter na sua lista de EC de conanca as EC raiz da entidade com quem efectuam a ligacao SSL. ` Devido as limitacoes do Cart o de Cidad o, e impossvel guardar no cart o a a a a cadeia de certicacao do certicado do Prossional. Por essa raz o, a RTS e a a IS devem fornecer os certicados da EC emissora e raiz da IS e da RTS, para que estes possam ser instalados no browser, pois caso vericacao da cadeia de certicacao n o tenha sucesso, a autenticacao falha. a A Figura 6.1 apresenta a hierarquia das Entidades Certicadoras da IS e da RTS respectivamente.

6.3

Geracao de um Pedido de Certicado

Devido ao espaco limitado (1000 Bytes) e a impossibilidade de criar novos pares de chaves no cart o, que e uma desvantagem em relacao aos smart cards normais, a optou-se pela reutilizacao da chave privada de autenticacao j nele existente. a O cart o possui dois pares de chaves, o de Autenticacao e o de Assinatura [7]. a 69

6. ARQUITECTURA PROPOSTA

Figura 6.1: Cadeias de Certicacao: IS - RTS

O par de chaves escolhido para ser reutilizado foi o de Autenticacao. Ap s uma modicacao no c digo do OpenSSL, e possvel emitir certicados o o que usam o par de chaves de autenticacao do Cart o de Cidad o usando a ferra a a menta de criacao de pedidos de certicados fornecida por esta biblioteca. Dene-se um cheiro de conguracao do OpenSSL que contem as extens es o com a informacao do cargo do prossional. E preciso criar um par de chaves num cheiro, cujo o unico efeito e permitir que o OpenSSL reserve internamente mem ria para a chave p blica no certicado o u criado, que depois e substituida pela chave p blica do Cart o de Cidad o, sem que u a a seja gerado um par novo no acto de criacao, assumindo que o dono do certicado j tem a chave privada em seu poder, como e o caso. a E gerado um cheiro no formato PEM que cont m o pedido de certicado. e ` Este pedido e enviado a Entidade Certicadora. A entidade certicadora est congurada para poder emitir certicados com a extens es consoante o cargo do funcion rio que fez o pedido. o a E executado o comando que processa a emiss o do certicado requerido, e a este e criado e fornecido ao prossional que o requisitou. Esse certicado vai num cheiro PEM, cujo conte do pode ser copiado para u o bloco de notas do Cart o de Cidad o, usando a aplicacao fornecida com o mida a 70

6. ARQUITECTURA PROPOSTA dleware do Cart o de Cidad o. a a

6.4

Processo de Autenticacao

O processo de autenticacao na pr tica apenas requer que um determinado pros a sional possua um certicado v lido no Cart o de Cidad o. E importante referir a a a que o processo de autenticacao n o e exclusivo apenas ao Cart o de Cidad o. E a a a possvel usar outro certicado contido num smart card ou token USB, desde que tenha sido emitido por uma IS colaboradora com a RTS. Quando e feito o acesso ao portal, o browser pede para que seja escolhido um certicado, o Prossional escolhe o certicado adequado, e se este for v lido, a e iniciada uma sess o SSL entre o Prossional e o Portal da RTS, sendo assim a concluido o processo de autenticacao.

71

Captulo 7 Avaliacao
Neste captulo e efectuada a avaliacao das funcionalidades implementadas. O objectivo principal era pegar numa infra-estrutura de chave p blica existente e u adapt -la ao uso do cart o de cidad o. a a a

7.1

Arquitectura Avaliada

O Cart o de Cidad o n o foi concebido para ser usado na arquitectura existente, a a a por isso tiveram que ser feitas algumas alteracoes. Essas alteracoes foram feitas em funcao dos recursos disponibilizados pelo Cart o de Cidad o. a a Foram analisadas v rias solucoes para a maneira como as credenciais dos a prossionais fossem armazenadas. A solucao escolhida foi guardar um certi cado no espaco do Bloco de Notas do Cart o de Cidad o usando o mesmo par de a a o fornecido com o cart o. Foi tamb m chaves usado pelo certicado de autenticaca a e considerada a hip tese de guardar o certicado fora do cart o, com a informacao o a ` para a sua localizacao guardado no seu Bloco de Notas. A partida, a primeira opcao e suciente, porque e possvel criar um certicado apenas com informacao necess ria que caiba no espaco disponvel do Bloco de Notas. a E usado apenas um certicado e n o dois, como anteriormente. Esse certia cado serve-se do par de chaves de autenticacao existente no Cart o de Cidad o, e a a o seu pedido necessita da exist ncia do Cart o de Cidad o no acto em que e exee a a cutado. O pedido tem que ser assinado com a chave privada do Cart o de Cidad o, a a e para que a operacao de assinatura seja concluida, o seu dono tem que introduzir o c digo PIN. Isto impede que alguem que n o conheca o PIN e consiga obter a o a 73

7. AVALIACAO posse de um cart o faca pedidos em nome de outro. a Como a chave privada est contida no cart o para o qual foi pedido o certia a cado, n o e possvel usar um certicado emitido para um cart o noutro cart o a a a diferente. Seria possvel copiar o certicado pois ele encontra-se numa zona p blica, capaz de ser visualizada por qualquer individuo que tenha acesso fsico u ao cart o. A sua tentativa de utilizacao num cart o diferente iria falhar porque a a a ` chave privada n o iria corresponder a chave p blica contida no cart o. a u a O pedido de certicados e feito usando o OpenSSL, com algumas alteracoes no seu c digo, permitindo o uso da PKCS#11, para poder aceder ao cart o e assio a nar o pedido com a chave privada do certicado de autenticacao contida no Cart o a de Cidad o. Esse c digo do OpenSSL foi alterado especicamente para a emiss o a o a de certicados que reutilizam o par de chaves de autenticacao existente no Cart o a de Cidad o. a Para aceder ao Bloco de Notas e conseguir que o browser lesse o certicado adicionado ao cart o, foi necess rio implementar um wrapper. Esse wrapper a a chama o m dulo da PKCS#11 fornecido com o Cart o de Cidad o, e permite ao o a a browser reconhecer o certicado contido no Bloco de Notas do Cart o de Cidad o. a a O wrapper foi apenas testado no browser Firefox, e concebido para satisfazer os pedidos efectuados por este browser. A sua utilizacao pelo Internet Explorer est sujeita a testes e provavelmente a iria implicar algumas alteracoes na sua implementacao, mas nada de muito sig nicativo. A implementacao pode ser melhorada, e uniformizada para funcionar com ambos os browsers mais populares. Seria mais eciente a concepcao de um m dulo que incluisse a PKCS#11 funcional para o Cart o de Cidad o e o acesso o a a ao Bloco de Notas para ler o certicado extra sem depender de outros m dulos, o tornando-o numa ferramenta mais robusta. Outra funcionalidade que foi referida mas n o chegou a ser implementada a foi a de ler certicados contidos em locais cujo o endereco electr nico estaria o guardado no Bloco de Notas. Isso iria permitir a leitura de v rios certicados e a n o os limitaria em tamanho. a

74

Captulo 8 Conclus es o
Neste documento foi apresentada uma adaptacao possvel de uma arquitectura de autenticacao j existente, em que eram usados smart cards gen ricos, ao uso do a e Cart o de Cidad o como meio de autenticar Prossionais na RTS. a a A solucao escolhida simplica em alguns aspectos a arquitectura previamente denida, como por exemplo o uso de apenas um certicado e a eliminacao de certicados cruzados, bastando que as Instituicoes de Sa de conem na EC raiz u da RTS e que a RTS cone nas EC emissoras das Instituicoes de Sa de. u Para os Prossionais, existe a vantagem de poder usar um cart o que j s o a a a obrigados a ter em sua posse. Para a RTS, tem a vantagem de n o requerer disa ` positivos extra que poderiam sair caros a organizacao. Como o Cart o de Cidad o e igual para todos, n o h o problema que existia a a a a com os smart cards nas quest es de incompatibilidades. O wrapper funciona com o qualquer Cart o de Cidad o uniformemente, e o mesmo acontece com a criacao a a de pedidos de certicados com o OpenSSL. A gest o dos Prossionais continua a ser feita com Active Directory sem sofrer a alteracoes, podendo manter a mesma estrutura j antes denida. a Este m todo de criacao de certicados com extens es aproveitando as chaves e o contidas no Cart o de Cidad o pode ter v rias aplicacoes, n o s a RTS, mas a a a a o ` qualquer tipo de infra-estrutura de chaves p blicas que obrigue a exist ncia de u e certicados com extens es. o

75

Bibliograa
[1] Cunha, J.P.S., Cruz, I., Oliveira, I., Pereira, A.S., Costa, C.T., Oliveira, A.M., Pereira, A.: The RTS Project: Promoting secure and effective clinical telematic communication within the Aveiro region. In: eHealth 2006 High Level Conf., Malaga, Spain (2006) [2] Gomes, H.: (2007) Autenticacao em Sistemas Telem ticos Biom dicos. U.A. a e

[3] AMA: Manual t cnico do middleware cart o de cidad o (June 2007) e a a [4] PKCS#11: Cryptographic Token Interface Standard, v2.20. RSALaboratories (2004) [5] Helder Gomes, Andr Z quete, J.P.S.C.: Arquitectura de autenticacao e u baseada em certicados para a rede telem tica de sa de (rts) a u [6] Andr Z quete, Helder Gomes, J.P.S.C.: Authentication architecture for e u region-wide e-health system with smartcards and a pki [7] AMA: Autenticacao com o cart o de cidad o (December 2008) a a [8] UCMA/UMIC/DGRN: O novo documento de identicacao dos cidad os a portugueses - nota informativa 1 (March 2007) [9] SEMA/UMIC/AMA: Especicacoes leitores base (June 2007) [10] Ali Sunyaev, Alexander Kaletsch, C.M., Krcmar, H.: Security analysis of the german electronic health cards peripheral parts (2009) [11] Andr Z quete, Helder Gomes, J.P.S.C.: Athentication of professionals in e u the rts e-health system (2008) [12] Housley, R., Ford, W., Polk, W., Solo, D.: Internet X.509 Public Key Infrastructure Certicate and CRL Prole. RFC 2459, IETF (January 1999) 77

BIBLIOGRAFIA [13] Housley, R., Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole. RFC 3280, IETF (April 2002)

78

Você também pode gostar