Uma Abordagem a Comunica c~ao Segura em Aplica c~oes Distribu das

Uma Abordagem a Comunicac~ao Segura

em Aplicac~oes Distribudas

Jose Carlos Rufino Amaro

Mestrado em Informatica

Area de Especializac~ao em Sistemas Distribudos, Comunicac~oes por Computador

e Arquitecturas de Computadores

Uma Abordagem a Comunicac~ao Segura

em Aplicac~oes Distribudas

Jose Carlos Rufino Amaro

Mestrado em Informatica

Area de Especializac~ao em Sistemas Distribudos, Comunicac~oes por Computador

e Arquitecturas de Computadores

Tese submetida a Universidade do Minho para obtenc~ao do grau de Mestre em

Informatica, elaborada sob a orientac~ao do Prof. Dr. Francisco Soares Moura.

Setembro 1997

(vers~ao revista de Junho de 1998)

thentication, Integrity and Sequencing | against replay attacks |) immediately above the Ber-keley sockets programming interface with which shares great resemblance, both in syntatic and in semantic ways. S3L allows migration, with a minimal eort, for non{secure Berkeley sockets based applications to a more secure operation mode where the exchange of security items (e.g.,

Nesta dissertac~ao apresenta{se o S3L, fundamentalmente uma API que fornece servicos de segu-ranca (Privacidade, Autenticac~ao, Integridade e Sequenciac~ao | contraataques{de{repetic~ao |)

imediatamente acima da interface de programac~ao dos sockets de Berkeley, preservando, tanto

quanto possvel, grandes semelhancas sintacticas e sem^anticas com o dito modelo de programac~ao. O S3L permite a migrac~ao, com um mnimo de esforco, de aplicac~oes n~ao seguras baseadas em

sockets de Berkeley, para um modo de operac~ao mais seguro, no qual a troca de informac~ao de

seguranca (e.g., chaves, algoritmos, numeros de sequ^encia, codigos de autenticac~ao, etc.) ocorre

de uma forma quase stateless. Desde que tenha lugar uma execuc~ao inicial do protocolo proposto

Skeyx (o qual permite a troca segura de chaves publicas de Die{Hellman n~ao certicadas) ent~ao, quaisquer contactos futuros entre duas entidades comunicantes poder~ao ocorrer, quer sobre pro-tocolos n~ao{orientados{a{conex~ao (IP/UDP) | incluindo a variante multiponto |, quer sobre

protocolosorientados{a{conex~ao(TCP), sem que para tal seja necessario o estabelecimento previo

de uma sess~ao segura. A informac~ao de seguranca especca para cada pacote viaja lado a lado com os dados do utilizador e a unica (mas obrigatoria) execuc~ao do protocolo Skeyx tem lugar de uma forma transparente e automatica. A analise de desempenho ao S3L prova que, apesar da sua depend^encia de criptograa por software, os benefcios obtidos com as qualidades de servico extra

Ao meu orientador, Prof. Dr. Francisco Soares Moura, pelo tema de investigac~ao e pelo interesse permanente na melhoria da qualidade desta dissertac~ao.

A todos os elementos do Grupo de Sistemas Distribudos, pela sua disponibilidade constante em fornecer ajuda.

Aos colegas de mestrado, especialmente a Maria Jo~ao, ao Exposto e ao Albano, agora colegas de pross~ao, pelo bom ambiente de trabalho proporcionado.

A Andrew Romanenko, pelo auxlio prestado no desenvolvimento do codigoIP Multi-cast.

Ao ilustre deputado Dr. Jose Magalh~aes, por ter respondido com solicitude as minhas duvidas sobre a legalidade de um trabalho numa area potencialmente controversa como e a Criptograa.

A Escola Superior de Tecnologia e Gest~ao do Instituto Politecnico de Braganca, pelas facilidades concedidas durante o perodo de elaborac~ao desta tese.

1 Introduc~ao

1

1.1 Motivac~ao . . . 2

1.2 Apresentac~ao . . . 3

1.3 Estrutura da Dissertac~ao . . . 5

1.4 Convenc~oes . . . 6

2 Elementos de Seguranca

8

2.2 Criptograa Simetrica . . . 10

2.2.1 Data Encryption Standard . . . 10

2.2.2 International Data Encryption Algorithm . . . 12

2.3 Criptograa Assimetrica . . . 12

2.3.1 Rivest{Shamir{Adleman . . . 13

2.3.2 Die{Hellman . . . 14

2.4 Sistemas Hbridos . . . 14

2.5 Autenticac~ao . . . 15

2.5.1 Func~oes de Hashing Unidireccionais . . . 15

2.5.2 Codigos de Autenticac~ao de Mensagens . . . 16

2.5.3 Assinaturas Digitais . . . 17

2.6 Sequenciac~ao . . . 19

2.7 Gest~ao de Chaves . . . 20

2.7.1 Gerac~ao . . . 20

2.7.2 Transmiss~ao . . . 21

2.7.3 Armazenamento . . . 24

2.7.4 Autenticac~ao . . . 24

3 Abordagens a Comunicac~ao Segura em Sistemas Distribudos

29

3.2 Encriptac~ao Fim{a{Fim . . . 30

3.3 Abordagens Fim{a{Fim . . . 32

3.3.1 Generic Security Service API . . . 32

3.3.2 Secure Network Programming . . . 34

3.3.3 Secure Sockets Layer . . . 35

3.3.4 Seguranca em Invocac~oes Remotas de Procedimentos . . . 38

3.3.5 Kerberos . . . 42

3.3.6 Secure Development Environment . . . 44

3.4 Abordagens na Camada de Rede . . . 45

3.4.1 swIPe . . . 45

3.4.2 Simple Key Management for Internet Protocols . . . 47

3.5 Analise Comparativa . . . 50

3.5.1 Outras Abordagens . . . 54

3.6 Oportunidade do S3L . . . 54

4 Skeyx: Gest~ao de Chaves no S3L

57

4.2 Modelo de Operac~ao do Skeyx . . . 61

4.2.1 Requisic~ao da Chave Publica do Servidor (C RKEY S) . . . 62

4.2.2 Recepc~ao de Mensagens C RKEYS . . . 64

4.2.3 Desao do Servidor ao Cliente (S CHALL C) . . . 65

4.2.4 Recepc~ao de Mensagens S CHALL C . . . 66

4.2.5 Desao do Cliente ao Servidor (C CHALL S) . . . 67

4.2.6 Recepc~ao de Mensagens C CHALL S . . . 68

4.2.7 Terminac~ao do Skeyx (S ACK C) . . . 69

4.2.8 Recepc~ao de Mensagens S ACK C . . . 70

4.3 Comunicac~ao Orientada{a{Conex~ao . . . 70

4.4 Reencaminhamento de MensagensC RKEYS . . . 71

4.5 Gest~ao da Cache de Chaves Publicas . . . 74

4.5.1 Estrutura da Cache . . . 74

4.5.2 Identicac~ao das Entradas da Cache . . . 76

4.5.3 Acesso Concorrente a Cache . . . 77

4.5.4 Actualizac~ao da Cache . . . 78

4.6 Replicac~ao no Contexto do Skeyx . . . 78

4.7 Trocas Skeyx Cruzadas . . . 81

5 Comunicac~ao Segura Ponto{a{Ponto via S3L

84

5.2 Mensagens S3L ponto{a{ponto . . . 88

5.2.1 Criterios de Rejeic~ao de Mensagens S3L Repetidas . . . 91

5.3 A Interface de Programac~ao de Aplicac~oes do S3L . . . 93

5.3.1 Manipulac~ao de Informac~ao de \Caracter Pessoal" . . . 94

5.3.2 Manipulac~ao de Contextos Seguros . . . 95

5.3.3 Sntese e Analise de Mensagens S3L . . . 96

5.3.4 Escrita e Leitura de Mensagens S3L sobre Sockets . . . 97

5.4 Ocorr^encias Implcitas do Protocolo Skeyx . . . 100

6 Comunicac~ao Segura Multiponto via S3L

106

6.2 Extens~oes Multiponto ao S3L . . . 110

6.2.1 Processo de Junc~ao ao Grupo . . . 111

6.2.2 Mensagens S3L Multiponto . . . 116

6.2.4 Sequenciac~ao de Mensagens S3L Multiponto . . . 121

6.3 A Interface de Programac~ao de Aplicac~oes do S3L Multiponto . . . 123

6.3.1 Manipulac~ao de Contextos Multiponto Seguros . . . 125

6.3.2 Sntese e Analise de Mensagens S3L Multiponto . . . 126

6.3.3 Escrita e Leitura de Mensagens S3L Multiponto sobre Sockets . . . . 127

6.4 Detecc~ao de Grupos Pre{Activos . . . 127

6.4.1 Detecc~ao na Propria Maquina . . . 128

6.4.2 Detecc~ao na Rede Local . . . 128

6.4.3 Detecc~ao num Contexto Global . . . 129

7 Analise de Desempenho

131

7.2 Metodologia . . . 131

7.3 Resultados . . . 132

7.3.1 Actualizac~oes de Contextos S3L Ponto{a{Ponto . . . 132

7.3.2 Primitivas Ponto{a{Ponto . . . 133

7.3.3 Algoritmos Simetricos . . . 138

7.3.4 Junc~oes a Grupos S3L Multiponto . . . 139

7.3.5 Primitivas Multiponto . . . 139

8 Conclus~oes

141

A Instalac~ao e congurac~ao do S3L

1

A.2 Congurac~ao . . . 3

A.2.1 Congurac~ao do SecuDE . . . 3

A.2.2 Congurac~ao do S3L . . . 8

A.2.3 Congurac~ao do IP Multicast . . . 9

B Utilizac~ao e programac~ao do S3L

11

B.1.1 Aplicac~oes Genericas . . . 12

B.1.2 Aplicac~oes Skeyx . . . 13

B.1.3 Aplicac~oes S3L Ponto{a{Ponto . . . 14

B.1.4 Aplicac~oes S3L Multiponto . . . 16

B.2 Programac~ao de Aplicac~oes com a API do S3L . . . 21

B.2.1 Constantes e Tipos Fundamentais . . . 21

B.2.2 Manipulac~ao de Informac~ao de \Caracter Pessoal" . . . 23

B.2.3 Manipulac~ao de Contextos S3L Ponto{a{Ponto . . . 25

B.2.4 Manipulac~ao de Mensagens S3L Ponto{a{Ponto . . . 28

B.2.5 Manipulac~ao de Contextos S3L Multiponto . . . 30

B.2.6 Manipulac~ao de Mensagens S3L Multiponto . . . 32

B.2.7 Escrita e Leitura de Mensagens S3L em Sockets . . . 34

Introduc~ao

Em meados dos anos setenta, a entidade governamental norte{americana Defense Advan-cedResearch ProjectsAgency(DARPA) iniciou um projecto do qual resultaria a denic~ao de um novo e revolucionario conjunto de protocolos na area das Comunicac~oes por Com-putador, hoje em dia conhecido por TCP/IP [Pos80c, Pos80b]. Esta pilha de protocolos transformou{se actualmente no standard de facto que permite a interligac~ao, a escala global, de redes de computadores baseadas nas mais diversas tecnologias, servindo organi-zac~oes e indivduos de interesses muitos diversicados. Essa imensa rede e universalmente conhecida porInternet.

Apesar da inu^encia que os meios militares tiveram no desenho original dos protocolos (e da propria infra{estrutura da Internet), tal n~ao impediu que posteriormente se iden-ticassem alguns problemas de seguranca na pilha TCP/IP [Bel89]. Contudo, foi so na decada presente que a preocupac~ao com a seguranca das comunicac~oes ganhou o protago-nismo de que hoje goza. Certamente, tal facto e indissociavel do crescimento exponencial da Internet1, o qual reforca ainda mais a necessidade de as organizac~oes e os indivduos garantirem a seguranca dos seus dados, face a uma exposic~ao cada vez maior a ataques.

A import^ancia da Criptograa no contexto actual das Comunicac~oes por Computador e, portanto, inquestionavel, suscitando um interesse crescente fora dos meios que tradi-cionalmente se lhe associam: Defesa, Espionagem e Diplomacia. Pode{se inclusivamente armar que a Criptograa e, em geral, as quest~oes associadas a Seguranca no domnio da Informatica est~ao \na moda". Por exemplo, a denic~ao de um mecanismo de transacc~oes seguras universal (que parece bem encaminhado atraves do protocolo Secure Electronic Transactions(SET))

2 tem sido objecto de intensa actividade, sendo esse mecanismo con-siderado decisivo para a consolidac~ao da explorac~ao comercial da Internet, permitindo a migrac~ao denitiva da comunidade nanceira para a \rede das redes". Intimamente asso-ciada a esta iniciativa, surge, inevitavelmente, a omnipresente quest~ao da Certicac~ao que, todavia, n~ao se limita ao domnio nanceiro. A operac~ao e a relac~ao entre Autoridades de Certicac~ao a varios nveis (organizacionais, nacionais ou mesmo supra{nacionais, de ^ambito publico ou privado | no contexto de uma Intranet, por exemplo |) e tambem um problema em aberto, sendo ainda em numero reduzido (e de reponsabilidade/credibilidade limitada) as Autoridades de Certicac~ao em actividade. Este cenario torna{se ainda mais

1Hoje reconhecidamente atribudo ao advento da

WorldWide Web(WWW). 2

http://www.visa.com/cgi-bin/vee/nt/ecomm/set/intro.html?2+0 disponibiliza a sua especicac~ao mais recente.

complexo porquanto a legislac~ao que regulamenta a produc~ao, exportac~ao e utilizac~ao de ferramentas criptogracas esta longe de ser uniforme3 (sendo, por vezes, inexistente ou desconhecida, como e o caso de Portugal). Apresentando como justicac~ao as dicul-dades acrescidas que a liberalizac~ao completa neste campo introduziria no combate ao crime, certos governos t^em insistido em controlar a utilizac~ao/exportac~ao de tecnologia do foro criptograco4. Ao nvel empresarial, mecanismos como as Redes Privadas Vir-tuais (VPNs5) e as rewalls s~ao de uso cada vez mais vulgarizado, como forma de manter a privacidade das comunicac~oes entre e dentro das organizac~oes. No domnio pessoal, e de assinalar a utilizac~ao crescente de ferramentas de encriptac~ao de cheiros e de correio electronico (como por exemplo o popular PGP), a preocupac~ao em assegurar a conden-cialidade de sess~oes remotas (materializada em aplicac~oes como o secure shell (ssh)) e a previsvel vulgarizac~ao dos smartcards. Em termos mais mediaticos, s~ao frequentes as notcias de \buracos de seguranca" em ferramentas de uso diario (como os browsers da Microsoft e da Netscape) e em sistemas operativos, bem como de ataques bem sucedidos a servidores organizacionais e fornecedores de acesso a Internet.

A area em que se insere este trabalho, a da comunicac~ao segura em aplicac~oes distri-budas, e assim de uma actualidade indiscutvel e de uma import^ancia cada vez maior, a medida que a operac~ao em rede se consolida como modelo dominante em praticamente todas as areas onde a Informatica se \inltra", fazendo corresponder aos seus enormes benefcios outra tanta dose de preocupac~ao pelas diculdades em assegurar a Privacidade da informac~ao, alguma da qual governa as nossas vidas.

1.1 Motivac~ao

A motivac~ao original para a realizac~ao deste trabalho partiu da constatac~ao da possibilida-de possibilida-de possibilida-desenvolver um protocolo possibilida-de gest~ao possibilida-de replicas possibilida-de objectos num ambiente nomada6, tomando como ponto de partida a comunicac~ao multiponto7 oferecida de base pelo IP Multicast [Dee89].

A utilizac~ao do IP Multicast colocava alguns desaos interessantes, nomeadamente a sua natureza n~ao{orientada{a{conex~ao8 e o facto de a entrega de pacotes se basear numa poltica de melhor esforco9.

Contudo, havia ainda um importante obstaculo a vencer: dada a natureza aberta dos grupos IP Multicast, segundo a qual n~ao ha restric~oes a gerac~ao e auscultac~ao do trafego associado a qualquer grupo, tornou{se evidente a necessidade de providenciar mecanismos de protecc~ao desse trafego.

Nesta linha, foi levado a cabo um estudo inicial [Ama96], a m de averiguar a via-bilidade da aplicac~ao de esquemas de seguranca (Privacidade, Autenticac~ao, etc.) ao IP

3A este proposito,

http://cwis.kub.nl/%7Efrw/people/koops/lawsurvy.htmloferece um estudo bas-tante completo que cobre a legislac~ao existente num conjunto diversicado de pases.

4Os Estados Unidos constituem um exemplo paradigmatico deste tipo de atitude. Todavia,

recente-mente, o debate sobre a quest~ao foi relancado, perspectivando{se evoluc~oes a curto prazo no sentido de uma maior liberalizac~ao neste sector.

5Do ingl^esVirtual Private Networks. 6Do ingl^esmobile.

Multicast, do qual resultou uma primeira vers~ao de um protocolo de comunicac~ao segura em grupo, embora com bastantes limitac~oes. Nesse trabalho, concluiu-se da necessidade de desenvolver um protocolo mais generico, que contemplasse, de base, seguranca sobre a tradicional comunicac~ao ponto{a{ponto10 e que fornecesse os alicerces para as extens~oes multiponto.

O desenho e a implementac~ao desse protocolo, que se convencionou designar de Sta-teless Secure SocketsLayer(S3L), suscitaram quest~oes em torno das quais acabou por se centrar a presente tese e que justicaram o abandono do objectivo inicial relativo a gest~ao de replicas.

Assim sendo, esta dissertac~ao deve ser encarada como uma descric~ao do processo de investigac~ao, concepc~ao, implementac~ao e analise de desempenho do S3L.

1.2 Apresentac~ao

Basicamente, o S3L e uma Interface de Programac~ao de Aplicac~oes (API11) que, em con-junto com alguns demonios e utilitarios de apoio, fornece servicos de seguranca imedia-tamente acima da interface de programac~ao dos socketsde Berkeley [LMKQ89, LFJL86], mantendo com estes grandes semelhancas sintacticas e sem^anticas nas operac~oes de escrita e leitura. Tais semelhancas contribuem decisivamente para a facilidade com que se faz a migrac~ao de aplicac~oes do \modelo de Berkeley" para o \modelo S3L".

As qualidades de servico oferecidas pelo S3L compreendem a Privacidade, a Autenti-cac~ao (incluindo a N~ao{Repudiac~ao), a Integridade, a Sequenciac~ao (contra ataques{de--repetic~ao) e a Compress~ao dos dados trocados, oferecendo{se ainda, na variante multi-ponto, Controle de Acesso na fase de junc~ao a um grupoIP Multicast seguro.

O S3L distingue{se de outras abordagens ans12em dois aspectos fundamentais:

pelo seu caracter stateless;

pelo seu suporte explcito a comunicacao segura em grupo sobre IP Multicast. O caracterstatelessatribudo ao S3L resulta do seu protocolo auxiliarSecureKey Ex-change (Skeyx), responsavel por denir um estado mnimo comum entre as partes inter-venientes numa comunicac~ao S3L. Esta aparente contradic~ao explica{se facilmente: toda a seguranca do S3L assenta, em ultima inst^ancia, no acordo de Die{Hellman; logo, a m de evitar que a transmiss~ao de toda e qualquer mensagem S3L seja precedida da troca de chaves publicas de Die{Hellman, executa{se o protocolo Skeyx uma unica vez, entre as duas entidades comunicantes. O Skeyx e executado transparentemente, on{the{y, du-rante a primeira comunicac~ao S3L entre duas entidades. A chave acordada e preservada, por cada entidade, numa cache propria, a m de ser eventualmente reutilizada, numa comunicac~ao S3L futura, sem necessidade de repetir o processo de acordo. Nessa cache, s~ao tambem preservados outros elementos resultantes desta negociac~ao previa, como por exemplo o tipo de algoritmos criptogracos suportados pela entidade remota.

As chaves publicas de Die{Hellman trocadas pelo Skeyx n~ao necessitam de ser cer-ticadas pelo que o Skeyx consiste, basicamente, num protocolo do tipo desao{resposta,

10

Doingl^esunicast. 11

onde cada interveniente tem que provar que possui a chave privada correspondente a cha-ve publica que envia ao outro. Ataques do tipo homem{no{meio durante este processo s~ao evitados atraves da utilizac~ao de assinaturas digitais baseadas na aplicac~ao de chaves publicas RSA certicadas. Todavia, o Skeyx foi concebido de forma a que uma entidade dispense o conhecimento previo da chave publica RSA da outra, sendo a unica restric~ao a de que a cadeia de certicac~ao de ambas tenha pelo menos um ponto comum.

A vantagem imediata de um acordo de Die{Hellman entre duas entidades comu-nicantes e a obtenc~ao de uma chave secreta comum (a chave acordada) que, doravante, podera ser usada na protecc~ao das mensagens trocadas entre ambas. As mensagens S3L podem assim circular de uma forma expedita, sem necessidade de estabelecimento previo de sess~oes seguras dedicadas, sendo possvel a escolha unilateral, por parte de cada enti-dade, de items de seguranca especcos para cada mensagem (como, por exemplo, chaves, algoritmos, numeros de sequ^encia, codigos de autenticac~ao, etc.) que viajam lado a lado com os dados do utilizador.

O S3L oferece funcionalidades ponto{a{ponto e multiponto. Basicamente, estas fun-cionalidades resumem{se ao encapsulamento dos dados do utilizador num formato proprio e a posterior invocac~ao de primitivas de leitura e escrita sobre os sockets de Berkeley tradicionais. E ainda possvel a assemblagem de mensagens S3L sem entrega directa a rede, constituindo{se dessa forma em contentores seguros de informac~ao, destinados a armazenamento ou a formas alternativas de transmiss~ao.

Assente em servicos criptogracos fundamentais fornecidos pelo Secure Development Environment (SecuDE) [Sch95a], o S3L e conceptualmente baseado no (mas n~ao e com-patvel nem interoperavel com o) Simple Key Management for Internet Protocols (SKIP) [AP95, AMP95c] da Sun, que fornece seguranca ao nvel da Camada de Rede. Todavia, o S3L transporta (e estende) os conceitos do SKIP para a Camada de Aplicac~ao, na vizi-nhanca da interface de programac~ao com sockets, representando uma forma mais exvel de implementar seguranca. Este ganho em exibilidade deriva da n~ao imposic~ao de um modelo global (embora reconhecidamente mais transparente) de seguranca, como acontece com o SKIP.

As diferencas de posicionamento em termos arquitecturais, entre o SKIP e o S3L, conduzem, inevitavelmente, a diferencas de fundo entre ambos. Basta dizer que, no SKIP a seguranca e estabelecida em func~ao do sistema (ou melhor, do seu endereco IP) na sua globalidade. As listas de controle de acesso do SKIP denem regras aplicaveis a todo o trafego de e para uma maquina. No S3L, o sujeito da seguranca e a entidade13, n~ao havendo limite teorico ao numero de entidades por maquina. Tal permite a gest~ao individualizada de qualidades de servico como a Privacidade, Autenticac~ao, Integridade, Compress~ao, etc. Outros aspectos, como por exemplo a Sequenciac~ao de mensagens, corroboram esta distinc~ao que se pretende vincar entre o SKIP e o S3L. Concretizando, o SKIP e bastante tolerante, lidando com granularidades demasiado altas para serem efectivas no combate a ataques{de{repetic~ao. O S3L, por seu turno, enfrenta a velha quest~ao da sincronizac~ao de relogios, redenindo e parametrizando o mecanismo do SKIP. Dispensando a sincronizac~ao de relogios, as soluc~oes preconizadas pelo S3L acabam por abrir janelas de ataque mas constituem, como se podera vericar, um risco bem calculado.

Na variante multiponto as diferencas n~ao se limitam ao mecanismo de Sequenciac~ao. 13

As listas de controle de acesso lidam, como seria de esperar, com entidades (e n~ao com en-derecos IP). O tempo de vida de um grupo e denido de forma independente do tempo de vida dachave{do{grupo, sendo o calculo desses tempos de vida independente da sincroni-zac~ao de relogios em todos os elementos do grupo. A (re)junc~ao ao grupo constitui sempre um processo automatico, realizado por necessidade, on{the{y, e quando ocorre em face da obsolesc^encia da chave{do{grupo prev^e{se a possibilidade de usar, temporariamente, essa chave ja obsoleta, enquanto a rejunc~ao n~ao se concretiza. O processo de criac~ao de um novo grupo procura evitar a sobreposic~ao de dois grupos diferentes no mesmo endereco IP Multicast.

Acrescente{se que o S3L n~ao faz assunc~oes relativamente a seguranca dos protocolos de base em que assenta (pilha IP/TCP) uma vez que toda a informac~ao que lhe e relevante (e que basicamente partilha, com os dados do utilizador, o campo de dados dos pacotes desses protocolos) e sujeita a mecanismos proprios de Autenticac~ao.

1.3 Estrutura da Dissertac~ao

O resto deste documento divide{se, informalmente, em tr^es partes distintas. A primeira contempla o captulo 2 e o captulo 3 nos quais se faz, genericamente, o enquadramento da dissertac~ao na sua area de investigac~ao especca. A segunda parte compreende os captulos 4, 5, 6, 7 e 8 ao longo dos quais se processa a concepc~ao, o desenvolvimento e a analise dos protocolos criados no ^ambito do S3L. A terceira parte consiste nos ap^endices A e B, que cont^em indicac~oes essenciais a instalac~ao e utilizac~ao do S3L. Concretamente:

no captulo 2 sintetizam{se as noc~oes fundamentais do ramo do conhecimento (Crip-tograa) em que se insere o presente trabalho. O captulo comeca por denir al-gumas qualidades de servico basicas (Condencialidade, Autenticac~ao, etc.) e res-pectivos ataques, no contexto da Seguranca em Sistemas Distribudos. De seguida descrevem{se os blocos construtores de qualquer sistema criptograco moderno: sis-temas simetricos, assimetricos e hbridos, metodos de Autenticac~ao, de Sequenciac~ao e de gest~ao de chaves;

o captulo 3 apresenta as perspectivas mais correntes do posicionamento das func~oes de encriptac~ao na arquitectura do Modelo de Comunicac~oes e do Sistema Operati-vo. Nomeadamente, s~ao discutidas as variantes Ligac~ao{a{Ligac~ao e Fim{a{Fim. A atenc~ao acaba por se concentrar em algumas das propostas Fim{a{Fim mais re-presentativas, sendo efectuada uma analise comparativa resumida das abordagens analisadas. O captulo termina procurando justicar a oportunidade do S3L bem como a escolha do SKIP e do SecuDE como pontos de partida teorico e pratico, respectivamente, para o seu desenvolvimento;

algoritmo de actualizac~ao de caches e posto a prova numa situac~ao especca com elevado grau de concorr^encia e imprevisibilidade;

o captulo 5 introduz a variante ponto{a{ponto do S3L. A sua relac~ao com o SKIP e claricada atraves do confronto entre a estrutura das mensagens (e seus mecanismos de sequenciac~ao) de ambos. De seguida introduz{se a API do S3L ponto{a{ponto, sugere{se uma metodologia de programac~ao e estabelecem{se relac~oes entre as \pri-mitivas S3L" e as pri\pri-mitivas de Berkeley. O captulo termina com a descric~ao do mecanismo de execuc~oes implcitas do protocolo Skeyx, desencadeadas on{the{y pela execuc~ao das \primitivas S3L";

o captulo 6 encerra a apresentac~ao do protocolo S3L com a discuss~ao das suas extens~oes multiponto que lhe permitem operar sobre o IP Multicast. As extens~oes multiponto do SKIP s~ao em primeiro lugar objecto de analise para de seguida se introduzir a proposta especca do S3L. O processo de junc~ao a um grupo S3L e ent~ao dissecado: dene{se o papel do \dono do grupo", estende{se a func~ao do servico de reencaminhamento introduzido no captulo 4, apresenta{se a estrutura dos pedidos (e respostas) de junc~ao e descreve{se o mecanismo de controle de acesso ao grupo. De seguida apresenta{se a estrutura das mensagens multiponto geradas pelos membros e justica{se a abordagem seguida na gest~ao de chaves de grupo e na sequenciac~ao de mensagens multiponto. O captulo prossegue apresentando as extens~oes multiponto a API do S3L e denindo um modelo de programac~ao com essas extens~oes. Por m, a viabilidade de detecc~ao de grupos pre{activos num determinado enderecoIP Multicaste discutida;

a analise de desempenho do S3L e efectuada no captulo 7 onde se descreve a meto-dologia seguida e os resultados obtidos nos varios testes realizados sobre ambas as modalidades ponto{a{ponto e multiponto do S3L;

no captulo 8 apresentam{se as conclus~oes do trabalho e apontam{se linhas de de-senvolvimento futuro;

os ap^endices A e B s~ao de leitura obrigatoria para os utilizadores do S3L. No ap^endice A descrevem{se, com pormenor, todos os procedimentos necessarios a instalac~ao e congurac~ao do S3L. No ap^endice B documentam{se todos os utilitarios e todas as func~oes da API do S3L sendo fornecidos exemplos de codigo comentados.

1.4 Convenc~oes

Esta dissertac~ao assume determinadas convenc~oes relativas a traduc~ao de termos ou ex-press~oes para a lngua portuguesa, tipos de letra usados e abreviaturas.

E feito um esforco no sentido de traduzir a maioria dos termos e designac~oes tecnicas. A qualidade dessa traduc~ao reecte necessariamente as limitac~oes do autor como tradutor. Assim, na aus^encia de uma traduc~ao satisfatoria, sera mantido o termo ou express~ao na sua lngua de origem. A primeira ocorr^encia de uma traduc~ao sera sempre acompanhada de uma nota de rodape assinalando o termo ou express~ao original.

italico: para termos na sua lngua original ou para conferir ^enfase a determinados termos ou frases de maior relev^ancia;

Elementos de Seguranca

S~ao dois os pilares teoricos em que assenta a presente dissertac~ao: Seguranca e IP Mul-ticast. Neste captulo pretende{se apenas condensar elementos teoricos fundamentais de Seguranca em Sistemas Distribudos. Dada a vastid~ao actual desta area, apenas ser~ao cobertos os topicos directamente relacionados com o trabalho. Relativamente ao IP Mul-ticast, este sera objecto de atenc~ao posteriormente (captulo 6), durante a descric~ao das extens~oes ao S3L que suportam grupos IP Multicast seguros.

2.1 Seguranca em Sistemas Distribudos

No contexto dos Sistemas Distribudos modernos, o conceito de Seguranca compreende algumas qualidades de servico1 basicas, entre as quais [Sta95]:

Condencialidade/Privacidade: assegura o acesso (de leitura) a determinado recurso ou mensagem apenas por entidades devidamente autorizadas;

Autenticac~ao: implica a identicac~ao correcta do originador (Autenticac~ao da Ori-gem) e/ou do destinatario (Autenticac~ao do Destino) de uma mensagem;

Integridade: assegura que qualquer modicac~ao (via acesso de escrita) no estado de um recurso ou na estrutura de uma mensagem e feita apenas por entidades com autorizac~ao adequada;

N~ao{Repudiac~ao: corresponde a capacidade de provar que um determinado emissor e/ou um determinado receptor de uma mensagem est~ao efectivamente comprometi-dos na sua troca, ainda que neguem tal facto;

Controle de Acesso: implica a possibilidade de colocar barreiras selectivas no aces-so (incluindo na propria natureza desse acesaces-so) a determinado recuraces-so (servico ou dados);

Disponibilidade: assegura a manutenc~ao do acesso a um determinado recurso e a sua operac~ao contnua, inclusivamente quando sujeito a ataques que visem a sua inoperacionalidade parcial ou total.

1

Doingl^esQualities{of{Service(QoS).

E precisamente sobre estas qualidades de servico que incide a maioria dos ataques feitos a Seguranca de um Sistema Distribudo: Intercepc~ao (ataque a Condencialidade), Inter-rupc~ao (ataque a Disponibilidade), Modicac~ao (ataque a Integridade) e Fabricac~ao/Fal-sicac~ao2 (ataque a Autenticidade).

A Intercepc~ao enquadra{se numa categoria mais vasta de ataques, designados por ataques passivos, que visam fundamentalmente a observac~ao da informac~ao (por exemplo, durante o acto da sua transmiss~ao) e sua possvel divulgac~ao. Uma vez que n~ao modica a informac~ao, este genero de ataques e difcil de detectar, colocando-se particular ^enfase na sua prevenc~ao.

Por oposic~ao, os ataques activos compreendem a Interrupc~ao, a Modicac~ao e a Fabri-cac~ao e apoiam-se em tecnicas como:

Personicac~ao/Simulac~ao

3: em que uma entidade consegue criar a ilus~ao de que e outra entidade;

Repetic~ao: em que ocorre a retransmiss~ao de uma mensagem (capturada atraves de um ataque passivo), como forma de, por exemplo, viabilizar um ataque de Personi-cac~ao;

Adulterac~ao: em que se modica o corpo de uma mensagem ou se introduz um atraso deliberado na sua propagac~ao ou, inclusivamente, se reordenam mensagens a m de obter efeitos que n~ao os originalmente pretendidos na transmiss~ao da mensagem original;

Negac~ao do Servico

4: em que se procura evitar que os potenciais clientes de um de-terminado servico a ele tenham acesso, quer gerando um grande numero de falsos pe-didos, quer desviando os pedidos originais, quer destruindo a propria infra{estrutura fornecedora do servico.

Os ataques activos s~ao de difcil prevenc~ao, o que leva a que as contra{medidas se baseiem, maioritariamente, em procedimentos de recuperac~ao, uma vez detectado o ata-que. Adicionalmente, os ataques ocorrem frequentemente em forma combinada, a m de se revelarem mais ecazes, o que diculta ainda mais o seu combate.

Obviamente, estas classicac~oes (quer das qualidades de servico, quer dos ataques) relativas a Seguranca de um Sistema Distribudo, est~ao longe de ser exaustivas, ja que n~ao colocamos nos objectivos da presente tese a elaborac~ao de classicac~oes desse tipo. Funda-mentalmente, elas servem para sensibilizar o leitor para a necessidade de se encontrarem mecanismos apropriados a implementac~ao de uma poltica de Seguranca capaz de imuni-zar uma comunidade, (seja ela de utilizadores, maquinas, aplicac~oes, objectos ou outras entidades), relativamente a interfer^encias indesejadas de agentes internos ou externos.

E precisamente neste contexto que se justica um breve resumo de algumas das tecnicas e conceitos em que assenta a Criptograa moderna. A apresentac~ao que se segue reecte, necessariamente, alguma da investigac~ao na area feita pelo autor, uma vez que a maioria dos topicos abordados encontram concretizac~ao na parte pratica da presente dissertac~ao, como oportunamente se vericara.

2

Doingl^esFabrication. 3

Doingl^esImpersonation/Masquerade. 4

2.2 Criptograa Simetrica

A ess^encia da criptograa simetrica (tambem designada por \convencional" ou \de chave secreta") reside no uso de uma chave comum ao processo de encriptac~ao e desencriptac~ao5. Enquanto essa chave n~ao for comprometida, existira um canal seguro entre os produtores e os consumidores de informac~ao que partilham a chave. O conhecimento do algoritmo de encriptac~ao/desencriptac~ao e a posse da mensagem cifrada nunca dever~ao ser sucientes para determinar a mensagem original.

A comunicac~ao entre duas entidades |AeB| que protegem as mensagens trocadas usando criptograa simetrica segue, em geral, um protocolo que, na direcc~ao A ! B, podera enunciar{se da seguinte forma:

1. A eB concordam previamente num algoritmo simetrico e numa chave K comuns; 2. A efectua C=E

K(

P) e enviaC a B; 3. B efectua P =D

K(

C), recuperando P;

em queE encriptac~ao, Ddesencriptac~ao,Kchave secreta,P mensagem original (outexto plano

6) e

Cmensagem cifrada (ou texto cifrado 7).

Os metodos criptogracos de chave secreta sofrem, porem, de alguns problemas fun-damentais [Sch96]:

a chave secreta tem de ser distribuda antecipadamente a todos os potenciais inter-venientes numa comunicac~ao segura. Essa distribuic~ao esta, naturalmente, sujeita a ataques que, se bem sucedidos, comprometer~ao irremediavelmente qualquer comu-nicac~ao futura;

como toda a seguranca do processo reside na ocultac~ao de uma unica chave, se essa chave e comprometida, todo o processo e comprometido;

mesmo que se opte pelo uso de chaves separadas para qualquer par de entidades comunicantes, tal pode n~ao ser viavel pelo elevado numero de chaves possivelmente necessarias: n(n,1)=2 chaves paranentidades.

2.2.1 Data Encryption Standard

O Data Encryption Standard (DES) [oS77] e o algoritmo de criptograa simetrica de uso mais vulgarizado. Datando ja de 1977 a sua adopc~ao pela organizac~ao norte-americana National Bureau of Standards

8, o DES baseia{se numa chave de 56 bits e num algoritmo que opera com blocos de 64 bits9.

O DES goza de varios modos de operac~ao (denidos originalmente em [oS80]), con-soante o tipo de aplicac~ao alvo, que lhe permitem agir sobre mensagens de dimens~oes 5O caso mais generico e aquele em que, apesar de as chaves n~ao serem iguais, qualquer uma delas pode

obter{se facilmente com base no conhecimento da outra.

6Do ingl^es

plaintext. 7Do ingl^es

ciphertext. 8Actualmente

NationalInstituteof StandardsandTechnology(NIST). 9Diz-se, ent~ao, que o DES e uma

arbitrarias, ao mesmo tempo que lhe conferem resist^encia a alguns tipos de ataques. No contexto do presente trabalho, apenas os seguintes modos de operac~ao do DES s~ao rele-vantes10:

Electronic Codebook(ECB): cada bloco de 64 bits e cifrado individualmente e de uma forma independente dos outros blocos (embora com a mesma chave), produzindo{se outro bloco de 64 bits. O mesmo bloco de entrada origina sempre o mesmo bloco a sada, para uma dada chave, provindo daa designac~ao Electronic Codebook, uma vez que, teoricamente, seria possvel manter uma tabela que zesse a correspond^encia entre um bloco n~ao cifrado e o respectivo bloco cifrado. O modo ECB deve ser usado preferencialmente na encriptac~ao de pequenas mensagens, onde a probabilidade de repetic~ao de blocos e menor. Assim, se por acaso se descobrir a correspond^encia entre um determinado bloco n~ao cifrado e o respectivo bloco cifrado, ent~ao a analise de uma mensagem cifrada, onde esse bloco ocorra frequentemente | ou mesmo sistematicamente (no cabecalho, por exemplo) |, podera car substancialmente facilitada [Sch96];

Cipher Block Chaining (CBC): a chave mantem-se ao longo de todo o processo. Porem, a encriptac~ao de um determinado bloco depende do resultado da encriptac~ao do bloco anterior. Assim, para cada bloco e calculado o ou logico exclusivo (XOR) com o bloco anterior cifrado, constituindo o bloco resultante uma nova entrada do algoritmo. Para o primeiro bloco, o bloco anterior devera consistir num bloco gerado aleatoriamente (o Vector de Inicializac~ao (IV)11, que devera ser conhecido por ambas as partes), a m de forcar sempre a produc~ao de resultados diferentes para os mesmos blocos de entrada (ou ent~ao a construc~ao de uma tabela semelhante a referida no modo ECB poderia tornar{se viavel).

Apesar de o DES ser bastante popular, a sua aceitac~ao nunca foi completamente pacca, devido, por um lado, ao receio de que a dimens~ao (actualmente considerada reduzida) das chaves se traduza numa vulnerabilidade a ataques do tipo forca{bruta12 (cuja viabilidade foi demonstrada recentemente em [Wie93] e posteriormente conrma-da13 no ^ambito de uma serie de desaos lancados pela rma americana RSA14), por outro lado, ao facto de certos detalhes da estrutura interna do DES terem vindo a ser ocultados, o que levantou suspeic~oes relativamente a seguranca efectiva do algoritmo.

3DES

Uma alternativa interessante a aplicac~ao simples do DES (e que no fundo constitui uma for-ma de prolongar a vida util do algoritmo) baseia{se num metodo de encriptac~ao multipla, segundo o qual se aplica o mesmo algoritmo um determinado numero de vezes, fazendo variar a chave em cada aplicac~ao. O 3DES (ou triplo DES) e uma variante do DES que usa duas (ou mesmo tr^es) chaves diferentes em modo Encrypt{Decrypt{Encrypt (EDE).

10Porque s~ao precisamente os modos oferecidos pelo pacote criptograco usado (ver secc~ao 3.3.6). 11Do ingl^es

InitializationVector. 12Do ingl^es

brute{force{atacks. Neste tipo de ataques, e feita uma procura exaustiva da chave, o que so

e viavel se o espaco das chaves for de dimens~oes \reduzidas".

13

http://www.frii.com/~rcv/deschall.htm

14

O modo EDE (originalmente sugerido por [Tuc79]) consiste em cifrar a mensagem com a primeira chave, decifrar com uma segunda e voltar a cifrar com a primeira (ou com uma terceira15). Uma discuss~ao mais completa das tecnicas de encriptac~ao multipla (incluindo possveis ataques) pode ser encontrada em [Sch96].

2.2.2 International Data Encryption Algorithm

O International Data Encryption Algorithm (IDEA) e um algoritmo simetrico recente [LM90], agurando{se como um serio candidato a disputa da hegemonia do DES.

A semelhanca do DES, o IDEA e tambem um algoritmo que consome e produz blocos de 64 bits, usando, porem, uma chave de 128 bits, o que, conjuntamente com a propria estrutura interna do algoritmo, contribui para a boa imagem (em termos de Seguranca) de que o IDEA goza actualmente. O IDEA tambem pode basear{se nos mesmos modos de operac~ao (ECB, CBC, CFB e OFB) denidos para o DES.

As implementac~oes em software do IDEA chegam a ser duas vezes mais rapidas que as implementac~oes do DES [Sch96]. No entanto, provavelmente, o principal factor de sucesso do IDEA reside na sua utilizac~ao pela aplicac~ao criptograca de uso mais vulgarizado: o Pretty Good Privacy(PGP) [Zim95].

2.3 Criptograa Assimetrica

A criptograa assimetrica (ou \de chave publica") e conhecida desde 197616 [DH76], cons-titundo um dos marcos mais importantes na evoluc~ao da ci^encia da Criptograa.

Este paradigma baseia-se no uso de um par de chaves: uma de encriptac~ao e outra de desencriptac~ao17. Uma delas e tornada publica e a outra devera permanecer privada. Acresce que devera ser computacionalmente impraticavel obter a chave privada, conhecida a respectiva chave publica.

A comunicac~ao entre duas entidadesAeBque protegem as mensagens trocadas usando criptograa assimetrica podera basear{se no seguinte protocolo, na direcc~ao A!B:

1. A eB concordam previamente num algoritmo de chave publica; 2. A toma conhecimento deK

pub

B e assegura{se de que essa chave e de B; 3. A efectua C=E

K pub

B(

P) e envia C a B; 4. B efectua P =D

Kprv B(

C), recuperandoP; em que K

pub B

chave publica de Be K prv

B

chave privada deB.

15Note{se que se todas as chaves forem iguais, o 3DES em modo EDE equivale a uma aplicac~ao simples do

DES, o que encontra justicac~ao na necessidade de assegurar retro{compatibilidade com implementac~oes antigas.

16A organizac~ao governamental norte{americanaNational Security Agency(NSA) reclama esse

conheci-mento desde 1966, sem que, contudo, tivesse fornecido provas publicas desse facto.

17Alguns esquemas (como por exemplo o RSA) permitem que uma chave possa ser usada em ambos os

Desta forma, garante-se um canal seguro sem ser necessario estabelec^e-lo a partida, ou seja, resolve{se um problema fundamental dos sistemas simetricos: a distribuic~ao de chaves.

S~ao pelo menos tr^es as aplicac~oes possveis dos algoritmos de chave publica: Privacida-de, Autenticac~ao e Troca de Chaves. Contudo, nem todos os algoritmos de chave publica s~ao capazes de suportar em simult^aneo todas estas aplicac~oes18. Adicionalmente, os es-quemas de criptograa assimetrica actuais traduzem{se, geralmente, num grande esforco computacional, n~ao sendo por isso frequente a sua aplicac~ao como forma de assegurar Privacidade.

Do conjunto de algoritmos de chave publica actualmente disponveis, a concretizac~ao pratica da presente dissertac~ao faz uso apenas do Rivest{Shamir{Adleman (RSA) e do Die{Hellman (DH).

2.3.1 Rivest{Shamir{Adleman

O Rivest{Shamir{Adleman (RSA) [RSA78] esta para a criptograa assimetrica assim como o DES esta para a criptograa simetrica: ambos constituem os algoritmos mais usados e estudados nas suas respectivas areas, sendo considerados seguros ate a data. A semelhanca do IDEA, a aceitac~ao e a disseminac~ao do RSA foi tambem favorecida pela sua inclus~ao no PGP.

A seguranca do RSA reside na diculdade em factorizar numeros grandes: a ideia base e a de que e \facil" encontrar dois numeros primos grandes, mas e impraticavel (em termos computacionais) factorizar o seu produto.

Para alem da abordagem da factorizac~ao, e possvel conceber outras categorias de ataques ao RSA, por exemplo dirigidos a sua concretizac~ao e n~ao ao algoritmo em si. [Sch96] descreve uma serie de ataques desse genero. A ttulo meramente ilustrativo, rera{ se o ataque classico do tipo texto{plano{escolhido19, cuja aplicac~ao, alias, e extensvel a outros algoritmos para alem do RSA: sejaC=E

K pub(

P) (em queCmensagem cifrada, P mensagem plana,Eencriptac~ao e K

pub

uma chave publica). Deste modo, se ha no maximon Ps diferentes e conhecidos, bastara cifrar todos os Ps possveis comK

pub e comparar o resultado com C, para se determinar, assim, qual oP que corresponde a C. A viabilidade deste ataque depende, obviamente, de uma dimens~ao favoravel ndo espaco das mensagens planas P. Se n for pequeno (i.e., se n for compatvel com os meios de calculo disponveis), ent~ao torna{se evidente que nem sempre e necessario recorrer a forca bruta ou a factorizac~ao para derrubar esquemas de seguranca baseados em algoritmos aparentemente t~ao robustos como o RSA.

O RSA e um algoritmo atraves do qual e possvel assegurar Privacidade e realizar Autenticac~ao e Troca de Chaves. Contudo, o RSA e particularmente vocacionado para estas duas ultimas vertentes, uma vez que, inclusivamente em hardware, o RSA e aproxi-madamente 1000 vezes mais lento que o DES [Sch96].

18Para uma descric~ao praticamente exaustiva dos algoritmos de chave publica existentes, recomenda{se

a consulta de [Sch96].

19Do ingl^es

2.3.2 Die{Hellman

O algoritmo de Die{Hellman20 (DH) foi o primeiro algoritmo de chave{publica a ser publicado [DH76].

O seu proposito e apenas o de permitir a troca de uma chave entre duas entidades21, para o que e suciente que as chaves publica e privada das entidades envolvidas sejam geradas com base em certos par^ametros especiais comuns (conhecidos antecipadamente por ambas as entidades) e que uma entidade faca chegar a outra, de uma forma avel, a sua chave publica.

A chave trocada22 (ou uma outra dela derivada) podera ent~ao ser empregue por um algoritmo de encriptac~ao (em geral simetrico) do trafego entre as duas entidades.

A seguranca do algoritmo DH deriva da diculdade em calcular logaritmos discretos num campo nito23. Relativamente a sua concretizac~ao, um ataque do tipo homem{ no{meio24 e evidentemente viavel se as mensagens envolvidas na troca das chaves n~ao forem assinadas pelos seus originadores. Num ataque deste genero, sup~oe-se que exista uma terceira entidade que tem a capacidade de interceptar uma mensagem e modica{la sem que o destinatario seja capaz de detectar esse facto. Um dos objectivos pode ser a Personicac~ao, levando a outra entidade a interactuar com um impostor.

2.4 Sistemas Hbridos

Tradicionalmente, os sistemas de criptograa publica s~ao usados para trocar chaves sime-tricas de sess~ao e n~ao tanto para garantir a Privacidade das mensagens. Nesta perspectiva, os sistemas assimetricos s~ao vistos como ferramentas que tornam mais seguras as trocas de chaves simetricas. Fundamentalmente, a raz~ao para tal procedimento assenta no grande esforco computacional em que se traduzem os algoritmos assimetricos. Adicionalmente, ja vimos que nem todos os algoritmos assimetricos suportam operac~oes de encriptac~ao.

Num sistema hbrido em que a entidade A usa criptograa assimetrica para enviar a entidadeBuma chave de sess~ao simetrica, um protocolo basico na direcc~aoA!Bpodera ser:

1. A e B concordam previamente num algoritmo de chave publica e noutro de chave secreta;

2. A toma conhecimento de K pub

B (e, idealmente, certica{se de que essa chave e realmente de B); decide ainda que a chave secreta eK;

3. A efectua C=E K

pub B(

K) e enviaC a B; 4. B efectua K=D

Kprv B(

C), tomando assim conhecimento deK; 5. doravante, Ae B cifram com K o trafego que trocarem entre si. 20Que rigorosamente deve ser designado por \Troca de Chaves deDie{Hellman".

21N~ao suportando directamente operac~oes de encriptac~ao, como acontece, por exemplo, com o RSA. 22Neste contexto o termoacordadatalvez fosse mais adequado, visto que, na realidade, a chave em si n~ao

e trocada, mas sim gerada por ambas as entidades com base em informac~ao de domnio publico e tambem em informac~ao privada.

Porem, este protocolo esta longe de ser satisfatorio , ja que, apesar de fornecer Con-dencialidade, carece de um mecanismo de Autenticac~ao, topico a abordar de seguida.

2.5 Autenticac~ao

No contexto de uma troca segura de mensagens, Autenticac~ao refere{se ao processo atraves do qual o receptor pode concluir com seguranca que o emissor e quem arma ser e que a mensagem recebida n~ao foi adulterada em tr^ansito. Adicionalmente, podera ser necessario assegurar que o emissor n~ao possa negar a transmiss~ao de uma mensagem e/ou o receptor n~ao possa negar a sua recepc~ao. Resumindo, a Autenticac~ao pretende combater pelo menos ataques de Personicac~ao, Modicac~ao (podendo estes ultimos incidir sobre o conteudo, sequ^encia ou temporizac~ao das mensagens) e Repudiac~ao.

Uma primeira abordagem (embora ingenua, como se constatara de seguida) a Auten-ticac~ao consiste em conceber a mensagem cifrada como o proprio elemento autenticador. Desta forma, se o destinatario consegue decifrar uma mensagem recebida, acredita que es-sa menes-sagem e proveniente de um originador legtimo (i.e., que possui a chave correcta). A fraqueza deste esquema e evidente: se uma dada mensagem puder ser uma sequ^encia arbitraria de bits, ent~ao e impossvel distinguir uma mensagem original de uma mensagem forjada ou adulterada em tr^ansito.

A soluc~ao deste problema passa pela adic~ao de um bloco de controle a mensagem, cuja vericac~ao, no destinatario, conrmara a pretensa origem. Actualmente, esses blocos de controle s~ao produzidos maioritariamente pela aplicac~ao de Func~oes de Hashing Unidirec-cionais26, eventualmente combinadas com encriptac~ao (ver secc~ao 2.5.2). Relativamente ao problema da Repudiac~ao, este pode ser resolvido com o auxlio de Assinaturas Digitais.

2.5.1 Func~oes de Hashing Unidireccionais Uma Func~ao de Hashing Unidireccional27

H goza das seguintes propriedades basicas [Sch96]:

dada uma entradaM, de dimens~ao arbitraria, a sadah=H(M) tem uma dimens~ao xa;

a determinac~ao deh com base em M e expedita;

e difcil determinar M com base em h; ou seja, na pratica, H n~ao e reversvel (propriedade da Unidireccionalidade);

para uma determinada mensagemM, e difcil encontrar outra mensagemM

0 tal que H(M) =H(M

0);

e difcil encontrar duas mensagens aleatorias M eM

0 tal que

H(M) =H(M 0);

i.e., H e resistente a colis~oes no espaco das imagens.

25E evidente quee vulneravel a um ataque do tipohomem{no{meio: a mensagem

Cpode ser interceptada

e substituda sem que o destinatarioBconsiga detectar esse facto.

26Do ingl^es One{Way Hash Functions. Dada a diculdade em traduzir o termoHash, optou{se pela

manutenc~ao dos termos dessa famlia na sua lngua original.

O cumprimento deciente do requisito da resist^encia a colis~ao de imagens constitui uma porta aberta a uma categoria particular de ataques denominadaataques{de{aniversario

28. Um ataque deste genero, aplicado a uma func~ao

H

m

M

M

H

M

H

M

S~ao varias as aplicac~oes das Func~oes de Hashing Unidireccionais a Autenticac~ao de mensagens (a qual ocorre frequentemente combinada com mecanismos que asseguram a Privacidade das mesmas29). Basicamente, todas elas envolvem o recalculo do

hash da mensagem pelo destinatario e sua comparac~ao com o hashque acompanha a mensagem. Se coincidirem, o destinatario conclui que n~ao so a mensagem original foi preservada en route (teste a Integridade), como tambem e proveniente de um determinado originador conhecido (Autenticac~ao).

MD5

O Message Digest #5 (MD5) [Riv92c] e um exemplo concreto de um algoritmo baseado numa Func~ao de Hashing Unidireccional, sendo, provavelmente, o mais conhecido e usado dos algoritmos desta categoria. Trata{se de uma evoluc~ao do MD4 [Riv92b], este mais rapido mas menos seguro que o MD5.

O MD5 gera uma sntese30 (uma especie de \impress~ao digital") de 128 bits de uma mensagem de dimens~ao arbitraria, tendo sido projectado para oferecer uma grande re-sist^encia a colis~oes. Todavia, tal n~ao impediu a detecc~ao recente de vulnerabilidades a esse nvel [Rob94, Dob96], sendo ja sugerida a adopc~ao de outros algoritmos em futuras aplicac~oes31.

2.5.2 Codigos de Autenticac~ao de Mensagens

Um Codigo de Autenticac~ao de uma Mensagem (MAC32) resulta da aplicac~ao de uma Func~ao de Hashing Unidireccional combinada com uma operac~ao de encriptac~ao.

A forma mais expedita de produzir um MAC consiste em cifrar com uma chave simetrica a sntese da mensagem. O destinatario, que devera tambem possuir essa chave, recalcula a sntese, cifra{a e compara{a com o MAC recebido. Se os MACs coincidirem, tal constitui prova da Integridade e Autenticidade da mensagem33.

A semelhanca das Func~oes de Hashing Unidireccionais, um esquema de produc~ao de MACs deve tambem respeitar certas propriedades, sob pena de ser vulneravel a determi-nados ataques. Assim, segundo [Sta95]:

28Do ingl^es birthday{attacks. [Sta95] descreve com algum pormenor os fundamentos matematicos e

probabilsticos deste ataque.

29[Sta95] lista algumas dessas possibilidades.

30Do ingl^esdigest, correspondente aohashde que temos vindo a falar.

31A concretizac~ao pratica da presente tese faz ainda uso do MD5 por n~ao ter aparecido, ate a data, uma

alternativa sucientemente consensual, embora seja crescente o protagonismo de algoritmos como oSecure Hash Algorithm(SHA) [oST95] ou o RIPEMD160 [DBP96].

32Do ingl^esMessage Authentication Code.

33[Sch96] refere ainda outras possibilidades para o calculo de MACs, assinalando tambem alguns ataques

dados M (mensagem) e MAC K(

M) (MAC de M baseado na aplicac~ao da chave secretaK), ent~ao o esforco computacional envolvido na determinac~ao deM

0, tal que MAC

K( M

0) = MAC

K(

M), devera ser incomportavel; MAC

K(

M) deve ser uniformemente distribudo no sentido de que, dadas duas men-sagens aleatorias M e M

0, a probabilidade de que MAC

K( M

0) = MAC

K(

M) e de 2,n (com

n= numero de bits da sntese); se M

0 =

f(M), em que f corresponde a determinada transformac~ao sobre M 34, ent~ao a probabilidade de MAC

K( M

0) = MAC

K(

M) devera ser 2

,n (ou seja, o algoritmo do MAC n~ao devera ser mais vulneravel em certas partes da mensagem do que noutras).

2.5.3 Assinaturas Digitais

Uma Assinatura Digital e uma tecnica de Autenticac~ao que pretende combater a Re-pudiac~ao, ou seja, a negac~ao da transmiss~ao de uma mensagem pelo emissor ou da sua recepc~ao pelo destinatario.

[Sta95] enumera algumas propriedades que se desejam presentes num esquema de As-sinaturas Digitais:

a assinatura deve ser uma sequ^encia de bits que depende da mensagem a assinar e de algo unico relativamente ao originador (a m de prevenir Falsicac~ao e Repudiac~ao);

a produc~ao, reconhecimento e vericac~ao de assinaturas devera ser facil;

devera ser computacionalmente impraticavel forjar uma assinatura, quer procurando uma mensagem para uma assinatura preexistente, quer gerando uma assinatura para uma mensagem preexistente;

devera ser possvel armazenar uma copia da assinatura para futura reutilizac~ao. A ttulo exemplicativo, apresenta{se, de seguida, um protocolo simples em que a Assinatura Digital resulta da aplicac~ao da chave privada do originador sobre uma sntese da mensagem. Assim, seAdeseja enviar a Buma mensagemM aberta (i.e., n~ao cifrada) mas assinada, um protocolo na direcc~ao A!Bpodera ser:

1. A eB concordam previamente num sistema assimetrico e numa Func~ao de Hashing Unidireccional,H, comuns;

2. A gera a snteseh=H(M); 3. A efectua ds=E

Kprv A(

h), gerando a assinatura digital ds; 4. A enviaMjds

35 (a mensagem e a sua assinatura digital) a B; 5. B efectua h

0 =

H(M), gerando uma sntese local,h 0; 34Por exemplo, inverter um ou mais bits especcos.

35Em que o smbolo \

6. B(que deve conhecer antecipadamenteK pub

A) efectua h=D

K pub

A(

ds), recuperando a sntese original,h;

7. Bcomparah 0 com

h; se forem iguais, ent~ao a Autenticidade deM esta comprovada. An~ao pode negar a origem da mensagem uma vez que soA(que e a unica entidade que possuiK

prv

A) poderia ter cifrado

ds de forma a que h 0 =

h.

O protocolo anterior fornece Autenticac~ao mas n~ao Privacidade, a qual pode ser con-seguida cifrando a mensagemM com uma chave simetrica comum ou com a chave publica do destinatario. E prudente que este procedimento seja extensvel a propria assinatura digitalds, ou seja, deve{se cifrar o conjuntoMjds, em vez de deixar a assinatura a desco-berto. Tal diculta a remoc~ao ou substituic~ao da assinatura por parte de um adversario. Existem ainda outras raz~oes que justicam esta pratica, entre as quais:

se a mensagem a assinar n~ao e visvel ao assinante, ent~ao a assinatura pode ter pouco valor legal [Rih94];

alguns algoritmos de chave publica, como por exemplo o RSA, s~ao vulneraveis a certos ataques quando se opta por cifrar antes de assinar [AN95].

Assim, seA deseja enviar aB uma mensagemM assinada e cifrada, um protocolo na direcc~ao A!B podera ser:

1. A eB concordam previamente num sistema assimetrico e numa Func~ao de Hashing Unidireccional,H, comuns. Dever~ao ainda conhecer as chaves publicas um do outro; 2. A efectua h=H(M), gerando a snteseh;

3. A efectua ds=E Kprv

A(

h), gerando a assinatura digital ds; 4. A efectua C=E

K pub

B(

Mjds) e enviaC jjMjdsjj 36 a

B; 5. B efectua D

Kprv B(

C) e obtem Mjds; 6. B efectua h

0 =

H(M), gerando uma sntese local,h 0; 7. B efectua h=D

K pub

A(

ds), recuperando a sntese original,h; 8. Bcomparah

0 com

h; se forem iguais, ent~ao a Autenticidade deM esta comprovada, tendo sido garantida Privacidade na sua transmiss~ao.

Estes protocolos caem na categoria dos Protocolos de Assinatura Digital Directa, as-sim designados porque o originador e o receptor da mensagem s~ao as unicas entidades participantes no protocolo. A seguranca da chave privada de cada entidade constitui o ponto crtico destes protocolos: uma entidade pode argumentar que a sua chave privada foi comprometida, repudiando assim a autoria de todas as mensagens posteriores a esse evento.

Alternativamente, um Protocolo de Assinatura Digital Arbitrada pode impedir a Re-pudiac~ao. Genericamente, sempre que o originador A pretender enviar uma mensagem

36Em que \

assinada ao destinatario B, remete{a para um arbitro C, o qual devera submeter a men-sagem a uma serie de vericac~oes que conrmem o seu conteudo e a sua origem como genunos, apos o que lhe aplica uma especie de certicado de autenticidade e a reencami-nha paraB. Desta forma, nenhum originador podera negar a autoria de uma mensagem. Porem, a presenca obrigatoria de um intermediario em qualquer troca de mensagens in-troduz novos problemas:

e difcil manter uma conanca total e permanente na entidade arbitro. Todo o esquema ruira a mnima suspeita de que o ponto intermedio foi comprometido;

uma vez que todas as mensagens s~ao serializadas atraves de um arbitro, este constitui um ponto de estrangulamento natural do sistema, n~ao so em termos de desempenho37 como de disponibilidade38.

Existem polticas de gest~ao de chaves que procuram, de alguma forma, dar uma res-posta satisfatoria a esta classe de problemas. Retomaremos este assunto na secc~ao 2.7.

2.6 Sequenciac~ao

Por vezes, n~ao basta ter a certeza de que uma mensagem recebida permaneceu secreta e ntegra e que o originador e quem arma ser (e que n~ao o pode negar). Pode ser necessario assegurar que a troca de mensagens segue uma determinada sequ^encia ou ainda que n~ao ha replicas em circulac~ao. Neste contexto, uma mensagem aut^entica devera ser rejeitada caso viole a sequ^encia ou constitua uma copia de uma mensagem recebida anteriormente39. Existem ataques, compreensivelmente denominados por ataques{de{repetic~ao40, que pretendem explorar as fraquezas de um protocolo ou algoritmo precisamente neste domnio. Basicamente, um ataque{de{repetic~ao assenta na retransmiss~ao de uma mensagem por parte de uma entidade que, de alguma forma, a interceptou. [Gon93] fornece alguns exemplos de ataques{de{repetic~ao possveis:

repetic~ao simples: uma entidade captura uma copia de uma mensagem e retransmi-te-a posteriormente, em qualquer instante;

repetic~ao limitada: uma marca temporal

41mantem{se valida nos limites de determi-nada janela de tempo, o que permite a retransmiss~ao de mensagens com essa marca, ao longo desse intervalo de tempo;

repetic~ao indetectavel: uma mensagem que foi interceptada e impedida de atingir o seu destino e posteriormente retransmitida; sob o ponto de vista do destinatario, esta mensagem corresponde a mensagem original;

repetic~ao dirigida a origem: uma mensagem e retransmitida em direcc~ao a sua ori-gem, na tentativa de a fazer passar por mensagem valida ou de provocar uma situac~ao n~ao prevista no protocolo.

37Do ingl^es performance. 38Do ingl^es availability.

39Copia exacta, entenda{se. Se houver necessidade de retransmitir uma mensagem, ela devera ser

individualizada de alguma forma, a m de se distinguir da copia anteriormente emitida.

Tradicionalmente, os mecanismos de combate a esta classe de ataques assentam na utilizac~ao de:

numeros de sequ^encia: uma mensagem e aceite se o seu numero de sequ^encia cor-responder ao esperado, o que normalmente exige que ambas as partes mantenham o registo da sequ^encia de numeros correcta, em ambos os sentidos;

marcas temporais: uma mensagem e aceite se possuir uma marca temporal (co-locada pelo originador) sucientemente proxima do tempo actual do receptor. A sincronizac~ao dos relogios de ambas as partes e, assim, um requisito fundamental a aplicac~ao desta tecnica, sendo necessarios protocolos adicionais de acesso a servido-res de tempo. Esses protocolos ja n~ao podem depender de relogios sincronizados; devem ser seguros, tolerantes a faltas e lidar com atrasos variaveis e imprevisveis na propagac~ao das mensagens;

desaos/respostas

42: uma mensagem e aceite se incluir um determinado valor que o receptor fez chegar previamente ao emissor; esse valor e gerado, no receptor, es-pecicamente para cada troca43. Note{se que n~ao e essencial que esse valor seja imprevisvel (gerado aleatoriamente, por exemplo): um simples contador pode ser-vir. Contudo, valores previsveis devem ser usados com prud^encia, uma vez que podem constituir oportunidade para ataques [AN94].

2.7 Gest~ao de Chaves

A gest~ao de chaves diz respeito aos seus processos de gerac~ao, transmiss~ao e armazena-mento e e, reconhecidamente, uma das tarefas mais arduas da Criptograa. Com efeito, de nada valem protocolos sosticados e algoritmos seguros se as respectivas chaves forem comprometidas. Dado que e precisamente na gest~ao de chaves que muitos ataques se con-centram, ela deve ser feita com um grau de seguranca n~ao inferior aquele que se exige para os dados que essas chaves protegem.

2.7.1 Gerac~ao

Um bom algoritmo de gerac~ao de chaves n~ao deve ser permeavel a analise criptograca, ou seja, n~ao devera ser possvel a determinac~ao de chaves com base na analise algortmica do seu processo de gerac~ao. Obviamente, a concretizac~ao do algoritmo tambem devera estar a altura das qualidades que governaram a sua concepc~ao. Factores como a dimens~ao do espaco das chaves (que determina a viabilidade de um ataque exaustivo, pela forca bruta), a vulnerabilidade a ataques{de{dicionario44 e o grau de aleatoriedade (quando necessaria) das chaves determinam a ecacia de um algoritmo de gerac~ao de chaves. Acresce ainda que ha algoritmos para os quais certas chaves s~ao consideradas \fracas" (como e o caso de DES [MS87]), no sentido de que a sua utilizac~ao pode ser detectada, sendo por isso

42Do ingl^es

challenges/responses. 43Diz{se que e um

valordeocasi~ao(do ingl^esnonce). 44Do ingl^es

dictionary{attacks. S~ao ataques baseados numa selecc~ao de chaves comummente usadas e

podem ser bastante ecazes: [Kle90] descreve uma aplicac~ao deste metodo sobrepasswordscom uma taxa

fortemente desaconselhada. Finalmente, a propria gerac~ao das chaves pode ser difcil se lhes forem exigidas determinadas propriedades matematicas (recordem{se, por exemplo, os requisitos do RSA em termos de numeros primos grandes, cujo produto devera ser difcil de factorizar).

2.7.2 Transmiss~ao

A troca de chaves entre duas entidades a m de estabelecerem um canal seguro e a sub-miss~ao de uma chave a uma entidade que proceda a sua certicac~ao45 (e eventualmente armazenamento) s~ao, entre outras, circunst^ancias em que se da lugar ao tr^ansito de uma chave, provavelmente atraves de um meio hostil. Consequentemente, torna-se necessario providenciar mecanismos de transmiss~ao segura das chaves. Esses mecanismos variam conforme o tipo de chaves em quest~ao.

Troca de Chaves Simetricas

Para chaves simetricas, [Sta95] assinala as seguintes alternativas basicas:

1. a entidadeAselecciona uma chave e entrega{a a entidadeBatraves de um encontro face{a{face ou de outra tecnica de distribuic~ao manual;

2. uma terceira entidade C gera a chave e entrega{a a A e a B tambem segundo uma tecnica de distribuic~ao manual;

3. seAeB ja partilham uma chave, esta pode ser usada para proteger a troca de uma nova chave. Nesta perspectiva, as chaves tambem podem classicar{se em chaves--de{encriptac~ao{de{chaves46 (usadas para proteger a distribuic~ao de outras chaves, sendo distribudas manual e pouco frequentemente) e chaves{de{dados47 (usadas para proteger o trafego dito \normal");

4. se A e B ja det^em um canal seguro com C, ent~ao podem trocar{se chaves atraves desse canal. A entidade C e vulgarmente designada por Centro de Distribuic~ao de Chaves(KDC)48e partilha com cada entidade uma chave mestra49. Genericamente, quando uma entidade pretende estabelecer com outra(s) um canal seguro, solicita ao KDC uma chave{de{sess~ao50que devera ser comunicada (pelo KDC ou pela entidade que tomou a iniciativa) a todas as partes interessadas. Todas as mensagens trocadas entre uma entidade e o KDC s~ao cifradas com base na chave mestra que partilham. Obviamente, este esquema pressup~oe uma distribuic~ao inicial segura (possivelmente manual) das chaves mestras. E ainda possvel (e ate desejavel, n~ao so em termos de distribuic~ao de carga, como tambem em termos de seguranca51) uma gest~ao distri-buda das chaves, baseada numa hierarquia de KDCs, cada qual responsabilizando{se 45O conceito de certicac~ao sera esclarecido ainda nesta secc~ao.

46Do ingl^eskey{encryption keys. 47Do ingl^esdata keys.

48Do ingl^esKey Distribution Center. 49Do ingl^esmaster key.

50Do ingl^essession key.

51Um ataque bem sucedido a um KDC que concentre todas as chaves e potencialmente mais grave que

por determinado domnio: duas entidades em domnios diferentes poderiam ainda estabelecer um canal seguro se os KDCs respectivos cooperarem nesse sentido.

Troca de Chaves Assimetricas

Ao permitirem a divulgac~ao publica de uma das chaves, os sistemas assimetricos resolvem o principal \quebra{cabecas" dos sistemas simetricos: como criar um canal seguro sem depender de uma troca segura de chaves52? No contexto dos sistemas assimetricos, a distribuic~ao de chaves envolve n~ao so as chaves publicas, mas tambem possveis aplicac~oes a distribuic~ao de chaves simetricas. Em relac~ao a distribuic~ao de chaves publicas, [Sta95] resume as tecnicas conhecidas nas seguintes categorias:

an uncio p ublico: uma entidade anuncia publicamente

53a sua chave publica. Contu-do, esse anuncio pode ser forjado: a entidadeA pode fazer{se passar pela entidade B e anunciar uma chave publica que, na realidade, n~ao e de B. Nitidamente, esta tecnica carece de alguma forma de Autenticac~ao;

directoria de chaves p ublicas: uma determinada entidade, universalmente conavel, e responsavel pela manutenc~ao de uma base de dados/directoria (possivelmente dis-tribuda) que armazena as chaves publicas de todas as entidades que se registaram (supostamente de forma segura e autenticada54). Sempre que uma entidade necessi-ta de uma cernecessi-ta chave publica, pode solicinecessi-ta{la a directoria (atraves de um protocolo seguro, necessariamente) ou consultar uma copia da directoria se esta for periodica-mente publicada. Em qualquer altura, uma entidade pode requisitar, na directoria, a substituic~ao da sua chave publica por outra. Os ataques mais obvios a este esquema concentram{se na determinac~ao da chave privada da autoridade que mantem a direc-toria ou na substituic~ao de entradas da base de dados55. E possvel considerar ainda uma variante mais robusta da directoria de chaves p ublicas: a autoridade para as chaves p ublicas, em que se assegura que a chave publica da autoridade que mantem a directoria chega ao conhecimento de cada entidade atraves de um procedimento seguro e autenticado;

certicados: nos esquemas centralizados descritos anteriormente, a requisic~ao da cha-ve publica de uma entidade junto de uma autoridade central antecede, pelo menos, o primeiro contacto com essa entidade. A autoridade central pode, por conseguinte, ser bastante sobrecarregada. Uma alternativa que minimiza a intervenc~ao de ter-ceiros consiste na certicac~ao das chaves publicas; ou seja, cada entidade submete (atraves de um protocolo seguro e autenticado) a sua chave publica a umaautoridade de certicac~ao

56, a qual comprova a origem da chave e lhe acrescenta determinada informac~ao de controle (como por exemplo uma assinatura baseada na sua chave privada e ainda um perodo de validade). Este certicado e devolvido a entidade 52Dito de outra forma: \como criar um canal seguro sem ter, a partida, um canal seguro"?

53Atraves da sua pagina WWW ou de um grupo de

news, por exemplo. 54Atraves de um encontro face{a{face, por exemplo.

55Em ambos os casos seria ent~ao possvel disseminar falsas chaves publicas e consequentemente ter acesso

as mensagens cifradas com base nessas chaves.

56Que n~ao e necessariamente unica. Em geral, esta autoridade fara parte de uma hierarquia de

que o requisitou, a qual podera exibi{lo junto de outra entidade a m de comprovar a associac~ao do seu nome a chave publica em quest~ao57. Essa comprovac~ao serve{se da chave publica da autoridade de certicac~ao, supostamente conhecida por todas as entidades (e, obviamente, certicada). Resumidamente, os requisitos mnimos de um esquema de certicac~ao s~ao:

{

{

{

{

Troca de Chaves Simetricas com base em Chaves Assimetricas

Com base numa infra{estrutura pre{montada de chaves assimetricas, e possvel levar a cabo a distribuic~ao de chaves simetricas de uma forma segura e autenticada.

O protocolo que a seguir se apresenta e uma evoluc~ao do protocolo apresentado na secc~ao 2.4 e demonstra a aplicac~ao deste conceito. Assim, se A deseja enviar a B uma chave de sess~ao simetricaK, combinando Condencialidade, Autenticac~ao (incluindo N~ao--Repudiac~ao), Integridade e Sequenciac~ao, ent~ao um protocolo na direcc~aoA!Bpodera ser:

1. A eB concordam previamente num sistema assimetrico e numa Func~ao de Hashing Unidireccional,H, comuns. Dever~ao ainda conhecer as chaves publicas, um do outro, devidamente certicadas;

2. A constroi a mensagemM =id A

jK AB

jt

A, em que id

A corresponde ao identicador da entidadeApresente no certicado da sua chave publica,K

AB e a chave de sess~ao et

Ae uma marca temporal (ou contador, caso os relogios de

AeBn~ao se suponham sincronizados) que identica esta transacc~ao;

3. A gera a snteseh=H(M) e a assinatura digital ds=E Kprv

A( h); 4. A efectua C=E

K pub

B(

Mjds) e enviaC jjMjdsjja B; 5. B efectua D

Kprv B(

C) e obtem Mjdsid A jK AB jt A jds; 6. B constata, pela leitura deid

A, que, aparentemente, a mensagem vem de A

58 e ve-rica se possui uma copia do certicado da chave publica deA. Em caso negativo, 57Note{se que a posse de um certicado n~ao implica a posse da chave privada correspondente a chave

publica certicada. Basta recordar que os certicados podem circular livremente, uma vez que a informac~ao que encerram e publica. Um certicado estabelece apenas uma associac~ao entre um identicador | da entidade que solicitou a certicac~ao | e uma chave publica, associac~ao essa que devera ter sido vericada pela autoridade de certicac~ao.

58Facto do qual ainda n~ao pode ter a certeza, ja que

idA pode ter sido forjado ou adulterado em

tr^ansito. Contudo, se isso tiver acontecido, a vericac~ao da assinatura digitaldsira falhar, detectando{se