Monografia Marcos Bezerra 2008

MARCOS ANTONIO DE SOUZA BEZERRA

CERTIFICAÇÃO DIGITAL Utilização em Aplicações Web

JOÃO PESSOA 2008



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

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



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

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.

"Procure ser uma pessoa de valor, em

vez de procurar ser uma pessoa de

sucesso. O sucesso é conseqüência."

Albert Einstein

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.

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.

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

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 27 – Indicação de uso do protocolo HTTPS na conexão com o sistema ....... 58

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

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

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

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

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.

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.

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

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.

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

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.

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.

1Cracker é 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.

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

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.

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.

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

2Bit, 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.

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

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.

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.

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.

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.

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 Assinatura

Identificador do algoritmo usado para assinatura do certificado pela 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.

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.

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.

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

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.

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.

36

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 Normativo

Responsável: CG ICP-Brasil

Papéis: Definir políticas, diretrizes, normas e regras operacionais.

Características: regulador de atividades econômico produtivas, formulador de políticas com poder de normalização (órgão sistêmico), fiscalização (auditoria) e poder de polícia (fazenda pública).

Componente de Credenciamento

Responsável: AC Raiz

Papéis: Realizar credenciamento, auditorias e certificação.

Características: órgão credenciador, auditor e fiscalizador das políticas diretrizes, normas e regras (regulamentos técnicos) definidos pelo CG.

Componente Operacional

Responsáveis: ACs e ARs

Papéis: Fazer a expedição de certificados de chaves públicas e de selos digitais.

Características: Identificação, cadastramento e lançamento da base operacional da ICP-Brasil

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

AC-Raiz Comitê Gestor

COTEC

AC 1º nível AC 1º nível AC 1º nível

AC 2º nível AC 2º nível

Auditoria Independente

AR

AR

AR

AR

PSS

PSS

PSS

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.

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.

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.

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.

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;

(a)

(b)

Apresentante SDT Tabelionato

Mensageiros

SDT On Line

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; 8InnoDB é um dos módulo de armazenamento para o MySQL. Sua principal característica é oferecer transações do tipo ACID.

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.

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

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

O projeto open source Eclipse PDT (PHP Development Tools)13

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

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.

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.

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

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

segundo a arquitetura 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

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 (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 SD

Figura 15: Modelo arquitetural MVC.Fonte: MENDES, 2002, p. 132.



base o usuário é solicitado para entrar novos dados;


o núcleo da aplicação e sua interface com o usuário, optou-se pelo desenvolvimento

segundo a arquitetura Modelo-Visão-Controle, ou simplesmente MVC.



agente segundo três componentes funcionais:

Modelo: responsável pela definição da competência do agente (núcleo

Visão: responsável pela definição do comportamento perceptivo do agente

para a saída (apresentação de resultados);

Controle: responsável pela definição do comportamento perceptivo do agente

para a entrada (comandos de usuário).



funcional e sua interface, que são requisitos essenciais ao projeto SDT On Line

Figura 15: Modelo arquitetural MVC. Fonte: MENDES, 2002, p. 132.

47




se pelo desenvolvimento



ção da competência do agente (núcleo

Visão: responsável pela definição do comportamento perceptivo do agente

Controle: responsável pela definição do comportamento perceptivo do agente



On Line.

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 UsoEntidades”. Fonte: O autor.

Figura 17: Diagrama de Caso de Uso para a funcionalidade “Cadastro de Usuários”. Fonte: O autor.

3.4.3 Diagramas de Casos de Uso


principais funcionalidades do sistema.

Figura 16: Diagrama de Caso de Uso para a funcionalidade “Cadastro de


48


para a funcionalidade “Cadastro de


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.

Figura 18: Diagrama de Caso de Uso para a funcionalidade “Enviar

Figura 19: Diagrama de Caso de Uso para a funcionalidade “Receber

49

Figura 18: Diagrama de Caso de Uso para a funcionalidade “Enviar

Figura 19: Diagrama de Caso de Uso para a funcionalidade “Receber

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

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

Figura 20: Diagrama de Caso de Uso para a funcionalidade “Solicitar Retirada de Títulos”.

3.4.4 Diagrama Entidade Relacionamento (DER)

A Virtus Sistemas, empresa responsável pelo projeto SDT On Line



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

50

Figura 20: Diagrama de Caso de Uso para a funcionalidade “Solicitar

On Line, autorizou a



no qual se apresentam os atributos num maior grau de detalhamento, teve seu uso

On Line.

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.

Figura 22: Diagrama de Classes do SDT Fonte: O autor.

3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT

O ponto alto deste estudo de caso se concentra na análise de como a aplicação

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.

Figura 22: Diagrama de Classes do SDT On Line – Camada de Modelo

3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT ON LINE

to deste estudo de caso se concentra na análise de como a aplicação



52

Camada de Modelo

to deste estudo de caso se concentra na análise de como a aplicação



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.

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

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.

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.


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.

57


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.

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.

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.

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:

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.

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.

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.

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.

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

Education

Monografia Marcos Bezerra 2008