Your SlideShare is downloading. ×
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Monografia Marcos Bezerra   2008
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Monografia Marcos Bezerra 2008

3,572

Published on

PDF contendo o texto da Monografia com o tema: "Certificação Digital - Utilização em aplicações Web", de autoria de Marcos Bezerra.

PDF contendo o texto da Monografia com o tema: "Certificação Digital - Utilização em aplicações Web", de autoria de Marcos Bezerra.

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,572
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
369
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MARCOS ANTONIO DE SOUZA BEZERRA CERTIFICAÇÃO DIGITAL Utilização em Aplicações Web JOÃO PESSOA 2008
  • 2. MARCOS ANTONIO DE SOUZA BEZERRA CERTIFICAÇÃO DIGITAL Utilização em Aplicações Web Trabalho de Conclusão de Curso, apresentado ao Curso de Graduação em Sistemas de Informação do IESP – Instituto de Educação Superior da Paraíba, em cumprimento às exigências para obtenção do grau de Bacharel em Sistemas de Informação. Orientadora: Profª. ISLEDNA RODRIGUES DE ALMEIDA JOÃO PESSOA 2008
  • 3. Dados de acordo com: AACR2, CDU e Cutter Biblioteca Central – IESP Faculdades – PB B574c Bezerra, Marcos Antônio de Sousa Certificação digital: utilização em aplicações Web/ Marcos Antônio de Sousa Bezerra. – João Pessoa, PB: [s.n], 2008. 65 f. Monografia (Graduação) – Instituto de Educação Superior da Paraíba (IESP) - Curso de Sistemas de Informação, 2008. 1. Internet - segurança 2. Aplicações Web 3. Certificação digital I. Título CDU 004.7
  • 4. MARCOS ANTONIO DE SOUZA BEZERRA CERTIFICAÇÃO DIGITAL Utilização em Aplicações Web Trabalho de Conclusão de Curso, apresentado ao Curso de Graduação em Sistemas de Informação do IESP – Instituto de Educação Superior da Paraíba, em cumprimento às exigências para obtenção do grau de Bacharel em Sistemas de Informação. Aprovada em 15/12/2008. BANCA EXAMINADORA ____________________________________ Profª. Isledna Rodrigues de Almeida, M.Sc. Orientadora Instituto de Educação Superior da Paraíba ____________________________________ Prof. Jânio Carlos Mesquita Vieira Instituto de Educação Superior da Paraíba ____________________________________ Prof. David dos Santos Ferreira Instituto de Educação Superior da Paraíba
  • 5. AGRADECIMENTOS Agradeço a todos que de forma direta ou indireta contribuíram para que eu alcançasse este objetivo. Agradeço a Franklin e Fernando Lordão, da Virtus Sistemas, por terem autorizado e compartilhado informações para a composição do estudo de caso neste trabalho. Agradeço aos professores Isledna e Jânio, pela paciência em orientar este trabalho e pela precisão de suas orientações, sem as quais a pesquisa não seria levada a cabo. Agradeço de coração aos meus pais, Aloísio e Helena, que me proporcionaram uma excelente educação e ajudaram a formar meu caráter, ambos essenciais para trilhar o caminho do sucesso. Agradeço de forma especial à minha esposa Joselina pelo apoio incondicional durante a duração do curso, tendo que suportar minha constante falta de tempo para a família.
  • 6. quot;Procure ser uma pessoa de valor, em vez de procurar ser uma pessoa de sucesso. O sucesso é conseqüência.quot; Albert Einstein
  • 7. RESUMO O presente trabalho faz uma análise da problemática da segurança da informação, no âmbito da Internet, em face das excelentes perspectivas de utilização das aplicações Web. Indo mais além, procura ainda entender como a Certificação Digital está estruturada para prover a necessária segurança à informação, viabilizando assim a utilização de tais aplicações. Em conclusão, realiza um estudo de caso de uma aplicação Web real, o SDT On Line, e analisa os resultados obtidos por ela com a utilização de um certificado digital em sua camada de segurança. Palavras Chaves: Aplicações Web, Segurança, Certificação Digital.
  • 8. ABSTRACT The present paper makes an analysis over the problem of the information safety, on Internet context, in face of the excellent perspectives to use Web applications. Going ahead, tries to understand as the Digital Certification is structured to provide the necessary safety to information, making possible the use of those applications. In conclusion, accomplishes a case study from a real Web application, known as SDT On Line, and analyzes the results obtained with the use of a digital certificate in your safety layer. Keywords: Web Applications, Safety, Digital Certification.
  • 9. LISTA DE SIGLAS AC – Autoridade Certificadora ANOREG – Associação de Notários e Registradores AR – Autoridade de Registro CG – Comitê Gestor CHM – Microsoft Compiled HTML Help COTEC – Comitê Técnico DER – Diagrama Entidade Relacionamento FEBRABAN – Federação Brasileira de Bancos GPL – General Purpose Licence HTML – HyperText Markup Language HTTPS – HyperText Transfer Protocol over Secure Socket Layer ICP – Infra-estrutura de Chaves Públicas IDE – Integrated Development Environment IP – Internet Protocol IPSec – IP Security Protocol LCR – Lista de Certificados Revogados LDAP – Lightweight Directory Access Protocol MD5 – Message-Digest Algorithm version 5 MVC – Model-View-Control PDF – Portable Document Format PDT – PHP Development Tools PGP – Pretty Good Privacy PHP – PHP: Hypertext Preprocessor (acrônimo recursivo) PSS – Prestador de Serviços de Suporte S/MIME – Secure Multipurpose Internet Mail Extensions SET – Security Electronic Transaction SDT – Serviço de Distribuição de Títulos SGBD – Sistema Gerenciador de Banco de Dados SHA-1 – Secure Hash Algorithm version 1 SSL – Security Socket Layer TCP – Transfer Control Protocol TLS – Transport Layer Security USB – Universal Serial Bus
  • 10. LISTA DE FIGURAS Figura 1 – Ataque de interrupção ............................................................................. 21 Figura 2 – Ataque de interceptação .......................................................................... 22 Figura 3 – Ataque de modificação ............................................................................. 22 Figura 4 – Ataque de fabricação ............................................................................... 23 Figura 5 – Uso de chave simétrica na criptografia .................................................... 25 Figura 6 – Uso de chaves assimétricas para obter integridade e confidencialidade . 26 Figura 7 – Uso de chaves assimétricas para obter autenticidade e integridade ....... 27 Figura 8 – Resumo obtido com uma função hash ..................................................... 27 Figura 9 – Processo de assinatura digital de uma mensagem .................................. 28 Figura 10 – Processo de verificação da assinatura digital ........................................ 29 Figura 11 – Verificação de certificado revogado ....................................................... 31 Figura 12 – Estrutura hierárquica da ICP-Brasil ........................................................ 36 Figura 13 – Ciclo de vida de um título para protesto ................................................. 40 Figura 14 – Tela de autenticação de usuário do SDT On Line .................................. 45 Figura 15 – Modelo arquitetural MVC ........................................................................ 48 Figura 16 – Diagrama de Caso de Uso para a funcionalidade “Cadastro de Entidades” ............................................................................................................... 48 Figura 17 – Diagrama de Caso de Uso para a funcionalidade “Cadastro de Usuários”. ................................................................................................................ 49 Figura 18 – Diagrama de Caso de Uso para a funcionalidade “Enviar Arquivos”...... 49 Figura 19 – Diagrama de Caso de Uso para a funcionalidade “Receber Arquivos” .. 50 Figura 20 – Diagrama de Caso de Uso para a funcionalidade “Solicitar Retirada de Títulos” .................................................................................................................... 50 Figura 21 – DER para o SDT On Line ....................................................................... 51 Figura 22 – Diagrama de Classes do SDT On Line – Camada de Modelo ............... 52 Figura 23 – Mídias para certificados A3 .................................................................... 54 Figura 24 – Verificação de Autenticidade – parte 1 .................................................. 56 Figura 25 – Verificação de Autenticidade – parte 2 .................................................. 56 Figura 26 – Verificação de Autenticidade – parte 3 .................................................. 57 Figura 27 – Indicação de uso do protocolo HTTPS na conexão com o sistema ....... 58
  • 11. LISTA DE QUADROS Quadro 1 – Lista de Certificados Revogados (LCR) ................................................. 30 Quadro 2 – Alguns mecanismos de segurança no mundo real e seus correspondentes na ICP.......................................................................................... 32 Quadro 3 – Componentes da ICP-Brasil ................................................................... 36 Quadro 4 – Comparativo de preços entre certificados equivalentes emitidos por AC pertencente e não pertencente à ICP-Brasil ........................................................... 53
  • 12. SUMÁRIO 1 INTRODUÇÃO ...................................................................................................... 14 1.1 OBJETIVO GERAL ........................................................................................ 15 1.2 OBJETIVOS ESPECÍFICOS .......................................................................... 15 1.3 JUSTIFICATIVA ............................................................................................. 15 1.4 METODOLOGIA DA PESQUISA ................................................................... 16 1.5 ORGANIZAÇÃO DA MONOGRAFIA ............................................................. 16 2 SEGURANÇA DA INFORMAÇÃO ........................................................................ 18 2.1 CONCEITUAÇÃO DE SEGURANÇA DA INFORMAÇÃO............................... 18 2.2 AMEAÇAS E VULNERABILIDADES ............................................................... 19 2.2.1 Ameaças ................................................................................................ 19 2.2.2 Vulnerabilidades .................................................................................... 20 2.3 ATAQUES ....................................................................................................... 21 2.3.1 Interrupção ............................................................................................. 21 2.3.2 Interceptação ......................................................................................... 21 2.3.3 Modificação ............................................................................................ 22 2.3.4 Fabricação ............................................................................................. 23 2.4 CERTIFICAÇÃO DIGITAL............................................................................... 23 2.4.1 Criptografia ............................................................................................ 24 2.4.2 Chaves criptográficas ............................................................................ 24 2.4.2.1 Chave simétrica........................................................................ 25 2.4.2.2 Chave assimétrica .................................................................... 25 2.4.3 Algoritmo de resumo (função hash) ....................................................... 27 2.4.4 Assinatura Digital ................................................................................... 28 2.4.5 Padrão X.509 ......................................................................................... 29 2.4.6 Lista de Certificados Revogados (LCR) ................................................. 30 2.4.7 Infra-estrutura de Chaves Públicas (ICP) .............................................. 31 2.4.8 Padrões relevantes para uma ICP ......................................................... 32 2.4.8.1 LDAP ........................................................................................ 32 2.4.8.2 S/MIME .................................................................................... 33
  • 13. 2.4.8.3 IPSec ........................................................................................ 34 2.4.8.4 SSL .......................................................................................... 34 2.4.8.5 TLS ........................................................................................... 35 2.4.9 ICP-Brasil ............................................................................................... 35 2.4.9.1 Estrutura ................................................................................... 36 2.4.9.2 Componentes da ICP-Brasil ..................................................... 37 2.5 CONSIDERAÇÕES FINAIS ............................................................................ 38 3 DESENVOLVIMENTO DA APLICAÇÃO – SDT ON LINE ...................................... 39 3.1 DEFINIÇÃO ..................................................................................................... 39 3.2 FUNCIONALIDADE ........................................................................................ 40 3.3 METODOLOGIA DE DESENVOLVIMENTO ................................................... 41 3.3.1 Sistema Gerenciador de Banco de Dados (SGBD) MySQL .................. 41 3.3.2 Linguagem de programação PHP .......................................................... 42 3.3.3 Servidor de criptografia OpenSSL ......................................................... 42 3.3.4 Servidor Web Apache ............................................................................ 42 3.3.5 Modelador gráfico JUDE/Community ..................................................... 43 3.3.6 Documentador de código PHPDocumentor ........................................... 43 3.3.7 Ambiente de Desenvolvimento Integrado (IDE) Eclipse PDT ................ 44 3.4 A APLICAÇÃO ................................................................................................ 44 3.4.1 Requisitos .............................................................................................. 45 3.4.1.1 Requisitos não-funcionais ........................................................ 46 3.4.1.2 Requisitos de domínio .............................................................. 46 3.4.1.3 Requisitos funcionais ............................................................... 46 3.4.2 Arquitetura ............................................................................................. 47 3.4.3 Diagramas de Caso de Uso ................................................................... 48 3.4.4 Diagrama Entidade Relacionamento (DER) .......................................... 51 3.4.5 Diagrama de Classes – Camada de Modelo ......................................... 52 3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT ON LINE .................................. 53 3.5.1 Autoridade Certificadora escolhida ........................................................ 53 3.5.2 Tipo de certificado adotado .................................................................... 54 3.5.3 Verificação de autenticidade do Website ............................................... 55 3.5.4 Transmissão segura de dados com SSL ............................................... 58
  • 14. 3.6 CONSIDERAÇÕES FINAIS ............................................................................ 58 4 ANALISE DE RESULTADOS ................................................................................. 59 4.1 RESULTADOS OPERACIONAIS.................................................................... 59 4.2 RESULTADOS TÉCNICOS ............................................................................ 60 4.3 PERSPECTIVAS FUTURAS ........................................................................... 62 5 CONCLUSÕES ...................................................................................................... 64 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 65
  • 15. 14 1 INTRODUÇÃO Uma aplicação Web consiste em um serviço baseado em software e banco de dados, operando num servidor Web, e que provê aos seus clientes uma variedade de operações envolvendo a troca de mensagens e documentos pelo meio eletrônico. Tais aplicações podem ser vulneráveis a ataques que visam comprometer a segurança das informações transacionadas. Os ataques que visam aplicações Web podem ser de quatro tipos: interrupção, interceptação, modificação e fabricação (SILVA, 2004). Estes podem ocasionar a perda da disponibilidade, confidencialidade e integridade das informações. Ao passo que a disponibilidade da informação é assegurada por outros meios, sua confidencialidade e integridade podem advir da adoção de um Certificado Digital. O Certificado Digital é um documento eletrônico, assinado digitalmente por uma terceira parte confiável, que associa uma entidade (pessoa, processo, servidor) a uma chave pública (ITI, 2005). Segundo Silva et al (2008, p. 25), um Certificado Digital é a versão digital de um documento de identidade e pode ser utilizado, dentre várias situações, para dar autenticidade a programas na Internet. Uma aplicação Web sob a proteção de um Certificado Digital poderá assegurar ao usuário do serviço a sua autenticidade através de uma simples verificação dos dados relacionados à entidade, acessíveis por qualquer navegador de Internet. Ademais, o certificado proverá à aplicação um canal criptografado para a troca de mensagens e documentos entre o usuário e o provedor do serviço, assegurando assim a integridade da informação.
  • 16. 15 1.1 OBJETIVO GERAL Descrever o funcionamento lógico dos processos envolvidos na Certificação Digital e explicar como estes dão segurança às aplicações Web que deles se utilizam. 1.2 OBJETIVOS ESPECÍFICOS Relatar os tipos de processos utilizados na Certificação Digital e apontar suas • características mais relevantes. Demonstrar como aplicações Web podem utilizar a Certificação Digital para • garantir os princípios da autenticidade, confidencialidade e integridade aos seus usuários. 1.3 JUSTIFICATIVA Com o desenvolvimento da arquitetura cliente-servidor, cada vez mais computadores em rede vêm sendo largamente utilizados como meios para o processamento de dados e para a troca de mensagens e documentos entre usuários finais e provedores de serviços. Nesse sentido, as aplicações Web têm surgido como um meio eficaz de prover transações eletrônicas com agilidade e grande comodidade. Porém, devido à crescente ameaça de ações criminosas que utilizam o meio eletrônico para serem aplicadas, estas transações necessitam da adoção de mecanismos de segurança capazes de garantir sua autenticidade, confiabilidade e integridade. A Certificação Digital é uma das tecnologias que se propõem a prover estes mecanismos.
  • 17. 16 Dentre os inúmeros benefícios de se adotar a Certificação Digital em aplicações Web, destaca-se a viabilização do uso da Internet como meio seguro de comunicação para que diversos serviços essenciais sejam disponibilizados, resultando em maior agilidade, facilidade de acesso e grande redução de custos. Com a Certificação Digital o relacionamento entre as partes fica mais seguro. Os usuários podem assinar e trocar seus documentos eletrônicos com a garantia de que não haverá violação, adulteração e repúdio. Assim, o documento eletrônico certificado poderá ter o reconhecimento e a validade de um documento real, passível de todos os direitos e obrigações jurídicas. 1.4 METODOLOGIA DA PESQUISA Através de uma pesquisa bibliográfica, pôde-se explicar os conceitos essenciais na segurança da informação e os processos envolvidos na Certificação Digital e, por meio da análise de uma aplicação Web, pôde-se demonstrar uma de suas aplicações práticas. A pesquisa foi feita em livros, publicados tanto no formato impresso quanto no formato eletrônico (e-book), e através da interação com a aplicação Web SDT On-line, disponível em <http://www.sdtpe.com.br>. A técnica de coleta de dados foi a observação indireta, utilizando-se a leitura compreensiva das publicações pesquisadas, e a observação direta, por meio do estudo de caso da aplicação Web analisada. 1.5 ORGANIZAÇÃO DA MONOGRAFIA Esta monografia é composta por cinco capítulos e está dividida da seguinte forma: O Capítulo 1 fornece uma visão geral do trabalho de pesquisa. O Capítulo 2 trata do referencial teórico, em que são discutidos os conceitos mais relevantes referentes à problemática da segurança da informação na Internet e à tecnologia
  • 18. 17 da Certificação Digital, que se estrutura como mecanismo adequado para o provimento de segurança à informação. O Capítulo 3 apresenta um estudo de caso sobre a aplicação Web SDT On Line, enfocando sua utilização de certificação digital para prover uma camada de segurança às informações transacionadas pelo sistema. O Capítulo 4 discute a análise de resultados do ponto-de-vista da aplicação, destacando os resultados funcionais alcançados conforme idealizado em projeto. O Capítulo 5 discute as conclusões do autor quanto aos objetivos da pesquisa e traça uma perspectiva futura para o caso estudado quanto a novas utilizações da certificação digital para a aplicação SDT On Line.
  • 19. 18 2 SEGURANÇA DA INFORMAÇÃO A falta de segurança da informação, em particular na Internet, tem levantado suspeitas quanto aos benefícios de se abraçar o meio digital como substituto viável às relações rotineiras de trabalho e negócios. Lima (2005, p. 4) explica que, ao se intensificar o relacionamento humano por meios digitais, ocorre o favorecimento das atividades lícitas, “trazendo também, por óbvio, novas condutas ilícitas”. Concordemente, Ottoni (2005, p. 3) afirma que, “pelas mesmas razões e na exata proporção” em que a Internet e o mundo digital trazem facilidade, introduzem também o risco e a insegurança. Adicionalmente, declara que “o meio eletrônico é instável e vulnerável, e tem se mostrado um ambiente favorável para fraude e outros crimes afetos”. Essas afirmações têm se mostrado verdadeiras na medida em que surgem inúmeros relatos acerca de crimes cometidos através do meio eletrônico. Entretanto, não seria sensato pensar em abrir mão das facilidades advindas do uso correto da tecnologia da informação e do meio Internet. Afinal, como observa Lima (2006, p. 23), “não é o computador em si perverso, trata-se apenas de uma ferramenta [...] que pode vir a facilitar o cometimento de um crime”. Com isso em mente, adotar medidas que diminuam as ameaças e proporcionem maior segurança constitui um proceder adequado a ser levado em conta. É necessário, portanto, compreender a relação existente entre vulnerabilidades, ataques e prevenção às ameaças que rondam a informação nos dias atuais, estabelecendo assim o ponto de partida para o usufruto das facilidades tecnológicas com ampla segurança. 2.1 CONCEITUAÇÃO DE SEGURANÇA DA INFORMAÇÃO “Desde que se vejam atendidos a três requisitos: confidencialidade, integridade e disponibilidade, poderá se entender estar diante de uma máquina apta a desenvolver uma atividade segura.” (LIMA, 2006). “O objetivo da segurança da informação é proteger a organização detentora da informação dos diversos tipos de ameaças para garantir a continuidade dos seus negócios.” (SILVA et al, 2008).
  • 20. 19 “Confidencialidade, autenticação, integridade e não-repudiação de mensagem vêm sendo considerados componentes fundamentais da comunicação segura há bastante tempo.” (MCCUMBER, 1991, apud KUROSE; ROSS, 2006, p. 514). A segurança da informação compõe-se de cinco premissas fundamentais: confidencialidade, integridade, disponibilidade, autenticidade e não-repúdio. A confidencialidade visa garantir que a informação seja acessível somente por quem tiver autorização para isso. Já a integridade procurar assegurar que a informação não seja adulterada durante uma transmissão entre duas partes. O funcionamento contínuo e com bom desempenho do sistema é a preocupação da disponibilidade. A autenticidade atesta a identidade de quem produz a informação. Por último, o não-repúdio evita que uma das partes na comunicação negue a autoria da informação por ele produzida. 2.2 AMEAÇAS E VULNERABILIDADES Para poder conquistar um ambiente relativamente seguro na Web é mister que se esteja totalmente a par das ameaças à segurança da informação, assim como as vulnerabilidades que representam riscos à mesma. As seções seguintes explanam estes dois conceitos fundamentais. 2.2.1 Ameaças Ameaça à segurança da informação é toda atividade que possa infringir qualquer um dos princípios básicos da segurança da informação: disponibilidade, autenticidade e integridade. “Uma ameaça pode ser iniciada por uma pessoa, programa de computador, desastre natural, acidente ou até mesmo uma idéia que represente algum perigo a uma propriedade.” (SILVA et al, 2008, p. 3). Ainda segundo Silva et al (2008, p. 3), as ameaças podem assumir as seguintes características: Intencionais ou acidentais; • Externas ou internas; • Ativas ou passivas. •
  • 21. 20 Ameaças intencionais ocorrem quando o sistema de informação sofre a ação deliberada de um agente, interno ou externo, com a intenção de que o mesmo falhe em sua segurança. Exemplo: inserção de um erro no código do sistema. Ameaças acidentais ocorrem quando o sistema de informação sofre a ação imprevista de um agente, geralmente externo, causando uma falha desintencional em sua segurança. Exemplo: desastre natural. Quando a ameaça provém de um agente externo ao sistema de informação, sempre de forma intencional, é caracterizada a ameaça externa. Exemplo: invasão de sistemas por crackers1. Quando a ameaça provém de um agente interno ao sistema de informação, de forma intencional ou não, caracteriza-se a ameaça interna. Exemplo: falha desconhecida do sistema. Ameaça ativa é quando a ameaça tem como objetivo impedir a operação do sistema ou modificar sua funcionalidade e/ou informações contidas nele. Exemplo: pichação de sítios na Internet (Websites). Ameaça passiva é quando a ameaça tem como objetivo espionar as atividades de um sistema e até mesmo interceptar informações importantes. Exemplo: captura de senhas bancárias. 2.2.2 Vulnerabilidades Vulnerabilidades são caracterizadas por falhas, ou pontos fracos, na segurança da informação. Através destas, pessoas ou sistemas mal intencionados podem lançar ataques contra sistemas inseguros e assim se apropriar indevidamente, corromper ou tornar indisponível a informação sob sua guarda. 1 Cracker é o termo universalmente utilizado para designar um usuário avançado de computador com atitudes antiéticas, que usa seus conhecimentos com o propósito de invadir sistemas vulneráveis, causando-lhes danos diversos.
  • 22. 21 Segundo Silva (2004, p. 90), as vulnerabilidades podem advir dos seguintes fatores, individualmente ou combinados entre si: Ausência de uma política de segurança; • Sistemas desatualizados em relação a falhas amplamente conhecidas; • Gestão inadequada dos softwares e dispositivos existentes praticados por • pessoas sem o conhecimento necessário para tal. 2.3 ATAQUES Silva (2004, pp. 87-90) descreve quatro abordagens básicas para os ataques atualmente praticados contra a segurança da informação: interrupção, interceptação, modificação e fabricação. 2.3.1 Interrupção Neste ataque não se pretende interceptar nenhuma informação para fins escusos. Antes, seu propósito é meramente prejudicar a comunicação entre as partes interessadas pela informação. A Figura 1 esquematiza este ataque. Figura 1: Ataque de interrupção. Fonte: O autor. 2.3.2 Interceptação A interceptação é considerada um dos ataques mais perigosos na transação entre as partes interessadas na informação. Isso de deve ao fato de: [1] não se saber qual é a
  • 23. 22 intenção do atacante e [2] é um ataque de difícil detecção, uma vez que o atacante não demonstra nenhuma ação durante a escuta. A Figura 2 ilustra o ataque. Figura 2: Ataque de interceptação. Fonte: O autor. 2.3.3 Modificação Esse tipo de ataque visa especificamente um benefício financeiro do atacante ou um prejuízo à idoneidade da informação. Por exemplo, uma informação irreal poderá ser propagada e assim induzir ao erro a todos que a obtiverem posteriormente, ocasionando danos de grandes proporções. A Figura 3 representa este ataque. Figura 3: Ataque de modificação. Fonte: O autor.
  • 24. 23 2.3.4 Fabricação Neste tipo, o atacante se faz passar por um usuário autêntico, forjando uma informação em seu nome, na tentativa de enganar o ponto de destino da informação. Geralmente tem por objetivo o benefício financeiro. A Figura 4 caracteriza este ataque. Figura 4: Ataque de fabricação. Fonte: O autor. 2.4 CERTIFICAÇÃO DIGITAL “Certificação Digital é uma tecnologia de segurança para as relações eletrônicas, que provê um sistema de identificação de pessoas e entidades no meio eletrônico, que combate o anonimato, a despersonalização e a insegurança em relação ao interlocutor.” (OTTONI, 2005, p. 4). “[...] De uma forma genérica, [...] um certificado digital é a versão digital de um documento de identidade.” (SILVA et al, 2008, p. 25). “Trata-se de um mecanismo para identificação de um indivíduo ou empresa na Internet. Ela dá validade jurídica a documentos enviados por e-mail e nas transações feitas pela rede.” (LIMA, 2006, p. 119). A Certificação Digital é uma das ferramentas que se propõem a solucionar os problemas de ataques à segurança da informação, especialmente no que concerne à sua integridade, autenticidade e confidencialidade.
  • 25. 24 Entender os conceitos-chave que envolvem esta tecnologia e de que forma se dá a sua utilização prática é o ponto de partida para se usufruir com segurança das facilidades oferecidas pelo meio digital durante as transações eletrônicas. 2.4.1 Criptografia Para Silva (2004, p. 43), “Criptografia é o estudo de códigos e cifras, cujo nome vem do grego kryptos, que significa oculto, e graphen, que significa escrever. Já a palavra cifra vem do hebraico saphar, que significa dar números. [Negritos e itálicos do autor]”. A criptografia vem sendo usada desde tempos antigos, geralmente em associação com fins militares, tendo sido utilizada de várias formas até chegar aos modernos algoritmos criptográficos utilizados na certificação digital. Para a criptografia moderna, mais importante que o próprio algoritmo utilizado está o emprego da chave de criptografia. Dois tipos de chaves se tornaram amplamente utilizadas: chaves simétricas e assimétricas. 2.4.2 Chaves criptográficas Segundo Silva et al (2008, p. 15), a chave criptográfica é um valor matemático determinante para produzir um texto cifrado a partir de um texto pleno. A posse da chave é obrigatória para decifrar a mensagem e assim recuperar o texto original. O tamanho de uma chave é definido pelo número de bits2 necessários para seu armazenamento. Já o espaço de chaves de uma chave é o conjunto de todos os possíveis valores matemáticos que têm o mesmo tamanho, em bits, desta chave. “Em geral uma chave de tamanho de n bits gera um espaço de chaves de 2n valores distintos.” (SILVA et al, 2008, p. 15). 2 Bit, acrônimo originário do Inglês Binary Digit, representa a menor unidade de medida para designar capacidade de armazenamento de dados na forma digital.
  • 26. 25 2.4.2.1 Chave simétrica Também conhecida como chave secreta, é compartilhada pelos dois pontos na comunicação. O destinatário deverá saber qual chave deverá utilizar para decifrar a informação e retorná-la ao seu estado original. A Figura 5 ilustra o uso de uma chave simétrica. Figura 5: Uso de chave simétrica na criptografia Fonte: ITI, 2005, p. 2, com intervenção do autor. “A grande vantagem neste tipo de chave é sua velocidade em relação à chave assimétrica.” (SILVA, 2004, p. 45). Como ponto fraco, pode-se destacar “a necessidade constante da troca da chave secreta, dificuldade para gerenciar grandes quantidades de chaves em larga escala e dificuldade para iniciar uma comunicação segura entre entidades desconhecidas.” (SILVA, 2004, p. 47). 2.4.2.2 Chave assimétrica Popularmente conhecida como chave pública, na chave assimétrica o segredo é dividido em duas partes relacionadas matematicamente. Daí, a parte pública da chave é distribuída livremente para todas as entidades interessadas em utilizá-la, enquanto a parte
  • 27. 26 privada da chave ficará guardada em segredo por seu titular, normalmente sob a proteção de uma chave simétrica. A criptografia por chaves assimétricas são adequadas para prover às partes a devida medida de segurança para os princípios de confidencialidade, integridade e autenticidade, favorecendo ainda o não-repúdio, conforme é visto na seção 2.4.4. Numa primeira utilização para as chaves assimétricas, supõe-se uma entidade qualquer que deseja enviar uma informação sigilosa para a entidade de nome Beto. Além da garantia de que apenas Beto lerá a mensagem, a entidade remetente deseja ainda que ela não seja adulterada num eventual ataque. Conforme pode ser entendido na Figura 6, o uso das chaves assimétricas de Beto pode garantir a essa mensagem a integridade e confidencialidade da informação. Figura 6: Uso de chaves assimétricas para obter integridade e confidencialidade. Fonte: ITI, 2005, p. 4. Numa outra utilização para as chaves assimétricas, supõe-se uma entidade de nome Alice que deseja disponibilizar publicamente uma informação de sua autoria. Além de garantir que a informação não será alterada, Alice deseja que todos reconheçam a informação como sendo autenticamente sua. Observa-se, na Figura 7, como o uso de chaves assimétricas de Alice provê integridade e autenticidade à informação.
  • 28. 27 Figura 7: Uso de chaves assimétricas para obter autenticidade e integridade. Fonte: ITI, 2005, p. 5. 2.4.3 Algoritmo de resumo (função hash) “Um algoritmo de resumo recebe uma entrada de tamanho variável e produz como resultado uma saída de tamanho fixo.” (SILVA et al, 2008, p.20). Essa saída de tamanho fixo é conhecida como resumo ou hash. Silva et al (2008, p. 20) alista três propriedades para caracterizar o resumo como seguro no sentido de criptografia: 1. Deve ser computacionalmente inviável reconstruir a mensagem de entrada a partir de seu resumo; 2. Não deve existir uma mensagem particular que tenha um resumo específico (previsível); 3. Não deve haver duas mensagens distintas com resumos iguais. Dois tipos de função hash são comumente utilizados: o MD5 (Message-Digest algorithm 5), um algoritmo unidirecional de 128 bits e o SHA-1(Secure Hash Algorithm), também um algoritmo unidirecional, mas com 160 bits. A Figura 8 exemplifica a obtenção de um resumo a partir da entrada de um documento numa função hash SHA-1. Figura 8: Resumo obtido com uma função hash. Fonte: ITI, 2005, p. 6, com intervenção do autor.
  • 29. 28 2.4.4 Assinatura Digital “O mesmo método de autenticação dos algoritmos de criptografia de chave pública operando em conjunto com uma função resumo, também conhecido como função de hash, é chamada de assinatura digital.” (ITI, 2005, p. 6). A Figura 9 descreve o processo de assinatura digital de uma mensagem. Figura 9: Processo de assinatura digital de uma mensagem. Fonte: ITI, 2005, p. 6. Num exemplo de utilização de assinatura digital, supõe-se que a entidade Alice queira enviar uma mensagem a outra entidade e, embora a mensagem não seja sigilosa, esta queira a garantia de não-repúdio de Alice. Tudo começa com a obtenção de um resumo criptográfico da mensagem, utilizando-se uma função hash. Em seguida, Alice utilizará a parte privada de sua chave assimétrica sobre o resumo e obterá assim sua assinatura digital para a mensagem, sendo esta anexada à mensagem original antes do envio ao destinatário. Ao receber a mensagem assinada digitalmente, o destinatário usará a parte pública da chave assimétrica de Alice como chave de verificação. Com ela é possível verificar a origem da mensagem e garantir sua integridade. Como o destinatário apenas poderá verificar a assinatura e não forjá-la, Alice não poderá repudiar o fato de que assinou a mensagem. A Figura 10 descreve o processo de verificação da assinatura digital. Caso o resumo obtido com a chave pública de Alice, a partir de sua assinatura digital anexada, seja idêntico ao resumo obtido da própria mensagem, estarão assegurados a integridade e o não-repúdio.
  • 30. 29 Figura 10: Processo de verificação da assinatura digital. Fonte: ITI, 2005, p. 7. As razões para se assinar apenas o resumo e não o documento inteiro tem a ver com o custo computacional do processo. Como os algoritmos de criptografia assimétrica são lentos, seu desempenho comprometeria a viabilidade do processo. Obter a assinatura a partir do resumo é rápido e também seguro. A alteração de um único bit na mensagem original acarretaria na obtenção de um resumo diferente e este não coincidiria com o resumo obtido a partir da assinatura anexada. 2.4.5 Padrão X.509 Embora existam diversos padrões de certificados digitais no mercado, tais como SPKI/SDSI, PGP e SET, a pesquisa desta monografia destaca o padrão X.509, atualmente na versão 3, pelo fato do mesmo ter sido amplamente adotado pela Infra-estrutura de Chaves Públicas (ICP) em todo o mundo. Segundo Silva (2004, p. 145) a “evolução do padrão X.509 procurou adaptar sua estrutura de dados originais para acomodar as necessidades básicas de transporte das ICPs, demandadas pelas distintas aplicações sobre TCP/IP3 com requisitos de funcionalidade criptográfica.” Dessa forma, tornou-se possível a utilização de certificação digital em uma rede aberta hierarquicamente, como é o caso da Internet. No Quadro 1 estão descritos os campos de um certificado no padrão X.509 versão 3. 3 Na arquitetura de uma rede de computadores sob o modelo OSI, TCP é um dos protocolos utilizados na camada de transporte e IP é o protocolo de endereçamento da camada de rede.
  • 31. 30 NOME DO CAMPO DESCRIÇÃO Versão Número da versão X.509 do certificado, tendo como valor válido apenas 1, 2 ou 3. Número de série Identificador único do certificado e representado por um inteiro. Não deve haver mais de um certificado emitido com o mesmo número de série por uma mesma autoridade certificadora. Algoritmo de Identificador do algoritmo usado para assinatura do certificado pela Assinatura autoridade certificadora. Emissor Nome da autoridade certificadora que produziu e assinou o certificado. Período de Validade Intervalo de tempo de duração que determina quando um certificado deve ser considerado válido pelas aplicações. Assunto Identifica o dono da chave pública do certificado. O assunto deve ser único para cada assunto no certificado emitido por uma autoridade certificadora. Chave Pública Contém o valor da chave pública do certificado junto com informações de algoritmos com o qual a chave deve ser usada. ID Único de Emissor Campo opcional para permitir o reuso de um emissor com o tempo. ID Único de Assunto Campo opcional para permitir o reuso de um assunto com o tempo. Extensões Campos complementares com informações adicionais personalizadas. Quadro 1: Descrição dos campos de um certificado no formato X.509 v3. Fonte: SILVA et al, 2008, p.28. 2.4.6 Lista de Certificados Revogados (LCR) Silva et al (2008, p. 29) explicam que, conforme visto na Tabela 1, um certificado no padrão X.509 possui um período de validade estabelecido pela autoridade certificadora que o emitiu. Durante a vigência deste, todas as entidades e aplicações em rede devem aceitá- lo. Ao término de sua vigência o certificado é expirado e se torna inválido. Porém, existem situações em que um certificado precisa ser revogado antes de sua expiração normal. Dentre elas, “podem ocorrer, por exemplo, o vazamento de chave privada ou mudança de dados do dono do certificado.” (SILVA et al, 2008, p. 29). A revogação de um certificado é de extrema relevância para se manter a confiabilidade no sistema de certificação digital. Segundo Silva (2004, p. 202), o método mais conhecido para fazer a revogação de um certificado é a publicação periódica na Lista de Certificados Revogados (LCR). “A Autoridade Certificadora (AC) tem a responsabilidade de preencher o repositório de certificados revogados e cabe aos usuários consultar esse repositório para validar um certificado recebido.” A Figura 11 esquematiza a verificação de certificado revogado.
  • 32. 31 Figura 11: Verificação de certificado revogado. Fonte: O autor. 2.4.7 Infra-estrutura de Chaves Públicas (ICP) “A infra-estrutura de chave pública é uma arquitetura de confiabilidade que as empresas podem especificar para suas redes corporativas e políticas de segurança. Ela possibilita transações via Internet tão seguras quanto negócios entre pessoas.” (SILVA, 2004, p. 23). Destacando seu caráter de fé pública, Silva (2004, p. 25) comenta que com uma ICP é “possível identificar e confiar em um usuário Internet, que pode ser outra pessoa, uma estação de trabalho ou qualquer outra entidade eletrônica”. Dessa forma, é possível “fazer uma réplica ou até mesmo aperfeiçoar os mecanismos usados para assegurar a segurança no mundo real.” (SILVA, 2004, p. 22). Com base nas considerações de Silva (2004, pp. 22-24), o Quadro 2 relaciona alguns mecanismos de segurança do mundo real e seus correspondentes viabilizados pela ICP.
  • 33. 32 MUNDO REAL EQUIVALENTE NA ICP Envelopes e firmas de envio seguro. Criptografia de dados. Assinaturas físicas e selos de autenticação. Assinaturas digitais. Documentos de identificação. Ex.: CPF, CNPJ. Equivalentes emitidos digitalmente: e-CPF, e- CNPJ. Fé pública por meio de tabelionatos. Fé pública por meio de Autoridades Certificadoras (Veja a seção 2.4.9.4). Prova testemunhal em documentos. Não-repúdio de assinaturas digitais. Operações financeiras presenciais. Operações financeiras on-line com identificação do usuário através de sua chave privada. Quadro 2: Alguns mecanismos de segurança do mundo real e seus correspondentes na ICP. Fonte: SILVA, 2004, p.22-24, compilação do autor. Para uma ICP ser vista como organismo de confiabilidade não basta apenas dispor de tecnologia apropriada. Conforme é visto na seção 2.4.9.1, também deve possuir uma estrutura hierárquica, apoiada por legislação regulamentadora específica e legitimada pelo Governo Federal para que receba o status de fé pública. 2.4.8 Padrões relevantes para uma ICP Os padrões analisados nesta seção não estão necessariamente correlacionados entre si. Individualmente possuem relevância no incremento da segurança a operações eletrônicas específicas sob a arquitetura da ICP. Por exemplo, o LDAP (Lightweight Directory Access Protocol)4 “serve para disponibilizar os certificados digitais dentro de uma estrutura amigável para consulta”, o IPSec5 “tem como função formar Redes Virtuais Privadas”, “o S/MIME (Secure Multipurpose Internet Mail Extensions)6 é um padrão seguro para envio e recebimento de e-mail” e o SSL/TLS (Security Socket Layer / Transport Layer Security)7 provêm “segurança durante a transmissão de dados importantes.” (SILVA, 2004, pp. 213, 235). 2.4.8.1 LDAP O LDAP “é uma definição de protocolo para acesso a bancos de dados especializados chamados diretórios.” (SILVA, 2004, p. 213). Silva (2004, p. 214) define 4 Protocolo de Acesso Leve a Diretório. 5 Protocolo de Internet Seguro 6 Extensões Seguras de Multipropósito para Correio de Internet. 7 SSL: Camada de Segurança para Soquetes; TLS: Camada de Transporte Seguro.
  • 34. 33 diretório basicamente como “qualquer banco de dados mais especializado em leitura que escrita.” O LDAP foi projetado para permitir a unificação de diretórios, resolvendo os problemas decorrentes de sua proliferação pela rede. Os seguintes benefícios são apontados por Silva (2004, p. 215) como resultantes dessa unificação: Normalização de dados; • Administração central; • Experiência do usuário consistente; • Gerenciamento e políticas de segurança consistentes; • Menos problemas de segurança; • Menos tempo de desenvolvimento desperdiçado. • Na ICP, o LDAP é utilizado para armazenar os certificados de usuários, certificados de Autoridades Certificadoras (ACs) e listas de certificados revogados (LCRs). Estas informações requerem um elevado grau de disponibilidade para que o diretório seja caracterizado como repositório público, ou seja, um banco de dados centralizado que dispõe a informação sempre que é demandado. Graças ao LDAP isso se torna possível. 2.4.8.2 S/MIME O S/MIME “é um protocolo para trocas de informações com privacidade em e-mail.” (SILVA, 2004, 218). Este protocolo geralmente vem embutido em aplicativos clientes de correio eletrônico, dispensando quaisquer instalações adicionais para sua utilização. O S/MIME é especialmente útil ao se prevenir ataques de interceptação e fabricação. Conforme explica Silva (2004, p. 220), sua metodologia consiste em primeiro aplicar uma assinatura digital à mensagem, em seguida enviando tanto a mensagem quanto a assinatura embutidas num envelope digital. Como a assinatura não poderá ser reproduzida por um interceptador, têm-se a garantia da autenticidade do remetente e durante a verificação da assinatura pode-se conferir se a mensagem manteve sua integridade. Embora o S/MIME seja um padrão importante para uma ICP, sua utilização não requer a presença de uma Autoridade Certificadora (AC). Isso permite sua livre utilização
  • 35. 34 por qualquer usuário, inclusive com a adoção de certificados gratuitos para e-mail, como os distribuídos pela Thawte (http://www.thawte.com). 2.4.8.3 IPSec O “IPSec é um conjunto de protocolos que define a arquitetura e as especificações para prover serviços de segurança dentro do protocolo IP.” (SILVA, 2004, p. 220). Os serviços de segurança definidos no IPSec incluem tráfego de dados, autenticação de cabeçalho, encapsulamento seguro do dado e procedimentos e protocolos de gerência de chaves. A análise de todas as particularidades que compõem o conjunto de serviços do IPSec merece uma pesquisa à parte. Na análise de seu uso, no contexto de uma ICP, é importante saber que o IPSec supre a demanda de segurança do protocolo IP, tanto em sua versão 4 (IPv4) quanto em sua versão 6 (IPv6). 2.4.8.4 SSL “O SSL é um protocolo de segurança” utilizado “durante a transmissão de dados importantes.” Ele “fornece criptografia de dados, autenticação de cliente e servidor e integridade de mensagem para transmissão de dados pela Internet.” (SILVA, 2004, p. 235). Amplamente utilizado em Websites que efetuam comércio eletrônico na rede, o SSL é suportado pela maioria dos navegadores de Internet e sua presença pode ser constatada pela indicação de um ícone, representando um cadeado de segurança, através do qual se pode obter informações acerca do certificado digital utilizado. Silva (2004, p. 235) descreve a metodologia para o estabelecimento de comunicação segura, com SSL, entre o servidor e um navegador Web: Quando o browser, lado cliente, conecta-se a uma página protegida por SSL, o servidor do SSL envia uma solicitação para iniciar a sessão segura. Se o browser suporta SSL, ele retorna uma resposta. Durante esse handshake inicial, o servidor e o browser trocam informações seguras. A resposta do browser define um número único para identificar a sessão, os algoritmos de criptografia e os métodos de compactação que suporta.
  • 36. 35 Nas informações de segurança fornecidas pelo browser, o servidor faz sua seleção e a comunica ao browser. O servidor e o browser, em seguida, trocam certificados digitais. O servidor também especifica uma chave pública, chave de sessão, apropriada para o algoritmo de criptografia anteriormente selecionado. O browser pode, então, usar a chave pública para criptografar informações enviadas ao servidor, e o servidor pode usar sua chave privada para descriptografar essas mensagens. Depois que o servidor e o browser estiverem de acordo sobre a organização da segurança, as informações poderão ser transmitidas entre os dois, em um modo seguro. 2.4.8.5 TLS TLS é “um protocolo para proteção de conexões entre aplicações na Internet” semelhantes à proporcionada pelo SSL versão 3. Entretanto, uma significativa diferença do TLS em relação ao SSL é que este é um protocolo proprietário, patenteado pela Netscape, enquanto aquele é uma iniciativa não-proprietária. 2.4.9 ICP-Brasil “O Brasil adotou a tecnologia de certificação digital implementando uma infra- estrutura de chaves públicas hierarquizada, fortemente centralizada e vinculada ao Governo Federal, a ICP-Brasil.” (OTTONI, 2005, p. 14). Silva et al (2008, p.79) registra sua criação: A ICP-Brasil foi instituída pela Medida Provisória 2.200-2, de 24 de agosto de 2001, que cria o Comitê Gestor da ICP-Brasil, a Autoridade Certificadora Raiz Brasileira e define as demais entidades que compõem a estrutura. A partir dessa medida foram elaborados os regulamentos que passaram a reger as atividades das entidades integrantes da ICP-Brasil, chamados de resoluções do Comitê Gestor da ICP-Brasil. Para Ottoni (2005, p. 15), “nos termos de seu artigo art. 1º, a finalidade da Medida Provisória é garantir a autenticidade, integridade e validade jurídica dos documentos e aplicações que utilizem certificados digitais”. A validade jurídica proporcionada pela ICP- Brasil se torna o maior argumento em apoio à adoção de um certificado digital originário de seu âmbito. Para entender como isso ocorre é importante analisar sua estrutura hierárquica. 2.4.9.1 Estrutura A Figura 12 retrata a estrutura simplificada da ICP-Brasil.
  • 37. 36 Comitê Gestor AC-Raiz COTEC PSS AC 1º nível AC 1º nível AC 1º nível AR PSS AR PSS AC 2º nível AC 2º nível AR AR Auditoria Independente Figura12: Estrutura hierárquica da ICP-Brasil. Fonte: SILVA, 2008, p.82. O Quadro 3 apresenta uma visão macro dos componentes da ICP-Brasil. Componente Papéis: Definir políticas, diretrizes, normas e regras operacionais. Normativo Características: regulador de atividades econômico produtivas, formulador Responsável: de políticas com poder de normalização (órgão sistêmico), fiscalização CG ICP-Brasil (auditoria) e poder de polícia (fazenda pública). Componente de Papéis: Realizar credenciamento, auditorias e certificação. Credenciamento Características: órgão credenciador, auditor e fiscalizador das políticas Responsável: diretrizes, normas e regras (regulamentos técnicos) definidos pelo CG. AC Raiz Papéis: Fazer a expedição de certificados de chaves públicas e de selos Componente digitais. Operacional Características: Identificação, cadastramento e lançamento da base Responsáveis: operacional da ICP-Brasil ACs e ARs Quadro 3: Componentes da ICP-Brasil. Fonte: SILVA, 2004, p. 280. 2.4.9.2 Componentes da ICP-Brasil O Comitê Gestor (CG) é o componente base da ICP-Brasil. Silva et al (2008, p. 82) estabelece da seguinte forma o papel do Comitê Gestor: Coordena a implantação e o funcionamento da ICP-Brasil, além de estabelecer a política, os critérios e as normas para credenciamento das autoridades certificadoras
  • 38. 37 (Acs), autoridades de registro (Ars) e demais prestadores de serviços de suporte em todos os níveis da cadeia de certificação. Este comitê é o órgão responsável por auditar a Autoridade Certificadora Raiz. O Comitê Técnico (COTEC) “presta suporte técnico e assistência ao Comitê Gestor, sendo responsável por manifestar-se previamente sobre as matérias apreciadas e decididas por este.” (SILVA et al, 2008, p. 83). A Autoridade Certificadora Raiz (AC-Raiz) “é a primeira autoridade na cadeia de certificação, executora das políticas de Certificados e normas técnicas e operacionais aprovadas pelo Comitê Gestor da ICP-Brasil.” (SILVA, 2004, p. 283). O Instituto Nacional de Tecnologia da Informação (ITI), órgão vinculado ao Ministério da Ciência e Tecnologia, possui o papel de AC-Raiz da ICP-Brasil. Logo abaixo na hierarquia vêm as Autoridades Certificadoras (ACs). “Autoridades certificadoras são entidades credenciadas a emitir certificados digitais, vinculando pares de chaves criptográficas ao respectivo titular.” (SILVA et al, 2008, p. 84). Cabe às ACs as tarefas de emitir, expedir, distribuir, revogar e gerenciar os certificados. Além disso, tornam público as listas de certificados revogados (LCRs) e outras informações pertinentes. Por sua vez, as Autoridades de Registro (ARs) “são entidades operacionalmente vinculadas à determinada AC. Compete-lhes identificar e cadastrar usuários na presença destes, encaminhar solicitações de certificados às AC (sic) e manter registros de suas operações.” (SILVA et al, 2008, pp. 84-85). Já para Silva (2004, p. 191), uma AR pode ter duas atribuições bem definidas: “verificar o conteúdo do certificado para uma AC e fornecer os mecanismos para ingressos de novos usuários na AC”. Os componentes finais da ICP-Brasil são os Prestadores de Serviços de Suporte (PSS) e as Auditorias Independentes. Conforme Silva et al (2008, p. 85), os PSSs são empresas contratadas pelas ACs ou ARs para prestarem serviços de “disponibilização de infra-estrutura física e lógica e de recursos humanos especializados”. Já as Auditorias Independentes “são contratadas pelas autoridades certificadoras para realizar auditorias operacionais em entidades a elas subordinadas.” As Auditorias Independentes só podem atuar sob a autorização da AC-Raiz.
  • 39. 38 2.5 CONSIDERAÇÕES FINAIS Numa transação convencional, as partes envolvidas devem partir do pressuposto de haver documentos que comprovem a identidade de cada um. Ademais, deve haver um órgão com uma relação de confiança já estabelecida para atestar a validade destes documentos. O mesmo ocorre no meio eletrônico com o uso de certificados digitais. A estrutura por detrás da relação de confiança é a ICP-Brasil, representada pela AC que emitiu o certificado e a AR que intermediou o ingresso da entidade certificada no sistema. Tanto as ACs quanto as ARs precisam atender a normas rigorosas de credenciamento, estabelecidas pela AC-Raiz, assim como submeter-se a minuciosas auditorias em suas operações. Somando-se a estas normas e diretrizes regulamentadoras, têm-se à disposição da ICP-Brasil uma consolidada tecnologia de chaves assimétricas e outra gama de protocolos de apoio à segurança criptográfica. Finalmente, o envolvimento do Governo Federal ao legitimar a ICP-Brasil como o mecanismo oficial em apoio à segurança das transações eletrônicas, deu ampla cobertura jurídica a toda e qualquer operação eletrônica realizada na Internet. Por tudo isso, com o uso de um certificado digital sob o âmbito da ICP-Brasil, pode- se endossar o que afirma Ottoni (2005, p. 3): “um sistema de documentação integralmente eletrônico [...] não é apenas inexorável como promete benefícios em todos os setores da economia e da sociedade”. A pesquisa passa, no capítulo seguinte, a analisar uma aplicação prática para a certificação digital, em especial o uso de Certificado Digital para Website, utilizando o protocolo de segurança SSL versão 3, num sistema de informação baseado em servidor Web e acessado por browsers Web como seus clientes.
  • 40. 39 3 DESENVOLVIMENTO DA APLICAÇÃO – SDT ON LINE O autor da pesquisa atuou ativamente em todas as etapas de desenvolvimento da aplicação SDT On Line, para os estados de Pernambuco (http://www.sdtpe.com.br) e da Paraíba (http://www.sdtpb.com.br), sendo esta um exemplo de utilização de certificado digital em aplicações Web. O presente estudo de caso tem como finalidade expor detalhes técnicos e metodológicos acerca da aplicação e apontar como a certificação digital é utilizada para garantir os princípios da autenticidade, integridade e confidencialidade. 3.1 DEFINIÇÃO Anteriormente, a entrega de um título para protesto fazia parte de um processo de livre escolha entre o apresentante e o respectivo ofício de sua preferência. Geralmente existem dois ofícios para protesto legalmente estabelecidos em cada cidade, sendo a cidade de São Paulo uma exceção à regra por possuir dez ofícios. Assim, passou a haver uma disputa comercial entre os ofícios pelos títulos dos apresentantes com maior volume, a rede bancária . Essa situação de disputa causou certo desconforto no meio notarial, cuja atuação é reconhecidamente pautada pela ética e transparência em toda a sua forma. Diante disso, a Associação dos Notários e Registradores (ANOREG) recomendou a criação de uma entidade que pudesse conciliar os interesses individuais na atividade de protesto de títulos. Assim, sob a tutela da ANOREG, foi criado em cada capital brasileira o Serviço de Distribuição de Títulos (SDT), um serviço provido por uma organização homônima, de caráter civil sem fins lucrativos, que visa atender, em cada estado da federação, à demanda por distribuição de títulos para fins de protesto, de forma eqüitativa, a todos os ofícios de protesto credenciados. Em sua versão na Internet, conhecida por SDT On Line, o serviço mantém o princípio básico da distribuição de títulos, fazendo uso de sua base tecnológica já existente, agregando a esta um canal eficaz para a entrega dos documentos em sua forma eletrônica.
  • 41. 40 3.2 FUNCIONALIDADE O SDT, como serviço, funciona como captador centralizado de títulos para protesto, provenientes de entidades conhecidas como Apresentantes. Os títulos recebidos são processados em seu sistema local e agrupados em lotes distintos, de forma eqüitativa, e daí são submetidos aos seus respectivos ofícios de protesto. Sistematicamente, os tabelionatos de protesto remetem de volta ao SDT lotes de títulos já movimentados, para que os mesmos sejam devolvidos aos seus respectivos apresentantes, completando assim o ciclo de vida de um título para protesto. A finalidade específica do SDT On Line é prover um meio seguro e rápido de fazer o envio e recepção de títulos entre as entidades que compõem o sistema. Até então o meio utilizado pelo SDT para o tráfego de documentos entre as entidades era através da utilização de discos magnéticos contendo os arquivos de dados do sistema, transportados por um mensageiro humano. A Figura 13 apresenta o ciclo de vida de um título para protesto. (a) SDT Tabelionato Apresentante Mensageiros (b) SDT On Line Figura 13: Ciclo de vida de um título para protesto. (a) Antes e (b) depois do SDT On Line. Fonte: O autor. Além de dar mais agilidade ao processo de repasse dos documentos, o SDT On Line resulta nos seguintes benefícios adicionais: Dispensa o papel de entregadores humanos;
  • 42. 41 Elimina o retrabalho de gravação em mídias defeituosas; Impede o acesso não autorizado ao conteúdo dos arquivos; Amplia o alcance do serviço para entidades mais remotas. 3.3 METODOLOGIA DE DESENVOLVIMENTO Para o desenvolvimento do SDT On Line foi utilizada uma combinação de tecnologias que suportam os requisitos essenciais para seu projeto: priorização de plataformas de código-fonte aberto (open source), base de dados relacional com integridade referencial, programação orientada à objetos, facilidade de hospedagem em servidor Web, implementações de segurança confiáveis e facilidade de documentação para o projeto. As tecnologias adotadas são justificadas pelo atendimento destes requisitos. 3.3.1 Sistema Gerenciador de Banco de Dados (SGBD) MySQL O MySQL (http://www.mysql.com/) é um dos mais populares SGBDs da Internet. Originalmente desenvolvido pela MySQL AB, hoje é mantido pela Sun Microsystems (http://www.sun.com/), sua atual proprietária. O MySQL versão 5 foi adotado em atendimento aos requisitos do projeto: Possui versão em plataforma de código-fonte aberto; Implementa bases de dados relacionais; Utiliza integridade referencial através de tabelas no padrão InnoDB8; Amplamente disponível em servidores Web comerciais; Rapidez nas respostas em consultas pela Internet. 3.3.2 Linguagem de programação PHP A linguagem PHP (http://www.php.net/), mantida pela empresa Zend Technologies (http://www.zend.com/en/), é amplamente utilizada para desenvolvimento de sistemas Web e foi adotada, em sua versão 5, por atender aos seguintes requisitos: É licenciada pela GNU GPL9, o que a caracteriza como open source; 8 InnoDB é um dos módulo de armazenamento para o MySQL. Sua principal característica é oferecer transações do tipo ACID.
  • 43. 42 Possui completo suporte para desenvolvimento orientado à objetos; Amplamente disponível em servidores Web comerciais; Permite desenvolvimento com características de robustez e segurança. 3.3.3 Servidor de Criptografia OpenSSL O projeto OpenSSL (http://www.openssl.org/) é uma iniciativa da comunidade de desenvolvedores colaborativos e visa prover um conjunto de ferramentas open source para implementação do protocolo SSL em servidores Web. Foi especialmente escolhido no projeto para compor a camada de certificação digital do sistema em sua fase de desenvolvimento, sendo substituído posteriormente por um certificado digital comercial, vinculado a uma Autoridade Certificadora. O OpenSSL atualmente suporta SSL versão 3. 3.3.4 Servidor Web Apache Mantido pela Apache Software Foundation (http://www.apache.org/) sob o modelo de código-fonte aberto, o servidor Web Apache (http://httpd.apache.org/) é, segundo seu desenvolvedor, o mais utilizado na Internet desde o ano de 1996. (ASF, 2008). A facilidade de instalação deste servidor em um ambiente de desenvolvimento, somada à sua ampla disponibilidade em provedores comerciais, foram decisivos em sua adoção no projeto, assim como também seu suporte nativo à linguagem de programação PHP versão 5 e ao SSL versão 3. 3.3.5 Modelador gráfico JUDE/Community Mantido pela comunidade de desenvolvedores, o projeto JUDE/Community (http://jude.change-vision.com/jude-Web/product/community.html) fornece uma ferramenta de modelagem gráfica open source de ótima qualidade. Essa foi a ferramenta utilizada na documentação do projeto, especificamente na composição de Diagramas Entidade relacionamento (DER), Diagramas de Caso de Uso e Diagramas de Classes. 9 GNU GPL (GNU General Public Licence), de autoria da Free Software Foundation (http://www.fsf.org/), é a mais popular das licenças utilizadas em sistemas de código-fonte aberto.
  • 44. 43 3.3.6 Documentador de código PHPDocumentor O PHPDocumentor (http://www.phpdoc.org/) é uma ferramenta de documentação automática para a linguagem PHP. Ela utiliza o padrão de documentação conhecido como DocBlock (http://phpdocu.sourceforge.net/howto.php), o qual consiste em se escrever um bloco de comentários, com instruções específicas, contendo detalhes acerca do código implementado logo abaixo. Ao ler o DocBlock, o PHPDocumentor gera uma documentação de saída em diversos formatos amigáveis ao usuário, tais como PDF (Portable Document Format)10, HTML (HyperText Markup Language)11, TXT (Arquivo-texto) e CHM (Microsoft Compiled HTML Help)12. O uso do PHPDocumentor permitiu a geração de documentação para o código sem comprometer o tempo de desenvolvimento do projeto, criando facilmente um modelo de referência para novos integrantes na equipe. 3.3.7 Ambiente de Desenvolvimento Integrado (IDE) Eclipse PDT Tools)13 O projeto Eclipse PDT (PHP open source Development (http://www.eclipse.org/pdt/) criou uma IDE baseada no Eclipse contendo todos os componentes necessários para o desenvolvimento em PHP. Além de manter a aderência aos padrões do Eclipse, o PDT fornece componentes exclusivos para o PHP tais como: Suporte ao Zend Framework14, para desenvolvimento baseado em padrões de projeto; Suporte ao PHPDocumentor, para criação de documentação de código; Suporte ao PHPUnit15, para criação de ambientes de testes de unidade; 10 Formato de Documento Portável. 11 Linguagem de Marcação de Hipertexto. 12 Ajuda em HTML compilado da Microsoft. 13 Ferramentas para Desenvolvimento em PHP. 14 Compreende uma biblioteca de classes, criada pela Zend Technologies na linguagem PHP, usada para auxiliar no desenvolvimento de software. 15 O PHPUnit é um framework, inspirado no JUnit do Java, com suporte à criação de testes automatizados na linguagem de programação PHP.
  • 45. 44 Suporte ao ZendDebug16, para depuração de código; Suporte para code autocompletation. 3.4 A APLICAÇÃO O SDT On Line é um projeto concebido e administrado pela Virtus Sistemas, responsável pelas etapas de levantamento de requisitos, documentação do projeto e validação das implementações. Foi executado sob a supervisão da PBGold Soluções Internet, responsável por alocar recursos para as etapas de Webdesign, modelagem de dados, codificação e testes do sistema. O SDT On Line é um sistema baseado na Web acessível de qualquer navegador Web (browser). A aplicação fica embutida no Website da organização, com acesso restrito apenas aos usuários devidamente cadastrados no sistema, enquanto que a parte pública do sítio mantém serviços de informação comuns a qualquer visitante. A Figura 14 apresenta a página do Website por onde os usuários podem se autenticar no sistema. A Federação Brasileira de Bancos (FEBRABAN) (http://www.febraban.org.br) elegeu o SDT On Line como projeto-piloto, a ser testado inicialmente nos estados de Pernambuco e da Paraíba durante o período de um ano. Após esse prazo o sistema será submetido a uma avaliação final para que seja homologado e sirva como modelo para a implementação em outros estados da federação. 16 ZendDebug é a ferramenta de depuração de código, baseada em servidor, da Zend Technologies.
  • 46. 45 Figura 14: Tela de autenticação de usuário do SDT On Line. Fonte: O autor. 3.4.1 Requisitos As entidades mantenedoras da aplicação SDT On Line autorizaram a divulgação parcial dos requisitos do sistema neste estudo de caso, resultando num nível de detalhamento superficial, mas adequado à exposição de importantes partes do projeto. 3.4.1.1 Requisitos não-funcionais Os requisitos não-funcionais do sistema são: 1. Acesso multi-usuário simultaneamente; 2. Interface Web compatível com os navegadores mais populares; 3. Acesso às funcionalidades do sistema para grupos de usuários através da atribuição de papéis e recursos específicos; 4. Banco de dados com integridade referencial.
  • 47. 46 3.4.1.2 Requisitos de domínio Os requisitos de domínio do sistema são: 1. Uso de certificação digital para garantir autenticidade do sistema e integridade e confidencialidade dos arquivos transacionados; 2. Desenvolvimento modular para permitir inclusão de novas funcionalidades; 3. Baixo acoplamento entre o núcleo do sistema e a interface; 4. Hospedeiro Web com alta estabilidade e disponibilidade; 5. Programação de backups e planejamento de recuperação de desastres. 3.4.1.3 Requisitos funcionais Os requisitos funcionais mais importantes do sistema são: 1. Cadastro de Entidades: disponível apenas para administradores do SDT; deverá permitir o cadastro de Apresentantes e Tabelionatos; deverá conter as funções de inclusão, consulta, alteração e exclusão de registros; 2. Cadastro de Usuários: disponível apenas para administradores das entidades; deverá existir uma entidade previamente cadastrada para acomodar o usuário; o usuário deverá ser vinculado a um grupo; deverá conter as funções de inclusão, consulta, alteração e exclusão de registros; 3. Enviar arquivos: disponível apenas para usuários autenticados no sistema; deverá possibilitar o envio de arquivos de diversos layouts; o arquivo será validado conforme layout da FEBRABAN; os dados serão extraídos do arquivo e armazenados no banco; informar ao apresentante o sucesso da operação e emitir o recibo; notificar ao SDT a disponibilidade dos dados; caso o arquivo seja invalidado deverá ser descartado; informar ao apresentante o fracasso da operação; 4. Receber arquivos: disponível apenas para usuários autenticados no sistema; deverá possibilitar a recepção de arquivos de diversos layouts; através da página de notificação, selecionar o arquivo desejado; os dados serão lidos da base e o arquivo será montado com base no layout da FEBRABAN; disponibilizar o arquivo para download; 5. Solicitar retirada de título: disponível apenas para usuários autenticados no sistema; informar dados de identificação do ofício para onde foi distribuído e o protocolo do título; localiza o título na base; solicita novos dados do título para
  • 48. 47 conferência; se dados conferem o tabelionato é notificado para devolução; gerar recibo da solicitação; caso dados não confiram ou título não exista na base o usuário é solicitado para entrar novos dados; p 3.4.2 Arquitetura Para atender aos requisitos de desenvolvimento modular e baixo acoplamento entre o núcleo da aplicação e sua interface com o usuário, optou-se pelo desenvolvimento optou se segundo a arquitetura Modelo-Visão-Controle, ou simplesmente MVC. Modelo Para Bass (1991, apud MENDES, 2002, p. 132) “a arquitetura MVC tem como base o paradigma de multiagentes”. Mendes (2002, p. 132) declara que o MVC enxerga um agente segundo três componentes funcionais: 1. Modelo: responsável pela definição da competência do agente (núcleo definição funcional); 2. Visão: responsável pela definição do comportamento perceptivo do agente para a saída (apresentação de resultados); 3. Controle: responsável pela definição do comportamento perceptivo do agente para a entrada (comandos de usuário). (c Conforme observado na Figura 15, o MVC decompõe as tarefas do sistema entre os componentes, resultando na obtenção de modularidade e desacoplamento entre o núcleo funcional e sua interface, que são requisitos essenciais ao projeto SDT On Line SD Line. Figura 15: Modelo arquitetural MVC. Fonte: MENDES, 2002, p. 132.
  • 49. 48 3.4.3 Diagramas de Casos de Uso As Figuras 16 a 20 apresentam os Diagramas de Caso de Uso para as principais funcionalidades do sistema. Figura 16: Diagrama de Caso de Uso para a funcionalidade “Cadastro de Entidades”. Fonte: O autor. Figura 17: Diagrama de Caso de Uso para a funcionalidade “Cadastro de Usuários”. Fonte: O autor.
  • 50. 49 Figura 18: Diagrama de Caso de Uso para a funcionalidade “Enviar Arquivos”. Fonte: O autor. Figura 19: Diagrama de Caso de Uso para a funcionalidade “Receber Arquivos”. Fonte: O autor.
  • 51. 50 Figura 20: Diagrama de Caso de Uso para a funcionalidade “Solicitar Retirada de Títulos”. Fonte: O autor. 3.4.4 Diagrama Entidade Relacionamento (DER) A Virtus Sistemas, empresa responsável pelo projeto SDT On Line autorizou a Line, utilização do DER simplificado, no qual se detalha o relacionamento entre as diversas entidades sem apresentar o detalhamento dos atributos. Por sua vez, o Dicionário de Dados, no qual se apresentam os atributos num maior grau de detalhamento, teve seu uso vetado neste estudo de caso. A Figura 21 apresenta o DER versão 2.4 para a aplicação SDT On Line Line.
  • 52. 51 Figura 21: DER para o SDT On Line. Fonte: Virtus Sistemas. 3.4.5 Diagrama de Classes – Camada de Modelo Da mesma forma que no DER, para o Diagrama de Classes foi autorizada a utilização de um modelo simplificado, contendo apenas atributos e operações básicos. Ainda assim, o núcleo da aplicação está corretamente representado quanto às suas principais funcionalidades. A Figura 22 esquematiza o Diagrama de Classes para o SDT On Line.
  • 53. 52 Figura 22: Diagrama de Classes do SDT On Line – Camada de Modelo Fonte: O autor. 3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT ON LINE O ponto alto deste estudo de caso se concentra na análise de como a aplicação to SDT On Line se utilizou dos conceitos acerca da certificação digital e como esta foi aplicada para prover os requisitos de autenticidade do sistema e integridade e confidencialidade dos arquivos transacionados.
  • 54. 53 São analisados: O que motivou a escolha da Autoridade Certificadora; A escolha do tipo de certificado digital apropriado à aplicação; Como é feita a verificação de autenticidade da aplicação pelo usuário; Como os arquivos contendo dados sensíveis trafegam em segurança entre o cliente e o servidor da aplicação. 3.5.1 Autoridade Certificadora Escolhida Uma das perguntas respondidas antes de se escolher uma Autoridade Certificadora foi: que tipo de proteção a aplicação precisa ter? A resposta é decisiva ao se optar por uma AC pertencente ou não à ICP-Brasil, pois isso tem reflexo direto no custo do certificado digital adquirido. Devido ao amparo jurídico e à garantia de não-repúdio, certificados digitais emitidos por ACs pertencentes à ICP-Brasil costumam custar até 12 vezes mais que um equivalente não pertencente à ICP-Brasil. O Quadro 4 faz um comparativo de preços entre certificados digitais equivalentes entre duas ACs, uma pertencente à ICP-Brasil e outra não. Certisign (ICP-Brasil) Comodo Certificado Certisign ICP-Brasil A1 InstantSSL A1 Valor anual: R$ 2.953,50 Valor anual: R$ 240,00 Quadro 4: Comparativo de preços entre certificados equivalentes emitidos por AC pertencente e não pertencente à ICP-Brasil. Fontes: Certisign Brasil (https://www.certisign.com.br/produtos/certificados/icp) e Comodo Brasil (http://www.comodobr.com/instantssl/prd_instantssl.php). No caso do SDT On Line, os requisitos para a proteção do sistema seriam a garantia a autenticidade, confidencialidade e integridade. Em nenhum caso as informações transacionadas implicam em se ter garantia ao não-repúdio. Sendo assim, um certificado da ICP-Brasil seria desnecessário, uma vez que todos os demais certificados têm tecnicamente condições de prover as demais garantias necessárias. A escolha pela Autoridade Certificadora recaiu sobre a Comodo Brasil (http://www.comodobr.com) que, além de apresentar um certificado compatível com as necessidades do sistema, oferece adicionalmente um seguro de US$ 100.000,00 (cem mil dólares americanos) em caso de prejuízos sofridos pelo sistema em uma eventual falha na proteção garantida pelo certificado.
  • 55. 54 3.5.2 Tipo de Certificado Adotado Basicamente, vigoram dois tipos de certificados digitais, conhecidos como A1 e A3. Uma das coisas que difere ambos é a forma como o par de chaves é armazenado. O tipo A1 armazena as chaves na unidade de disco de um computador, enquanto o tipo A3 armazena as chaves em mídias seguras, tais como um smart card ou um token USB. A Figura 23 apresenta as mídias para armazenamento de certificados do tipo A3. Figura 23: Mídias para certificados A3. Fonte: Certisign. O tipo A3 é mais recomendável para usuários clientes, levando-se em conta o fator segurança. Em caso de roubo ou extravio de sua mídia, o par de chaves continuará seguro, desde que sua senha de acesso não tenha sido revelada. Basta então comunicar à AC para que o certificado seja revogado. O tipo A1 é mais vulnerável ao roubo e extravio de computadores, principalmente laptops. O par de chaves assim armazenado está de certa forma mais disponível para o uso indevido antes da revogação do certificado, por isso não se recomenda para uso pessoal. Porém, o mesmo se apresenta adequado para armazenamento em servidores, os quais geralmente gozam de um maior aparato de segurança. Dessa forma, despontam como
  • 56. 55 adequados para uso em servidores Web nos quais rodam aplicações que necessitam de seus mecanismos de proteção. Toda a aplicação SDT On Line roda em um servidor Web do tipo Apache, com suporte ao protocolo SSL. Assim, ela faz uso desse recurso ao fornecer o par de chaves assimétricas de seu certificado para uso do SSL no servidor. Para esse fim, um certificado digital do tipo InstantSSL A1, emitido pela Comodo Brasil, especialmente configurado para uso em Websites com SSL, foi adquirido pelos mantenedores da aplicação e instalado dentro do servidor Web contratado. 3.5.3 Verificação de Autenticidade do Website Conforme visto no item 2.3.4, um ataque de fabricação contra um sistema pode fazer com que um usuário incauto interaja com um serviço fraudulento, fazendo-se passar por um legítimo. O SDT On Line não está livre de ser clonado por algum criminoso digital mal-intencionado, mas, com o uso de seu certificado digital, pode prevenir seus usuários contra esse tipo de golpe, por prover os meios de conferência de sua autenticidade. Nas Figuras 24 a 26, obtidas com o navegador Web Mozilla Firefox versão 3, são delineados os passos necessários para se fazer a verificação de autenticidade do sistema, mediante o uso de seu certificado digital. Figura 24: Verificação de Autenticidade – parte 1. Fonte: O autor.
  • 57. 56 Na Figura 24 as áreas circundadas em vermelho indicam as áreas no navegador Web por onde começam a verificação de autenticidade. O ícone representando um cadeado, no canto inferior direito, indica o nível de segurança. Estando completamente fechado é um indicativo de que a segurança é alta. Um duplo clique nas áreas circundadas leva à parte dois da verificação, conforme a Figura 25. Figura 25: Verificação de Autenticidade – parte 2. Fonte: O autor. Na Figura 25 são destacadas as seções “Identidade do site” e “Detalhes técnicos”. Na primeira já se pode observar de forma resumida qual o site que está sendo acessado, seu proprietário e a AC que o homologou. Na segunda é apresentada a informação de que a conexão está criptografada e qual o seu nível de segurança. A informação destacada ao centro, sob o rótulo “Este site fornece um certificado para comprovar sua identidade”, permite que, ao se pressionar o botão “Exibir certificado” passemos para a terceira parte da verificação de autenticidade, conforme apresentada na Figura 26.
  • 58. 57 Figura 26: Verificação de Autenticidade – parte 3. Fonte: O autor. A Figura 26 apresenta o Visualizador de Certificados associado ao navegador Web. As seções são apresentadas conforme explicado a seguir: Expedido para: contém dados relativos ao proprietário do certificado digital; Expedido por: contém informações acerca da AC que emitiu o certificado; Validade: informa as datas de início da vigência do certificado e quando se dará sua expiração; Assinaturas: contém as assinaturas digitais da AC, aplicada sobre o próprio certificado impedindo sua adulteração. As assinaturas foram obtidas a partir de duas funções hash distintas: SHA1 e MD5. Neste ponto o usuário tem assegurado que sua interação com o sistema é legítima e ele não sofrerá nenhum tipo de dano durante as operações efetuadas.
  • 59. 58 3.5.4 Transmissão Segura de Dados com SSL Conforme explicado no item 2.4.8.4, o SSL provê um canal criptografado por onde as informações podem trafegar de modo seguro. O servidor SSL se utiliza das chaves assimétricas presentes no certificado digital do SDT On Line para garantir o princípio da confidencialidade. Ao se iniciar a transmissão de dados, deve-se observar qual o protocolo que está sendo utilizado pela aplicação. Conforme mostra a Figura 27, o protocolo HTTPS (HyperText Transfer Protocol over Secure Socket Layer)17 assegura que a transmissão se dará sob a criptografia provida pelo SSL e que nenhuma informação trafegada entre o usuário e a aplicação poderá ser compreendida caso haja uma interceptação. Figura 27: Indicação de uso do protocolo HTTPS na conexão com o sistema. Fonte: O autor. 3.6 CONSIDERAÇÕES FINAIS Este estudo de caso apresenta como uma aplicação Web pode ganhar uma satisfatória proteção e assegurar uma adequada medida de segurança a seus usuários. De forma simples, a adoção de um certificado digital elimina os principais problemas relacionados à segurança da informação no ambiente Internet. Conforme mostra a análise da arquitetura do sistema, nenhum tipo de implementação especial foi previsto e utilizado no projeto para fazer uso da certificação digital. Todos os elementos necessários para permitir sua funcionalidade já estão disponíveis na infra-estrutura da Web, sendo somente necessário utilizá-los. O próximo capítulo faz uma análise dos resultados obtidos, do ponto de vista da aplicação, segundo a estratégia de desenvolvimento se utilizando das tecnologias discutidas neste capítulo. 17 Protocolo de Transferência de Hipertexto sobre Camada Segura de Soquete.
  • 60. 59 4. ANALISE DE RESULTADOS Os resultados analisados neste capítulo levam em conta aspectos operacionais e técnicos, sempre do ponto de vista da própria aplicação. Os resultados operacionais focam os processos internos do SDT e como a aplicação proporcionou melhorias nestes. Já os resultados técnicos focam como a utilização de tecnologias previstas em projeto permitiu alcançar os objetivos de implementação traçados. Ao final, são traçadas as perspectivas futuras para a evolução da aplicação. 4.1 RESULTADOS OPERACIONAIS Com o uso do SDT On Line se constatou o melhoramento no ciclo de vida de um título para protesto. Conforme demonstrado na Figura 13, antes havia a participação de mensageiros humanos no processo de entrega dos arquivos contendo os títulos para protesto e isso acarretava alguns problemas, todos sanados com o uso da aplicação. Dentre os avanços conquistados destacamos: Aumento na segurança: arquivos em formato de texto plano, gravados em • disquetes comuns, sem nenhum tipo de criptografia, podiam ser lidos facilmente em qualquer computador e sofrer adulterações em seu conteúdo. Atualmente os arquivos são trafegados criptografados dentro da aplicação, inviabilizando possíveis adulterações nos dados. Aumento na disponibilidade: devido ao fato de que a mídia disquete • apresentava freqüentes falhas de gravação, não era incomum que os dados não pudessem ser lidos, obrigando a adoção da prática de redundância de mídia. Atualmente os dados são armazenados em banco de dados relacional, com ampla disponibilidade pela Internet. Agilidade na entrega: por melhor que fosse a logística desenvolvida pelas • entidades, a entrega por um mensageiro humano enfrentava diariamente obstáculos naturais à agilidade: trânsito, acidentes, interação com outras pessoas e distância entre as entidades. Atualmente os dados ficam disponíveis à entidade destinatária no momento imediatamente após a confirmação de envio bem sucedido.
  • 61. 60 Alcance do serviço: devido aos motivos destacados nos pontos anteriores, • a área geográfica de atendimento do SDT se limitava à região metropolitana da capital em que estava estabelecido. Com o advento da aplicação on line as barreiras naturais que impediam sua atuação em cidades mais remotas foram superadas, e o atendimento do SDT já chegou ao interior de cada estado em que atua. Inovação: devido ao seu caráter inovador para o serviço, o SDT On Line • foi eleito pela FEBRABAN como projeto-piloto no gênero. Esse status daria o direito à aplicação de concorrer ao processo de homologação da FEBRABAN para ser recomendado como solução de software oficial em uso nos SDTs de todo o país. 4.2 RESULTADOS TÉCNICOS A primeira preocupação na entrega da aplicação foi se certificar de que a mesma atendia aos requisitos especificados no projeto. Através de uma lista de verificação própria, utilizada durante a fase de testes, pôde-se atestar o atendimento a cada um dos requisitos. Importante ressaltar que, ao longo do processo de implantação, vários requisitos foram atendidos de uma forma mais eficaz do que havia sido previsto, a exemplo do requisito de desacoplamento da interface. A solução adotada conseguiu, além do já esperado, também o desacoplamento da base de dados, aumentando a flexibilidade na possível substituição do SGBD. Adicionalmente, uma nova lista de verificação foi aplicada, dessa vez segundo os critérios de homologação da FEBRABAN, para fins de homologação. Neste momento dos testes vários ajustes foram requeridos para adequação às novas exigências. Contudo, a implantação dos ajustes não descaracterizou o projeto original, servindo apenas para garantir sua participação no processo de homologação. A utilização da arquitetura MVC no projeto também resultou em vantagens óbvias. O já citado desacoplamento entre a interface e o núcleo do sistema é resultante da adoção do MVC. Em especial, a implementação do MVC através do Zend Framework, permitiu realizar uma implementação modular com as seguintes características:
  • 62. 61 Camada de modelo com mapeamento objeto-relacional: o framework • adota em sua camada de modelo a biblioteca PDO (PHP Data Objects)18, a qual permite o mapeamento automático de cada tabela do banco de dados, criando objetos a partir das tuplas nas tabelas, cujas propriedades são suas colunas. Adicionalmente, o PDO permite ainda o uso de qualquer SGBD disponível no mercado, possibilitando o desacoplamento da camada de dados com o núcleo da aplicação. Camada de visão flexível: o componente de visão do framework permite • encapsular outros frameworks específicos para visão, como o Adobe Flex19 ou o Smarty Templates20. Com isso, a aplicação poderá modernizar sucessivamente sua interface sem a necessidade de alteração no núcleo. Camada de controle modularizada em ações: os contextos da aplicação • são tratados em controladores e as funcionalidades de cada contexto são tratadas em métodos específicos chamados de ações. Com isso, qualquer alteração na regra de negócio da aplicação ou inclusão de novas funcionalidades poderão ser implementadas sem causar impactos negativos no restante da aplicação. O uso de documentação no projeto foi outra atividade que resultou em vantagens para o ciclo de vida da aplicação. Com o uso de diagramas UML e documentação de código organizada em páginas navegáveis fica mais fácil projetar alterações significativas no projeto. Por sua vez, o ingresso de novos membros no desenvolvimento é facilitado com a documentação, diminuindo a curva de aprendizado necessário ao amplo entendimento dos aspectos funcionais da aplicação. Finalmente, o uso da certificação digital no SDT On Line proporcionou a necessária segurança às operações de tráfego de dados com conteúdo sensível. Através do certificado digital para servidor com SSL se podem garantir os princípios da autenticidade, integridade e confidencialidade à informação. Enquanto não houver a necessidade de não-repúdio como requisito da aplicação, o SDT On Line poderá optar por uma AC não vinculada à ICP-Brasil, o que resulta em uma excelente relação custo-benefício para o sistema. 18 Objetos de Dados do PHP. 19 Framework para desenvolvimento de aplicações web com interfaces ricas da Adobe Systems. 20 Framework open source para camada de visão com o uso de modelos em HTML.
  • 63. 62 4.3 PERSPECTIVAS FUTURAS A partir do ano de 2009, começa a fase de evolução da aplicação para acomodar novas tecnologias ou permitir um melhor aproveitamento das já em uso. O uso de certificação digital para a autenticação de usuários é um desses melhoramentos. Pretende-se recomendar que cada usuário nas entidades envolvidas adquira seu certificado digital pessoal (e-CPF), expedido pela Receita Federal, para através de sua chave privada poder ser autenticado no SDT On Line. Para isso, a aplicação deverá passar por uma mudança no módulo de autenticação, agregando um repositório de chaves públicas para os certificados pessoais dos usuários. O autenticador deverá receber como entrada a assinatura digital do usuário e fazer a verificação de autenticidade com sua respectiva chave pública. Assim, apenas usuários devidamente credenciados através de seus certificados digitais poderão utilizar o sistema, aumentando ainda mais a segurança do sistema. Outro melhoramento previsto teve origem em uma iniciativa de uma entidade da categoria Apresentante no sistema, o Banco Itaú. Este apresentante fará uso de repositório na Web para que as operações de envio e recepção de arquivos sejam automatizadas. Na prática, o sistema de informação do apresentante gravará o arquivo, assinado digitalmente e criptografado, no seu próprio repositório público de arquivos na Web. O SDT On Line armazenará o endereço e os dados de acesso do repositório de cada entidade, assim como suas chaves públicas para o processo de decifragem e verificação da assinatura digital. Periodicamente o SDT On Line varrerá estes repositórios para fazer a retirada dos arquivos para processamento interno, dispensando assim uma operação hoje acionada por um usuário humano. O processo inverso, de gravação de um arquivo de retorno ou de movimentação, seguirá uma lógica semelhante. O sistema de informação do SDT assinará o arquivo digitalmente e o criptografará com a chave pública do destinatário, gravando-o em seguida no repositório público da entidade através do SDT On Line. Periodicamente o sistema da entidade destinatária varrerá o repositório para receber os arquivos, utilizando sua própria chave privada para a decifragem e a chave pública do SDT para validar a assinatura.
  • 64. 63 Dessa forma, o processo de envio e recepção de arquivos, além de ganhar mais segurança, ficará ainda mais ágil e livre de possíveis falhas operacionais humanas. De todas as perspectivas futuras, talvez a que cause maior expectativa seja a recomendação de uso do SDT On Line pela FEBRABAN, após a homologação, a todos os SDTs em cada estado brasileiro. Isso significaria o ápice do sucesso do projeto e estaria atestando a capacitação técnica de uma equipe de desenvolvimento paraibana e comprovando a viabilidade em se desenvolver software com qualidade na Paraíba.
  • 65. 64 5. CONCLUSÕES Analisando as diversas ameaças que pairam sobre a segurança da informação, sobretudo nas aplicações baseadas na Web, pode-se perceber que há a necessidade de se adotar uma tecnologia específica que implemente uma camada consistente de segurança para estas aplicações. A certificação digital mostrou ser a tecnologia mais adequada para prover garantias aos princípios da integridade, confidencialidade e autenticidade na troca de informações entre partes distintas. O modelo de certificação digital baseado em chaves assimétricas já está devidamente consolidado para uso em todas as modalidades de sistemas que requeiram segurança na troca de dados, particularmente os baseados na Web. Por sua vez, a análise de um estudo de caso real, o SDT On Line, fazendo uso de certificação digital em sua camada de segurança, permitiu a percepção de como, na prática, é incrivelmente simples adequar a tecnologia da certificação digital em um sistema Web. Percebeu-se, no exame do projeto, que nenhuma implementação especial, ou adaptação com grande complexidade, foi necessária para que a aplicação tivesse sua camada de segurança baseada na tecnologia da certificação digital. Assim, a compreensão de aspectos essenciais dessa tecnologia é tão somente necessária como apoio para que se possa fazer a correta tomada de decisão. Pode-se ver pela análise dos resultados de sucesso obtidos e na forma como a aplicação foi desenvolvida que, não só é viável se desenvolver uma aplicação segura baseada na Web, como este resultado está ao alcance de todos que desejarem empreender tal sistema. Este trabalho deixa como contribuição para estudos futuros, o modelo de utilização de certificação digital em uma aplicação Web. Embora não se vislumbre grandes avanços na tecnologia por detrás da certificação digital, estando a mesma bem consolidada, os interessados podem fazer novas análises em relação a como esta pode ser empregada, das mais diversas formas, para proporcionar um ambiente mais seguro para a informação.
  • 66. 65 REFERÊNCIAS BIBLIOGRÁFICAS IDENTIDADE Digital. Certisign, São Paulo, 8 ago. 2005. Disponível em: <http://www.certisign.com.br/formularios/guias/guia_formulario.jsp?guia=guia_identidadeDigi talebook>. Acesso em: 21 nov. 2005, 11:42:51. KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: Uma abordagem top-down. 3. ed. São Paulo, Pearson Addison Wesley, 2006. LIMA, Paulo Marco Ferreira. Crimes de Computador e Segurança Computacional. Campinas: Millenium Editora, 2006. MENDES, Antônio. Arquitetura de Software: desenvolvimento orientado para arquitetura. Rio de Janeiro: Editora Campus, 2002. O que é Certificação Digital? ITI, Brasília, 29 jul. 2005. Disponível em: <http://www.iti.br/twiki/bin/view/Main/Cartilhas/CertificacaoDigital.pdf>. Acesso em: 17 set. 2005, 21:58:50. OTTONI, Márcia Benedicto. Certificação Digital e Segurança. São Paulo: Certisign, 2005. SILVA, Lino Sarlo da. Public Key Infrastructure – PKI: conheça a infra-estrutura de chaves públicas e a certificação digital. São Paulo: Novatec, 2004. SILVA, Luiz Gustavo Cordeiro da, et al. Certificação Digital: Conceitos e Aplicações. Rio de Janeiro: Editora Ciência Moderna, 2008. THE Number One HTTP Server On The Internet. ASF, USA, 2008. Disponível em: <http://httpd.apache.org/>. Acesso em: 01 out. 2008, 13:44.

×