0 evaluări0% au considerat acest document util (0 voturi)
59 vizualizări162 pagini
Este documento descreve um projeto de infraestrutura de chaves públicas (ICP) privada para ambientes corporativos. O projeto inclui a criação de uma autoridade certificadora interna para a empresa e um aplicativo para gerenciar chaves públicas e privadas para criptografia assimétrica de dados, prover integridade, autenticidade e não-repúdio às informações dentro da corporação.
Este documento descreve um projeto de infraestrutura de chaves públicas (ICP) privada para ambientes corporativos. O projeto inclui a criação de uma autoridade certificadora interna para a empresa e um aplicativo para gerenciar chaves públicas e privadas para criptografia assimétrica de dados, prover integridade, autenticidade e não-repúdio às informações dentro da corporação.
Drepturi de autor:
Attribution Non-Commercial (BY-NC)
Formate disponibile
Descărcați ca PDF, TXT sau citiți online pe Scribd
Este documento descreve um projeto de infraestrutura de chaves públicas (ICP) privada para ambientes corporativos. O projeto inclui a criação de uma autoridade certificadora interna para a empresa e um aplicativo para gerenciar chaves públicas e privadas para criptografia assimétrica de dados, prover integridade, autenticidade e não-repúdio às informações dentro da corporação.
Drepturi de autor:
Attribution Non-Commercial (BY-NC)
Formate disponibile
Descărcați ca PDF, TXT sau citiți online pe Scribd
FAET - FACULDADE DE CINCIAS EXATAS E TECNOLOGIA CURSO DE ENGENHARIA DA COMPUTAO
UMA ABORDAGEM DE INFRA-ESTRUTURA DE CHAVES PBLICAS PARA AMBIENTES CORPORATIVOS
BRASLIA DF 2004 www .ProjetodeRedes .com.br Outros trabalhos em: ii UNICEUB CENTRO UNIVERSITRIO DE BRASLIA FAET - FACULDADE DE CINCIAS EXATAS E TECNOLOGIA CURSO DE ENGENHARIA DA COMPUTAO
UMA ABORDAGEM DE INFRA-ESTRUTURA DE CHAVES PBLICAS PARA AMBIENTES CORPORATIVOS
por
BRUNO DE MELO SILVA 9965620 FAET UNICEUB
Projeto Final de Graduao
Prof. MC./XL] 2WDYLR %RWHOKR /HQWR Orientador
Braslia/DF, junho de 2004.
i Agradecimentos
Aos meus pais, Luiz Carlos da Silva e Jacira de Melo Silva, por sua compreenso, apoio fraterno e dedicao.
Ao meu filho Pedro de Matta e Melo Silva, pelos momentos de descontrao e ensinamentos que s uma criana pode proporcionar.
minha namorada Soraya Chaibub Arajo de Lemos, pela pacincia e incentivo, alm de todo o apoio nestes cinco longos anos.
Ao professor Luiz Otavio, por sua orientao e sbias sugestes que foram fundamentais para a elaborao do projeto.
Ao meu irmo Vitor de Melo Silva, que nos deixou muito cedo, mas de certa forma continua conosco nesta jornada.
A todos os meus colegas e professores que participaram dessa maratona acadmica e que espero na minha formatura.
A todos os meus familiares que me apoiaram e ajudaram em alguns momentos difceis durante minha formao.
ii Resumo
Este trabalho visa o estudo dos padres e definies de uma Infra-estrutura de Chaves Pblicas (ICP) no modelo hierrquico e o desenvolvimento de um projeto de uma Infra- estrutura de Chaves Pblicas privada para ambientes corporativos, de forma a implantar uma poltica de segurana e prover um aplicativo com as funcionalidades necessrias para a utilizao dessa infra-estrutura. O projeto abrange a criao de uma Autoridade Certificadora interna a uma empresa e a implantao de um aplicativo para efetivar o gerenciamento de chaves pblicas e privadas e utilizao das mesmas para criptografia assimtrica dos dados. Este trabalho ir prover integridade, autenticidade e no-repdio s informaes dentro de uma corporao, diminuindo os prejuzos relativos a algumas fraudes eletrnicas, aumentando a segurana na guarda e trfego de informaes e evitando o gasto de se contratar uma Autoridade Certificadora externa.
Palavras-chave: ICP, certificados, AC, confidencialidade, no-repdio. iii LISTA DE FIGURAS
FIGURA 1 - CRIPTOGRAFIA SIMTRICA..................................................................................... 6 FIGURA 2 CRIPTOGRAFIA ASSIMTRICA.............................................................................. 10 FIGURA 3 - PROCESSO DE VERIFICAO DE ASSINATURA DIGITAL. ........................................ 13 FIGURA 4 CONFIDENCIALIDADE DOS DADOS........................................................................ 15 FIGURA 5 - NO-REPDIO ..................................................................................................... 16 FIGURA 6 - CONFIDENCIALIDADE, AUTENTICIDADE E NO-REPDIO...................................... 17 FIGURA 7 - ARQUITETURA HIERRQUICA .............................................................................. 20 FIGURA 8 - ARQUITETURA MISTA.......................................................................................... 22 FIGURA 9 - CERTIFICADO DIGITAL PADRO X.509 (CERTIFICADO RAIZ DA ICP-BRASIL) ........ 24 FIGURA 10 - CERTIFICADO DIGITAL X.509 ............................................................................ 28 FIGURA 11 - HIERARQUIA DA ICP-BRASIL............................................................................. 34 FIGURA 12 - FLUXOGRAMA DE GERAO DE CERTIFICADO..................................................... 39 FIGURA 13 - FLUXOGRAMA DE TROCA DE CHAVES CRIPTOGRFICAS....................................... 40 FIGURA 14 - FLUXOGRAMA DE GERAO DE MENSAGENS....................................................... 42 FIGURA 15 - FLUXOGRAMA DE RECEBIMENTO DE MENSAGENS................................................ 43 FIGURA 16 - INSTALAO DO JAVA ....................................................................................... 51 FIGURA 17 - TELA PRINCIPAL DO MDULO CLIENTE............................................................... 56 FIGURA 18 - GERAO DA CSR ............................................................................................ 57 FIGURA 19 - IMPORTAO DE CERTIFICADOS......................................................................... 58 FIGURA 20 - EXPORTAO DE UM CERTIFICADO DIGITAL........................................................ 59 FIGURA 21 - ASSINATURA E CIFRAGEM DE UMA MENSAGEM................................................... 60 FIGURA 22 - CONFERNCIA E DECIFRAGEM DE UMA MENSAGEM............................................. 61 FIGURA 23 - TELA PRINCIPAL DO MDULO AC....................................................................... 62 FIGURA 24 - GERAO DE CERTIFICADOS DIGITAIS ................................................................ 63 FIGURA 25 - REVOGAO DE CERTIFICADOS DIGITAIS............................................................ 63
iv LISTA DE TABELAS
TABELA 1 ESTRUTURA DO X.509 V3................................................................................... 25 TABELA 2 DEFINIO DOS PROTOCOLOS PKCS................................................................... 29 TABELA 3 - PROTOCOLO PKCS #10 ...................................................................................... 30 TABELA 4 - TIPOS DE CERTIFICADOS...................................................................................... 33 TABELA 5 - POLTICAS DE CERTIFICADOS DAS ACS DA ICP-BRASIL....................................... 34 v Sumrio
AGRADECIMENTOS......................................................................................................... I RESUMO.............................................................................................................................II LISTA DE FIGURAS ....................................................................................................... III LISTA DE TABELAS....................................................................................................... IV 1 ~ INTRODUAO..............................................................................................................1 2 ~ CRIPTOGRAFIA...........................................................................................................3 2.1 - AS RAZES DA CRIPTOGRAFIA....................................................................................... 3 2.2 - O OBJETIVO DA CRIPTOGRAFIA .................................................................................... 5 2.3 - ALGORITMOS SIMTRICOS ........................................................................................... 6 2.4 - ALGORITMOS ASSIMTRICOS ....................................................................................... 9 2.5 - ASSINATURA DIGITAL................................................................................................ 11 2.5.1 - HASH................................................................................................................ 13 2.6 - CONFIDENCIALIDADE, AUTENTICIDADE, NO-REPDIO............................................... 15 2.6.1 Confiaencialiaaae............................................................................................. 15 2.6.2 - No-repuaio ...................................................................................................... 16 2.6.3 - Confiaencialiaaae, Autenticiaaae e No-Repuaio .............................................. 17 3 ~ ICP................................................................................................................................ 18 3.1 A ARQUITETURA DE UMA ICP ................................................................................... 19 3.1.1 - Arquitetura Hierarquica.................................................................................... 19 3.1.2 - Arquitetura Mista .............................................................................................. 22 3.2 - CERTIFICADOS DIGITAIS PARA USURIOS (MODELO X.509) ........................................ 23 3.3 PROTOCOLOS PKCS ................................................................................................. 29 3.3.1 - PKCS !10.......................................................................................................... 30 3.3.2 - PKCS !7............................................................................................................ 30 3.4 - ICP BRASIL E POLTICAS DE SEGURANA DE UMA AC ................................................ 32 3.!.1 - Segurana Fisica ae uma AC............................................................................. 35 4 ~ UMA ABORDAGEM DE ICP PARA AMBIENTES CORPORATIVOS................. 37 4.1 FLUXOGRAMA............................................................................................................. 39 !.1.1 Gerao ao Certificaao Digital......................................................................... 39 !.1.2 Troca ae chaves criptograficas ......................................................................... !0 !.1.3 Envio ae mensagens.......................................................................................... !2 !.1.! Recebimento ae mensagens............................................................................... !3 4.2 POLTICAS DE SEGURANA ....................................................................................... 45 !.2.1 - Consiaeraes Gerais........................................................................................ !5 !.2.2 - REQUISITOS DE SEGURANA DO AMBIENTE FISICO................................ !6 !.2.3 - REQUISITOS DE SEGURANA DO AMBIENTE LOGICO.............................. !7 4.3 - REQUISITOS E INSTALAO ....................................................................................... 49 !.3.1 - Pre-Requisitos para a Autoriaaae Certificaaora................................................ !9 !.3.2 - Instalao aa AC............................................................................................... 50 !.3.3 - Pre-Requisitos para o Cliente............................................................................ 5! !.3.! - Instalao ao Cliente......................................................................................... 55 4.4 - UTILIZAO DA ICP PROJETADA ............................................................................... 56 !.!.1 O moaulo Cliente.............................................................................................. 56 vi !.!.1.1 Requisio ae Certificaaos............................................................................. 57 !.!.1.2 Importao ae Certificaaos Digitais............................................................... 58 !.!.1.3 Exportao ao Certificaao Digital ................................................................. 59 !.!.1.! Gerao ae uma Mensagem Assinaaa e Cifraaa............................................. 60 !.!.1.5 Recepo ae mensagem assinaaa e cifraaa .................................................... 61 !.!.2 O moaulo AC.................................................................................................... 62 !.!.2.1 Gerao ae Certificaaos Digitais................................................................... 63 !.!.2.2 Revogao ae Certificaaos............................................................................. 63 4.5 - DECISES DE PROJETO .............................................................................................. 64 !.5.1 - Quanto a estrutura ............................................................................................ 6! !.5.2 - Quanto a politica ae segurana ......................................................................... 6! !.5.3 - Quanto ao aesenvolvimento em linguagem JAJA............................................... 65 !.5.! - Quanto as bibliotecas aa Bouncy Castle ............................................................ 66 !.5.5 - Quanto ao sistema operacional.......................................................................... 66 !.5.6 - Quanto ao algoritmo RSA.................................................................................. 67 5 ~ CONCLUSAO.............................................................................................................. 68 IMPLEMENTAES FUTURAS.............................................................................................. 69 6 ~ REFERNCIAS BIBLIOGRFICAS......................................................................... 71 7 ~ BIBLIOGRAFIA.......................................................................................................... 72 8 ~ ANEXOS....................................................................................................................... 73 ANEXO A CDIGO FONTE DO MDULO AUTORIDADE CERTIFICADORA .......................... 73 Main.fava ..................................................................................................................... 73 ControleCA.fava........................................................................................................... 7! Principal.Java.............................................................................................................. 76 GeraCert.Java.............................................................................................................. 78 RevogarCert.Java......................................................................................................... 82 ANEXO B CDIGO FONTE DO MDULO CLIENTE............................................................ 86 Main.Java..................................................................................................................... 86 ControleCliente.Java.................................................................................................... 87 Principal.Java.............................................................................................................. 93 GeraCSR.Java.............................................................................................................. 96 Importacao.Java......................................................................................................... 100 Exportacao.Java......................................................................................................... 102 EnviaMsg.fava............................................................................................................ 106 ReceberMsg.Java ....................................................................................................... 112 ANEXO C MTODOS PARA GERENCIAMENTO DA ICP................................................... 117 Base6!Decoaer.Java.................................................................................................. 117 Base6!Encoaer.Java .................................................................................................. 121 Base6!FormatException.Java .................................................................................... 125 UtilRSAPrivateCrtKey.Java........................................................................................ 126 UtilRSAPrivateKey.Java............................................................................................. 130 UtilRSAPublicKey.Java.............................................................................................. 132 MsgUtils.Java............................................................................................................. 135 Utils.Java ................................................................................................................... 1!0 FileUtils.Java............................................................................................................. 153 GuiUtils.fava.............................................................................................................. 15!
1 1 ~ Introduao
Com o espantoso crescimento da informtica e, posteriormente, o surgimento da Internet, a troca de informaes atravs dos meios digitais se expandiu rapidamente. Empresas passaram a depender exclusivamente dessa tecnologia, agilizando seus negcios e expandindo suas abrangncias no mercado. A comunicao se tornou simples, eficiente e barata. O comrcio eletrnico, dependente dessa comunicao, foi responsvel por cerca de US$100 bilhes em vendas, durante 1999. Com esse crescimento, surgiram os problemas e os riscos de segurana. Diversos tipos de fraudes foram desenvolvidos se aproveitando de falhas na segurana. O setor de tecnologia de segurana passou por um crescimento explosivo em um curto perodo de tempo, devido a essas falhas de segurana. Variando desde novos desenvolvimentos em hardware criptogrficos at o uso de cartes em infra-estruturas de chaves pblicas, essa indstria continua aumentando a sua abrangncia. As empresas comearam a se deparar com problemas como documentos internos fraudados ou mesmo alterados. Dados cruciais de empresas, funcionrios e clientes precisavam de uma segurana confivel, onde a leitura ou alterao de tais dados fossem restritos. Surgiu a necessidade de se enviar informaes onde apenas o destinatrio fosse capaz de ler. E, alm disso, surgiu a questo de como se faria uma transao garantindo um dos lados, ou seja, como seria possvel garantir que a empresa ou cliente que enviou aquele documento, era ele mesmo (No-repdio). A criptografia, inicialmente criada com finalidade governamental, foi utilizada para resolver esses problemas. A criptografia simtrica surgiu garantindo o sigilo dos dados enviados. Somente a outra parte poderia ler o documento. Mas algumas dificuldades surgiram na utilizao dessa tcnica. A troca da chave utilizada na criptografia se mostrava insegura, j que a chave a mesma para os dois lados de uma transao. E, alm desse problema de distribuio das chaves, ainda existia o fato de que para cada participante do ciclo de informaes deveria ser criada uma nova chave criptogrfica para a troca de mensagens. O conceito de criptografia simtrica tambm no poderia garantir a autenticidade do remetente de uma mensagem. Estes problemas s vieram a ser superados com um novo conceito de cifragem chamado de criptografia assimtrica. www .ProjetodeRedes .com.br Outros trabalhos em: 2 Essa criptografia garante o sigilo do dado enviado, a autenticidade e, principalmente, garante a identidade do indivduo participante do ciclo da informao. Apenas o par da chave criptogrfica criada pode desfazer a cifragem da outra chave. A criptografia de chaves assimtricas ainda precisava ser aprimorada. Um indivduo mal intencionado poderia gerar um par de chaves e enviar a sua chave pblica para outros, se passando por algum que ele no . Ou ento poderia interceptar uma chave pblica em trnsito e o lado que deveriam receber a chave pblica do primeiro, receberia a chave pblica do indivduo que esta intermediando a comunicao. Era preciso que um terceiro participante, que fosse confivel pelos outros dois, fosse criado. Esse terceiro iria validar os outros dois, permitindo assim, a troca de informaes segura. A infra-estrutura de chave pblica foi desenvolvida com essa base. Com diversos tipos e modos de aplicao, sua utilizao cresce cada vez mais no mercado. Foram criadas as Autoridades Certificadoras (AC) para executarem essa tarefa de validao. Os certificados digitais surgiram guardando as informaes dos indivduos. Aps a assinatura digital de uma AC confivel em um certificado digital, o receptor desse certificado poderia validar a confiabilidade deste, utilizando a chave pblica da AC que o assinou. Lembre-se que as chaves pblicas so expostas a qualquer um. Da surgiu o seu nome, que caracteriza essa propriedade. O sistema de assinatura digital, os certificados digitais e os outros participantes dessa infra-estrutura passam a ter abordagens legislativas. Atualmente, o detentor de uma chave privada totalmente responsvel por ela, podendo responder a processos jurdicos, caso seja feito mau uso da mesma. Este trabalho visa realizar um estudo sobre infra-estrutura de chaves pblicas em um ambiente corporativo, permitindo a troca segura e confivel de informaes dentro de uma empresa. Qualquer corporao pode se tornar a sua Autoridade Certificadora, gerando certificados para seus funcionrios e, se desejar, para seus clientes e parceiros comerciais, reduzindo o custo de se implementar uma estrutura de chaves publicas j preparada por uma AC comercial, como a VeriSign.
3 2 ~ Criptografia
A palavra criptografia tem origem grega (kriptos = escondido, oculto e grifo = grafia, escrita) e define a arte ou cincia de escrever em cifras ou em cdigos, utilizando um conjunto de tcnicas que torna uma mensagem incompreensvel, chamada comumente de texto cifrado, atravs de um processo chamado cifragem, permitindo que apenas o destinatrio desejado consiga decodificar e ler a mensagem com clareza, no processo inverso, a decifragem. Criptografia a cincia de escrever ocultamente e hoje, sem dvida, a maneira mais segura de se enviar informaes atravs de um canal de comunicao inseguro como, por exemplo, a Internet. A criptografia representa um conjunto de tcnicas que so usadas para manter a informao segura. Estas tcnicas consistem na utilizao de chaves e algoritmos de criptografia. Tendo conhecimento da chave e do algoritmo usado possvel desembaralhar a mensagem recebida.[1] Fica claro que o objetivo transformar palavras escritas de forma a tornarem ilegveis para receptores no autorizados. O destinatrio autorizado pode transformar a palavra recebida novamente em mensagem compreensvel. Por exemplo, esta uma mensagem a ser cifrada: "A mudana de regra est nos obrigando a fazer essa enriquecedora monografia"
Esta a mensagem j cifrada: "~k&*(d)(*&%$jrijgo~oruTkh*,MjHbbvRyh565$#$$%7><><;;^{+--"."
2.1 - As razes da criptografia
A idia da criptografia tem milhares de anos: generais gregos e romanos usaram a criptografia para enviar mensagens em cdigo aos comandantes de campo. Estes sistemas antigos eram baseados em duas tcnicas: substituio e transposio. A SUBSTITUIAO baseia-se na troca de cada letra ou grupo de letras da mensagem de acordo com uma tabela de substituio. As substituies podem ser subdivididas em:
4 1. Substituiao simples ou monoalfabtica: o tipo de cifra na qual cada letra da mensagem substituda por outra, de acordo com uma tabela baseada geralmente num deslocamento da letra original dentro do alfabeto. A cifragem de (Lolius Caessar) Jlio Csar que no confiava em seus mensageiros, por exemplo, substitua a letra "A" por "D", "B" por "E" e assim por diante. S aqueles que conheciam a regra "desloque 3 frente" podia decifrar a mensagem original. Algumas cifras de substituio usam o mesmo esquema de substituio para todas as letras; outros usam esquemas diferentes para letras diferentes; 2. Substituiao monofnica: funciona como a substituio monoalfabtica, mas cada caracter da mensagem original pode ser mapeado para um ou vrios caracteres na mensagem cifrada. Por exemplo, a letra A seria substituda pelos nmeros 7, 34 ou 78. 3. Substituiao polialfabtica: consiste em utilizar vrias cifras de substituio simples, em que as letras ou blocos da mensagem so substitudos por valores diferentes; 4. Substituiao de polgramos ou blocos: utiliza um grupo de caracteres ao invs de um nico caractere individual para a substituio da mensagem. Por exemplo, "ABA" pode corresponder a "ME" e "ABB" corresponder a "JKI"; 5. Substituiao por deslocamento: ao contrrio da cifra de Csar, no usa um valor fixo para a substituio de todas as letras. Cada letra tem um valor associado para a rotao atravs de um critrio. Por exemplo, cifrar a palavra "CARRO" utilizando o critrio de rotao "023", seria substituir "C" pela letra que est 0(zero) posies frente no alfabeto, o "A" pela letra que est 2 (duas) posies a frente, e assim por diante, repetindo-se o critrio se necessrio, gerando, assim, o criptograma "CCURQ". A TRANSPOSIAO baseia-se na mistura dos caracteres da mensagem. Temos como exemplo de um sistema de transposio em que a mensagem escrita em uma tabela linha por linha e depois lida coluna por coluna. No incio do sculo XX, vrios mecanismos eletromecnicos foram construdos na Europa e nos Estados Unidos com a finalidade de codificar mensagens enviadas por telgrafo ou por rdio. Estes sistemas baseavam-se principalmente na substituio, pois no havia uma forma especfica para armazenar uma mensagem inteira usando tcnicas de transposio. Hoje em dia, algoritmos de criptografia executados em computadores digitais de alta velocidade usam combinaes de transposio e substituio, assim como outras funes matemticas.[1] 5 2.2 - O objetivo da criptografia
O objetivo da criptografia tornar impossvel a recuperao de um texto em claro a partir de um texto cifrado sem a chave correspondente e, alm disso, dificultar ao mximo a chance de que se descubra sem autorizao qual a chave que tornaria isso possvel. Muitos sistemas modernos de criptografia realizam essa tarefa com facilidade. De fato, existem atualmente algoritmos criptogrficos sem falhas conhecidas disponveis para serem utilizados. Os sistemas modernos de criptografia consistem de dois processos complementares: Cifragem: Processo pelo qual uma mensagem (o texto em claro) transformada em uma segunda mensagem (o texto cifrado) usando uma funo complexa (o algoritmo de criptografia) e uma chave criptogrfica especial;
Decifragem: O processo inverso, pelo qual o texto cifrado transformado no texto em claro usando uma segunda funo complexa e uma chave de decifragem. Em alguns sistemas criptogrficos a chave criptogrfica e a chave de decifragem so iguais, em outros, diferentes. A tendncia atual utilizar algoritmos conhecidos e largamente testados, cuja eficcia e robustez sejam comprovadas, sendo que a segurana reside totalmente na chave secreta, que o parmetro da funo. Esta chave numrica deve ter tamanho suficiente para evitar sua descoberta por teste exaustivo pois, como o algoritmo conhecido, pode ser utilizado para combinar todas os possveis valores da chave secreta. As chaves devem ter, portanto, um tamanho que inviabilize este tipo de ataque, exigindo do atacante um tempo de processamento excessivamente longo, mesmo utilizando capacidade computacional elevada. Os algoritmos criptogrficos so classificados em simtricos e assimtricos, sendo que cada esquema tem vantagens e desvantagens, e a abordagem utilizada normalmente combin-los de modo adequado, para eliminar as desvantagens de cada um e aproveitar suas vantagens comparativas.
6 2.3 - Algoritmos simtricos
Estes so os algoritmos convencionais de criptografia, onde a mesma chave secreta utilizada tanto para cifrar como para decifrar uma mensagem, devendo ser conhecida por ambos os lados do processo. Este o grande problema do mtodo, pois a chave tem de ser entregue aos participantes de modo seguro, e as transaes s podem ser realizadas depois disso.
Figura 1 - Criptografia Simtrica
O fato de ambos os lados conhecerem a chave tambm leva possibilidade de repdio da transao, pois um lado pode sempre alegar que o outro usou a chave e realizou a transao em seu nome, indevidamente. Como cada par de participantes deve ter uma chave prpria, o nmero de chaves necessrias para comunicao segura entre muitos participantes cresce combinatoriamente, com agravante adicional de que todas essas chaves so secretas e devem ser protegidas adequadamente. Ou seja, um participante do ciclo de criptografia dever ter a chave de todos os outros para se comunicar com cada um deles. Isso inviabiliza o uso destes algoritmos isoladamente em certas aplicaes. Os algoritmos de chave simtrica so usados para cifrar a maioria dos dados ou fluxos de dados. Estes algoritmos so projetados para serem bem rpidos e (geralmente) terem um grande nmero de chaves possveis. Os melhores algoritmos de chave simtrica oferecem boa segurana quando os dados so cifrados com determinada chave, e dificilmente pode-se decifrar os dados sem possuir a mesma chave. Como a criptografia sempre uma carga 7 adicional ao processamento, esta vantagem importante e dever ser utilizada adequadamente. Os algoritmos de chave simtrica podem ser divididos em duas categorias: de bloco e de fluxo.
Algoritmos de bloco: Cifram os dados a partir de blocos, ou seja, se o dado a ser cifrado um texto, esse texto ser dividido em blocos e a criptografia ser aplicada em cima de cada bloco. Um problema com essa cifragem que se o mesmo bloco de texto simples aparecer em dois lugares, ele encriptar o mesmo texto, gerando assim, um padro de repetio.
Algoritmos de fluxo: Cifram os dados byte a byte. O dado a ser criptografado no cifrado por blocos, como o anterior e sim, serialmente. A informao vai sendo criptografada do inicio ao fim, sem separaes.[2] H muitos algoritmos de chave simtrica em uso atualmente. Alguns dos algoritmos mais comuns no campo da segurana so:
DES - o Padro para Criptografia de Dados (Data Encryption Standard) foi adotado como padro pelo governo dos EUA em 1977, e como padro ANSI em 1981. O DES um algoritmo de bloco que usa uma chave de 56 bits e tem diferentes modos de operao, dependendo da finalidade com que usado. O DES um algoritmo poderoso, mas o seu reinado no mercado comeou a ruir em janeiro/1997, quando a empresa RSA Data Security Inc. (que detm a patente do sistema criptogrfico RSA) - decidiu colocar o DES prova, oferecendo um prmio de US$ 10 mil primeira pessoa ou instituio que decifrasse uma frase criptografada com o DES (vencido o primeiro desafio, a RSADSI decidiu repeti-lo a cada semestre, condicionando o pagamento do prmio quebra do recorde de tempo estabelecido at o momento). Atualmente uma mquina preparada para a tarefa capaz de decifrar uma mensagem cifrada com o DES em poucas horas.
DESX - uma simples modificao do algoritmo DES, constituda em duas etapas. Este mtodo parece melhorar a segurana do algoritmo, dificultando a busca da chave.
Triple-DES - uma maneira de tornar o DES pelo menos duas vezes mais seguro, usando o algoritmo de criptografia trs vezes, com trs chaves diferentes. Usar o DES duas vezes com duas chaves diferentes no aumenta tanto a segurana quanto se poderia pensar devido a um 8 tipo terico de ataque conhecido como meet-in-the-midle (encontro no meio), com o qual o atacante tenta cifrar o texto limpo simultaneamente com uma operao do DES e decifrar o texto com outra operao, at que haja um encontro no meio. Atualmente, o Triple-DES est sendo usado por instituies financeiras com uma alternativa para o DES.
IDEA - o International Data Encryption Algorithm (IDEA - Algoritmo de Criptografia de Dados Internacional) foi desenvolvido em Zurique, na Sua, por James L. Massey e Xuenjia Lai, e publicado em 1990. O IDEA usa chave de 128 bits, e bastante poderoso.
RC2 - este algoritmo de bloco foi desenvolvido originalmente por Ronald Rivest, e mantido em segredo pela RSA Data Security. Foi revelado por uma mensagem annima na Usenet em 1996, e parece ser relativamente poderoso (embora algumas chaves sejam vulnerveis). O RC2 vendido com uma implementao que permite a utilizao de chaves de 1 a 2048 bits.
RC4 - Inventado em 1987 pela RSA, nunca teve o seu algoritmo de funcionamento interno publicado. Esse segredo possua interesses financeiros e no de segurana. A empresa esperava que mantendo-o em segredo, ningum mais o implementaria e o comercializaria. uma cifragem muito utilizada hoje em dia, at fazendo parte no protocolo de comunicao SSL (Security Socket Layer).
RC5 - este algoritmo de bloco foi desenvolvido por Ronald Rivest e publicado em 1994. O RC5 permite que o tamanho da chave, o tamanho dos blocos de dados e o nmero de vezes que a criptografia ser realizada seja definida pelo usurio.
Blowfish - um algoritmo de criptografia em bloco, rpido, compacto e simples, inventado por Bruce Schneier. O algoritmo permite a utilizao de uma chave de tamanho varivel, de at 448 bits, e otimizado para executar em processadores de 32 ou 64 bits. No patenteado e foi colocado em domnio pblico.[3] 9 2.4 - Algoritmos assimtricos
A existncia da criptografia de chave pblica foi postulada pela primeira vez em meados de 1975 por Withfield Diffie e Martin Hellman. Os dois pesquisadores, na poca na universidade de Stanford, escreveram um artigo em que pressuponham a existncia de uma tcnica criptogrfica com a qual a informao criptografada com uma chave poderia ser decifrada por uma segunda chave, aparentemente sem relao com a primeira. Robert Merkle, ento estudante em Berkeley que tinha idias semelhantes mas, devido lentido do processo de publicao acadmica, seus artigos s foram publicados quando a idia de criptografia de chave pblica j era bem conhecida. Desde ento, vrios sistemas de chave pblica foram desenvolvidos. Infelizmente, houve muito menos desenvolvimento nos algoritmos de chave pblica em relao aos de chave simtrica. A razo disso tem a ver com o modo como esses algoritmos so criados. Um bom algoritmo de chave simtrica simplesmente embaralha os dados de entrada, dependendo da chave utilizada. O desenvolvimento de um novo algoritmo de chave simtrica depende da criao de novas maneiras de executar esta operao de forma confivel. Os algoritmos de chave pblica so baseados na teoria dos nmeros. Especialistas dizem que "O desenvolvimento de novos algoritmos de chave pblica requer a identificao de novos problemas matemticos com propriedades particulares". Os algoritmos assimtricos utilizam-se de duas chaves diferentes, uma em cada extremidade do processo. As duas chaves so associadas atravs de um relacionamento matemtico, pertencendo a apenas um participante, que as utilizar para se comunicar com todos os outros de modo seguro. Essas duas chaves so geradas de tal maneira que a partir de uma delas no possvel calcular a outra a um custo computacional vivel, possibilitando a divulgao de uma delas, denominada chave pblica, sem colocar em risco o segredo da outra, denominada chave secreta ou privada.
10
Figura 2 ~ Criptografia Assimtrica
Os principais sistemas de chaves pblicas atualmente em uso so:
Diffie-Hellman - Um sistema para troca de chaves criptogrficas entre partes. Na verdade, no um mtodo de criptografia ou decifragem, um mtodo para troca de chave secreta compartilhada por meio de um canal de comunicao pblico. Com efeito, as duas partes estabelecem certos valores numricos comuns e cada uma delas cria uma chave. As transformaes matemticas das chaves so intercambiadas. Cada parte calcula ento uma terceira chave (a chave de sesso) que no pode ser descoberta facilmente por um atacante que conhea os valores intercambiados. 11 ElGamal - Batizado com o nome de seu criador, Taher ElGamal, um sistema criptogrfico de chave pblica baseado no protocolo de troca de chaves de Diffie- Hellman. O ElGamal pode ser utilizado para criptografia e assinatura digital, de forma semelhante ao algoritmo RSA.
DSS - O Digital Signature Standard (DSS - Padro de Assinatura Digital) foi desenvolvido pela Agncia Nacional de Segurana (NSA), e adotado como Padro Federal de Processamento de Informao (FIPS) pelo Instituto Nacional de Padres Tecnologia (NIST) dos EUA. O DSS baseado no Algoritmo de Assinatura Digital - DSA (Digital Signature Algorithm) - que permite a utilizao de qualquer tamanho de chave, embora no DSS FIPS s sejam permitidas chaves entre 512 e 1024 bits. O DSS s pode ser usado para a realizao de assinaturas digitais, embora haja implementaes do DSA para criptografia.
RSA - RSA um sistema criptogrfico de chave pblica conhecido, desenvolvido por Ronald Rivest, Adi Shamir e Leonard Adleman, ento professores do MIT (Instituto de Tecnologia de Massachusets). O RSA utiliza criptografia em blocos e possui uma segurana muito forte, devido ao alto poder computacional necessrio para se tentar quebrar uma chave RSA. Pode tanto ser usado para cifrar informaes como para servir de base para um sistema de assinatura digital. As assinaturas digitais podem ser usadas para provar a autenticidade de informaes digitais. A chave pode ser de qualquer tamanho, dependendo da implementao utilizada.[4] [14]
2.5 - Assinatura digital
Outra grande vantagem dos algoritmos assimtricos, particularmente o RSA, que o mais conhecido e utilizado atualmente, que o processo funciona tambm na criptografia no outro sentido, da chave secreta para a chave pblica, o que possibilita implementar o que se denomina assinatura digital. O conceito de assinatura o de um processo que apenas o signatrio possa realizar, garantindo dessa maneira sua participao pessoal no processo. Como a chave secreta de posse e uso exclusivo de seu detentor, um processo de cifragem usando a chave privada do signatrio se encaixa nesse conceito, permitindo, assim, a gerao de uma assinatura por um processo digital. 12 No caso da assinatura digital, inadequado cifrar toda a mensagem ou documento a ser assinado digitalmente devido ao tempo gasto na criptografia de um documento utilizando chaves assimtricas. A criptografia aplicada apenas sobre um identificador unvoco do mesmo. Normalmente utilizado como identificador o resultado da aplicao de uma funo tipo HASH, que mapeia um documento digital de tamanho qualquer num conjunto de bits de tamanho fixo. Ao valor do HASH podem ainda ser anexados a data/hora, nmero de seqncia e outros dados identificadores, e este conjunto ento cifrado com a chave secreta do signatrio constituindo a assinatura digital do documento. A funo de HASH ser explicada em seguida. Qualquer participante pode verificar a autenticidade de uma assinatura digital, bastando decifr-la com a chave pblica do signatrio, o qual todos podem ter acesso. Se o resultado significativo, est garantido o uso da chave secreta correspondente na assinatura, e portanto sua autenticidade. Resta ainda comprovar a associao da assinatura ao documento, o que feito recalculando o HASH do documento recebido e comparando-o com o valor includo na assinatura. Se forem iguais, prova-se ainda a ligao com o documento, assim como a integridade (no alterao) do mesmo. Uma vez que a verificao realizada utilizando a chave pblica, sua validao pode ser realizada por terceiros, tais como rbitros e auditores.
13
Figura 3 - Processo de Verificaao de Assinatura Digital.
2.5.1 - HASH
A funo HASH define uma criptografia de modo unidirecional, ou seja, efetua uma criptografia que no apresenta volta. Uma vez utilizada uma funo de HASH em um documento, deve ser computacionalmente invivel obter o documento digital original a partir do valor resultante da funo HASH sobre ele. Um fator interessante que documentos de tamanhos e formatos diferentes podem gerar um mesmo valor de HASH. Mas nunca podem ser obtidos a partir destes valores. 14 Os algoritmos conhecidos como HASH so utilizados para codificao de mensagens. Os principais so:
HMAC - o Hashed Message Authentication Code (Cdigo de Autenticao de Mensagens por Confuso), uma tcnica que usa uma chave secreta e uma funo de codificao para criar um cdigo secreto de autenticao de mensagem. O mtodo HMAC refora uma funo de codificao existente de forma a torn-la resistente a ataques externos, mesmo que a prpria funo de codificao esteja de certa forma comprometida.
MD2 - Message Digest #2 (Codificao de Mensagem #2), desenvolvido por Ronald Rivest. Esta a mais segura das funes de codificao de mensagem de Rivest, mas demora mais para calcular e produz algumas colises em seu clculo. Produz uma codificao de 128 bits.
MD4 - Message Digest #4 (Codificao de Mensagem #4), tambm desenvolvido por Ronald Rivest. Este algoritmo de codificao de mensagem foi desenvolvido como uma alternativa rpida para o MD2. Depois, o MD4 mostrou ser pouco seguro. Ou seja, possvel encontrar dois arquivos que produzem o mesmo cdigo MD4 sem uma pesquisa de fora bruta. O MD4 produz uma codificao de 128 bits.
MD5 - Message Digest #5 (Codificao de Mensagem #5), tambm desenvolvido por Ronald Rivest. O MD5 uma modificao do MD4 que inclui tcnicas para torn-lo mais seguro e mais rpido. Embora largamente usado, foram descobertas algumas falhas nele em meados de 1996, que permitiam calcular alguns tipos de coliso. Como resultado, sua popularidade vem caindo. O MD5 produz uma codificao de 128 bits.
SHA1 - O Secure Hash Algorithm se parece muito com o MD5. O SHA1 incorpora pequenas mudanas, como produzir uma codificao maior com 160 bits. Os clculos internos so mais fortes do que o do MD5. Variantes do SHA1 que produzem variantes de 192 a 256 bits esto em desenvolvimento.[5]
Vamos supor que Antnio queira enviar, atravs de um canal de comunicao inseguro (a Internet, por exemplo) uma mensagem sigilosa M a Benedito, utilizando um sistema criptogrfico de chave pblica. Aps obter PB, a chave pblica de Benedito (essa chave deve ser conseguida de forma segura, como ser apresentado no projeto), ele cifra a mensagem M, obtendo a mensagem cifrada PB (M). Benedito, aps receber a mensagem cifrada, aplica a ela sua chave secreta SB, obtendo a mensagem inicial M. Observe que apenas Benedito conseguir ler a mensagem, j que invivel a qualquer outra pessoa, somente de posse da chave pblica de Benedito (PB), deduzir sua chave secreta (SB).
Figura 4 ~ Confidencialidade dos dados 16 2.6.2 - Nao-repdio
No exemplo anterior, Benedito no tem como afirmar, com certeza, se a mensagem foi efetivamente enviada por Antnio ou se por algum impostor. Vamos supor, agora, que Antnio queira enviar uma mensagem M no sigilosa, mas que, por outro lado, queira assinar tal mensagem, de modo a permitir que Benedito, ou qualquer outra pessoa que tenha acesso mensagem, possa ter certeza, ao examin-la, que seu remetente realmente Antnio. Antnio codifica a mensagem M com sua chave secreta SA, obtendo SA (M). Benedito, ou qualquer outra pessoa, pode confirmar que a mensagem provm realmente de Antnio, atravs da aplicao da chave pblica de Antnio (PA) mensagem SA (M). Note que as chaves se completam, tornando possvel o caminho de ida e volta utilizando as chaves pblica e privada.
Figura 5 - Nao-repdio
17 2.6.3 - Confidencialidade, Autenticidade e Nao-Repdio
Neste terceiro exemplo, suponha que Antnio queira enviar a Benedito, novamente atravs de um canal de comunicao inseguro, uma mensagem sigilosa M, permitindo que Benedito possa se certificar da procedncia da mensagem e de que essa mensagem no foi alterada. Inicialmente, Antnio assina a mensagem M, utilizando sua chave secreta SA e, em seguida, cifra a mensagem resultante, utilizando a chave pblica de Benedito (PB), obtendo, assim, PB (SA (M)). Benedito, ao receber a mensagem cifrada e assinada por Antnio, aplica, em primeiro lugar, sua chave secreta (SB), obtendo, dessa forma, a mensagem criptografada pela chave secreta de Antnio. Em seguida, Benedito, utilizando a chave pblica de Antnio (PA), recupera a mensagem original, M. Dessa forma pode-se concluir que a mensagem enviada foi confidencial, autentica e existe a certeza do remetente da mensagem.
Figura 6 - Confidencialidade, Autenticidade e Nao-Repdio
18 3 ~ Infra-estrutura de Chaves Pblicas
Uma Infra-estrutura de Chaves Pblicas (ICP) um sistema de segurana baseado em tecnologia para estabelecer e garantir a confiabilidade de chaves pblicas de criptografia. A criptografia de chaves pblicas tem se apresentado como um importante mecanismo de segurana para o fornecimento de servios de autenticao, gerao de provas, integridade de dados e confidencialidade para operaes internas e externas de e-business. Quando implementada como um componente integral de uma soluo de habilitao de confiabilidade, uma ICP pode contribuir para a otimizao da velocidade e do valor das transaes de e-business. A infra-estrutura de chaves pblicas atrela as chaves pblicas s suas entidades, possibilitando que outras entidades verifiquem a validade das chaves pblicas e disponibilize os servios necessrios para o gerenciamento das chaves que trafegam em um sistema distribudo. O objetivo maior dessa arquitetura de segurana moderna proteger e distribuir a informao que necessria em ambientes altamente distribudos, nos quais os usurios, recursos e empresas podem estar em lugares diferentes. Em transaes comerciais convencionais, por exemplo, os clientes e os comerciantes baseiam-se em cartes de crditos (p.ex., VISA ou Mastercard) para completar os aspectos financeiros das transaes. O vendedor autentica o cliente atravs da comparao de assinaturas ou verificando um documento de identidade, como um RG. O vendedor se baseia na informao contida no carto de crdito e na informao obtida junto ao emissor do carto de crdito para garantir que o pagamento ser recebido. Da mesma forma, o cliente faz a transao sabendo que ele pode rejeitar a conta se o vendedor falhar no fornecimento do bem ou servio. O emissor do carto de crdito o terceiro confivel nesse tipo de transao. O mesmo modelo pode ser aplicado em uma transferncia de informao (como um cadastro de pessoa fsica), mesmo sabendo que o consumidor e o vendedor talvez nunca se encontrem. O vendedor no pode comparar as assinaturas ou pedir um documento de identidade. Eles podem estar separados por centenas de quilmetros. Mas ambos precisam ser capazes de assegurar que a outra parte legtima para que haja a troca de informaes. A infra-estrutura de chave pblica uma combinao de software, tecnologias de encriptao e servios que permite s empresas obterem segurana em suas comunicaes e transaes comerciais via rede, integrando certificados digitais, criptografia de chave pblica 19 e autoridades certificadoras numa arquitetura de segurana de redes completa para, dessa forma, criar uma estrutura de confiana para os dois lados da transao. A ICP consegue assegurar confidencialidade, integridade e no-repdio de uma maneira difcil de ser fraudada e que se apresenta de forma transparente para o usurio. Estes dois pontos, transparncia aliada forte base tcnica de seus mecanismos, denotam o aspecto forte desta tecnologia.[2]
3.1 ~ A arquitetura de uma ICP
Existem, atualmente, dois tipos bsicos de arquiteturas de ICP criadas para solucionar o problema de validao dos participantes em um processo de troca de informaes: A arquitetura Hierrquica e a Mista. O projeto em questo abrange a soluo Hierrquica, que a mesma utilizada pela ICP-Brasil (Infra-estrutura de Chaves Pblicas Brasileira).
3.1.1 - Arquitetura Hierrquica
A arquitetura tradicional utilizada pela ICP a Hierrquica. Nesta arquitetura, mltiplas AC's prestam servios de infra-estrutura e as Autoridades Certificadoras possuem uma relao de confiana em escala Hierrquica. Nessa arquitetura, todas as AC's confiam em uma AC central chamada de Raiz. Com exceo da AC Raiz, todas as outras AC's possuem uma nica AC superior. O modelo abaixo representa essa arquitetura.
20
Figura 7 - Arquitetura Hierrquica
A AC Raiz o topo da hierarquia, ou seja, o certificado digital dessa AC um certificado auto-assinado. Ningum assina seu certificado, pois ela no dependente de nenhuma outra AC. Isso necessrio para garantir a validao da hierarquia das outras AC's. A partir da, cada AC que for criada nessa estrutura ter seu certificado assinado pela AC Raiz. Seguindo a lgica da figura, temos o seguinte esquema: A AC Raiz assina o seu prprio certificado e se prepara para receber mais AC's em sua hierarquia. A AC 1 e a AC 2 decidem entrar na arquitetura oferecida pela AC Raiz. Elas enviam uma REQUISIO DE ASSINATURA DE CERTIFICADO (CSR) para a AC Raiz e recebem desta seus certificados j assinados pela chave secreta da Raiz. A AC 2 decide que ir gerar certificados digitais diretamente aos seus clientes. Ento, os clientes geram um CSR (Atravs de um browser ou um aplicativo disponibilizado pela AC 2) e, a partir desse CSR, a AC 2 devolve um certificado assinado por ela. 21 No outro caso, a AC 1 no assina certificados de usurios em geral, apenas de empresas ou outras AC's. A AC 3 envia um CSR para a AC 1 que assina e devolve um certificado assinado por ela para a AC 3. A AC 3, por sua vez, recebe CSR's de clientes. Qual a importncia dessa cadeia de assinaturas? Usaremos um exemplo de uma empresa que vende automveis pela Internet e, para isso, exige que o cliente apresente seu Certificado Digital. O cliente acessa o site da empresa e compra um automvel, utilizando o seu certificado digital. O prprio site da empresa captura o certificado digital do cliente (lembre- se que o certificado digital PBLICO) e ir tentar conferir a validade deste. Essa empresa precisa ter, em primeiro lugar, o certificado digital da AC Raiz. Esse certificado de extrema importncia e precisa ser confivel, podendo ser conseguido junto prpria AC Raiz. Aproveitando a figura da arquitetura hierrquica acima, digamos que o cliente que comprou o automvel um cliente da Autoridade Certificadora 3. A empresa de automveis precisa, agora, conseguir o certificado da AC 3. Esse certificado pode ser conseguido atravs de um e- mail, ou no site da AC 3, ou de outra forma que a AC 3 o disponibilizar. Pronto, a empresa de Automveis pode conferir agora a veracidade do certificado do cliente. Primeiro, a empresa de Automveis utiliza o certificado digital da AC 3 para conferir se o certificado do cliente foi assinado por aquela AC. Confirmando isso, a empresa agora ir utilizar o certificado da AC Raiz para verificar se o certificado da AC 3 foi assinado pela prpria Raiz. Foi feito assim, toda a validao da cadeia hierrquica at a AC Raiz. Por isso a importncia do certificado da AC Raiz ser extremamente confivel. Porque a partir desse certificado, possvel verificar se algum certificado abaixo dela foi alterado ou se foi gerado por outra AC, no confivel. Ento, passando por estas etapas, o cliente ser autorizado a efetivar a compra. Todo esse procedimento pode ser reduzido. Uma vez que o certificado da AC 3 for validado e garantido pelo certificado da AC Raiz, no ser necessrio refazer essa validao toda vez que um cliente tentar efetuar uma compra. Basta guardar o certificado da AC 3 de forma segura e ento a empresa ir validar o certificado dos clientes apenas com a AC 3, no precisando mais passar pela AC Raiz. importante destacar que todo esse procedimento descrito feito de forma transparente e automtica para o cliente.[6] 22 3.1.2 - Arquitetura Mista
Esta arquitetura, tambm conhecida como certificao cruzada, mltiplas AC's se validam em um ambiente. Cada usurio confia em uma nica AC, mas as AC's no se reportam unicamente a uma AC superior a ela, como acontece na arquitetura hierrquica. Na viso do usurio isso transparente. Afinal, ele s confia na AC que assinou o seu certificado. Mas para as AC's isso muda. O diagrama abaixo representa um exemplo desta arquitetura.
Figura 8 - Arquitetura Mista
No exemplo acima, pode ser observado que ainda existe a estrutura hierrquica citada anteriormente, mas desta vez, a AC Raiz no o ultimo ponto desta rede. As AC's Razes podem confiar em outras AC's Razes, criando um ciclo de confiana e no limitando a sua abrangncia apenas a sua hierarquia. Contextualizando, digamos que um indivduo brasileiro esteja de frias na Alemanha. Essa pessoa aluga um carro alemo, gosta do modelo e do estilo do carro e decide trazer um para o Brasil. Ele se dirige para uma revendedora deste modelo de 23 carro e solicita um exemplar. E que este seja enviado ao Brasil. A revendedora exige do cliente para isso, o seu certificado digital e o nmero de sua conta corrente. Com isso, ela poder efetivar a compra. O cliente, ento, entrega um certificado digital assinado por uma AC brasileira, situada abaixo da AC Raiz do Brasil. A revendedora ir validar a cadeia de assinaturas. Quando isso ocorrer, ir perceber que aquele certificado no est abaixo na hierarquia da AC Raiz da Alemanha. Mas a AC Raiz da Alemanha possui uma confiana na AC Raiz do Brasil. Com isso, informa a revendedora que aquele certificado em questo vlido e confivel, j que foi assinada por uma AC Raiz conhecida. O cliente, ento, poder efetivar a sua compra. necessrio lembrar sempre que esse procedimento transparente para o cliente e que essa arquitetura pode ser montada com uma quantidade varivel de AC's Razes.[6]
3.2 - Certificados digitais para usurios (Modelo X.509)
Os certificados digitais so um meio seguro de distribuir as chaves pblicas dentro de uma rede. So anlogos a um CPF ou uma carteira de identidade, por exemplo. Em qualquer caso, existe um terceiro confivel que confirma a identidade e os privilgios e direitos de acesso do usurio. Em seu padro mais bsico, um certificado digital contm uma chave pblica, a identidade da pessoa a qual ele pertence e o nome da parte que estar atestando a validade deste. Diversos certificados esto em utilizao. Alguns dele, como o Pretty Good Privacy (PGP), so patenteados. Outros certificados so especficos de um aplicativo como certificados SET e o Internet Protocol Security (IPSec). O padro de certificado digital mais aceito atualmente no mercado o X.509 Verso 3 da ITU (International Telecommunications Union). Esse padro de certificados, apesar de ser amplamente usado para a Internet, tambm muito utilizado em ambientes empresariais.
24
Figura 9 - Certificado Digital padrao X.509 (Certificado raiz da ICP-Brasil)
25 A tabela abaixo representa a disposio dos campos de um certificado padro X.509 v3.
Tabela 1 ~ Estrutura do X.509 v3 Version (Versao) Certificate Serial Number (Nmero Serial do Certificado) Signature Algorithm Identifier (Identificador do algoritmo de assinatura) Issuer Name (Nome do emissor) Validity (Not Before/Not After) Validade(Nao antes/Nao depois) Subject Name (Nome do sujeito) Subject Public Key Information (Informaes da chave pblica do sujeito) Issuer Unique Identifier (Identificador nico de emissor) Subject Unique Identifier (Identificador nico do sujeito) Extensions (Extenses) Signature (Assinatura)
Version (Versao): Esse campo define a verso do certificado, como Verso 1, Verso 2, Verso 3. Esse campo permite possveis verses futuras.
Certificate Serial Number (Nmero serial do certificado): Esse campo contm um valor nico em cada certificado gerado pela AC.
26 Signature Algorithm Identifier (Identificador do algoritmo de assinatura): Indica o identificador do algoritmo utilizado para assinar o certificado.
Issuer Name (Nome do emissor): Esse campo identifica o nome distinto (Distinguished Name-DN) com o qual a AC cria e assina esse certificado.
Validity (Validade(Nao antes/Nao depois)): Contm dois valores de data/hora que definem o perodo que esse certificado pode ser considerado vlido a menos que seja revogado.
Subject Name (Nome do sujeito): Esse campo identifica o DN da entidade final a que o certificado se refere, ou seja, o possuidor da chave privada correspondente.
Subject Public Key Information (Informaes da chave pblica do sujeito): Esse campo possui o valor da chave pblica do sujeito, bem como o identificador de algoritmo e qualquer outro parmetro associado ao algoritmo pelos quais a chave deve ser utilizada.
Issuer Unique Identifier (Identificador nico de emissor): Campo opcional que contm um identificador nico que utilizado para exibir de maneira no-ambgua o nome da AC, em casos onde um mesmo nome foi reutilizado por diferentes entidades ao longo do tempo.
Subject Unique Identifier (Identificador nico do sujeito): Campo opcional que contm um identificador nico que utilizado para exibir de maneira no-ambgua o nome do proprietrio do certificado, em casos onde um mesmo nome foi reutilizado por diferentes entidades ao longo do tempo.
Extenses de Certificado X.509 Versao 3
As verses 1 e 2 de certificados X.509 ainda possuam algumas deficincias. Muitos dados importantes no eram inseridos no certificado por causa do padro adotado. Por essa razo, a verso 3 veio com uma alterao importante que era o conjunto de extenses. Essas extenses abrangem as informaes sobre a poltica, a chave, os atributos do sujeito e do emissor e as restries do caminho de certificao. As informaes contidas nas extenses podem ser marcadas como crticas ou no-crticas. Os seguintes campos definem as extenses dos certificados digitais X.509 v3. 27 Authority Key Identifier (Identificador de chave de autoridade): Este campo utilizado para diferenciar chaves de assinaturas com mltiplos certificados de uma mesma AC. A AC fornece um identificador nico de chave ou um ponteiro para um outro certificado.
Subject Key Identifier (Identificador de chave do sujeito): Essa extenso utilizada para diferenciar chaves de assinaturas com mltiplos certificados de um mesmo proprietrio de certificado. O proprietrio fornece um identificador nico de chave ou um ponteiro para um outro certificado.
Key Usage (Utilizaao da chave): Essa extenso utilizada para definir as restries quanto s operaes que podem ser realizadas pela chave pblica do certificado, como assinatura digital, assinatura de certificado, cifragem de dados, etc.
Extended Key Usage (Utilizaao de chave estendida): Pode ser utilizado alm do campo Key Usage para definir uma ou mais utilizaes da chave pblica do certificado, como utilizao do protocolo TLS.
CRL Distribution Point (Ponto de Distribuiao de CRL): Esse campo apresenta um identificador de recurso uniforme (URI) para localizar a estrutura de CRL definida.
Private Key Usage Period (Perodo de uso de chave privada): Semelhante ao campo Validity, essa extenso indica o perodo de tempo para utilizao da chave privada associada chave pblica nesse certificado.
Certificate Policies (Polticas de Certificado): Essa extenso identifica as informaes sobre as polticas e qualificadores opcionais que a AC associa ao certificado.
Policy Mappings (Mapeamento de polticas): Utilizada apenas quando o sujeito do certificado tambm for uma AC.
Subject Alternative Name (Nome alternativo do sujeito): Indica uma ou mais formas alternativas de nomes associados ao proprietrio desse certificado. Podem ser includos nomes diversos, como o prprio e-mail.
28 Issuer Alternative Name (Nome alternativo do emissor): Indica uma ou mais formas alternativas de nomes associados ao emissor do certificado.
Subject Directory Attributes (Atributos do diretrio do sujeito): Fornece as informaes adicionais sobre a identidade do sujeito que no so transportadas para os campos de nome, como telefone, posio dentro da empresa, etc.
Basic Constraints (Restries Bsicas): Indica se o sujeito pode agir como uma AC, fornecendo uma maneira para restringir que usurios finais atuem como AC's.
Name Constraints (Restries de nomes): Deve ser utilizada apenas dentro de certificados de AC. Ela especifica o espao de nome dentro do qual todos os nomes de sujeito devem estar localizados para qualquer certificado subseqente que seja parte desse caminho de certificado.[7] A figura 10 representa um certificado X.509 e alguns de seus campos apresentados.
Figura 10 - Certificado Digital X.509 29 3.3 ~ Protocolos PKCS
Alguns protocolos foram criados para se utilizar e implementar uma transao de ICP. Definidos como PKCS (Public Key Cryptography Standards), esses padres foram criados pela RSA Security em conjunto com outras grandes empresas para auxiliar a utilizao de uma infra-estrutura de chaves pblicas e padronizar essa utilizao no mercado. A tabela 2 lista os padres PKCS ainda ativos. Tabela 2 Definiao dos protocolos PKCS Padrao Descriao PKCS #1 Esse padro define mecanismos para cifragem e assinatura de dados usando o sistema RSA. PKCS #3 Define o padro de chaves Diffie-Hellman. PKCS #5 Descreve um mtodo para gerar uma chave secreta baseado em uma senha. PKCS #6 Padro de sintaxe de certificado. PKCS #7 Define uma sintaxe genrica para mensagens que devem ser criptografadas. Esse protocolo ser melhor definido em seguida. PKCS #8 Define um mtodo para a guarda de informaes de chave privada. PKCS #9 Define tipos de atributos para uso nos protocolos PKCS. PKCS #10 Padro de Requisio de Certificados. PKCS #11 Padro de interface para criptografia em Tokens. PKCS #12 Descreve um formato porttil para guarda e transporte de chaves privadas, certificados, etc. PKCS #13 Esse padro define mecanismos para cifragem e assinatura de dados usando o algoritmo de curvas elpticas. PKCS #14 Padro para gerao de nmeros pseudo-randmicos. PKCS #15 Descreve um padro para informaes credenciais criptografadas armazenadas em tokens.
Os protocolos PKCS #7 e #10 so os mais utilizados atualmente. Os padres PKCS #2 e #4 no mais existem, pois foram incorporados no PKCS #1. [8]
30 3.3.1 - PKCS #10
O protocolo PKCS #10 muito utilizado atualmente. Ele representa o padro de Requisio de Certificados. Esse padro possui um formato que agrupa um DN (Distinguished Name), uma chave pblica, um campo opcional de atributos, um identificador de algoritmo e uma assinatura digital. O campo opcional foi designado para complementar atributos para incluso no certificado digital, como por exemplo, e-mail. Essa requisio deve ser assinada utilizando a chave privada do solicitante. Dessa forma, ao enviar o PKCS #10 para a AC, esta ter a certeza de que o solicitante possuidor da chave privada relativa quela chave pblica enviada no PKCS #10. Utilizando a chave pblica contida no PKCS #10, a AC ir aplicar essa chave na requisio recebida e verificar se a chave pblica que recebeu o complemento da chave particular que gerou o CSR (Requisio de assinatura de certificado).[9] A tabela abaixo representa os campos do padro PKCS # 10. Tabela 3 - Protocolo PKCS #10 Versao DN - Distinguished Name Chave Pblica Atributos (Opcional) Algoritmo de Assinatura Assinatura Digital
3.3.2 - PKCS #7
O padro PKCS #7 descreve uma sintaxe genrica para dados que podem ser submetidos a funes criptogrficas, tais como assinatura e envelopagem digital. Permite recursividade, com aninhamento de envelopes. Permite tambm a associao de atributos arbitrrios, como, por exemplo, contra-assinatura. Esse padro pode dar suporte a uma variedade de arquiteturas de gerenciamento baseadas em infra-estrutura de chaves pblicas. Esse protocolo provavelmente o mais utilizado de todos devido a sua caracterstica genrica para utilizao de chaves pblicas. Foi criado especificamente para proteger 31 mensagens com criptografia mas pode ser utilizado de outras formas. Esse padro define basicamente dois campos: o tipo de contedo e o contedo. O campo do tipo de contedo pode ser classificado em seis tipos diferentes: dados (data), dado assinado (signed data), dado envelopado (enveloped data), dado assinado e envelopado (Signed and Enveloped Data), HASH do dado assinado (Digested data) e dado encriptado (Encrypted Data). Para melhor compreenso do PKCS #7, seus tipos primitivos sero detalhados.
Dados (Data): Essa definio indica que o protocolo ir guardar apenas o dado em questo, podendo, por exemplo, ser um texto em ASCII ou mesmo uma informao binria.
Dado Assinado (Signed Data): Essa definio caracteriza o protocolo como um tipo assinado. Ou seja, o padro armazena uma assinatura de um dado qualquer. Esse tipo pode conter tambm a prpria mensagem que foi assinada.
Dado Envelopado (Enveloped Data): Esse padro consiste em uma estrutura de dados contendo informaes encriptadas de qualquer tipo e a chave simtrica (utilizada para a cifragem da mensagem) encriptada pela chave pblica do destinatrio da mensagem O processo pelo qual um envelope digital formado envolve os seguintes passos: 1 Uma chave de encriptao simtrica gerada aleatoriamente. 2 Utiliza-se essa chave para encriptar a mensagem. 3 Em seguida, a chave pblica do destinatrio utilizada para cifrar a chave simtrica. 4 Ao final, o padro possui uma mensagem cifrada simetricamente e uma chave simtrica cifrada com uma chave pblica.
Dado Assinado e Envelopado (Signed and Enveloped Data): Esse tipo consiste em uma estrutura contendo dados encriptados, a chave simtrica utilizada para cifrar os dados em questo, a chave pblica de destino e um HASH assinado. O processo pelo qual um tipo Assinado e Envelopado formado envolve os seguintes passos: 1 Uma funo HASH aplicada sobre os dados a serem enviados. 2 A chave privada do remetente aplicada sobre esse HASH gerado, formando assim, a assinatura dos dados. 3 Utiliza-se uma chave simtrica para cifrar os dados em questo. 32 4 A chave pblica do destinatrio usada para cifrar essa chave simtrica gerada anteriormente. 5 Ao final, o PKCS #7 possui uma mensagem cifrada simetricamente, um HASH criptografado por uma chave privada e uma chave simtrica criptografada com a chave pblica do destinatrio.
HASH do Dado Assinado (Digested Data): Esse tipo padroniza o PKCS #7 com um HASH da mensagem e a assinatura desse HASH, podendo ou no conter a prpria mensagem assinada. Ou seja, um HASH aplicado sobre a mensagem, gerando uma cadeia de bytes. Em seguida, a chave privada aplicada sobre o resultado desse HASH. O protocolo ir conter exatamente esse HASH cifrado pela chave privada.
Dado Encriptado (Encrypted Data): Nesse padro, o PKCS #7 transporta apenas a mensagem cifrada simetricamente. Pressupe-se que a chave simtrica j tenha sido trocada de forma segura anteriormente. Por questes de segurana, no se envia a chave simtrica em aberto para o destinatrio.[10]
3.4 - ICP Brasil e polticas de segurana de uma AC
Este tpico tem como objetivo apresentar de forma clara uma breve definio do que vem a ser o rgo ICP-Brasil, que rege todas as leis referentes a infra-estruturas de chaves pblicas no Brasil. Esse instituto deve ser apresentado, pois todo o projeto teve como base essas normas. O tpico relativo segurana de uma AC foi enfatizado devido a importncia dessa segurana. Qualquer falha em uma Autoridade Certificadora pode comprometer toda a infra-estrutura. O Instituto Nacional de Tecnologia da Informaao ~ ITI, autarquia federal vinculada Casa Civil da Presidncia da Repblica, a Autoridade Certificadora Raiz ~ AC Raiz da Infra-estrutura de Chaves Pblicas Brasileira ICP-Brasil. Como tal a primeira autoridade da cadeia de certificao, executora das Polticas de Certificados e normas tcnicas e operacionais aprovadas pelo Comit Gestor da ICP-Brasil, e tem por competncias emitir, expedir, distribuir, revogar e gerenciar os certificados das Autoridades Certificadoras - AC de nvel imediatamente subseqente ao seu; gerenciar a lista de certificados emitidos, revogados e vencidos; executar atividades de fiscalizao e auditoria 33 das AC, das Autoridades de Registro - AR e dos prestadores de servio habilitados na ICP- Brasil. Seu certificado constitui um Certificado Auto-Assinado, j que o primeiro de toda a hierarquia. de responsabilidade ainda do ITI estimular e articular projetos de pesquisa cientfica e de desenvolvimento tecnolgico voltados ampliao da cidadania digital. Neste setor, o ITI tem como sua principal linha de ao a popularizao da certificao digital e a incluso digital, atuando sobre questes como sistemas criptogrficos, software livre, hardware compatveis com padres abertos e universais, convergncia digital de mdias, entre outras. As polticas de certificados descritas na tabela abaixo so definidas pela ICP-Brasil. uma forma de se qualificar o certificado de acordo com a forma de gerao ou armazenamento do mesmo. Alm disso, a nomenclatura sugere o uso do certificado, Assinatura (A) ou Sigilo (S). Certificados de tipos A1, A2, A3 e A4 so utilizados em aplicaes como confirmao de identidade na heb, correio eletrnico, transaes on-line, redes privadas virtuais, cifragem de chaves de sesso e assinatura de documentos eletrnicos com verificao da integridade de suas informaes. Certificados de tipos S1, S2, S3 e S4 sero utilizados em aplicaes como cifragem de documentos, bases de dados, mensagens e outras informaes eletrnicas, com a finalidade de garantir o seu sigilo. A tabela abaixo descreve os tipos de certificados definidos pela ICP-Brasil. Tabela 4 - Tipos de certificados Tipo de Certificado Chave Geraao do Par de Chaves Criptografia Armazenamento do Certificado e da Chave Privada Validade A1 e S1 1024 Software Software Software 1 ano A2 e S2 1024 Software Software Hardware 2 anos A3 e S3 1024 Hardware Hardware Hardware 3 anos A4 e S4 2048 Hardware Hardware Hardware 3 anos
O projeto permite a utilizao do tipo A1, podendo ser implementado futuramente a utilizao dos outros tipos. Atualmente existem diversas AC's situadas abaixo na cadeia hierrquica da ICP Brasil. Essas AC's so responsveis por gerar certificados digitais, revogar, divulgar listas de certificados revogados, entre outras funes. A estrutura abaixo representa a hierarquia atual da ICP-Brasil. 34
Figura 11 - Hierarquia da ICP-Brasil
Cada AC possui sua aceitao dentro de uma poltica de certificados definida. O quadro abaixo apresenta cada AC na ICP-Brasil e suas definies de certificados com que trabalha.[11] Tabela 5 - Polticas de certificados das AC's da ICP-Brasil AUTORIDADE CERTIFICADORA POLITICAS DE CERTIFICADO AC Presidncia da Repblica A1, A3 AC SERPRO A1, A3, SPB AC SERASA AC AC SERASA SPB AC SERASA CD A1, A2, A3, A4 S1, S2, S3, S4 AC CERTISIGN AC AC CERTISIGN SPB SPB AC CERTISIGN MULTIPLA A1, A2, A3, A4 S1, S2, S3, S4 AC SERTISIGN SRF A1, A3, A4 AC SRF AC AC SERPRO SRF A1, A3 AC SERASA SRF A1, A3, A4 AC CAIXA AC AC CAIXA PF A1, A3 AC CAIXA PJ A1, A3 AC CAIXA IN A1, A3
ICP-BRASIL AC SERASA AC CEF AC PR AC SERPRO AC CERTISIGN AC SRF 35 3.4.1 - Segurana Fsica de uma AC
A segurana necessria a uma AC de extrema importncia. Uma nica falha nesse processo pode comprometer toda a estrutura de chaves pblicas em que esta AC esteja envolvida. Por exemplo, se um indivduo de alguma forma conseguir invadir a base de dados de uma AC e, dessa forma, roubar a chave privada da mesma, essa pessoa poder gerar certificados digitais e assin-los com a chave privada que roubou. Dessa forma, esse indivduo poder se passar por qualquer pessoa ou at mesmo pela AC de quem roubou a chave privada. Mas uma infra-estrutura de chaves pblicas tem sua proteo em caso de exposio da chave privada. Caso isso venha a acontecer, a AC avisa a todos os participantes da ICP-Brasil o ocorrido, envia um CSR a AC acima dela na hierarquia e recebe um novo certificado. Em seguida, distribui novamente o seu novo certificado pela infra-estrutura de chaves pblicas. Essa segurana exigida pela ICP muito ampla e cara, mas necessria. Abrange tpicos que poucas empresas sequer imaginaram abordar em sua segurana fsica. Segue abaixo uma relao de algumas preocupaes que uma AC deve ter com seu ambiente fsico.
- Sistemas de segurana devero ser instalados para controlar e auditar o acesso aos sistemas de certificao. - Os sistemas de AC devero estar localizados em rea protegida ou afastados de fontes potentes de magnetismo ou interferncia de rdio freqncia. - Recursos e instalaes crticas ou sensveis devem ser mantidos em reas seguras, protegidas por um permetro de segurana definido, com barreiras de segurana e controle de acesso. Elas devem ser fisicamente protegidas de acesso no autorizado, dano, ou interferncia. A proteo fornecida deve ser proporcional aos riscos identificados. - Quaisquer equipamentos de gravao, fotografia, vdeo, som ou outro tipo de equipamento similar, s devem ser utilizados a partir de autorizao formal e mediante superviso. - Sistemas de deteco de intrusos devem ser instalados e testados regularmente de forma a cobrir os ambientes, as portas e janelas acessveis, nos ambientes onde ocorrem processos crticos. As reas no ocupadas devem possuir um sistema de alarme que permanea sempre ativado. Existem AC's que possuem salas cofres com vrios nveis de acesso, sendo que uma nica pessoa no possui acesso em todas as portas dos nveis. Ou seja, dessa forma, sempre preciso de mais de um indivduo para se atingir o ltimo nvel, dificultando a fraude em uma 36 AC. At mesmo os desastres causados por fogo ou gua (como um sistema anti-fogo) devem ser reestruturado. As auditorias da ICP para validar uma instituio como uma AC so sempre muito rigorosas, sendo que diversas vezes, so necessrias muitas auditorias at que se consiga um ttulo de AC. [12]
37 4 ~ Uma abordagem de ICP para ambientes corporativos
Este captulo do trabalho refere-se implementao do aplicativo, sua instalao e utilizao e algumas polticas de segurana, visando o desenvolvimento de uma infra- estrutura de chaves pblicas em um ambiente coorporativo, permitindo a troca segura e confivel de informaes dentro de uma empresa, garantindo confidencialidade, autenticidade e no-repdio das informaes enviadas. A prpria empresa ir possuir uma Autoridade Certificadora, gerando certificados para seus funcionrios e, se desejar, para seus clientes e parceiros comerciais, reduzindo o custo de se implementar uma estrutura de chaves pblicas j preparada por uma AC comercial. Este trabalho teve uma influncia mercadolgica muito grande. Atualmente as corporaes passam por muitos problemas relacionados a fraudes eletrnicas. Algumas delas so: - Dados enviados em claro, trafegando pela rede sem nenhuma proteo. Esses dados podem ser capturados e lidos enquanto trafegam pela empresa. Podem se tratar de projetos ou informaes cruciais que no deveriam ser lidos por qualquer funcionrio, podendo comprometer a empresa. - Informaes que so enviadas a um destinatrio e so alteradas antes de chegar no mesmo. Por exemplo, um documento enviado pelo diretor financeiro da empresa para a rea de compra com um pedido de 100 unidades de determinada impressora pode ser facilmente alterado para 1000 unidades, provocando um prejuzo na empresa. - Documentos que so enviados em nome de uma pessoa sendo que ela nem mesmo tem o conhecimento da existncia destes. Uma solicitao com o e-mail e o nome do presidente pode ser enviada a rea de informtica da empresa para se alterar alguma configurao de rede. Estas fraudes causam grande prejuzo a algumas empresas. Este projeto permite que esse tipo de fraude seja evitado, minimizando os prejuzos de uma empresa e garantindo segurana nas informaes que precisam ser trafegadas pela rede. O aplicativo pode tambm garantir a guarda de dados. Apesar de ser um objetivo secundrio, esse projeto pode tambm fazer essa funo. Um bom meio de se fazer isto criptografando o dado com a chave pblica de um funcionrio e guardar a informao. Caso essa informao precise ser resgatada, utiliza-se a chave privada do mesmo funcionrio. Ento, cada indivduo dentro da empresa 38 pode guardar seus dados em seu computador de forma segura, garantindo a confidencialidade do documento. Os benefcios que o projeto pretende prover podem ser definidos de forma simples. Confidencialidade, autenticidade e no-repdio dos dados. Atravs da criptografia assimtrica, essa infra-estrutura ir garantir a segurana e a autenticidade dos dados de uma empresa. As informaes no mais iro trafegar em claro, impedindo que terceiros leiam dados que no deveriam ser lidos. Alm do que pode-se assinar digitalmente um documento, garantindo que o remetente realmente a pessoa e no um falsrio se passando por ela. Alm disso, este trabalho ir trazer para a corporao uma economia em gastos que seriam feitos com Autoridades Certificadoras externas ou firewalls e outros mecanismos que no ajudariam muito neste problema, j que a viso do projeto impedir alguns tipos de ataques internos. E tambm ir minimizar o prejuzo da empresa com fraudes eletrnicas. Uma boa poltica de segurana e um aplicativo que gerencie e manipule todo o trabalho com criptografia assimtrica pode ter resultados de forma rpida e confivel, refletindo essa segurana nos oramentos da empresa.
39 4.1 Fluxograma
O projeto desenvolvido pode ser muito bem representado por fluxogramas que demonstraro cada processo executado em toda a infra-estrutura de chaves pblicas. Todos os passos sero muito detalhados para que o entendimento seja o mais claro possvel. O fluxograma do projeto foi dividido em quatro etapas que so os principais processos que ocorrero nessa estrutura de segurana desenvolvida. Cada etapa ser explicada e ilustrada de forma a facilitar o entendimento de toda a infra-estrutura e auxiliando tambm no entendimento do aplicativo.
4.1.1 ~ Geraao do Certificado Digital
Figura 12 - Fluxograma de geraao de certificado
Esse fluxograma representa a gerao de um certificado digital. O cliente inicia todo o procedimento gerando uma CSR (Requisio de Certificado). Nessa gerao de CSR, o cliente ir gerar o par de chaves criptogrficas e um arquivo CSR no padro PKCS #10 explicado anteriormente. Em seguida, o cliente deve se dirigir a Autoridade Certificadora para se identificar. A AC, aps verificar a identidade do cliente, ir gerar e assinar um certificado tornando-o vlido perante a infra-estrutura de chaves pblicas.
40 4.1.2 ~ Troca de chaves criptogrficas
Figura 13 - Fluxograma de troca de chaves criptogrficas
Este fluxograma representa a troca de chaves criptogrficas do projeto. Para que haja uma interao dos usurios dentro de uma infra-estrutura de segurana, estes usurios 41 precisam trocar suas chaves pblicas de criptografia. A figura acima ser detalhada para um melhor entendimento deste processo. Exemplificando, o funcionrio Joo envia o seu certificado para Maria. Maria, ao receber o certificado de Joo, precisa ter a certeza de que esse certificado vlido e conferido pela Autoridade Certificadora em questo. Ento, a cadeia de assinatura do certificado de Joo verificada. Nesse procedimento, ser possvel determinar se a AC assinou esse certificado digital ou se este certificado foi gerado por uma outra AC no confivel, tornando o certificado invlido. A validade do certificado conferida em seguida, pois um certificado vencido no pode ser utilizado para no comprometer a segurana da estrutura projetada. No procedimento de verificao de certificados revogados, Maria consegue a Lista de Certificados Revogados com a AC para verificar se o certificado que ela recebeu de Joo no foi cancelado por algum motivo. Ao final de todas essas verificaes, o certificado pode ser considerado confivel, pois no est revogado, nem vencido e Maria tem a certeza de que foi assinado pela AC em que ela confia. Este certificado recebe o status de confivel. Todo esse procedimento transparente para o usurio.
42 4.1.3 ~ Envio de mensagens
Figura 14 - Fluxograma de geraao de mensagens
A troca de mensagens entre usurios da infra-estrutura o procedimento mais complexo envolvido. Uma explicao mais detalhada necessria para melhor se compreender todo esse processo. Joo ir gerar uma mensagem para Maria que contm as caractersticas de uma mensagem assinada e envelopada. Com a mensagem j definida, Joo ir aplicar um algoritmo de HASH gerando um resumo da mensagem que ele quer enviar. Em seguida, utiliza sua chave privada para assinar esse resumo que foi gerado. Ento, ele tem agora um resumo assinado da mensagem. Em paralelo, ele utiliza uma chave simtrica para poder criptografar a mensagem que ele quer enviar. Ao final deste processo, ele possui agora uma mensagem criptografada por uma chave simtrica. Mas para Maria conseguir abrir essa mensagem, ela tambm precisa da mesma chave simtrica que cifrou a mensagem. Para enviar essa chave em segurana, Joo aplica a chave pblica de Maria para cifrar essa chave simtrica. Em posse de um HASH assinado, uma mensagem criptografada e uma chave simtrica cifrada com a chave pblica do destinatrio, Joo ir gerar um arquivo no padro PKCS #7 contendo estes dados que sero enviados para Maria.
43 4.1.4 ~ Recebimento de mensagens
Figura 15 - Fluxograma de recebimento de mensagens
A etapa de recebimento de mensagens completa o crculo de procedimentos de utilizao da infra-estrutura projetada. Esse procedimento se inicia com Maria recebendo o arquivo no padro PKCS #7. Ao receber esse arquivo, Maria precisa desfazer todo o processo feito anteriormente. Se nenhum problema for apresentado na inverso do processo, Maria poder ler a mensagem 44 que lhe foi enviada, tendo a certeza de que no foi alterada e que ningum mais poderia ter lido a informao contida no arquivo. O primeiro procedimento a seguir o de se extrair a assinatura que est inserida no arquivo que Joo enviou. Como a assinatura consiste em um HASH que se aplicou a chave privada de Joo, Maria ir aplicar a chave pblica de Joo que pode ser conseguida no prprio certificado digital de Joo que ela recebeu anteriormente. Maria agora possui o valor do HASH original que foi gerado da mensagem por Joo. Ela ir precisar deste dado futuramente. Em seguida, Maria extrai a chave simtrica que foi criptografada pela sua chave pblica. Ela utiliza a sua chave privada e consegue desfazer o que sua chave pblica cifrou, conseguindo a chave simtrica que ser utilizada para decifrar a mensagem que est cifrada. Agora Maria ir extrair a mensagem cifrada. Para conseguir ler a mensagem cifrada, Maria ir utilizar a chave simtrica que acabou de decifrar para desfazer a criptografia aplicada mensagem. Nesse momento, Maria j conseguiu algumas garantias a respeito de se utilizar a infra-estrutura de chaves pblicas. Como ela, utilizando a chave pblica de Joo, conseguiu desfazer a assinatura e conseguir o HASH (que foi assinado pela chave privada de Joo), j tem a certeza de que foi Joo quem assinou essa mensagem. Tambm, como sabe que a chave simtrica que cifrou a mensagem esta protegida pela sua chave pblica e que somente ela pode desfazer esta criptografia, ela tem a certeza de que ningum mais leu esta mensagem. S resta saber se aps Joo assinar a mensagem, esta no foi alterada. Para ter essa certeza, Maria aplica o mesmo algoritmo de HASH que Joo utilizou para se conseguir o valor do resumo. Aps conseguir esse valor, ela compara com o valor original que veio com o arquivo PKCS #7 e verifica se eles so iguais. Caso os valores sejam idnticos, significa que essa mensagem no foi alterada em nenhum momento. Isso acaba de garantir para Maria toda confidencialidade, autenticidade e no-repdio que uma infra-estrutura de segurana poderia oferecer.
45 4.2 ~ Polticas de Segurana
Essa poltica tem como objetivo orientar todas as aes de segurana, para reduzir riscos e garantir a integridade, sigilo e disponibilidade das informaes dos sistemas de informao e recursos. A poltica de segurana necessria para a implementao e utilizao do projeto deve ser rigorosamente seguida. Uma ocorrncia de fraude pode comprometer um usurio ou, at mesmo, toda a infra-estrutura de segurana de uma empresa. Essa segurana se estende por todos os usurios desse servio e, principalmente, a Autoridade Certificadora, que o principal ponto em toda a estrutura. A AC deve ter uma segurana muito maior do que a dos outros participantes da infra- estrutura porque se de alguma forma a chave privada da AC for violada, todo o sistema poder estar comprometido. Essa chave privada poderia ser utilizada para assinar outros certificados gerados de forma ilcita. E esses falsos certificados tornariam-se verdadeiros dentro da empresa. Ento, a poltica de segurana descrita para esse projeto deve ser implementada para o timo funcionamento da infra-estrutura.
Abrangncia: - Requisitos de segurana Fsica - Requisitos de segurana Lgica
4.2.1 - Consideraes Gerais
- Esta poltica deve ser comunicada para todo o pessoal envolvido e largamente divulgada atravs das entidades, garantindo que todos tenham conscincia da mesma e a pratiquem dentro da empresa. - Aconselha-se um programa de conscientizao sobre segurana da informao para assegurar que todo o pessoal seja informado sobre os potenciais riscos de segurana e exposio a que esto submetidos os sistemas e operaes das entidades. - Previso de mecanismo e repositrio centralizado para ativao e manuteno de trilhas, logs e demais notificaes de incidentes. 46 - Esta Poltica de Segurana deve ser revisada e atualizada periodicamente no mximo a cada 3 (trs) anos, caso no ocorram eventos ou fatos relevantes que exijam uma reviso imediata.
4.2.2 - REQUISITOS DE SEGURANA DO AMBIENTE FISICO
4.2.2.1 - Responsabilidade da AC
- Sistemas de segurana para acesso fsico como cmeras, portas com acesso restrito, etc, devero ser instalados para controlar e auditar o acesso aos sistemas de certificao. - Controles duplicados sobre o inventrio e cartes/chaves de acesso devero ser estabelecidos. Uma lista atualizada do pessoal que possui cartes/chaves dever ser mantida. - O servidor da AC deve ser mantido em rea segura, protegido por um permetro de segurana definido, com barreiras de segurana e controles de acesso. Deve ser fisicamente protegido de acesso no autorizado, dano, ou interferncia. A proteo fornecida deve ser proporcional aos riscos identificados. - A entrada e sada, nestas reas ou partes dedicadas, devero ser automaticamente registradas com data e hora definidas. - Quaisquer equipamentos de gravao, fotografia, vdeo, som ou outro tipo de equipamento similar, no so permitidos dentro do ambiente do servidor da AC. - O ambiente pertinente a AC deve ser monitorado, em tempo real, com as imagens registradas por meio de sistemas de CFTV. - Sistemas de deteco de intrusos devem ser instalados e testados regularmente de forma a cobrir os ambientes, as portas e janelas acessveis, no ambiente da AC.
47 4.2.3 - REQUISITOS DE SEGURANA DO AMBIENTE LGICO
4.2.3.1 - Responsabilidade da AC
- Os dados, as informaes e os sistemas de informao das entidades e sob sua guarda devem ser protegidos contra ameaas e aes no autorizadas, acidentais ou no, de modo a reduzir riscos e garantir a integridade, sigilo e disponibilidade desses bens. - As violaes de segurana devem ser registradas e esses registros devem ser analisados periodicamente para os propsitos de carter corretivo, legal e de auditoria. - Os sistemas devem possuir controle de acesso de modo a assegurar o uso apenas a usurios ou processos autorizados. O responsvel pela autorizao ou confirmao da autorizao deve ser claramente definido e registrado. - Os arquivos de logs devem ser criteriosamente definidos para permitir recuperao nas situaes de falhas, auditoria nas situaes de violaes de segurana e contabilizao do uso de recursos. Os logs devem ser periodicamente analisados para identificar tendncias, falhas ou usos indevidos. - O acesso lgico, ao ambiente ou servios disponveis em servidores, deve ser controlado e protegido. As autorizaes devem ser revistas, confirmadas e registradas continuadamente. - O nico acesso remoto ao servidor da AC disponvel para divulgao de certificados dos usurios e listas de certificados revogados. - Devem ser adotados procedimentos sistematizados para monitorar a segurana do ambiente operacional, principalmente no que diz respeito integridade dos arquivos de configurao do sistema operacional e de outros arquivos crticos. - Proteo lgica adicional (criptografia) deve ser adotada para evitar o acesso no- autorizado s informaes. - A verso do sistema operacional, assim como outros softwares bsicos instalados em mquinas servidoras, devem ser mantidos atualizados, em conformidade com as recomendaes dos fabricantes. - Os procedimentos de cpia de segurana (backup) e de recuperao devem estar documentados, mantidos atualizados e devem ser regularmente testados. - Firewalls, IDS e outros tipos de proteo contra ataques externos devem ser empregados para garantir a segurana do servidor. 48 - As seguintes caractersticas das senhas de acesso devem estar definidas de forma adequada: conjunto de caracteres permitidos, tamanho mnimo e mximo, prazo de validade mximo, forma de troca e restries especficas. - O sistema de controle de acesso deve permitir ao usurio alterar sua senha sempre que desejar. A troca de uma senha bloqueada s deve ser executada aps a identificao positiva do usurio. A senha digitada no deve ser exibida. - O servidor deve sempre estar atualizado com antivrus e antitrojans para evitar que qualquer aplicativo dessa natureza comprometa a segurana.
4.2.3.2 - Responsabilidade do Cliente
- Devem ser adotadas medidas de segurana lgica referentes a combate a vrus, trojans, backup, controle de acesso e uso de software no autorizado. - A entidade dever estabelecer os aspectos de controle, distribuio e instalao de softwares utilizados. - Os sistemas em uso devem solicitar nova autenticao aps certo tempo de inatividade da sesso (time-out). - Os procedimentos de combate a processos destrutivos (virus, cavalo-ae-troia e worms) devem estar sistematizados e devem abranger mquinas servidoras, estaes de trabalho, equipamentos portteis e microcomputadores stana alone que utilizem a infra-estrutura. - Os computadores pessoais devem ser protegidos por senhas de acesso ao sistema operacional e o acesso REMOTO aos computadores devem ser feitos apenas por funcionrios ou servios autorizados.
49 4.3 - Requisitos e Instalaao
Existem procedimentos relativos instalao e implantao do aplicativo desenvolvido neste projeto para gerenciamento e guarda das chaves criptogrficas que se referem tanto a AC quanto ao computador pessoal utilizado pelos usurios finais. Alguns pr-requisitos so exigidos para o bom funcionamento de toda a infra- estrutura. A instalao abrange desde a instalao do sistema operacional e configurao do mesmo at a instalao do aplicativo desenvolvido. Essa instalao deve ser seguida corretamente, enfatizando a parte relativa a segurana do terminal disponibilizado para servir como AC.
4.3.1 - Pr-Requisitos para a Autoridade Certificadora
O servidor para a AC deve conter a seguinte configurao fsica (Ou superior): - Pentium III 1.0Ghz - 512 Mb de memria Ram - Placa de rede 10/100 Mbps - Drive de disquete 1.44 - Monitor - Teclado - Mouse - Porta USB
Softwares Necessrios: - Windows 2000 ou XP - Java SDK 1.3 - Bibliotecas de criptografia da Bouncy Castle - Apache Server 2.0 para Windows - Um Firewall de escolha da empresa - Internet Explorer - Antivrus a escolha da empresa - Antitrojans a escolha da empresa 50 - Pacote desenvolvido neste trabalho contendo o aplicativo para gerenciamento e guarda de chaves criptogrficas. 4.3.2 - Instalaao da AC 4.3.2.1 - Instalando o sistema operacional
- O Sistema operacional deve ser instalado em sua forma mais bsica, sem disponibilidade de servio adicional. Devero ser ativados todos os servios de auditoria relativos a gravao de logs ou trilhas. - Devero ser criados usurios para acesso ao sistema. - O usurio administrador s dever ser utilizado em emergncias. - A senha do usurio administrador dever ser guardada em local seguro e com acesso restrito apenas a determinados funcionrios que podero fazer uso da mesma. - Servios do sistema operacional como Telnet, FTP ou qualquer outro tipo de acesso remoto diferente do oferecido pelo aplicativo APACHE no devero estar habilitados.
51 4.3.2.2 - Instalando o JAVA SDK 1.3
- Instalar a verso 1.3 do JAVA SDK padro. No necessita de maiores alteraes de segurana. A Virtual Machine j acompanha o pacote de instalao do Java e necessria para o funcionamento do aplicativo relativo a AC. - A instalao ser necessria para a utilizao do aplicativo.
Figura 16 - Instalaao do Java
52 4.3.2.3 - Instalando o Apache Server 2
Nesse passo j importante frisar a configurao do Servidor WEB. Um certo nvel de segurana j necessrio nessa configurao e ser apresentado nesse momento.
- Instalar o pacote do APACHE HTTP SERVER 2.0 ou superior para plataforma Windows. - A instalao deve ser feita no modo padro. - O arquivo httpd.conf deve ser configurado conforme abaixo:
# Listen: Allows you to bind Apache to specific IP addresses and/or # ports, instead of the default. # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) #Listen 12.34.56.78:80 Listen 80
Nessa parte da configurao do servidor, o comando Listen deve estar setado apenas para responder na porta 80. Essa porta ir ser utilizada pelo aplicativo do usurio para conseguir informaes sobre a CRL (Lista de Certificados Revogados). Em seguida, segue o cdigo de configurao do diretrio reservado para a CRL. Esse diretrio deve ser configurado para o local onde a lista for divulgada. Dessa forma, o usurio s poder acessar esse diretrio na forma de leitura.
# DocumentRoot: The directory out of which you will serve your # documents. By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations. DocumentRoot "C:/CRL"
53 4.3.2.4 - Segurana lgica
A segurana implementada no servidor da AC de extrema importncia para a infra- estrutura. Esse tpico detalha um nvel de segurana mnimo para que o servidor seja confivel.
- Instalar e configurar o Firewall escolhido. As configuraes do firewall devero ser definidas de forma a bloquear todo e qualquer pacote ou requisio que no seja do tipo TCP/IP na porta 80 do servidor. - O antivrus escolhido deve ser instalado e a atualizao do mesmo deve ser configurada como automtica. A verificao de novas atualizaes do antivrus deve ser diria. - O antitrojan escolhido deve ser instalado e a atualizao do mesmo deve ser configurada como automtica. A verificao de novas atualizaes do antitrojan deve ser diria. - Os logs de acesso remoto e local devem ser gravados em disco e, se possvel, utilizando algum tipo de criptografia simtrica. - Configurar o servidor com um IP fixo na rede para responder as requisies de Lista de Certificados Revogados. - Os usurios criados para acessarem o sistema operacional devero ter acesso limitado s funes destinadas a eles. - Mesmo com o firewall habilitado e configurado, os servios de acesso remoto no permitidos devero ser desativados. - Dever ser configurada uma proteo de tela com uma senha que se ativar em um tempo de 5 minutos. - As atualizaes automticas do sistema operacional devero estar habilitadas para que o prprio sistema se encarregue dessa funo.
54 4.3.3 - Pr-Requisitos para o Cliente
O computador pessoal para o cliente deve conter a seguinte configurao fsica (Ou superior): - Pentium III 500 Mhz - 128 Mb de memria Ram - Placa de rede 10/100 Mbps - Drive de disquete 1.44 - Drive de CD-ROM - Monitor - Teclado - Mouse - Porta USB
Softwares Necessrios:
- Windows 2000 ou XP - Java Virtual Machine - Internet Explorer - Outlook Express - Antivrus a escolha da empresa - Antitrojans a escolha da empresa - Pacote contendo o aplicativo para utilizao e guarda de chaves criptogrficas (Mdulo do Cliente)
55 4.3.4 - Instalaao do Cliente
4.3.4.1 - Instalando o sistema operacional
- O Sistema operacional deve ser instalado em modo padro, sem disponibilidade de servio adicional. Devero ser ativados todos os servios de auditoria relativos a gravao de logs ou trilhas. - Os usurios de acesso a mquina ficam a critrio da empresa. - O usurio no ter acesso ao usurio administrador. - Qualquer outro programa a ser instalado dever estar de acordo com as normas da empresa.
4.3.4.2 - Segurana lgica
A segurana relativa ao cliente importante para evitar fraudes em relao a sua chave privada. Entretanto, importante frisar que essa chave de responsabilidade do funcionrio. Sua guarda, apesar de protegida pelo aplicativo, deve ser sempre observada pelo usurio.
- O antivrus escolhido deve ser instalado e a atualizao do mesmo deve ser configurada como automtica. A verificao de novas atualizaes do antivrus deve ser diria. - O antitrojan escolhido deve ser instalado e a atualizao do mesmo deve ser configurada como automtica. A verificao de novas atualizaes do antitrojan deve ser diria. - Os logs de acesso remoto e local devem ser gravados em disco e, se possvel, utilizando algum tipo de criptografia simtrica. - A estao de trabalho pode utilizar IP dinmico. - Os usurios com acesso ao terminal devem ter acessos limitados. - Dever ser configurada uma proteo de tela com senha que se ativar num tempo de 15 minutos. - As atualizaes automticas do sistema operacional devero estar habilitadas para que o prprio sistema se encarregue dessa funo. 56 4.4 - Utilizaao da ICP projetada
Este tpico ir apresentar e explicar todo o escopo do aplicativo desenvolvido para o gerenciamento das chaves criptogrficas em uma ICP. As imagens da aplicao esto sendo apresentadas de forma a facilitar a compreenso do mesmo. Atravs do aplicativo, ser possvel um melhor entendimento de uma infra-estrutura de chaves pblicas, j que a funo desta aplicao a de exemplificar e embasar o projeto desenvolvido. O projeto possui dois plos distintos: o cliente e a AC.
4.4.1 ~ O mdulo Cliente
O mdulo definido na parte do cliente mais complexo do que o da AC porque a interao entre os usurios maior, mais freqente e precisa ser muito mais elaborada do que a interface da AC, que ir apenas gerar certificados e listas de certificados revogados. Este mdulo define o uso da infra-estrutura de chaves pblicas por parte do cliente. As funes so diversas. Conforme mostra a figura abaixo, as funcionalidades que sero apresentadas so: Importaao de certificados, Exportaao do prprio certificado, Assinatura e Criptografia de Mensagens, Decifragem e verificaao de assinaturas em mensagens e Requisiao de Certificados para a AC.
Figura 17 - Tela Principal do mdulo Cliente
57 4.4.1.1 ~ Requisiao de Certificados
Essa funcionalidade representa o incio da participao de um usurio dentro de uma infra-estrutura de chaves pblicas. O procedimento que aqui executado ir gerar uma REQUISIO DE ASSINATURA DE CERTIFICADO (CSR) que dever ser enviada para a AC. Neste momento gerado o par de chaves que ser utilizado na criptografia assimtrica. A chave privada ficar sob a guarda do usurio enquanto um protocolo no formato PKCS #10 ir ser gerado e enviado para a AC. O usurio deve lembrar que dever estar presente na entrega desse arquivo, pois o certificado s ser gerado mediante identificao do funcionrio.
Figura 18 - Geraao da CSR
Um funcionrio responsvel pela recepo da CSR ir comprovar se o usurio ele mesmo atravs de uma documentao exigida, como o CPF e a Carteira de Identidade e em seguida ir impostar o nome e o CPF do usurio para poder gerar o certificado Digital.
58 4.4.1.2 ~ Importaao de Certificados Digitais
Este processo representa a troca de certificados entre os usurios da ICP. Atravs desta funcionalidade do aplicativo, o usurio ir receber certificados digitais de outros usurios para poder trocar informaes de forma segura e confivel. Os certificados que sero importados e definidos como confiveis so pblicos a qualquer participante da ICP dentro de uma corporao. Neste momento ocorrem algumas verificaes de grande importncia para a segurana da infra-estrutura criada. Para se evitar que um indivduo mal intencionado crie certificados de outros usurios, como o de um presidente, por exemplo, algumas verificaes so necessrias. Ao se importar um certificado, ser feita uma verificao de cadeia de assinatura. Quando a AC gera um certificado, significa que aquele certificado foi assinado pela chave privada desta AC. Ento, quando o aplicativo recebe um certificado, a chave pblica da AC (conseguida no certificado da AC que tambm pblico) utilizada neste certificado recebido para se ter certeza de que foi realmente a autoridade certificadora em questo que assinou aquele certificado digital, tornando-o vlido. Alm disso, a aplicao ir buscar uma CRL (Lista de Certificados Revogados) junto a AC de forma a verificar se o certificado recebido no est revogado.
Figura 19 - Importaao de Certificados
59 4.4.1.3 ~ Exportaao do Certificado Digital
Figura 20 - Exportaao de um certificado digital
O processo de exportao de um certificado digital muito simples e faz parte da troca de certificados. O usurio poder exportar o seu prprio certificado e o de outro usurio do servio de ICP, caso deseje. Esse procedimento transparente para o usurio e efetuado de forma segura, sem que haja qualquer interligao com a chave privada.
60 4.4.1.4 ~ Geraao de uma Mensagem Assinada e Cifrada
A funcionalidade da gerao de uma mensagem assinada e cifrada consiste no seguinte processo. O aplicativo recebe um texto digitado em sua interface com o cliente. Pode ser implementado tambm para atuar em um arquivo definido pelo usurio. Em seguida, o procedimento que ele executa funciona de acordo com a seqncia abaixo:
1- Um algoritmo de HASH do tipo SHA1 aplicado sobre a mensagem, gerando um resumo desta. 2- Nesse momento, a chave privada do usurio utilizada para assinar o HASH que foi gerado anteriormente. 3- O certificado digital de um outro usurio escolhido para se utilizar a chave pblica do mesmo para a cifragem
Em seguida, o aplicativo ir salvar a informao assinada e cifrada em um arquivo com o padro do protocolo PKCS #7 explicado anteriormente, sendo do tipo assinado e envelopado.
Figura 21 - Assinatura e cifragem de uma mensagem
61 4.4.1.5 ~ Recepao de mensagem assinada e cifrada
Figura 22 - Conferncia e decifragem de uma mensagem
Esse procedimento caracterizado pelo recebimento de uma mensagem assinada e cifrada por um outro usurio. A aplicao ento ir utilizar em primeiro lugar uma decifragem utilizando a chave privada do usurio que recebeu a mensagem. Aps decifrar a mensagem, necessrio verificar a assinatura e a integridade dos dados. O aplicativo ir utilizar a chave pblica do usurio que enviou a mensagem e aps isso ir gerar um HASH da mensagem que estava protegida no arquivo padro PKCS #7. Se o HASH gerado sobre a mensagem for o mesmo que estava protegido pela chave privada do emissor da mensagem, ento a informao ser validada.
62 4.4.2 ~ O mdulo AC
Este mdulo define o uso da infra-estrutura de chaves pblicas por parte da AC. As funes so divididas em dois processos: o de geraao de certificados e o de revogaao de certificados. Os usurios no possuem acesso a nenhum dos dois processos, sendo exclusivos apenas s pessoas com permisses para operar o terminal da Autoridade Certificadora.
Figura 23 - Tela principal do mdulo AC
A revogao dos certificados pode ser feita por qualquer razo que possa comprometer a infra-estrutura de chaves pblicas. Um usurio que pode ter tido sua chave privada roubada ou mesmo um usurio que esteja utilizando sua chave criptogrfica transgredindo alguma norma da empresa pode ter seu certificado revogado, seja por solicitao ou por deciso da corporao.
63 4.4.2.1 ~ Geraao de Certificados Digitais
Figura 24 - Geraao de certificados digitais
A gerao de um certificado mediante solicitao ocorre neste processo. O cliente entrega um arquivo CSR para um operante da AC e recebe um certificado digital em seu nome.
4.4.2.2 ~ Revogaao de Certificados
Figura 25 - Revogaao de certificados digitais
O processo de revogao de certificados digitais bem simples. Um usurio ou a corporao pode decidir revogar um certificado. Aps ser revogado, o certificado passa a no ser mais vlido dentro da infra-estrutura projetada. Essa revogao inclui o certificado cancelado na Lista de Certificados Revogados, que utilizada pelo aplicativo para verificar se um certificado digital que ser utilizado est ativo ou no.
64 4.5 - Decises de Projeto
4.5.1 - Quanto estrutura
A estrutura escolhida para o projeto foi do tipo hierrquica. Essa topologia foi selecionada porque em diversos aspectos se aproxima da formao da ICP-Brasil, que a atual entidade raiz no Brasil. Outros fatores tambm foram decisivos. A estrutura hierrquica, ao contrrio da mista, uma estrutura que demanda um menor tempo de implementao, j que a validao de cadeia de assinatura dos certificados mais simples. A visualizao da infra-estrutura muito mais simples, j que se tem uma entidade raiz e todos os outros participantes dessa estrutura ficam situados abaixo. importante tambm enfatizar o lado da segurana dessa infra-estrutura. Qualquer problema que ocorra com a AC relativo a fraude poder ser rapidamente contornado. Se a chave privada for corrompida, a AC poder gerar uma outra chave rapidamente e distribuir a todos os participantes dependentes da sua infra-estrutura. Numa estrutura mista, mais complexo, j que a distribuio do novo certificado vai alm das dependncias daquela AC. A proposta do trabalho implementar uma infra-estrutura interna a uma empresa, independente de outras Autoridades Certificadoras, sejam elas AC's do mercado ou particulares de outras empresas. Esse fator diminui o custo de implementao da infra- estrutura de chaves pblicas. Os gastos e o tempo com implantao e desenvolvimento dos aplicativos so menores utilizando a topologia hierrquica.
4.5.2 - Quanto poltica de segurana
A poltica de segurana foi definida da forma apresentada para garantir um mnimo de segurana a AC e aos clientes desta. Essa poltica de segurana pode ser incrementada, conforme a utilizao da ICP ou o grau de importncia das informaes que trafegam pela rede. Muitos aspectos foram herdados das normas da ICP-Brasil. Tanto as normas de segurana lgica e fsica foram estudadas para proporcionar uma boa segurana. As principais 65 caractersticas desta poltica de segurana implementada foram o tempo de implementao e o baixo custo. Atualmente a implantao de uma AC no mercado exige um custo altssimo em segurana fsica e lgica. E ainda traz mudanas considerveis ao ambiente em que ela instalada, como novas metodologias de trabalho e restries de reas. A poltica deste trabalho no apresenta gastos altos para a empresa e muitos tpicos definidos, como o de segurana, j so inicialmente impostos pelas prprias empresas. Algumas normas j so implementadas pela corporao enquanto outras trazem baixos custos para implantao. O ambiente fsico restrito citado pode ser qualquer ambiente com um mnimo de segurana, onde no seja aberto a todos os funcionrios. Isso j garante um nvel de segurana. E a segurana lgica escolhida pode ser implementada pelo prprio sistema operacional com o auxlio de outros aplicativos como antivrus, antitrojans e firewalls, garantindo um segundo nvel de segurana e limitando o nmero de usurios com permisso a acessar essa AC.
4.5.3 - Quanto ao desenvolvimento em linguagem JAVA
A linguagem Java foi utilizada para o desenvolvimento devido a suas caractersticas genricas. A portabilidade desta linguagem permite que o aplicativo seja utilizado tanto em ambiente Windows quanto Linux. Mas o ambiente Linux possui algumas restries, devido a apenas algumas novas verses possurem suporte a certificados digitais. Alm da portabilidade, a linguagem oferece uma grande facilidade na implementao e, principalmente, uma segurana extra para o aplicativo. A linguagem C poderia ter sido utilizada, juntamente com as bibliotecas de criptografia da Microsoft, mas isso limitaria a aplicao a um tipo de plataforma alm de requerer um conhecimento muito amplo das bibliotecas da Microsoft. Isso demandaria um tempo desnecessrio a implementao do projeto. Apesar da portabilidade, o aplicativo no foi testado no ambiente Linux e isso dever ser feito futuramente. O ambiente de desenvolvimento utilizado foi o Eclipse Platform, da IBM, que uma ferramenta Free e auxilia na visualizao do projeto e influencia no desenvolvimento do trabalho, alm do prprio ambiente compilar e analisar os cdigos escritos.
66 4.5.4 - Quanto s bibliotecas da Bouncy Castle A organizao Bouncy Castle trabalha especificamente com classes em Java desenvolvidas para manipulao de criptografia e certificao digital. Essa organizao disponibiliza gratuitamente suas classes e a documentao, divulgando assim, seus servios. A utilizao destas classes permitiu que a implementao do aplicativo fosse mais simples. Essas classes foram escolhidas para o desenvolvimento devido a grande quantidade de mtodos que permitem ao programador trabalhar com gerao de chaves simtricas ou assimtricas, gerao de certificados digitais e at mesmo assinaturas digitais. O escopo do projeto no abrange a implementao de algoritmos criptogrficos, j que essa implementao muito pesada e demandaria um estudo muito mais aprofundado na rea matemtica sobre criptografia. Ento, optou-se por utilizar as classes da Bouncy Castle para utilizao dos algoritmos mais comuns no mercado e para facilitar a gerao e manipulao de certificados digitais. Outros fatores da utilizao destas classes foram a otimizao destas classes, trabalhando de forma rpida com criptografia assimtrica e a compatibilidade com o padro de certificados X.509, que est sendo utilizado no projeto.
4.5.5 - Quanto ao sistema operacional
O sistema operacional da Microsoft possui algumas caractersticas que eram necessrias execuo do projeto. A escolha do Windows 2000 para implementao do projeto foi embasada na facilidade com que esse sistema operacional possui de trabalhar com certificados digitais. A Microsoft possui muitos recursos de acesso a certificados e outras facilidades que ainda no foram implementadas no sistema operacional Linux. Estes recursos foram decisivos para a escolha do sistema operacional a ser utilizado. Alm disso, so diversas as ferramentas de desenvolvimento visual e de cdigo para a linguagem Java que so da plataforma Windows. Isso contribuiu com o andamento do trabalho.
67 4.5.6 - Quanto ao algoritmo RSA
Atualmente o algoritmo RSA o mais utilizado no mercado e em diversas solues que envolvem criptografia assimtrica. Sua segurana indiscutivelmente muito forte, inibindo qualquer tipo de ataque que utilize fora bruta. A escolha desse algoritmo foi embasada nestes dois fatores. O projeto foi desenhado em cima desse algoritmo, pois o RSA possui uma grande aceitao no mercado, j que diversos tipos de testes e ataques j foram efetuados em cima desse algoritmo sem resultados. O motivo da escolha baseado na fora criptogrfica deste algoritmo simples. Esse algoritmo est h muito tempo no mercado e seu algoritmo de domnio pblico. Isso comprova que o poder est na chave criptogrfica, que torna invivel a quebra dessa criptografia. Ento, acaba por se tornar um algoritmo muito seguro e confivel. No se sabe de nenhum ataque de fora bruta que tenha tido sucesso em um curto espao de tempo sobre o algoritmo RSA. E quanto maior o tamanho da chave, maior a dificuldade de se quebrar essa criptografia. 68 5 ~ Conclusao
Servios como transaes bancrias, comrcios eletrnicos, entre outros, precisam de uma segurana concreta e uma garantia de ambos os participantes da transao. Atravs da criao de uma autoridade certificadora que valide os participantes, um aplicativo gerenciador de chaves criptogrficas e uma poltica de segurana uma infra-estrutura foi construda para garantir essa troca de informaes. O projeto demonstra que atualmente a principal tecnologia para garantir processos bsicos como confidencialidade, integridade e autenticidade no trfego de uma rede de comunicao o processo de certificao digital. Utilizando-se de criptografia assimtrica pode-se garantir esses processos. A utilizao pura e simples de pares de chaves para garantir requisitos como integridade, confidencialidade e autenticidade encontram seu grande obstculo no gerenciamento destas chaves criptogrficas. O projeto apresentou uma soluo para a garantia destes servios de criptografia atravs de um modelo implementado que garante a gerao e validao dos certificados, simulando uma autoridade certificadora que ir gerar e assinar todos os certificados digitais que estaro em uso dentro da infra- estrutura. Diversos prejuzos podem ser evitados utilizando-se desta infra-estrutura criada, minimizando assim, as perdas de uma corporao. Ficou tambm definido que apenas um aplicativo para tal gerenciamento no suficiente. Uma poltica de segurana com uma boa base de informao ao usurio tornam-se fundamental para a utilizao correta de uma ICP. O trabalho abrangeu tambm a explicao de como funciona o processo de criptografia assimtrica e assinatura digital, que so conceitos importantes para todos os usurios da infra-estrutura. Todo o objetivo do trabalho desenvolvido est focado para a segurana da informao que trafega em uma rede aberta, onde toda e qualquer informao pode ser interceptada ou alterada durante seu percurso. Diversas empresas j 69 amargaram altos prejuzos por falhas de segurana quanto a confidencialidade de seus dados. Avalizando o conceito de utilizao do processo de Certificao Digital no Brasil, vem a ICP-Brasil regulamentando a infra-estrutura de chaves pblicas brasileiras. Finalizando, uma infra-estrutura de chaves pblicas no pode ser implementada da noite para o dia confiando-se apenas na tecnologia utilizada. Deve-se ter a preocupao com os usurios, principalmente. Estes devem ser informados sobre o funcionamento de uma ICP e conhecer a poltica de segurana nela definida. Dessa forma, ser possvel garantir integridade, confidencialidade e no-repdio das informaes digitais que trafegam dentro de um ambiente corporativo.
Implementaes Futuras
Algumas alteraes ou melhorias podem ser adicionadas ao projeto de forma a se ter uma infra-estrutura de chaves pblicas mais segura e bem elaborada. So elas:
- Suporte a cartes criptogrficos: A utilizao de cartes de criptografia pode garantir uma maior segurana e maior flexibilidade do projeto. Entretanto, ser necessrio um maior estudo do sistema operacional a se utilizar, j que cada sistema possui sua prpria comunicao com as leitoras de Smart Card. - Implementao de uma estrutura mista: Com essa implementao, uma corporao pode trabalhar em parceria com outra, aceitando e validando certificados participantes de outras ICPs. - Interao com aplicativos internos a empresa: Modularizar a aplicao de forma a se conseguir diversas funcionalidades separadas para qualquer servio dentro de uma empresa possa utilizar os mtodos de criptografia. 70 - Centralizao dos diretrios: Os diretrios atualmente no esto centralizados. Cada usurio possui os seus diretrios de certificados. Implementando uma estrutura centralizada pode garantir maior segurana desta ICP. - Melhoria da poltica de segurana do projeto: A poltica utilizada foi desenvolvida de forma bsica, para no se gerar custos a corporao que pretende utilizar a ICP. Uma nova poltica pode ser desenvolvida e otimizada para se complementar a atual. Uma poltica de segurana bem elaborada pode ser decisiva em um projeto de ICP. 71 6 ~ Referncias Bibliogrficas
[1] - Comercio & Segurana na hEB: Simsom Garfinkel e Gene Sparfford So Paulo, Market Press, 1999.
[2] - Certificao Digital: Fernando Augusto Higa, Jorge Andr R. N. Murr monografia, Porto Alegre, 2002.
[3] - Criptografia e Segurana - o guia oficial RSA: Steve Burnett, Stephen Paine Rio de Janeiro, Editora Campus, 2002.
[4] - Segurana em Computao: Ricardo Felipe Custdio, Santa Catarina, monografia, 2000.
[5] - Infra-estrutura ae chaves publicas um estuao comparativo entre o moaelo brasileiro e o moaelo americano: Jos Roberto Lenotti monografia, Bauru 2002.
[6] - RSA Criptografia Assimetrica e Assinatura Digital: Luis Alberto M. Barbosa, Luis Fernando B., Marcelo L. Brisqui, Sirlei Cristina da Silva, Campinas, 2003.
[7] - Plannig for PKI: Russ Housley, Tim Polk Canada, Wiley Computer Publishing, 2001.
[8] - RFC [3029{ - Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols, 2001.
[9] - Introauction to the PKCS Stanaaras: Mohan Atreya, tutorial.
/** * Autor: Bruno * * Classe responsvel por gerenciar o load da parte da Autoridade Certificadora * * Gera diretrios de certificados validos e revogados. * Verifica se j existe um certificado gerado para a AC. * Caso no exista, gera um auto-assinado. * */ SDFNDJH ca.controle;
//cria diretorios se necessario QHZ File(DIRETORIO_CERTIFICADOS).mkdirs(); QHZ File(DIRETORIO_CERTIFICADOS_REVOGADOS).mkdirs(); //gera certificado autoassinado da CA se necessario LI(!QHZ File(ARQUIVO_CHAVE_CA).exists() || !QHZ File(ARQUIVO_CERTIFICADO_CA).exists()){
//avisa a criacao do certificado da CA JOptionPane.showMessageDialog(frame, "Ser gerado agora um certificado raz para a Autoridade Certificadora (CA)");
WU\{ //gera o par de chaves KeyPair kp = Utils.gerarKeyPairRSA();
//gera um certificado auto assinado, logo o proprietario(subject) e o emissor(issuer) so iguais X509CertificateObject cert = Utils.gerarCertificadoX509V3(SUBJECT_CA, SUBJECT_CA, "01", kp, "SHA1withRSAEncryption");
//grava a chave privada em PKCS 12 e o certificado em um outro arquivo Utils.gravarPrivKeyPkcs12(ARQUIVO_CHAVE_CA, SENHA_CA.toCharArray(), kp.getPrivate(), ALIAS_CA, cert); Utils.gravarCertificado(cert, ARQUIVO_CERTIFICADO_CA);
//ok JOptionPane.showMessageDialog(frame, "O certificado raz para a Autoridade Certificadora foi gerado com sucesso!");
}FDWFK(Exception e){ e.printStackTrace(); JOptionPane.showMessageDialog(frame, "Erro ao gerar o certificado raz da CA: "+e.getMessage()); } }
/** * Gera certificado a partir de uma requisicao. */ SULYDWH YRLG gerarCertificado(){
WU\{
//pergunta por um arquivo ao usuario File arq = GuiUtils.promptFileForOpen(WKLV, "Abrir Requisio de Certificado", QXOO); LI(arq == QXOO){ //usuario abortou UHWXUQ; } 80
//tenta ler a requisicao de certificado PKCS10CertificationRequest req = Utils.getInstanceRequisicaoCertificado(arq.getAbsolutePath());
//extrai o proprietario String proprietario = req.getCertificationRequestInfo().getSubject().toString();
//recupera a chave publica da requisicao PublicKey pubKey = req.getPublicKey();
//le a chave privada da ca PrivateKey privKey = Utils.lerPrivKeyPkcs12(ControleCA.ARQUIVO_CHAVE_CA, ControleCA.SENHA_CA.toCharArray(), ControleCA.ALIAS_CA);
//le o certificado da ca X509CertificateObject certCA = Utils.getInstanceCertificadoX509(ControleCA.ARQUIVO_CERTIFICADO_CA);
//extrai o emissor String emissor = certCA.getSubjectDN().getName();
//gera numero serial LQW qtdeArquivos = (QHZ File(ControleCA.DIRETORIO_CERTIFICADOS).list().length) + 1; String serialNumber = Integer.toString(qtdeArquivos);
//insere a chave publica do proprietario e assina o certificado com a chave privada da CA KeyPair kp = QHZ KeyPair(pubKey, privKey);
//gera certificado assinado pela CA X509CertificateObject cert = Utils.gerarCertificadoX509V3(proprietario, emissor, serialNumber, kp, "SHA1withRSA");
//grava arquivo no diretorio da CA String nmArqCertNovo = ControleCA.DIRETORIO_CERTIFICADOS + File.separator + serialNumber+".crt"; Utils.gravarCertificado(cert, nmArqCertNovo);
//pergunta por um arquivo para salvar o certificado File arqCertCliente = GuiUtils.promptFileForSave(WKLV, "Salvar Certificado", QXOO);
//recupera o nome do arquivo com a extensao LQW i = selecao.indexOf(".crt"); String nmArq = selecao.substring(0, i + 4); String nmArqCer = ControleCA.DIRETORIO_CERTIFICADOS + File.separator + nmArq;
//copia para o diretorio de certificados revogados String nmArqCerRevogado = ControleCA.DIRETORIO_CERTIFICADOS_REVOGADOS + File.separator + nmArq; WU\{
/** * Autor: Bruno * * Classe responsvel por gerenciar o load da parte do cliente * * Gera diretrios de certificados confiveis e revogados. * Verifica se j existe um certificado gerado para o cliente. * Verifica se existe uma CA confivel e se existe uma chave * privada para o funcionrio em questo. * */ SDFNDJH cliente.controle;
//cria diretorios se necessario QHZ File(DIRETORIO_CERTIFICADOS).mkdirs(); QHZ File(DIRETORIO_CERTIFICADOS_REVOGADOS).mkdirs();
//verifica se jah existe certificado instalado LI(!QHZ File(ARQUIVO_CHAVE_CLIENTE).exists() || !QHZ File(ARQUIVO_CERTIFICADO_CLIENTE).exists()){
//avisa a que deve ser criado um certificado para o cliente
JOptionPane.showMessageDialog(frame, "Nenhum certificado foi criado para este cliente,\n use a opo \"Requisio de Certificado\" para gerar um\n e depois a opo \"Importar Certificado\" para cadastr-lo."); }HOVH{
WU\{ //verifica se o certificado do usuario foi revogado X509Certificate certUsuario = Utils.getInstanceCertificadoX509(ARQUIVO_CERTIFICAD O_CLIENTE); LI(ControleCliente.isCertificadoRevogado(frame, certUsuario)){ JOptionPane.showMessageDialog(frame, "O certificado do usurio foi revogado, favor requisitar um novo certificado."); } }FDWFK(Exception e){ e.printStackTrace(); }
}
frame.show(); }
SXEOLF YRLG actionPerformed(ActionEvent e) {
LI(e.getSource() == WKLV.frame.getJButton()){
//precisa que o root jah esteja cadastrado
LI(!QHZ File(ARQUIVO_CERTIFICADO_ROOT).exists()){ //cancela a importacao 89 JOptionPane.showMessageDialog(frame, "Importe primeiro o certificado de uma Autoridade Certificadora confivel!"); UHWXUQ; }
//Assinar e Criptografar Mensagens QHZ EnviaMsg().show();
LI(!QHZ File(ARQUIVO_CERTIFICADO_ROOT).exists()){ //cancela a importacao JOptionPane.showMessageDialog(frame, "Importe primeiro o certificado de uma Autoridade Certificadora confivel!"); UHWXUQ; }
LI(!QHZ File(ARQUIVO_CERTIFICADO_ROOT).exists()){ //cancela a importacao JOptionPane.showMessageDialog(frame, "Importe primeiro o certificado de uma Autoridade Certificadora confivel!"); UHWXUQ; }
//Receber e Verificar Assinatura na Mensagem QHZ ReceberMsg().show();
//verifica se eh um certificado de AC LI(cert.getIssuerDN().equals(cert.getSubjectDN())){
//arquivo de root AC FileUtils.copiarArquivo(arq, QHZ File(ARQUIVO_CERTIFICADO_ROOT));
JOptionPane.showMessageDialog(frame, "Importao do certificado de AC foi realizada com sucesso!"); UHWXUQ;
}HOVH {
//valida AC LI(!validarRoot(frame, cert)){ UHWXUQ; }
//verifica se existe a chave temporaria LI(arqChaveTemp.exists()){ //chave publica do certificado a importar RSAPublicKey pubKey = (RSAPublicKey) cert.getPublicKey();
//verifica se o certificado corresponde com a chave privada RSAPrivateKey privKey = (RSAPrivateKey) Utils.lerPrivKeyPkcs5(ARQUIVO_CHAVE_TEMP_CLIEN TE, SENHA_CLIENTE.toCharArray()); LI(Utils.isChavePublicaConfere(privKey, pubKey)){
//cria PKCS12 para armazenar a chave privada Utils.gravarPrivKeyPkcs12(ARQUIVO_CHAVE_CLIENT E, SENHA_CLIENTE.toCharArray(), privKey, ALIAS_CLIENTE, cert);
//apaga a chave privada temporaria arqChaveTemp.delete();
//ok JOptionPane.showMessageDialog(frame, "Importao do certificado pessoal foi realizada com sucesso!"); UHWXUQ; 91 } }
//copia para o diretorio de certificados LQW qtdeArquivos = (QHZ File(ControleCliente.DIRETORIO_CERTIFICADOS).list().length) + 1; String nmArqCertNovo = DIRETORIO_CERTIFICADOS + File.separator + Integer.toString(qtdeArquivos) + ".crt"; FileUtils.copiarArquivo(arq, QHZ File(nmArqCertNovo));
//ok JOptionPane.showMessageDialog(frame, "Importao de certificado realizada com sucesso!"); }
/** * Valida se um certificado pertence a AC cadastrada. * */ SXEOLF VWDWLF ERROHDQ validarRoot(Component frame, X509Certificate cert){ //valida AC WU\{
LI(!QHZ File(ARQUIVO_CERTIFICADO_ROOT).exists()){ //cancela a importacao JOptionPane.showMessageDialog(frame, "Importe primeiro o certificado de uma Autoridade Certificadora confivel!");
//testa a extensao do arquivo LI(nmArq.indexOf(".crt") > 0){
WU\{ //recupera o proprietario do certificado cert = Utils.getInstanceCertificadoX509(arqs[i].getAbsolut ePath());
//compara apenas serial number porque o issuer j foi validado //anteriormente LI(cert.getSerialNumber().equals(certTeste.getSerial Number())){ UHWXUQ WUXH; }
/** * Gera requisio de certificado */ SULYDWH YRLG gerarCSR(){
String nome = getJTextField().getText(); String cpf = getJTextField1().getText();
//valida os campos digitados pelo usuario LI(nome.trim().length() == 0 || cpf.trim().length() == 0){ JOptionPane.showMessageDialog(WKLV, "Os campos no devem estar em branco."); UHWXUQ; }
WU\{
//nome que serah exibido no certificado String proprietario = ControleCliente.SUBJECT_CLIENTE + nome + ":" + cpf;
//pergunta por um arquivo ao usuario File arq = GuiUtils.promptFileForSave(WKLV, "Salvar Requisio de Certificado", QXOO); LI(arq == QXOO){ //usuario abortou UHWXUQ; }
//gera par de chaves KeyPair kp = Utils.gerarKeyPairRSA();
//grava apenas a chave privada, armazenamento temporario ateh a chegada do certificado Utils.gravarPrivKeyPkcs5(ControleCliente.ARQUIVO_CHAVE_TE MP_CLIENTE, ControleCliente.SENHA_CLIENTE.toCharArray(), kp.getPrivate());
//ok JOptionPane.showMessageDialog(WKLV, "Requisio de certificado gerado com sucesso!"); 99
}FDWFK(Exception e){ e.printStackTrace(); JOptionPane.showMessageDialog(WKLV, "Erro ao gerar a requisio de certificado: "+e.getMessage()); } }
/** * Autor: Bruno * * Classe para importao de certificados. * Verifica se o certificado importado faz parte de um * certificado de CA, um certificado pessoal ou de um * outro usurio. * */
//recupera o nome do arquivo com a extensao LQW i = selecao.indexOf(".crt"); String nmArq = selecao.substring(0, i + 4); String nmArqCer = ControleCliente.DIRETORIO_CERTIFICADOS + File.separator + nmArq;
/** * Autor: Bruno * * Classe para gerao de mensagens assinadas e envelopadas * no padro PKCS#7. As funcionalidades no se encontram * totalmente nesta classe. * Ela apenas utiliza os mtodos de outras classes como a MsgUtils * e a Utils. * */ SDFNDJH cliente.ui;
//recupera o nome do arquivo com a extensao LQW i = selecao.indexOf(".crt"); String nmArq = selecao.substring(0, i + 4); String nmArqCer = ControleCliente.DIRETORIO_CERTIFICADOS + File.separator + nmArq;
//arquivo de saida File nmArqMsgSaida = GuiUtils.promptFileForSave(WKLV, "Arquivo de sada", QXOO);
//grava a mensagem assinada e envelopada em sequencia FileOutputStream fos = QHZ FileOutputStream(nmArqMsgSaida); DataOutputStream dos = QHZ DataOutputStream(fos);
//ok JOptionPane.showMessageDialog(WKLV, "Mensagem gerada com sucesso!");
}FDWFK(Exception e){ e.printStackTrace(); JOptionPane.showMessageDialog(WKLV, "Erro ao gerar a mensagem: "+e.getMessage()); } }HOVH{ JOptionPane.showMessageDialog(WKLV, "Digite algo na rea de texto."); } }
WU\{ //descobre o certificado de origem da mensagem para validar a assinatura X509Certificate certAssinante = MsgUtils.getCertificateFromPkcs7SignedData(msgAssinada); certRemetente = certAssinante.getSubjectDN().toString(); Remetente = Utils.extrairCN(certRemetente); //Apresenta msg recebida e o remetente da mesma. getJTextArea().setText("Remetente: " + Remetente + "\nMensagem: " + QHZ String(dados, "ISO-8859-1") );
//valida AC LI(!ControleCliente.validarRoot(WKLV, certAssinante)){ //se falhou cancela UHWXUQ; }
//verifica se o certificado foi revogado LI(ControleCliente.isCertificadoRevogado(WKLV, certAssinante)){ //se falhou cancela JOptionPane.showMessageDialog(WKLV, "O certificado do assinante foi revogado, operao cancelada!"); getJTextArea().setText(""); UHWXUQ; }
// Base64Decoder.java // $Id: Base64Decoder.java,v 1.5 2000/06/08 16:36:05 ylafon Exp $ // (c) COPYRIGHT MIT and INRIA, 1996. // Please first read the full copyright statement in file COPYRIGHT.html
LPSRUW java.io.*;
/** * Decode a BASE64 encoded input stream to some output stream. * This class implements BASE64 decoding, as specified in the * <a href="http://ds.internic.net/rfc/rfc1521.txt">MIME specification</a>. * #VHH org.w3c.tools.codec.Base64Encoder * * Nota: Classe oferecida pela organizacao * Bouncy Castle para decodificacao de dados * em Base64. * * */
InputStream in = QXOO ; OutputStream out = QXOO ; ERROHDQ stringp = IDOVH ;
/** * Create a decoder to decode a stream. * #SDUDP in The input stream (to be decoded). * #SDUDP out The output stream, to write decoded data to. */
SXEOLF Base64Decoder (InputStream in, OutputStream out) { WKLV.in = in ; WKLV.out = out ; WKLV.stringp = IDOVH ; } /** * Create a decoder to decode a String. * #SDUDP input The string to be decoded. */
// Base64Encoder.java // $Id: Base64Encoder.java,v 1.7 2000/06/08 16:35:01 ylafon Exp $ // (c) COPYRIGHT MIT and INRIA, 1996. // Please first read the full copyright statement in file COPYRIGHT.html
LPSRUW java.io.*;
/** * BASE64 encoder implementation. * This object takes as parameter an input stream and an output stream. It * encodes the input stream, using the BASE64 encoding rules, as defined * in <a href="http://ds.internic.net/rfc/rfc1521.txt">MIME specification</a> * and emit the resulting data to the output stream. * #VHH org.w3c.tools.codec.Base64Decoder * * * Nota: Classe oferecida pela organizacao * Bouncy Castle para codificacao de dados * em Base64. * */
SXEOLF FODVV Base64Encoder { SULYDWH VWDWLF ILQDO LQW BUFFER_SIZE = 1024 ; SULYDWH VWDWLF E\WH encoding[] = { (E\WH) A, (E\WH) B, (E\WH) C, (E\WH) D, (E\WH) E, (E\WH) F, (E\WH) G, (E\WH) H, // 0-7 (E\WH) I, (E\WH) J, (E\WH) K, (E\WH) L, (E\WH) M, (E\WH) N, (E\WH) O, (E\WH) P, // 8-15 (E\WH) Q, (E\WH) R, (E\WH) S, (E\WH) T, (E\WH) U, (E\WH) V, (E\WH) W, (E\WH) X, // 16-23 (E\WH) Y, (E\WH) Z, (E\WH) a, (E\WH) b, (E\WH) c, (E\WH) d, (E\WH) e, (E\WH) f, // 24-31 (E\WH) g, (E\WH) h, (E\WH) i, (E\WH) j, (E\WH) k, (E\WH) l, (E\WH) m, (E\WH) n, // 32-39 (E\WH) o, (E\WH) p, (E\WH) q, (E\WH) r, (E\WH) s, (E\WH) t, (E\WH) u, (E\WH) v, // 40-47 (E\WH) w, (E\WH) x, (E\WH) y, (E\WH) z, (E\WH) 0, (E\WH) 1, (E\WH) 2, (E\WH) 3, // 48-55 (E\WH) 4, (E\WH) 5, (E\WH) 6, (E\WH) 7, (E\WH) 8, (E\WH) 9, (E\WH) +, (E\WH) /, // 56-63 (E\WH) = // 64 };
InputStream in = QXOO ; OutputStream out = QXOO ; ERROHDQ stringp = IDOVH ;
/** * Create a new Base64 encoder, encoding input to output. * #SDUDP in The input stream to be encoded. * #SDUDP out The output stream, to write encoded data to. */
122 SXEOLF Base64Encoder (InputStream in, OutputStream out) { WKLV.in = in ; WKLV.out = out ; WKLV.stringp = IDOVH ; } /** * Create a new Base64 encoder, to encode the given string. * #SDUDP input The String to be encoded. */
SXEOLF VWDWLF YRLG main (String args[]) { LI ( args.length != 1 ) { System.out.println ("Base64Encoder <string>") ; System.exit (0) ; } Base64Encoder b = QHZ Base64Encoder (args[0]) ; System.out.println ("["+b.processString()+"]") ; // joe:eoj -> am9lOmVvag== // 12345678:87654321 -> MTIzNDU2Nzg6ODc2NTQzMjE= } /** * Process the data: encode the input stream to the output stream. * This method runs through the input stream, encoding it to the output * stream. * #H[FHSWLRQ IOException If we werent able to access the input stream or * the output stream. */
123 SXEOLF YRLG process () WKURZV IOException { E\WH buffer[] = QHZ E\WH[BUFFER_SIZE] ; LQW got = -1 ; LQW off = 0 ; LQW count = 0 ; ZKLOH ((got = in.read(buffer, off, BUFFER_SIZE-off)) > 0) { LI ( got >= 3 ) { got += off; off = 0; ZKLOH (off + 3 <= got) { LQW c1 = get1(buffer,off) ; LQW c2 = get2(buffer,off) ; LQW c3 = get3(buffer,off) ; LQW c4 = get4(buffer,off) ; VZLWFK (count) { FDVH 73: out.write(encoding[c1]); out.write(encoding[c2]); out.write(encoding[c3]); out.write (\n) ; out.write(encoding[c4]) ; count = 1 ; EUHDN ; FDVH 74: out.write(encoding[c1]); out.write(encoding[c2]); out.write (\n) ; out.write(encoding[c3]); out.write(encoding[c4]) ; count = 2 ; EUHDN ; FDVH 75: out.write(encoding[c1]); out.write (\n) ; out.write(encoding[c2]); out.write(encoding[c3]); out.write(encoding[c4]) ; count = 3 ; EUHDN ; FDVH 76: out.write(\n) ; out.write(encoding[c1]); out.write(encoding[c2]); out.write(encoding[c3]); out.write(encoding[c4]) ; count = 4 ; EUHDN ; GHIDXOW: out.write(encoding[c1]); out.write(encoding[c2]); out.write(encoding[c3]); out.write(encoding[c4]) ; count += 4 ; EUHDN ; } off += 3 ; } // Copy remaining bytes to beginning of buffer: IRU ( LQW i = 0 ; i < 3 ;i++) 124 buffer[i] = (i < got-off) ? buffer[off+i] : ((E\WH) 0) ; off = got-off ; } HOVH { // Total read amount is less then 3 bytes: off += got; } } // Manage the last bytes, from 0 to off: VZLWFK (off) { FDVH 1: out.write(encoding[get1(buffer, 0)]) ; out.write(encoding[get2(buffer, 0)]) ; out.write(=) ; out.write(=) ; EUHDN ; FDVH 2: out.write(encoding[get1(buffer, 0)]); out.write(encoding[get2(buffer, 0)]); out.write(encoding[get3(buffer, 0)]); out.write(=); } UHWXUQ ; } /** * Encode the content of this encoder, as a string. * This methods encode the String content, that was provided at creation * time, following the BASE64 rules, as specified in the rfc1521. * #UHWXUQ A String, reprenting the encoded content of the input String. */
// Base64FormatException.java // $Id: Base64FormatException.java,v 1.3 1998/01/22 12:42:16 bmahe Exp $ // (c) COPYRIGHT MIT and INRIA, 1996. // Please first read the full copyright statement in file COPYRIGHT.html
// Base64FormatException.java // $Id: Base64FormatException.java,v 1.3 1998/01/22 12:42:16 bmahe Exp $ // (c) COPYRIGHT MIT and INRIA, 1996. // Please first read the full copyright statement in file COPYRIGHT.html
/** * Exception for invalid BASE64 streams. * * Nota: Classe oferecida pela organizacao * Bouncy Castle para tratar exceptions. * * */
/** * A provider representation for a RSA private key, with CRT factors included. * * Nota: Classe oferecida pela RSA para gerenciamento * de chaves privadas utilizadas na criptografia. * Aceita passagem de parametros. * * */ SDFNDJH pki;
UHWXUQ bOut.toByteArray(); } /** * return the encoding format we produce in getEncoded(). * * #UHWXUQ the encoding format we produce in getEncoded(). */ SXEOLF String getFormat() { UHWXUQ "PKCS#8"; } /** * return the prime exponent for P. * * #UHWXUQ the prime exponent for P. */ SXEOLF BigInteger getPrimeExponentP() { UHWXUQ primeExponentP; } /** * return the prime exponent for Q. * * #UHWXUQ the prime exponent for Q. */ SXEOLF BigInteger getPrimeExponentQ() { UHWXUQ primeExponentQ; } /** * return the prime P. * * #UHWXUQ the prime P. */ SXEOLF BigInteger getPrimeP() 129 { UHWXUQ primeP; } /** * return the prime Q. * * #UHWXUQ the prime Q. */ SXEOLF BigInteger getPrimeQ() { UHWXUQ primeQ; } /** * return the public exponent. * * #UHWXUQ the public exponent. */ SXEOLF BigInteger getPublicExponent() { UHWXUQ publicExponent; } SXEOLF String toString() { StringBuffer buf = QHZ StringBuffer(); String nl = System.getProperty("line.separator");
** * Chave privada sem CRT parameters. * * Nota: Classe oferecida pela RSA para gerenciamento * de chaves privadas utilizadas na criptografia. * Nao precisa de parametros para gerenciamento. * */ SDFNDJH pki;
UHWXUQ getModulus().equals(key.getModulus()) 133 && getPublicExponent().equals(key.getPublicExponent()); } /** * Returns the standard algorithm name for this key. For * example, "DSA" would indicate that this key is a DSA key. * See Appendix A in the <a href= * "../../../guide/security/CryptoSpec.html#AppA"> * Java Cryptography Architecture API Specification & Reference </a> * for information about standard algorithm names. * * #UHWXUQ the name of the algorithm associated with this key. */ SXEOLF java.lang.String getAlgorithm() { UHWXUQ "RSA"; } /** * Returns the key in its primary encoding format, or null * if this key does not support encoding. * * #UHWXUQ the encoded key, or null if the key does not support * encoding. */ SXEOLF E\WH[] getEncoded() { ByteArrayOutputStream bOut = QHZ ByteArrayOutputStream(); DEROutputStream dOut = QHZ DEROutputStream(bOut); SubjectPublicKeyInfo info = QHZ SubjectPublicKeyInfo(QHZ AlgorithmIdentifier(PKCSObjectIdentifiers.rsaEncryption, QXOO), QHZ RSAPublicKeyStructure(getModulus(), getPublicExponent()).getDERObject());
UHWXUQ bOut.toByteArray(); } /** * Returns the name of the primary encoding format of this key, * or null if this key does not support encoding. * The primary encoding format is * named in terms of the appropriate ASN.1 data format, if an * ASN.1 specification for this key exists. * For example, the name of the ASN.1 data format for public * keys is <I>SubjectPublicKeyInfo</I>, as * defined by the X.509 standard; in this case, the returned format is * <code>"X.509"</code>. Similarly, * the name of the ASN.1 data format for private keys is * <I>PrivateKeyInfo</I>, * as defined by the PKCS #8 standard; in this case, the returned format is * <code>"PKCS#8"</code>. * 134 * #UHWXUQ the primary encoding format of the key. */ SXEOLF java.lang.String getFormat() {
UHWXUQ "X.509"; } /** * Returns the modulus. * * #UHWXUQ the modulus */ SXEOLF java.math.BigInteger getModulus() { UHWXUQ modulus; } /** * Returns the public exponent. * * #UHWXUQ the public exponent */ SXEOLF java.math.BigInteger getPublicExponent() { UHWXUQ publicExponent;
SignerInformationStore signers = s.getSignerInfos(); Collection c = signers.getSigners(); Iterator it = c.iterator();
//verifica soh o primeiro LI (it.hasNext()) { SignerInformation signer = (SignerInformation)it.next(); Collection certCollection = certs.getCertificates(signer.getSID());
Iterator certIt = certCollection.iterator();
//verifica se deve utilizar o certificado passado por parametro LI(cert == QXOO){ cert = (X509Certificate)certIt.next(); }
UHWXUQ signer.verify(cert, "BC"); }
UHWXUQ IDOVH; }
/** * Recupera o certificado de uma mensagem asssinada. * #SDUDP msg * #SDUDP dados * #SDUDP origKP * #SDUDP origCert * #UHWXUQ * #WKURZV Exception */ 138 SXEOLF VWDWLF X509Certificate getCertificateFromPkcs7SignedData(E\WH msg[]) WKURZV Exception {
ByteArrayInputStream bIn = QHZ ByteArrayInputStream(msg); ASN1InputStream aIn = QHZ ASN1InputStream(bIn);
CMSSignedData s = QHZ CMSSignedData(ContentInfo.getInstance(aIn.readObject()));
/** * Gera os parametros necessarios a gravacao de um segredo PKCS12. * * #UHWXUQ org.bouncycastle.asn1.pkcs.PBES2Parameters * #SDUDP salt random password * #SDUDP iterationCount iterationCount - 2048 - minimo recomendado eh 1000. * #SDUDP iv Inicialization Vector p/ 3DES * #H[FHSWLRQ Exception ... */ SULYDWH VWDWLF PBES2Parameters generatePBES2Parameters(E\WH[] salt, LQW iterationCount, E\WH[] iv)WKURZV Exception {
//validacao WU\{ LI(salt.length != 8 || iv.length != 8){ WKURZ QHZ Exception(); } }FDWFK(Exception e){ WKURZ QHZ IllegalArgumentException("Valor do salt ou IV invlido. Um OctetString deve ter 8 bytes."); }
//certificado em si X509CertificateObject cert=QXOO; cert = (X509CertificateObject) CERT_GENERATOR.generateX509Certificate(parChavesRSA.getPrivate(), "BC");
/** * Pergunta ao usuario um nome de arquivo para salvar. * */ SXEOLF VWDWLF File promptFileForSave(Component parent, String titulo, String dirAtual) {