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

1. MARCOS ANTONIO DE SOUZA BEZERRA
CERTIFICAÇÃO DIGITAL
Utilização em Aplicações Web
JOÃO PESSOA
2008

2. MARCOS ANTONIO DE SOUZA BEZERRA
CERTIFICAÇÃO DIGITAL
Utilização em Aplicações Web
Trabalho de Conclusão de Curso,
apresentado ao Curso de Graduação em
Sistemas de Informação do IESP – Instituto
de Educação Superior da Paraíba, em
cumprimento às exigências para obtenção
do grau de Bacharel em Sistemas de
Informação.
Orientadora: Profª. ISLEDNA RODRIGUES DE ALMEIDA
JOÃO PESSOA
2008

3. Dados de acordo com: AACR2, CDU e Cutter
Biblioteca Central – IESP Faculdades – PB
B574c Bezerra, Marcos Antônio de Sousa
Certificação digital: utilização em aplicações Web/ Marcos
Antônio de Sousa Bezerra. – João Pessoa, PB: [s.n], 2008.
65 f.
Monografia (Graduação) – Instituto de Educação Superior
da Paraíba (IESP) - Curso de Sistemas de Informação, 2008.
1. Internet - segurança 2. Aplicações Web 3. Certificação
digital I. Título
CDU 004.7

4. MARCOS ANTONIO DE SOUZA BEZERRA
CERTIFICAÇÃO DIGITAL
Utilização em Aplicações Web
Trabalho de Conclusão de Curso,
apresentado ao Curso de Graduação em
Sistemas de Informação do IESP – Instituto
de Educação Superior da Paraíba, em
cumprimento às exigências para obtenção
do grau de Bacharel em Sistemas de
Informação.
Aprovada em 15/12/2008.
BANCA EXAMINADORA
____________________________________
Profª. Isledna Rodrigues de Almeida, M.Sc.
Orientadora
Instituto de Educação Superior da Paraíba
____________________________________
Prof. Jânio Carlos Mesquita Vieira
Instituto de Educação Superior da Paraíba
____________________________________
Prof. David dos Santos Ferreira
Instituto de Educação Superior da Paraíba

5. AGRADECIMENTOS
Agradeço a todos que de forma direta ou indireta contribuíram para que eu
alcançasse este objetivo.
Agradeço a Franklin e Fernando Lordão, da Virtus Sistemas, por terem autorizado
e compartilhado informações para a composição do estudo de caso neste trabalho.
Agradeço aos professores Isledna e Jânio, pela paciência em orientar este trabalho
e pela precisão de suas orientações, sem as quais a pesquisa não seria levada a cabo.
Agradeço de coração aos meus pais, Aloísio e Helena, que me proporcionaram uma
excelente educação e ajudaram a formar meu caráter, ambos essenciais para trilhar o
caminho do sucesso.
Agradeço de forma especial à minha esposa Joselina pelo apoio incondicional
durante a duração do curso, tendo que suportar minha constante falta de tempo para a
família.

6. quot;Procure ser uma pessoa de valor, em
vez de procurar ser uma pessoa de
sucesso. O sucesso é conseqüência.quot;
Albert Einstein

7. RESUMO
O presente trabalho faz uma análise da problemática da segurança da informação,
no âmbito da Internet, em face das excelentes perspectivas de utilização das aplicações
Web. Indo mais além, procura ainda entender como a Certificação Digital está estruturada
para prover a necessária segurança à informação, viabilizando assim a utilização de tais
aplicações. Em conclusão, realiza um estudo de caso de uma aplicação Web real, o SDT On
Line, e analisa os resultados obtidos por ela com a utilização de um certificado digital em
sua camada de segurança.
Palavras Chaves: Aplicações Web, Segurança, Certificação Digital.

8. ABSTRACT
The present paper makes an analysis over the problem of the information safety, on
Internet context, in face of the excellent perspectives to use Web applications. Going ahead,
tries to understand as the Digital Certification is structured to provide the necessary safety to
information, making possible the use of those applications. In conclusion, accomplishes a
case study from a real Web application, known as SDT On Line, and analyzes the results
obtained with the use of a digital certificate in your safety layer.
Keywords: Web Applications, Safety, Digital Certification.

9. LISTA DE SIGLAS
AC – Autoridade Certificadora
ANOREG – Associação de Notários e Registradores
AR – Autoridade de Registro
CG – Comitê Gestor
CHM – Microsoft Compiled HTML Help
COTEC – Comitê Técnico
DER – Diagrama Entidade Relacionamento
FEBRABAN – Federação Brasileira de Bancos
GPL – General Purpose Licence
HTML – HyperText Markup Language
HTTPS – HyperText Transfer Protocol over Secure Socket Layer
ICP – Infra-estrutura de Chaves Públicas
IDE – Integrated Development Environment
IP – Internet Protocol
IPSec – IP Security Protocol
LCR – Lista de Certificados Revogados
LDAP – Lightweight Directory Access Protocol
MD5 – Message-Digest Algorithm version 5
MVC – Model-View-Control
PDF – Portable Document Format
PDT – PHP Development Tools
PGP – Pretty Good Privacy
PHP – PHP: Hypertext Preprocessor (acrônimo recursivo)
PSS – Prestador de Serviços de Suporte
S/MIME – Secure Multipurpose Internet Mail Extensions
SET – Security Electronic Transaction
SDT – Serviço de Distribuição de Títulos
SGBD – Sistema Gerenciador de Banco de Dados
SHA-1 – Secure Hash Algorithm version 1
SSL – Security Socket Layer
TCP – Transfer Control Protocol
TLS – Transport Layer Security
USB – Universal Serial Bus

10. LISTA DE FIGURAS
Figura 1 – Ataque de interrupção ............................................................................. 21
Figura 2 – Ataque de interceptação .......................................................................... 22
Figura 3 – Ataque de modificação ............................................................................. 22
Figura 4 – Ataque de fabricação ............................................................................... 23
Figura 5 – Uso de chave simétrica na criptografia .................................................... 25
Figura 6 – Uso de chaves assimétricas para obter integridade e confidencialidade . 26
Figura 7 – Uso de chaves assimétricas para obter autenticidade e integridade ....... 27
Figura 8 – Resumo obtido com uma função hash ..................................................... 27
Figura 9 – Processo de assinatura digital de uma mensagem .................................. 28
Figura 10 – Processo de verificação da assinatura digital ........................................ 29
Figura 11 – Verificação de certificado revogado ....................................................... 31
Figura 12 – Estrutura hierárquica da ICP-Brasil ........................................................ 36
Figura 13 – Ciclo de vida de um título para protesto ................................................. 40
Figura 14 – Tela de autenticação de usuário do SDT On Line .................................. 45
Figura 15 – Modelo arquitetural MVC ........................................................................ 48
Figura 16 – Diagrama de Caso de Uso para a funcionalidade “Cadastro de
Entidades” ............................................................................................................... 48
Figura 17 – Diagrama de Caso de Uso para a funcionalidade “Cadastro de
Usuários”. ................................................................................................................ 49
Figura 18 – Diagrama de Caso de Uso para a funcionalidade “Enviar Arquivos”...... 49
Figura 19 – Diagrama de Caso de Uso para a funcionalidade “Receber Arquivos” .. 50
Figura 20 – Diagrama de Caso de Uso para a funcionalidade “Solicitar Retirada de
Títulos” .................................................................................................................... 50
Figura 21 – DER para o SDT On Line ....................................................................... 51
Figura 22 – Diagrama de Classes do SDT On Line – Camada de Modelo ............... 52
Figura 23 – Mídias para certificados A3 .................................................................... 54
Figura 24 – Verificação de Autenticidade – parte 1 .................................................. 56
Figura 25 – Verificação de Autenticidade – parte 2 .................................................. 56
Figura 26 – Verificação de Autenticidade – parte 3 .................................................. 57
Figura 27 – Indicação de uso do protocolo HTTPS na conexão com o sistema ....... 58

11. LISTA DE QUADROS
Quadro 1 – Lista de Certificados Revogados (LCR) ................................................. 30
Quadro 2 – Alguns mecanismos de segurança no mundo real e seus
correspondentes na ICP.......................................................................................... 32
Quadro 3 – Componentes da ICP-Brasil ................................................................... 36
Quadro 4 – Comparativo de preços entre certificados equivalentes emitidos por AC
pertencente e não pertencente à ICP-Brasil ........................................................... 53

12. SUMÁRIO
1 INTRODUÇÃO ...................................................................................................... 14
1.1 OBJETIVO GERAL ........................................................................................ 15
1.2 OBJETIVOS ESPECÍFICOS .......................................................................... 15
1.3 JUSTIFICATIVA ............................................................................................. 15
1.4 METODOLOGIA DA PESQUISA ................................................................... 16
1.5 ORGANIZAÇÃO DA MONOGRAFIA ............................................................. 16
2 SEGURANÇA DA INFORMAÇÃO ........................................................................ 18
2.1 CONCEITUAÇÃO DE SEGURANÇA DA INFORMAÇÃO............................... 18
2.2 AMEAÇAS E VULNERABILIDADES ............................................................... 19
2.2.1 Ameaças ................................................................................................ 19
2.2.2 Vulnerabilidades .................................................................................... 20
2.3 ATAQUES ....................................................................................................... 21
2.3.1 Interrupção ............................................................................................. 21
2.3.2 Interceptação ......................................................................................... 21
2.3.3 Modificação ............................................................................................ 22
2.3.4 Fabricação ............................................................................................. 23
2.4 CERTIFICAÇÃO DIGITAL............................................................................... 23
2.4.1 Criptografia ............................................................................................ 24
2.4.2 Chaves criptográficas ............................................................................ 24
2.4.2.1 Chave simétrica........................................................................ 25
2.4.2.2 Chave assimétrica .................................................................... 25
2.4.3 Algoritmo de resumo (função hash) ....................................................... 27
2.4.4 Assinatura Digital ................................................................................... 28
2.4.5 Padrão X.509 ......................................................................................... 29
2.4.6 Lista de Certificados Revogados (LCR) ................................................. 30
2.4.7 Infra-estrutura de Chaves Públicas (ICP) .............................................. 31
2.4.8 Padrões relevantes para uma ICP ......................................................... 32
2.4.8.1 LDAP ........................................................................................ 32
2.4.8.2 S/MIME .................................................................................... 33

13. 2.4.8.3 IPSec ........................................................................................ 34
2.4.8.4 SSL .......................................................................................... 34
2.4.8.5 TLS ........................................................................................... 35
2.4.9 ICP-Brasil ............................................................................................... 35
2.4.9.1 Estrutura ................................................................................... 36
2.4.9.2 Componentes da ICP-Brasil ..................................................... 37
2.5 CONSIDERAÇÕES FINAIS ............................................................................ 38
3 DESENVOLVIMENTO DA APLICAÇÃO – SDT ON LINE ...................................... 39
3.1 DEFINIÇÃO ..................................................................................................... 39
3.2 FUNCIONALIDADE ........................................................................................ 40
3.3 METODOLOGIA DE DESENVOLVIMENTO ................................................... 41
3.3.1 Sistema Gerenciador de Banco de Dados (SGBD) MySQL .................. 41
3.3.2 Linguagem de programação PHP .......................................................... 42
3.3.3 Servidor de criptografia OpenSSL ......................................................... 42
3.3.4 Servidor Web Apache ............................................................................ 42
3.3.5 Modelador gráfico JUDE/Community ..................................................... 43
3.3.6 Documentador de código PHPDocumentor ........................................... 43
3.3.7 Ambiente de Desenvolvimento Integrado (IDE) Eclipse PDT ................ 44
3.4 A APLICAÇÃO ................................................................................................ 44
3.4.1 Requisitos .............................................................................................. 45
3.4.1.1 Requisitos não-funcionais ........................................................ 46
3.4.1.2 Requisitos de domínio .............................................................. 46
3.4.1.3 Requisitos funcionais ............................................................... 46
3.4.2 Arquitetura ............................................................................................. 47
3.4.3 Diagramas de Caso de Uso ................................................................... 48
3.4.4 Diagrama Entidade Relacionamento (DER) .......................................... 51
3.4.5 Diagrama de Classes – Camada de Modelo ......................................... 52
3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT ON LINE .................................. 53
3.5.1 Autoridade Certificadora escolhida ........................................................ 53
3.5.2 Tipo de certificado adotado .................................................................... 54
3.5.3 Verificação de autenticidade do Website ............................................... 55
3.5.4 Transmissão segura de dados com SSL ............................................... 58

14. 3.6 CONSIDERAÇÕES FINAIS ............................................................................ 58
4 ANALISE DE RESULTADOS ................................................................................. 59
4.1 RESULTADOS OPERACIONAIS.................................................................... 59
4.2 RESULTADOS TÉCNICOS ............................................................................ 60
4.3 PERSPECTIVAS FUTURAS ........................................................................... 62
5 CONCLUSÕES ...................................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 65

15. 14
1 INTRODUÇÃO
Uma aplicação Web consiste em um serviço baseado em software e banco de
dados, operando num servidor Web, e que provê aos seus clientes uma variedade de
operações envolvendo a troca de mensagens e documentos pelo meio eletrônico. Tais
aplicações podem ser vulneráveis a ataques que visam comprometer a segurança das
informações transacionadas.
Os ataques que visam aplicações Web podem ser de quatro tipos: interrupção,
interceptação, modificação e fabricação (SILVA, 2004). Estes podem ocasionar a perda da
disponibilidade, confidencialidade e integridade das informações. Ao passo que a
disponibilidade da informação é assegurada por outros meios, sua confidencialidade e
integridade podem advir da adoção de um Certificado Digital.
O Certificado Digital é um documento eletrônico, assinado digitalmente por uma
terceira parte confiável, que associa uma entidade (pessoa, processo, servidor) a uma
chave pública (ITI, 2005). Segundo Silva et al (2008, p. 25), um Certificado Digital é a versão
digital de um documento de identidade e pode ser utilizado, dentre várias situações, para
dar autenticidade a programas na Internet.
Uma aplicação Web sob a proteção de um Certificado Digital poderá assegurar ao
usuário do serviço a sua autenticidade através de uma simples verificação dos dados
relacionados à entidade, acessíveis por qualquer navegador de Internet. Ademais, o
certificado proverá à aplicação um canal criptografado para a troca de mensagens e
documentos entre o usuário e o provedor do serviço, assegurando assim a integridade da
informação.

16. 15
1.1 OBJETIVO GERAL
Descrever o funcionamento lógico dos processos envolvidos na Certificação Digital e
explicar como estes dão segurança às aplicações Web que deles se utilizam.
1.2 OBJETIVOS ESPECÍFICOS
Relatar os tipos de processos utilizados na Certificação Digital e apontar suas
•
características mais relevantes.
Demonstrar como aplicações Web podem utilizar a Certificação Digital para
•
garantir os princípios da autenticidade, confidencialidade e integridade aos seus
usuários.
1.3 JUSTIFICATIVA
Com o desenvolvimento da arquitetura cliente-servidor, cada vez mais
computadores em rede vêm sendo largamente utilizados como meios para o processamento
de dados e para a troca de mensagens e documentos entre usuários finais e provedores de
serviços. Nesse sentido, as aplicações Web têm surgido como um meio eficaz de prover
transações eletrônicas com agilidade e grande comodidade.
Porém, devido à crescente ameaça de ações criminosas que utilizam o meio
eletrônico para serem aplicadas, estas transações necessitam da adoção de mecanismos
de segurança capazes de garantir sua autenticidade, confiabilidade e integridade. A
Certificação Digital é uma das tecnologias que se propõem a prover estes mecanismos.

17. 16
Dentre os inúmeros benefícios de se adotar a Certificação Digital em aplicações
Web, destaca-se a viabilização do uso da Internet como meio seguro de comunicação para
que diversos serviços essenciais sejam disponibilizados, resultando em maior agilidade,
facilidade de acesso e grande redução de custos.
Com a Certificação Digital o relacionamento entre as partes fica mais seguro. Os
usuários podem assinar e trocar seus documentos eletrônicos com a garantia de que não
haverá violação, adulteração e repúdio. Assim, o documento eletrônico certificado poderá ter
o reconhecimento e a validade de um documento real, passível de todos os direitos e
obrigações jurídicas.
1.4 METODOLOGIA DA PESQUISA
Através de uma pesquisa bibliográfica, pôde-se explicar os conceitos essenciais na
segurança da informação e os processos envolvidos na Certificação Digital e, por meio da
análise de uma aplicação Web, pôde-se demonstrar uma de suas aplicações práticas. A
pesquisa foi feita em livros, publicados tanto no formato impresso quanto no formato
eletrônico (e-book), e através da interação com a aplicação Web SDT On-line, disponível
em <http://www.sdtpe.com.br>. A técnica de coleta de dados foi a observação indireta,
utilizando-se a leitura compreensiva das publicações pesquisadas, e a observação direta,
por meio do estudo de caso da aplicação Web analisada.
1.5 ORGANIZAÇÃO DA MONOGRAFIA
Esta monografia é composta por cinco capítulos e está dividida da seguinte forma:
O Capítulo 1 fornece uma visão geral do trabalho de pesquisa.
O Capítulo 2 trata do referencial teórico, em que são discutidos os conceitos mais
relevantes referentes à problemática da segurança da informação na Internet e à tecnologia

18. 17
da Certificação Digital, que se estrutura como mecanismo adequado para o provimento de
segurança à informação.
O Capítulo 3 apresenta um estudo de caso sobre a aplicação Web SDT On Line,
enfocando sua utilização de certificação digital para prover uma camada de segurança às
informações transacionadas pelo sistema.
O Capítulo 4 discute a análise de resultados do ponto-de-vista da aplicação,
destacando os resultados funcionais alcançados conforme idealizado em projeto.
O Capítulo 5 discute as conclusões do autor quanto aos objetivos da pesquisa e
traça uma perspectiva futura para o caso estudado quanto a novas utilizações da
certificação digital para a aplicação SDT On Line.

19. 18
2 SEGURANÇA DA INFORMAÇÃO
A falta de segurança da informação, em particular na Internet, tem levantado
suspeitas quanto aos benefícios de se abraçar o meio digital como substituto viável às
relações rotineiras de trabalho e negócios. Lima (2005, p. 4) explica que, ao se intensificar o
relacionamento humano por meios digitais, ocorre o favorecimento das atividades lícitas,
“trazendo também, por óbvio, novas condutas ilícitas”.
Concordemente, Ottoni (2005, p. 3) afirma que, “pelas mesmas razões e na exata
proporção” em que a Internet e o mundo digital trazem facilidade, introduzem também o
risco e a insegurança. Adicionalmente, declara que “o meio eletrônico é instável e
vulnerável, e tem se mostrado um ambiente favorável para fraude e outros crimes afetos”.
Essas afirmações têm se mostrado verdadeiras na medida em que surgem inúmeros relatos
acerca de crimes cometidos através do meio eletrônico.
Entretanto, não seria sensato pensar em abrir mão das facilidades advindas do uso
correto da tecnologia da informação e do meio Internet. Afinal, como observa Lima (2006, p.
23), “não é o computador em si perverso, trata-se apenas de uma ferramenta [...] que pode
vir a facilitar o cometimento de um crime”. Com isso em mente, adotar medidas que
diminuam as ameaças e proporcionem maior segurança constitui um proceder adequado a
ser levado em conta.
É necessário, portanto, compreender a relação existente entre vulnerabilidades,
ataques e prevenção às ameaças que rondam a informação nos dias atuais, estabelecendo
assim o ponto de partida para o usufruto das facilidades tecnológicas com ampla segurança.
2.1 CONCEITUAÇÃO DE SEGURANÇA DA INFORMAÇÃO
“Desde que se vejam atendidos a três requisitos: confidencialidade, integridade e
disponibilidade, poderá se entender estar diante de uma máquina apta a desenvolver uma
atividade segura.” (LIMA, 2006).
“O objetivo da segurança da informação é proteger a organização detentora da
informação dos diversos tipos de ameaças para garantir a continuidade dos seus negócios.”
(SILVA et al, 2008).

20. 19
“Confidencialidade, autenticação, integridade e não-repudiação de mensagem vêm
sendo considerados componentes fundamentais da comunicação segura há bastante
tempo.” (MCCUMBER, 1991, apud KUROSE; ROSS, 2006, p. 514).
A segurança da informação compõe-se de cinco premissas fundamentais:
confidencialidade, integridade, disponibilidade, autenticidade e não-repúdio.
A confidencialidade visa garantir que a informação seja acessível somente por
quem tiver autorização para isso. Já a integridade procurar assegurar que a informação não
seja adulterada durante uma transmissão entre duas partes. O funcionamento contínuo e
com bom desempenho do sistema é a preocupação da disponibilidade. A autenticidade
atesta a identidade de quem produz a informação. Por último, o não-repúdio evita que uma
das partes na comunicação negue a autoria da informação por ele produzida.
2.2 AMEAÇAS E VULNERABILIDADES
Para poder conquistar um ambiente relativamente seguro na Web é mister que se
esteja totalmente a par das ameaças à segurança da informação, assim como as
vulnerabilidades que representam riscos à mesma. As seções seguintes explanam estes
dois conceitos fundamentais.
2.2.1 Ameaças
Ameaça à segurança da informação é toda atividade que possa infringir qualquer um
dos princípios básicos da segurança da informação: disponibilidade, autenticidade e
integridade.
“Uma ameaça pode ser iniciada por uma pessoa, programa de computador,
desastre natural, acidente ou até mesmo uma idéia que represente algum perigo a uma
propriedade.” (SILVA et al, 2008, p. 3).
Ainda segundo Silva et al (2008, p. 3), as ameaças podem assumir as seguintes
características:
Intencionais ou acidentais;
•
Externas ou internas;
•
Ativas ou passivas.
•

21. 20
Ameaças intencionais ocorrem quando o sistema de informação sofre a ação
deliberada de um agente, interno ou externo, com a intenção de que o mesmo falhe em sua
segurança. Exemplo: inserção de um erro no código do sistema.
Ameaças acidentais ocorrem quando o sistema de informação sofre a ação
imprevista de um agente, geralmente externo, causando uma falha desintencional em sua
segurança. Exemplo: desastre natural.
Quando a ameaça provém de um agente externo ao sistema de informação,
sempre de forma intencional, é caracterizada a ameaça externa. Exemplo: invasão de
sistemas por crackers1.
Quando a ameaça provém de um agente interno ao sistema de informação, de
forma intencional ou não, caracteriza-se a ameaça interna. Exemplo: falha desconhecida do
sistema.
Ameaça ativa é quando a ameaça tem como objetivo impedir a operação do
sistema ou modificar sua funcionalidade e/ou informações contidas nele. Exemplo: pichação
de sítios na Internet (Websites).
Ameaça passiva é quando a ameaça tem como objetivo espionar as atividades de
um sistema e até mesmo interceptar informações importantes. Exemplo: captura de senhas
bancárias.
2.2.2 Vulnerabilidades
Vulnerabilidades são caracterizadas por falhas, ou pontos fracos, na segurança da
informação. Através destas, pessoas ou sistemas mal intencionados podem lançar ataques
contra sistemas inseguros e assim se apropriar indevidamente, corromper ou tornar
indisponível a informação sob sua guarda.
1
Cracker é o termo universalmente utilizado para designar um usuário avançado de computador com
atitudes antiéticas, que usa seus conhecimentos com o propósito de invadir sistemas vulneráveis,
causando-lhes danos diversos.

22. 21
Segundo Silva (2004, p. 90), as vulnerabilidades podem advir dos seguintes fatores,
individualmente ou combinados entre si:
Ausência de uma política de segurança;
•
Sistemas desatualizados em relação a falhas amplamente conhecidas;
•
Gestão inadequada dos softwares e dispositivos existentes praticados por
•
pessoas sem o conhecimento necessário para tal.
2.3 ATAQUES
Silva (2004, pp. 87-90) descreve quatro abordagens básicas para os ataques
atualmente praticados contra a segurança da informação: interrupção, interceptação,
modificação e fabricação.
2.3.1 Interrupção
Neste ataque não se pretende interceptar nenhuma informação para fins escusos.
Antes, seu propósito é meramente prejudicar a comunicação entre as partes interessadas
pela informação. A Figura 1 esquematiza este ataque.
Figura 1: Ataque de interrupção.
Fonte: O autor.
2.3.2 Interceptação
A interceptação é considerada um dos ataques mais perigosos na transação entre
as partes interessadas na informação. Isso de deve ao fato de: [1] não se saber qual é a

23. 22
intenção do atacante e [2] é um ataque de difícil detecção, uma vez que o atacante não
demonstra nenhuma ação durante a escuta. A Figura 2 ilustra o ataque.
Figura 2: Ataque de interceptação.
Fonte: O autor.
2.3.3 Modificação
Esse tipo de ataque visa especificamente um benefício financeiro do atacante ou
um prejuízo à idoneidade da informação. Por exemplo, uma informação irreal poderá ser
propagada e assim induzir ao erro a todos que a obtiverem posteriormente, ocasionando
danos de grandes proporções. A Figura 3 representa este ataque.
Figura 3: Ataque de modificação.
Fonte: O autor.

24. 23
2.3.4 Fabricação
Neste tipo, o atacante se faz passar por um usuário autêntico, forjando uma
informação em seu nome, na tentativa de enganar o ponto de destino da informação.
Geralmente tem por objetivo o benefício financeiro. A Figura 4 caracteriza este ataque.
Figura 4: Ataque de fabricação.
Fonte: O autor.
2.4 CERTIFICAÇÃO DIGITAL
“Certificação Digital é uma tecnologia de segurança para as relações eletrônicas,
que provê um sistema de identificação de pessoas e entidades no meio eletrônico, que
combate o anonimato, a despersonalização e a insegurança em relação ao interlocutor.”
(OTTONI, 2005, p. 4).
“[...] De uma forma genérica, [...] um certificado digital é a versão digital de um
documento de identidade.” (SILVA et al, 2008, p. 25).
“Trata-se de um mecanismo para identificação de um indivíduo ou empresa na
Internet. Ela dá validade jurídica a documentos enviados por e-mail e nas transações feitas
pela rede.” (LIMA, 2006, p. 119).
A Certificação Digital é uma das ferramentas que se propõem a solucionar os
problemas de ataques à segurança da informação, especialmente no que concerne à sua
integridade, autenticidade e confidencialidade.

25. 24
Entender os conceitos-chave que envolvem esta tecnologia e de que forma se dá a
sua utilização prática é o ponto de partida para se usufruir com segurança das facilidades
oferecidas pelo meio digital durante as transações eletrônicas.
2.4.1 Criptografia
Para Silva (2004, p. 43), “Criptografia é o estudo de códigos e cifras, cujo nome
vem do grego kryptos, que significa oculto, e graphen, que significa escrever. Já a palavra
cifra vem do hebraico saphar, que significa dar números. [Negritos e itálicos do autor]”.
A criptografia vem sendo usada desde tempos antigos, geralmente em associação
com fins militares, tendo sido utilizada de várias formas até chegar aos modernos algoritmos
criptográficos utilizados na certificação digital.
Para a criptografia moderna, mais importante que o próprio algoritmo utilizado está
o emprego da chave de criptografia. Dois tipos de chaves se tornaram amplamente
utilizadas: chaves simétricas e assimétricas.
2.4.2 Chaves criptográficas
Segundo Silva et al (2008, p. 15), a chave criptográfica é um valor matemático
determinante para produzir um texto cifrado a partir de um texto pleno. A posse da chave é
obrigatória para decifrar a mensagem e assim recuperar o texto original.
O tamanho de uma chave é definido pelo número de bits2 necessários para seu
armazenamento. Já o espaço de chaves de uma chave é o conjunto de todos os possíveis
valores matemáticos que têm o mesmo tamanho, em bits, desta chave. “Em geral uma
chave de tamanho de n bits gera um espaço de chaves de 2n valores distintos.” (SILVA et
al, 2008, p. 15).
2
Bit, acrônimo originário do Inglês Binary Digit, representa a menor unidade de medida para designar
capacidade de armazenamento de dados na forma digital.

26. 25
2.4.2.1 Chave simétrica
Também conhecida como chave secreta, é compartilhada pelos dois pontos na
comunicação. O destinatário deverá saber qual chave deverá utilizar para decifrar a
informação e retorná-la ao seu estado original. A Figura 5 ilustra o uso de uma chave
simétrica.
Figura 5: Uso de chave simétrica na criptografia
Fonte: ITI, 2005, p. 2, com intervenção do autor.
“A grande vantagem neste tipo de chave é sua velocidade em relação à chave
assimétrica.” (SILVA, 2004, p. 45). Como ponto fraco, pode-se destacar “a necessidade
constante da troca da chave secreta, dificuldade para gerenciar grandes quantidades de
chaves em larga escala e dificuldade para iniciar uma comunicação segura entre entidades
desconhecidas.” (SILVA, 2004, p. 47).
2.4.2.2 Chave assimétrica
Popularmente conhecida como chave pública, na chave assimétrica o segredo é
dividido em duas partes relacionadas matematicamente. Daí, a parte pública da chave é
distribuída livremente para todas as entidades interessadas em utilizá-la, enquanto a parte

27. 26
privada da chave ficará guardada em segredo por seu titular, normalmente sob a proteção
de uma chave simétrica.
A criptografia por chaves assimétricas são adequadas para prover às partes a
devida medida de segurança para os princípios de confidencialidade, integridade e
autenticidade, favorecendo ainda o não-repúdio, conforme é visto na seção 2.4.4.
Numa primeira utilização para as chaves assimétricas, supõe-se uma entidade
qualquer que deseja enviar uma informação sigilosa para a entidade de nome Beto. Além da
garantia de que apenas Beto lerá a mensagem, a entidade remetente deseja ainda que ela
não seja adulterada num eventual ataque. Conforme pode ser entendido na Figura 6, o uso
das chaves assimétricas de Beto pode garantir a essa mensagem a integridade e
confidencialidade da informação.
Figura 6: Uso de chaves assimétricas para obter integridade e
confidencialidade.
Fonte: ITI, 2005, p. 4.
Numa outra utilização para as chaves assimétricas, supõe-se uma entidade de
nome Alice que deseja disponibilizar publicamente uma informação de sua autoria. Além de
garantir que a informação não será alterada, Alice deseja que todos reconheçam a
informação como sendo autenticamente sua. Observa-se, na Figura 7, como o uso de
chaves assimétricas de Alice provê integridade e autenticidade à informação.

28. 27
Figura 7: Uso de chaves assimétricas para obter autenticidade e
integridade.
Fonte: ITI, 2005, p. 5.
2.4.3 Algoritmo de resumo (função hash)
“Um algoritmo de resumo recebe uma entrada de tamanho variável e produz como
resultado uma saída de tamanho fixo.” (SILVA et al, 2008, p.20). Essa saída de tamanho fixo
é conhecida como resumo ou hash.
Silva et al (2008, p. 20) alista três propriedades para caracterizar o resumo como
seguro no sentido de criptografia:
1. Deve ser computacionalmente inviável reconstruir a mensagem de
entrada a partir de seu resumo;
2. Não deve existir uma mensagem particular que tenha um resumo
específico (previsível);
3. Não deve haver duas mensagens distintas com resumos iguais.
Dois tipos de função hash são comumente utilizados: o MD5 (Message-Digest
algorithm 5), um algoritmo unidirecional de 128 bits e o SHA-1(Secure Hash Algorithm),
também um algoritmo unidirecional, mas com 160 bits. A Figura 8 exemplifica a obtenção de
um resumo a partir da entrada de um documento numa função hash SHA-1.
Figura 8: Resumo obtido com uma função hash.
Fonte: ITI, 2005, p. 6, com intervenção do autor.

29. 28
2.4.4 Assinatura Digital
“O mesmo método de autenticação dos algoritmos de criptografia de chave pública
operando em conjunto com uma função resumo, também conhecido como função de hash, é
chamada de assinatura digital.” (ITI, 2005, p. 6). A Figura 9 descreve o processo de
assinatura digital de uma mensagem.
Figura 9: Processo de assinatura digital de uma mensagem.
Fonte: ITI, 2005, p. 6.
Num exemplo de utilização de assinatura digital, supõe-se que a entidade Alice
queira enviar uma mensagem a outra entidade e, embora a mensagem não seja sigilosa,
esta queira a garantia de não-repúdio de Alice.
Tudo começa com a obtenção de um resumo criptográfico da mensagem,
utilizando-se uma função hash. Em seguida, Alice utilizará a parte privada de sua chave
assimétrica sobre o resumo e obterá assim sua assinatura digital para a mensagem, sendo
esta anexada à mensagem original antes do envio ao destinatário.
Ao receber a mensagem assinada digitalmente, o destinatário usará a parte pública
da chave assimétrica de Alice como chave de verificação. Com ela é possível verificar a
origem da mensagem e garantir sua integridade. Como o destinatário apenas poderá
verificar a assinatura e não forjá-la, Alice não poderá repudiar o fato de que assinou a
mensagem.
A Figura 10 descreve o processo de verificação da assinatura digital. Caso o
resumo obtido com a chave pública de Alice, a partir de sua assinatura digital anexada, seja
idêntico ao resumo obtido da própria mensagem, estarão assegurados a integridade e o
não-repúdio.

30. 29
Figura 10: Processo de verificação da assinatura digital.
Fonte: ITI, 2005, p. 7.
As razões para se assinar apenas o resumo e não o documento inteiro tem a ver
com o custo computacional do processo. Como os algoritmos de criptografia assimétrica são
lentos, seu desempenho comprometeria a viabilidade do processo.
Obter a assinatura a partir do resumo é rápido e também seguro. A alteração de um
único bit na mensagem original acarretaria na obtenção de um resumo diferente e este não
coincidiria com o resumo obtido a partir da assinatura anexada.
2.4.5 Padrão X.509
Embora existam diversos padrões de certificados digitais no mercado, tais como
SPKI/SDSI, PGP e SET, a pesquisa desta monografia destaca o padrão X.509, atualmente
na versão 3, pelo fato do mesmo ter sido amplamente adotado pela Infra-estrutura de
Chaves Públicas (ICP) em todo o mundo.
Segundo Silva (2004, p. 145) a “evolução do padrão X.509 procurou adaptar sua
estrutura de dados originais para acomodar as necessidades básicas de transporte das
ICPs, demandadas pelas distintas aplicações sobre TCP/IP3 com requisitos de
funcionalidade criptográfica.”
Dessa forma, tornou-se possível a utilização de certificação digital em uma rede
aberta hierarquicamente, como é o caso da Internet. No Quadro 1 estão descritos os
campos de um certificado no padrão X.509 versão 3.
3
Na arquitetura de uma rede de computadores sob o modelo OSI, TCP é um dos protocolos
utilizados na camada de transporte e IP é o protocolo de endereçamento da camada de rede.

31. 30
NOME DO CAMPO DESCRIÇÃO
Versão Número da versão X.509 do certificado, tendo como valor válido apenas 1,
2 ou 3.
Número de série Identificador único do certificado e representado por um inteiro. Não deve
haver mais de um certificado emitido com o mesmo número de série por
uma mesma autoridade certificadora.
Algoritmo de Identificador do algoritmo usado para assinatura do certificado pela
Assinatura autoridade certificadora.
Emissor Nome da autoridade certificadora que produziu e assinou o certificado.
Período de Validade Intervalo de tempo de duração que determina quando um certificado deve
ser considerado válido pelas aplicações.
Assunto Identifica o dono da chave pública do certificado. O assunto deve ser único
para cada assunto no certificado emitido por uma autoridade certificadora.
Chave Pública Contém o valor da chave pública do certificado junto com informações de
algoritmos com o qual a chave deve ser usada.
ID Único de Emissor Campo opcional para permitir o reuso de um emissor com o tempo.
ID Único de Assunto Campo opcional para permitir o reuso de um assunto com o tempo.
Extensões Campos complementares com informações adicionais personalizadas.
Quadro 1: Descrição dos campos de um certificado no formato X.509 v3.
Fonte: SILVA et al, 2008, p.28.
2.4.6 Lista de Certificados Revogados (LCR)
Silva et al (2008, p. 29) explicam que, conforme visto na Tabela 1, um certificado no
padrão X.509 possui um período de validade estabelecido pela autoridade certificadora que
o emitiu. Durante a vigência deste, todas as entidades e aplicações em rede devem aceitá-
lo. Ao término de sua vigência o certificado é expirado e se torna inválido.
Porém, existem situações em que um certificado precisa ser revogado antes de sua
expiração normal. Dentre elas, “podem ocorrer, por exemplo, o vazamento de chave privada
ou mudança de dados do dono do certificado.” (SILVA et al, 2008, p. 29). A revogação de
um certificado é de extrema relevância para se manter a confiabilidade no sistema de
certificação digital.
Segundo Silva (2004, p. 202), o método mais conhecido para fazer a revogação de
um certificado é a publicação periódica na Lista de Certificados Revogados (LCR). “A
Autoridade Certificadora (AC) tem a responsabilidade de preencher o repositório de
certificados revogados e cabe aos usuários consultar esse repositório para validar um
certificado recebido.” A Figura 11 esquematiza a verificação de certificado revogado.

32. 31
Figura 11: Verificação de certificado revogado.
Fonte: O autor.
2.4.7 Infra-estrutura de Chaves Públicas (ICP)
“A infra-estrutura de chave pública é uma arquitetura de confiabilidade que as
empresas podem especificar para suas redes corporativas e políticas de segurança. Ela
possibilita transações via Internet tão seguras quanto negócios entre pessoas.” (SILVA,
2004, p. 23).
Destacando seu caráter de fé pública, Silva (2004, p. 25) comenta que com uma
ICP é “possível identificar e confiar em um usuário Internet, que pode ser outra pessoa, uma
estação de trabalho ou qualquer outra entidade eletrônica”. Dessa forma, é possível “fazer
uma réplica ou até mesmo aperfeiçoar os mecanismos usados para assegurar a segurança
no mundo real.” (SILVA, 2004, p. 22).
Com base nas considerações de Silva (2004, pp. 22-24), o Quadro 2 relaciona
alguns mecanismos de segurança do mundo real e seus correspondentes viabilizados pela
ICP.

33. 32
MUNDO REAL EQUIVALENTE NA ICP
Envelopes e firmas de envio seguro. Criptografia de dados.
Assinaturas físicas e selos de autenticação. Assinaturas digitais.
Documentos de identificação. Ex.: CPF, CNPJ. Equivalentes emitidos digitalmente: e-CPF, e-
CNPJ.
Fé pública por meio de tabelionatos. Fé pública por meio de Autoridades
Certificadoras (Veja a seção 2.4.9.4).
Prova testemunhal em documentos. Não-repúdio de assinaturas digitais.
Operações financeiras presenciais. Operações financeiras on-line com identificação
do usuário através de sua chave privada.
Quadro 2: Alguns mecanismos de segurança do mundo real e seus correspondentes na
ICP.
Fonte: SILVA, 2004, p.22-24, compilação do autor.
Para uma ICP ser vista como organismo de confiabilidade não basta apenas dispor
de tecnologia apropriada. Conforme é visto na seção 2.4.9.1, também deve possuir uma
estrutura hierárquica, apoiada por legislação regulamentadora específica e legitimada pelo
Governo Federal para que receba o status de fé pública.
2.4.8 Padrões relevantes para uma ICP
Os padrões analisados nesta seção não estão necessariamente correlacionados
entre si. Individualmente possuem relevância no incremento da segurança a operações
eletrônicas específicas sob a arquitetura da ICP.
Por exemplo, o LDAP (Lightweight Directory Access Protocol)4 “serve para
disponibilizar os certificados digitais dentro de uma estrutura amigável para consulta”, o
IPSec5 “tem como função formar Redes Virtuais Privadas”, “o S/MIME (Secure Multipurpose
Internet Mail Extensions)6 é um padrão seguro para envio e recebimento de e-mail” e o
SSL/TLS (Security Socket Layer / Transport Layer Security)7 provêm “segurança durante a
transmissão de dados importantes.” (SILVA, 2004, pp. 213, 235).
2.4.8.1 LDAP
O LDAP “é uma definição de protocolo para acesso a bancos de dados
especializados chamados diretórios.” (SILVA, 2004, p. 213). Silva (2004, p. 214) define
4
Protocolo de Acesso Leve a Diretório.
5
Protocolo de Internet Seguro
6
Extensões Seguras de Multipropósito para Correio de Internet.
7
SSL: Camada de Segurança para Soquetes; TLS: Camada de Transporte Seguro.

34. 33
diretório basicamente como “qualquer banco de dados mais especializado em leitura que
escrita.”
O LDAP foi projetado para permitir a unificação de diretórios, resolvendo os
problemas decorrentes de sua proliferação pela rede. Os seguintes benefícios são
apontados por Silva (2004, p. 215) como resultantes dessa unificação:
Normalização de dados;
•
Administração central;
•
Experiência do usuário consistente;
•
Gerenciamento e políticas de segurança consistentes;
•
Menos problemas de segurança;
•
Menos tempo de desenvolvimento desperdiçado.
•
Na ICP, o LDAP é utilizado para armazenar os certificados de usuários, certificados
de Autoridades Certificadoras (ACs) e listas de certificados revogados (LCRs). Estas
informações requerem um elevado grau de disponibilidade para que o diretório seja
caracterizado como repositório público, ou seja, um banco de dados centralizado que dispõe
a informação sempre que é demandado. Graças ao LDAP isso se torna possível.
2.4.8.2 S/MIME
O S/MIME “é um protocolo para trocas de informações com privacidade em e-mail.”
(SILVA, 2004, 218). Este protocolo geralmente vem embutido em aplicativos clientes de
correio eletrônico, dispensando quaisquer instalações adicionais para sua utilização.
O S/MIME é especialmente útil ao se prevenir ataques de interceptação e
fabricação. Conforme explica Silva (2004, p. 220), sua metodologia consiste em primeiro
aplicar uma assinatura digital à mensagem, em seguida enviando tanto a mensagem quanto
a assinatura embutidas num envelope digital. Como a assinatura não poderá ser
reproduzida por um interceptador, têm-se a garantia da autenticidade do remetente e
durante a verificação da assinatura pode-se conferir se a mensagem manteve sua
integridade.
Embora o S/MIME seja um padrão importante para uma ICP, sua utilização não
requer a presença de uma Autoridade Certificadora (AC). Isso permite sua livre utilização

35. 34
por qualquer usuário, inclusive com a adoção de certificados gratuitos para e-mail, como os
distribuídos pela Thawte (http://www.thawte.com).
2.4.8.3 IPSec
O “IPSec é um conjunto de protocolos que define a arquitetura e as especificações
para prover serviços de segurança dentro do protocolo IP.” (SILVA, 2004, p. 220). Os
serviços de segurança definidos no IPSec incluem tráfego de dados, autenticação de
cabeçalho, encapsulamento seguro do dado e procedimentos e protocolos de gerência de
chaves.
A análise de todas as particularidades que compõem o conjunto de serviços do
IPSec merece uma pesquisa à parte. Na análise de seu uso, no contexto de uma ICP, é
importante saber que o IPSec supre a demanda de segurança do protocolo IP, tanto em sua
versão 4 (IPv4) quanto em sua versão 6 (IPv6).
2.4.8.4 SSL
“O SSL é um protocolo de segurança” utilizado “durante a transmissão de dados
importantes.” Ele “fornece criptografia de dados, autenticação de cliente e servidor e
integridade de mensagem para transmissão de dados pela Internet.” (SILVA, 2004, p. 235).
Amplamente utilizado em Websites que efetuam comércio eletrônico na rede, o SSL
é suportado pela maioria dos navegadores de Internet e sua presença pode ser constatada
pela indicação de um ícone, representando um cadeado de segurança, através do qual se
pode obter informações acerca do certificado digital utilizado.
Silva (2004, p. 235) descreve a metodologia para o estabelecimento de
comunicação segura, com SSL, entre o servidor e um navegador Web:
Quando o browser, lado cliente, conecta-se a uma página protegida por SSL, o
servidor do SSL envia uma solicitação para iniciar a sessão segura. Se o browser
suporta SSL, ele retorna uma resposta. Durante esse handshake inicial, o servidor e o
browser trocam informações seguras. A resposta do browser define um número único
para identificar a sessão, os algoritmos de criptografia e os métodos de compactação
que suporta.

36. 35
Nas informações de segurança fornecidas pelo browser, o servidor faz sua seleção e
a comunica ao browser. O servidor e o browser, em seguida, trocam certificados
digitais. O servidor também especifica uma chave pública, chave de sessão,
apropriada para o algoritmo de criptografia anteriormente selecionado.
O browser pode, então, usar a chave pública para criptografar informações enviadas
ao servidor, e o servidor pode usar sua chave privada para descriptografar essas
mensagens. Depois que o servidor e o browser estiverem de acordo sobre a
organização da segurança, as informações poderão ser transmitidas entre os dois,
em um modo seguro.
2.4.8.5 TLS
TLS é “um protocolo para proteção de conexões entre aplicações na Internet”
semelhantes à proporcionada pelo SSL versão 3. Entretanto, uma significativa diferença do
TLS em relação ao SSL é que este é um protocolo proprietário, patenteado pela Netscape,
enquanto aquele é uma iniciativa não-proprietária.
2.4.9 ICP-Brasil
“O Brasil adotou a tecnologia de certificação digital implementando uma infra-
estrutura de chaves públicas hierarquizada, fortemente centralizada e vinculada ao Governo
Federal, a ICP-Brasil.” (OTTONI, 2005, p. 14).
Silva et al (2008, p.79) registra sua criação:
A ICP-Brasil foi instituída pela Medida Provisória 2.200-2, de 24 de agosto de 2001,
que cria o Comitê Gestor da ICP-Brasil, a Autoridade Certificadora Raiz Brasileira e
define as demais entidades que compõem a estrutura. A partir dessa medida foram
elaborados os regulamentos que passaram a reger as atividades das entidades
integrantes da ICP-Brasil, chamados de resoluções do Comitê Gestor da ICP-Brasil.
Para Ottoni (2005, p. 15), “nos termos de seu artigo art. 1º, a finalidade da Medida
Provisória é garantir a autenticidade, integridade e validade jurídica dos documentos e
aplicações que utilizem certificados digitais”. A validade jurídica proporcionada pela ICP-
Brasil se torna o maior argumento em apoio à adoção de um certificado digital originário de
seu âmbito. Para entender como isso ocorre é importante analisar sua estrutura hierárquica.
2.4.9.1 Estrutura
A Figura 12 retrata a estrutura simplificada da ICP-Brasil.

37. 36
Comitê Gestor AC-Raiz
COTEC
PSS
AC 1º nível AC 1º nível
AC 1º nível
AR PSS
AR
PSS
AC 2º nível AC 2º nível AR
AR
Auditoria Independente
Figura12: Estrutura hierárquica da ICP-Brasil.
Fonte: SILVA, 2008, p.82.
O Quadro 3 apresenta uma visão macro dos componentes da ICP-Brasil.
Componente Papéis: Definir políticas, diretrizes, normas e regras operacionais.
Normativo
Características: regulador de atividades econômico produtivas, formulador
Responsável: de políticas com poder de normalização (órgão sistêmico), fiscalização
CG ICP-Brasil (auditoria) e poder de polícia (fazenda pública).
Componente de Papéis: Realizar credenciamento, auditorias e certificação.
Credenciamento
Características: órgão credenciador, auditor e fiscalizador das políticas
Responsável: diretrizes, normas e regras (regulamentos técnicos) definidos pelo CG.
AC Raiz
Papéis: Fazer a expedição de certificados de chaves públicas e de selos
Componente
digitais.
Operacional
Características: Identificação, cadastramento e lançamento da base
Responsáveis:
operacional da ICP-Brasil
ACs e ARs
Quadro 3: Componentes da ICP-Brasil.
Fonte: SILVA, 2004, p. 280.
2.4.9.2 Componentes da ICP-Brasil
O Comitê Gestor (CG) é o componente base da ICP-Brasil. Silva et al (2008, p. 82)
estabelece da seguinte forma o papel do Comitê Gestor:
Coordena a implantação e o funcionamento da ICP-Brasil, além de estabelecer a
política, os critérios e as normas para credenciamento das autoridades certificadoras

38. 37
(Acs), autoridades de registro (Ars) e demais prestadores de serviços de suporte em
todos os níveis da cadeia de certificação. Este comitê é o órgão responsável por
auditar a Autoridade Certificadora Raiz.
O Comitê Técnico (COTEC) “presta suporte técnico e assistência ao Comitê Gestor,
sendo responsável por manifestar-se previamente sobre as matérias apreciadas e decididas
por este.” (SILVA et al, 2008, p. 83).
A Autoridade Certificadora Raiz (AC-Raiz) “é a primeira autoridade na cadeia de
certificação, executora das políticas de Certificados e normas técnicas e operacionais
aprovadas pelo Comitê Gestor da ICP-Brasil.” (SILVA, 2004, p. 283). O Instituto Nacional de
Tecnologia da Informação (ITI), órgão vinculado ao Ministério da Ciência e Tecnologia,
possui o papel de AC-Raiz da ICP-Brasil.
Logo abaixo na hierarquia vêm as Autoridades Certificadoras (ACs). “Autoridades
certificadoras são entidades credenciadas a emitir certificados digitais, vinculando pares de
chaves criptográficas ao respectivo titular.” (SILVA et al, 2008, p. 84). Cabe às ACs as
tarefas de emitir, expedir, distribuir, revogar e gerenciar os certificados. Além disso, tornam
público as listas de certificados revogados (LCRs) e outras informações pertinentes.
Por sua vez, as Autoridades de Registro (ARs) “são entidades operacionalmente
vinculadas à determinada AC. Compete-lhes identificar e cadastrar usuários na presença
destes, encaminhar solicitações de certificados às AC (sic) e manter registros de suas
operações.” (SILVA et al, 2008, pp. 84-85). Já para Silva (2004, p. 191), uma AR pode ter
duas atribuições bem definidas: “verificar o conteúdo do certificado para uma AC e fornecer
os mecanismos para ingressos de novos usuários na AC”.
Os componentes finais da ICP-Brasil são os Prestadores de Serviços de Suporte
(PSS) e as Auditorias Independentes. Conforme Silva et al (2008, p. 85), os PSSs são
empresas contratadas pelas ACs ou ARs para prestarem serviços de “disponibilização de
infra-estrutura física e lógica e de recursos humanos especializados”. Já as Auditorias
Independentes “são contratadas pelas autoridades certificadoras para realizar auditorias
operacionais em entidades a elas subordinadas.” As Auditorias Independentes só podem
atuar sob a autorização da AC-Raiz.

39. 38
2.5 CONSIDERAÇÕES FINAIS
Numa transação convencional, as partes envolvidas devem partir do pressuposto
de haver documentos que comprovem a identidade de cada um. Ademais, deve haver um
órgão com uma relação de confiança já estabelecida para atestar a validade destes
documentos.
O mesmo ocorre no meio eletrônico com o uso de certificados digitais. A estrutura
por detrás da relação de confiança é a ICP-Brasil, representada pela AC que emitiu o
certificado e a AR que intermediou o ingresso da entidade certificada no sistema. Tanto as
ACs quanto as ARs precisam atender a normas rigorosas de credenciamento, estabelecidas
pela AC-Raiz, assim como submeter-se a minuciosas auditorias em suas operações.
Somando-se a estas normas e diretrizes regulamentadoras, têm-se à disposição da
ICP-Brasil uma consolidada tecnologia de chaves assimétricas e outra gama de protocolos
de apoio à segurança criptográfica.
Finalmente, o envolvimento do Governo Federal ao legitimar a ICP-Brasil como o
mecanismo oficial em apoio à segurança das transações eletrônicas, deu ampla cobertura
jurídica a toda e qualquer operação eletrônica realizada na Internet.
Por tudo isso, com o uso de um certificado digital sob o âmbito da ICP-Brasil, pode-
se endossar o que afirma Ottoni (2005, p. 3): “um sistema de documentação integralmente
eletrônico [...] não é apenas inexorável como promete benefícios em todos os setores da
economia e da sociedade”.
A pesquisa passa, no capítulo seguinte, a analisar uma aplicação prática para a
certificação digital, em especial o uso de Certificado Digital para Website, utilizando o
protocolo de segurança SSL versão 3, num sistema de informação baseado em servidor
Web e acessado por browsers Web como seus clientes.

40. 39
3 DESENVOLVIMENTO DA APLICAÇÃO – SDT ON LINE
O autor da pesquisa atuou ativamente em todas as etapas de desenvolvimento da
aplicação SDT On Line, para os estados de Pernambuco (http://www.sdtpe.com.br) e da
Paraíba (http://www.sdtpb.com.br), sendo esta um exemplo de utilização de certificado
digital em aplicações Web.
O presente estudo de caso tem como finalidade expor detalhes técnicos e
metodológicos acerca da aplicação e apontar como a certificação digital é utilizada para
garantir os princípios da autenticidade, integridade e confidencialidade.
3.1 DEFINIÇÃO
Anteriormente, a entrega de um título para protesto fazia parte de um processo de
livre escolha entre o apresentante e o respectivo ofício de sua preferência. Geralmente
existem dois ofícios para protesto legalmente estabelecidos em cada cidade, sendo a cidade
de São Paulo uma exceção à regra por possuir dez ofícios. Assim, passou a haver uma
disputa comercial entre os ofícios pelos títulos dos apresentantes com maior volume, a rede
bancária . Essa situação de disputa causou certo desconforto no meio notarial, cuja atuação
é reconhecidamente pautada pela ética e transparência em toda a sua forma.
Diante disso, a Associação dos Notários e Registradores (ANOREG) recomendou a
criação de uma entidade que pudesse conciliar os interesses individuais na atividade de
protesto de títulos. Assim, sob a tutela da ANOREG, foi criado em cada capital brasileira o
Serviço de Distribuição de Títulos (SDT), um serviço provido por uma organização
homônima, de caráter civil sem fins lucrativos, que visa atender, em cada estado da
federação, à demanda por distribuição de títulos para fins de protesto, de forma eqüitativa, a
todos os ofícios de protesto credenciados.
Em sua versão na Internet, conhecida por SDT On Line, o serviço mantém o
princípio básico da distribuição de títulos, fazendo uso de sua base tecnológica já existente,
agregando a esta um canal eficaz para a entrega dos documentos em sua forma eletrônica.

41. 40
3.2 FUNCIONALIDADE
O SDT, como serviço, funciona como captador centralizado de títulos para protesto,
provenientes de entidades conhecidas como Apresentantes. Os títulos recebidos são
processados em seu sistema local e agrupados em lotes distintos, de forma eqüitativa, e daí
são submetidos aos seus respectivos ofícios de protesto. Sistematicamente, os tabelionatos
de protesto remetem de volta ao SDT lotes de títulos já movimentados, para que os mesmos
sejam devolvidos aos seus respectivos apresentantes, completando assim o ciclo de vida de
um título para protesto.
A finalidade específica do SDT On Line é prover um meio seguro e rápido de fazer
o envio e recepção de títulos entre as entidades que compõem o sistema. Até então o meio
utilizado pelo SDT para o tráfego de documentos entre as entidades era através da
utilização de discos magnéticos contendo os arquivos de dados do sistema, transportados
por um mensageiro humano. A Figura 13 apresenta o ciclo de vida de um título para
protesto.
(a) SDT Tabelionato
Apresentante
Mensageiros
(b)
SDT On Line
Figura 13: Ciclo de vida de um título para protesto. (a) Antes e (b)
depois do SDT On Line.
Fonte: O autor.
Além de dar mais agilidade ao processo de repasse dos documentos, o SDT On
Line resulta nos seguintes benefícios adicionais:
Dispensa o papel de entregadores humanos;

42. 41
Elimina o retrabalho de gravação em mídias defeituosas;
Impede o acesso não autorizado ao conteúdo dos arquivos;
Amplia o alcance do serviço para entidades mais remotas.
3.3 METODOLOGIA DE DESENVOLVIMENTO
Para o desenvolvimento do SDT On Line foi utilizada uma combinação de
tecnologias que suportam os requisitos essenciais para seu projeto: priorização de
plataformas de código-fonte aberto (open source), base de dados relacional com integridade
referencial, programação orientada à objetos, facilidade de hospedagem em servidor Web,
implementações de segurança confiáveis e facilidade de documentação para o projeto. As
tecnologias adotadas são justificadas pelo atendimento destes requisitos.
3.3.1 Sistema Gerenciador de Banco de Dados (SGBD) MySQL
O MySQL (http://www.mysql.com/) é um dos mais populares SGBDs da Internet.
Originalmente desenvolvido pela MySQL AB, hoje é mantido pela Sun Microsystems
(http://www.sun.com/), sua atual proprietária. O MySQL versão 5 foi adotado em
atendimento aos requisitos do projeto:
Possui versão em plataforma de código-fonte aberto;
Implementa bases de dados relacionais;
Utiliza integridade referencial através de tabelas no padrão InnoDB8;
Amplamente disponível em servidores Web comerciais;
Rapidez nas respostas em consultas pela Internet.
3.3.2 Linguagem de programação PHP
A linguagem PHP (http://www.php.net/), mantida pela empresa Zend Technologies
(http://www.zend.com/en/), é amplamente utilizada para desenvolvimento de sistemas Web
e foi adotada, em sua versão 5, por atender aos seguintes requisitos:
É licenciada pela GNU GPL9, o que a caracteriza como open source;
8
InnoDB é um dos módulo de armazenamento para o MySQL. Sua principal característica é oferecer
transações do tipo ACID.

43. 42
Possui completo suporte para desenvolvimento orientado à objetos;
Amplamente disponível em servidores Web comerciais;
Permite desenvolvimento com características de robustez e segurança.
3.3.3 Servidor de Criptografia OpenSSL
O projeto OpenSSL (http://www.openssl.org/) é uma iniciativa da comunidade de
desenvolvedores colaborativos e visa prover um conjunto de ferramentas open source para
implementação do protocolo SSL em servidores Web. Foi especialmente escolhido no
projeto para compor a camada de certificação digital do sistema em sua fase de
desenvolvimento, sendo substituído posteriormente por um certificado digital comercial,
vinculado a uma Autoridade Certificadora. O OpenSSL atualmente suporta SSL versão 3.
3.3.4 Servidor Web Apache
Mantido pela Apache Software Foundation (http://www.apache.org/) sob o modelo
de código-fonte aberto, o servidor Web Apache (http://httpd.apache.org/) é, segundo seu
desenvolvedor, o mais utilizado na Internet desde o ano de 1996. (ASF, 2008).
A facilidade de instalação deste servidor em um ambiente de desenvolvimento,
somada à sua ampla disponibilidade em provedores comerciais, foram decisivos em sua
adoção no projeto, assim como também seu suporte nativo à linguagem de programação
PHP versão 5 e ao SSL versão 3.
3.3.5 Modelador gráfico JUDE/Community
Mantido pela comunidade de desenvolvedores, o projeto JUDE/Community
(http://jude.change-vision.com/jude-Web/product/community.html) fornece uma ferramenta
de modelagem gráfica open source de ótima qualidade. Essa foi a ferramenta utilizada na
documentação do projeto, especificamente na composição de Diagramas Entidade
relacionamento (DER), Diagramas de Caso de Uso e Diagramas de Classes.
9
GNU GPL (GNU General Public Licence), de autoria da Free Software Foundation
(http://www.fsf.org/), é a mais popular das licenças utilizadas em sistemas de código-fonte aberto.

44. 43
3.3.6 Documentador de código PHPDocumentor
O PHPDocumentor (http://www.phpdoc.org/) é uma ferramenta de documentação
automática para a linguagem PHP. Ela utiliza o padrão de documentação conhecido como
DocBlock (http://phpdocu.sourceforge.net/howto.php), o qual consiste em se escrever um
bloco de comentários, com instruções específicas, contendo detalhes acerca do código
implementado logo abaixo.
Ao ler o DocBlock, o PHPDocumentor gera uma documentação de saída em
diversos formatos amigáveis ao usuário, tais como PDF (Portable Document Format)10,
HTML (HyperText Markup Language)11, TXT (Arquivo-texto) e CHM (Microsoft Compiled
HTML Help)12.
O uso do PHPDocumentor permitiu a geração de documentação para o código sem
comprometer o tempo de desenvolvimento do projeto, criando facilmente um modelo de
referência para novos integrantes na equipe.
3.3.7 Ambiente de Desenvolvimento Integrado (IDE) Eclipse PDT
Tools)13
O projeto Eclipse PDT (PHP
open source Development
(http://www.eclipse.org/pdt/) criou uma IDE baseada no Eclipse contendo todos os
componentes necessários para o desenvolvimento em PHP. Além de manter a aderência
aos padrões do Eclipse, o PDT fornece componentes exclusivos para o PHP tais como:
Suporte ao Zend Framework14, para desenvolvimento baseado em
padrões de projeto;
Suporte ao PHPDocumentor, para criação de documentação de código;
Suporte ao PHPUnit15, para criação de ambientes de testes de unidade;
10
Formato de Documento Portável.
11
Linguagem de Marcação de Hipertexto.
12
Ajuda em HTML compilado da Microsoft.
13
Ferramentas para Desenvolvimento em PHP.
14
Compreende uma biblioteca de classes, criada pela Zend Technologies na linguagem PHP, usada
para auxiliar no desenvolvimento de software.
15
O PHPUnit é um framework, inspirado no JUnit do Java, com suporte à criação de testes
automatizados na linguagem de programação PHP.

45. 44
Suporte ao ZendDebug16, para depuração de código;
Suporte para code autocompletation.
3.4 A APLICAÇÃO
O SDT On Line é um projeto concebido e administrado pela Virtus Sistemas,
responsável pelas etapas de levantamento de requisitos, documentação do projeto e
validação das implementações. Foi executado sob a supervisão da PBGold Soluções
Internet, responsável por alocar recursos para as etapas de Webdesign, modelagem de
dados, codificação e testes do sistema.
O SDT On Line é um sistema baseado na Web acessível de qualquer navegador
Web (browser). A aplicação fica embutida no Website da organização, com acesso restrito
apenas aos usuários devidamente cadastrados no sistema, enquanto que a parte pública do
sítio mantém serviços de informação comuns a qualquer visitante. A Figura 14 apresenta a
página do Website por onde os usuários podem se autenticar no sistema.
A Federação Brasileira de Bancos (FEBRABAN) (http://www.febraban.org.br)
elegeu o SDT On Line como projeto-piloto, a ser testado inicialmente nos estados de
Pernambuco e da Paraíba durante o período de um ano. Após esse prazo o sistema será
submetido a uma avaliação final para que seja homologado e sirva como modelo para a
implementação em outros estados da federação.
16
ZendDebug é a ferramenta de depuração de código, baseada em servidor, da Zend Technologies.

46. 45
Figura 14: Tela de autenticação de usuário do SDT On Line.
Fonte: O autor.
3.4.1 Requisitos
As entidades mantenedoras da aplicação SDT On Line autorizaram a divulgação
parcial dos requisitos do sistema neste estudo de caso, resultando num nível de
detalhamento superficial, mas adequado à exposição de importantes partes do projeto.
3.4.1.1 Requisitos não-funcionais
Os requisitos não-funcionais do sistema são:
1. Acesso multi-usuário simultaneamente;
2. Interface Web compatível com os navegadores mais populares;
3. Acesso às funcionalidades do sistema para grupos de usuários através da
atribuição de papéis e recursos específicos;
4. Banco de dados com integridade referencial.

47. 46
3.4.1.2 Requisitos de domínio
Os requisitos de domínio do sistema são:
1. Uso de certificação digital para garantir autenticidade do sistema e
integridade e confidencialidade dos arquivos transacionados;
2. Desenvolvimento modular para permitir inclusão de novas funcionalidades;
3. Baixo acoplamento entre o núcleo do sistema e a interface;
4. Hospedeiro Web com alta estabilidade e disponibilidade;
5. Programação de backups e planejamento de recuperação de desastres.
3.4.1.3 Requisitos funcionais
Os requisitos funcionais mais importantes do sistema são:
1. Cadastro de Entidades: disponível apenas para administradores do SDT;
deverá permitir o cadastro de Apresentantes e Tabelionatos; deverá conter as
funções de inclusão, consulta, alteração e exclusão de registros;
2. Cadastro de Usuários: disponível apenas para administradores das
entidades; deverá existir uma entidade previamente cadastrada para
acomodar o usuário; o usuário deverá ser vinculado a um grupo; deverá
conter as funções de inclusão, consulta, alteração e exclusão de registros;
3. Enviar arquivos: disponível apenas para usuários autenticados no sistema;
deverá possibilitar o envio de arquivos de diversos layouts; o arquivo será
validado conforme layout da FEBRABAN; os dados serão extraídos do
arquivo e armazenados no banco; informar ao apresentante o sucesso da
operação e emitir o recibo; notificar ao SDT a disponibilidade dos dados; caso
o arquivo seja invalidado deverá ser descartado; informar ao apresentante o
fracasso da operação;
4. Receber arquivos: disponível apenas para usuários autenticados no sistema;
deverá possibilitar a recepção de arquivos de diversos layouts; através da
página de notificação, selecionar o arquivo desejado; os dados serão lidos da
base e o arquivo será montado com base no layout da FEBRABAN;
disponibilizar o arquivo para download;
5. Solicitar retirada de título: disponível apenas para usuários autenticados no
sistema; informar dados de identificação do ofício para onde foi distribuído e o
protocolo do título; localiza o título na base; solicita novos dados do título para

48. 47
conferência; se dados conferem o tabelionato é notificado para devolução;
gerar recibo da solicitação; caso dados não confiram ou título não exista na
base o usuário é solicitado para entrar novos dados;
p
3.4.2 Arquitetura
Para atender aos requisitos de desenvolvimento modular e baixo acoplamento entre
o núcleo da aplicação e sua interface com o usuário, optou-se pelo desenvolvimento
optou se
segundo a arquitetura Modelo-Visão-Controle, ou simplesmente MVC.
Modelo
Para Bass (1991, apud MENDES, 2002, p. 132) “a arquitetura MVC tem como base
o paradigma de multiagentes”. Mendes (2002, p. 132) declara que o MVC enxerga um
agente segundo três componentes funcionais:
1. Modelo: responsável pela definição da competência do agente (núcleo
definição
funcional);
2. Visão: responsável pela definição do comportamento perceptivo do agente
para a saída (apresentação de resultados);
3. Controle: responsável pela definição do comportamento perceptivo do agente
para a entrada (comandos de usuário).
(c
Conforme observado na Figura 15, o MVC decompõe as tarefas do sistema entre
os componentes, resultando na obtenção de modularidade e desacoplamento entre o núcleo
funcional e sua interface, que são requisitos essenciais ao projeto SDT On Line
SD Line.
Figura 15: Modelo arquitetural MVC.
Fonte: MENDES, 2002, p. 132.

49. 48
3.4.3 Diagramas de Casos de Uso
As Figuras 16 a 20 apresentam os Diagramas de Caso de Uso para as
principais funcionalidades do sistema.
Figura 16: Diagrama de Caso de Uso para a funcionalidade “Cadastro de
Entidades”.
Fonte: O autor.
Figura 17: Diagrama de Caso de Uso para a funcionalidade “Cadastro de
Usuários”.
Fonte: O autor.

50. 49
Figura 18: Diagrama de Caso de Uso para a funcionalidade “Enviar
Arquivos”.
Fonte: O autor.
Figura 19: Diagrama de Caso de Uso para a funcionalidade “Receber
Arquivos”.
Fonte: O autor.

51. 50
Figura 20: Diagrama de Caso de Uso para a funcionalidade “Solicitar
Retirada de Títulos”.
Fonte: O autor.
3.4.4 Diagrama Entidade Relacionamento (DER)
A Virtus Sistemas, empresa responsável pelo projeto SDT On Line autorizou a
Line,
utilização do DER simplificado, no qual se detalha o relacionamento entre as diversas
entidades sem apresentar o detalhamento dos atributos. Por sua vez, o Dicionário de
Dados, no qual se apresentam os atributos num maior grau de detalhamento, teve seu uso
vetado neste estudo de caso.
A Figura 21 apresenta o DER versão 2.4 para a aplicação SDT On Line
Line.

52. 51
Figura 21: DER para o SDT On Line.
Fonte: Virtus Sistemas.
3.4.5 Diagrama de Classes – Camada de Modelo
Da mesma forma que no DER, para o Diagrama de Classes foi autorizada a
utilização de um modelo simplificado, contendo apenas atributos e operações básicos. Ainda
assim, o núcleo da aplicação está corretamente representado quanto às suas principais
funcionalidades. A Figura 22 esquematiza o Diagrama de Classes para o SDT On Line.

53. 52
Figura 22: Diagrama de Classes do SDT On Line – Camada de Modelo
Fonte: O autor.
3.5 USO DE CERTIFICAÇÃO DIGITAL NO SDT ON LINE
O ponto alto deste estudo de caso se concentra na análise de como a aplicação
to
SDT On Line se utilizou dos conceitos acerca da certificação digital e como esta foi aplicada
para prover os requisitos de autenticidade do sistema e integridade e confidencialidade dos
arquivos transacionados.

54. 53
São analisados:
O que motivou a escolha da Autoridade Certificadora;
A escolha do tipo de certificado digital apropriado à aplicação;
Como é feita a verificação de autenticidade da aplicação pelo usuário;
Como os arquivos contendo dados sensíveis trafegam em segurança
entre o cliente e o servidor da aplicação.
3.5.1 Autoridade Certificadora Escolhida
Uma das perguntas respondidas antes de se escolher uma Autoridade Certificadora
foi: que tipo de proteção a aplicação precisa ter? A resposta é decisiva ao se optar por uma
AC pertencente ou não à ICP-Brasil, pois isso tem reflexo direto no custo do certificado
digital adquirido.
Devido ao amparo jurídico e à garantia de não-repúdio, certificados digitais emitidos
por ACs pertencentes à ICP-Brasil costumam custar até 12 vezes mais que um equivalente
não pertencente à ICP-Brasil. O Quadro 4 faz um comparativo de preços entre certificados
digitais equivalentes entre duas ACs, uma pertencente à ICP-Brasil e outra não.
Certisign (ICP-Brasil) Comodo
Certificado Certisign ICP-Brasil A1 InstantSSL A1
Valor anual: R$ 2.953,50 Valor anual: R$ 240,00
Quadro 4: Comparativo de preços entre certificados equivalentes emitidos por AC
pertencente e não pertencente à ICP-Brasil.
Fontes: Certisign Brasil (https://www.certisign.com.br/produtos/certificados/icp) e Comodo Brasil
(http://www.comodobr.com/instantssl/prd_instantssl.php).
No caso do SDT On Line, os requisitos para a proteção do sistema seriam a
garantia a autenticidade, confidencialidade e integridade. Em nenhum caso as informações
transacionadas implicam em se ter garantia ao não-repúdio. Sendo assim, um certificado da
ICP-Brasil seria desnecessário, uma vez que todos os demais certificados têm tecnicamente
condições de prover as demais garantias necessárias.
A escolha pela Autoridade Certificadora recaiu sobre a Comodo Brasil
(http://www.comodobr.com) que, além de apresentar um certificado compatível com as
necessidades do sistema, oferece adicionalmente um seguro de US$ 100.000,00 (cem mil
dólares americanos) em caso de prejuízos sofridos pelo sistema em uma eventual falha na
proteção garantida pelo certificado.

55. 54
3.5.2 Tipo de Certificado Adotado
Basicamente, vigoram dois tipos de certificados digitais, conhecidos como A1 e A3.
Uma das coisas que difere ambos é a forma como o par de chaves é armazenado. O tipo A1
armazena as chaves na unidade de disco de um computador, enquanto o tipo A3 armazena
as chaves em mídias seguras, tais como um smart card ou um token USB. A Figura 23
apresenta as mídias para armazenamento de certificados do tipo A3.
Figura 23: Mídias para certificados A3.
Fonte: Certisign.
O tipo A3 é mais recomendável para usuários clientes, levando-se em conta o fator
segurança. Em caso de roubo ou extravio de sua mídia, o par de chaves continuará seguro,
desde que sua senha de acesso não tenha sido revelada. Basta então comunicar à AC para
que o certificado seja revogado.
O tipo A1 é mais vulnerável ao roubo e extravio de computadores, principalmente
laptops. O par de chaves assim armazenado está de certa forma mais disponível para o uso
indevido antes da revogação do certificado, por isso não se recomenda para uso pessoal.
Porém, o mesmo se apresenta adequado para armazenamento em servidores, os quais
geralmente gozam de um maior aparato de segurança. Dessa forma, despontam como

56. 55
adequados para uso em servidores Web nos quais rodam aplicações que necessitam de
seus mecanismos de proteção.
Toda a aplicação SDT On Line roda em um servidor Web do tipo Apache, com
suporte ao protocolo SSL. Assim, ela faz uso desse recurso ao fornecer o par de chaves
assimétricas de seu certificado para uso do SSL no servidor. Para esse fim, um certificado
digital do tipo InstantSSL A1, emitido pela Comodo Brasil, especialmente configurado para
uso em Websites com SSL, foi adquirido pelos mantenedores da aplicação e instalado
dentro do servidor Web contratado.
3.5.3 Verificação de Autenticidade do Website
Conforme visto no item 2.3.4, um ataque de fabricação contra um sistema pode
fazer com que um usuário incauto interaja com um serviço fraudulento, fazendo-se passar
por um legítimo. O SDT On Line não está livre de ser clonado por algum criminoso digital
mal-intencionado, mas, com o uso de seu certificado digital, pode prevenir seus usuários
contra esse tipo de golpe, por prover os meios de conferência de sua autenticidade.
Nas Figuras 24 a 26, obtidas com o navegador Web Mozilla Firefox versão 3, são
delineados os passos necessários para se fazer a verificação de autenticidade do sistema,
mediante o uso de seu certificado digital.
Figura 24: Verificação de Autenticidade –
parte 1.
Fonte: O autor.

57. 56
Na Figura 24 as áreas circundadas em vermelho indicam as áreas no navegador
Web por onde começam a verificação de autenticidade. O ícone representando um
cadeado, no canto inferior direito, indica o nível de segurança. Estando completamente
fechado é um indicativo de que a segurança é alta. Um duplo clique nas áreas circundadas
leva à parte dois da verificação, conforme a Figura 25.
Figura 25: Verificação de Autenticidade – parte
2.
Fonte: O autor.
Na Figura 25 são destacadas as seções “Identidade do site” e “Detalhes técnicos”.
Na primeira já se pode observar de forma resumida qual o site que está sendo acessado,
seu proprietário e a AC que o homologou. Na segunda é apresentada a informação de que a
conexão está criptografada e qual o seu nível de segurança.
A informação destacada ao centro, sob o rótulo “Este site fornece um certificado
para comprovar sua identidade”, permite que, ao se pressionar o botão “Exibir certificado”
passemos para a terceira parte da verificação de autenticidade, conforme apresentada na
Figura 26.

58. 57
Figura 26: Verificação de Autenticidade – parte 3.
Fonte: O autor.
A Figura 26 apresenta o Visualizador de Certificados associado ao navegador Web.
As seções são apresentadas conforme explicado a seguir:
Expedido para: contém dados relativos ao proprietário do certificado
digital;
Expedido por: contém informações acerca da AC que emitiu o
certificado;
Validade: informa as datas de início da vigência do certificado e quando
se dará sua expiração;
Assinaturas: contém as assinaturas digitais da AC, aplicada sobre o
próprio certificado impedindo sua adulteração. As assinaturas foram
obtidas a partir de duas funções hash distintas: SHA1 e MD5.
Neste ponto o usuário tem assegurado que sua interação com o sistema é legítima
e ele não sofrerá nenhum tipo de dano durante as operações efetuadas.

59. 58
3.5.4 Transmissão Segura de Dados com SSL
Conforme explicado no item 2.4.8.4, o SSL provê um canal criptografado por onde
as informações podem trafegar de modo seguro. O servidor SSL se utiliza das chaves
assimétricas presentes no certificado digital do SDT On Line para garantir o princípio da
confidencialidade.
Ao se iniciar a transmissão de dados, deve-se observar qual o protocolo que está
sendo utilizado pela aplicação. Conforme mostra a Figura 27, o protocolo HTTPS
(HyperText Transfer Protocol over Secure Socket Layer)17 assegura que a transmissão se
dará sob a criptografia provida pelo SSL e que nenhuma informação trafegada entre o
usuário e a aplicação poderá ser compreendida caso haja uma interceptação.
Figura 27: Indicação de uso do protocolo HTTPS na conexão com o
sistema.
Fonte: O autor.
3.6 CONSIDERAÇÕES FINAIS
Este estudo de caso apresenta como uma aplicação Web pode ganhar uma
satisfatória proteção e assegurar uma adequada medida de segurança a seus usuários. De
forma simples, a adoção de um certificado digital elimina os principais problemas
relacionados à segurança da informação no ambiente Internet.
Conforme mostra a análise da arquitetura do sistema, nenhum tipo de
implementação especial foi previsto e utilizado no projeto para fazer uso da certificação
digital. Todos os elementos necessários para permitir sua funcionalidade já estão
disponíveis na infra-estrutura da Web, sendo somente necessário utilizá-los.
O próximo capítulo faz uma análise dos resultados obtidos, do ponto de vista da
aplicação, segundo a estratégia de desenvolvimento se utilizando das tecnologias discutidas
neste capítulo.
17
Protocolo de Transferência de Hipertexto sobre Camada Segura de Soquete.

60. 59
4. ANALISE DE RESULTADOS
Os resultados analisados neste capítulo levam em conta aspectos operacionais e
técnicos, sempre do ponto de vista da própria aplicação. Os resultados operacionais focam
os processos internos do SDT e como a aplicação proporcionou melhorias nestes. Já os
resultados técnicos focam como a utilização de tecnologias previstas em projeto permitiu
alcançar os objetivos de implementação traçados. Ao final, são traçadas as perspectivas
futuras para a evolução da aplicação.
4.1 RESULTADOS OPERACIONAIS
Com o uso do SDT On Line se constatou o melhoramento no ciclo de vida de um
título para protesto. Conforme demonstrado na Figura 13, antes havia a participação de
mensageiros humanos no processo de entrega dos arquivos contendo os títulos para
protesto e isso acarretava alguns problemas, todos sanados com o uso da aplicação. Dentre
os avanços conquistados destacamos:
Aumento na segurança: arquivos em formato de texto plano, gravados em
•
disquetes comuns, sem nenhum tipo de criptografia, podiam ser lidos
facilmente em qualquer computador e sofrer adulterações em seu
conteúdo. Atualmente os arquivos são trafegados criptografados dentro da
aplicação, inviabilizando possíveis adulterações nos dados.
Aumento na disponibilidade: devido ao fato de que a mídia disquete
•
apresentava freqüentes falhas de gravação, não era incomum que os
dados não pudessem ser lidos, obrigando a adoção da prática de
redundância de mídia. Atualmente os dados são armazenados em banco
de dados relacional, com ampla disponibilidade pela Internet.
Agilidade na entrega: por melhor que fosse a logística desenvolvida pelas
•
entidades, a entrega por um mensageiro humano enfrentava diariamente
obstáculos naturais à agilidade: trânsito, acidentes, interação com outras
pessoas e distância entre as entidades. Atualmente os dados ficam
disponíveis à entidade destinatária no momento imediatamente após a
confirmação de envio bem sucedido.

61. 60
Alcance do serviço: devido aos motivos destacados nos pontos anteriores,
•
a área geográfica de atendimento do SDT se limitava à região
metropolitana da capital em que estava estabelecido. Com o advento da
aplicação on line as barreiras naturais que impediam sua atuação em
cidades mais remotas foram superadas, e o atendimento do SDT já
chegou ao interior de cada estado em que atua.
Inovação: devido ao seu caráter inovador para o serviço, o SDT On Line
•
foi eleito pela FEBRABAN como projeto-piloto no gênero. Esse status
daria o direito à aplicação de concorrer ao processo de homologação da
FEBRABAN para ser recomendado como solução de software oficial em
uso nos SDTs de todo o país.
4.2 RESULTADOS TÉCNICOS
A primeira preocupação na entrega da aplicação foi se certificar de que a mesma
atendia aos requisitos especificados no projeto. Através de uma lista de verificação própria,
utilizada durante a fase de testes, pôde-se atestar o atendimento a cada um dos requisitos.
Importante ressaltar que, ao longo do processo de implantação, vários requisitos
foram atendidos de uma forma mais eficaz do que havia sido previsto, a exemplo do
requisito de desacoplamento da interface. A solução adotada conseguiu, além do já
esperado, também o desacoplamento da base de dados, aumentando a flexibilidade na
possível substituição do SGBD.
Adicionalmente, uma nova lista de verificação foi aplicada, dessa vez segundo os
critérios de homologação da FEBRABAN, para fins de homologação. Neste momento dos
testes vários ajustes foram requeridos para adequação às novas exigências. Contudo, a
implantação dos ajustes não descaracterizou o projeto original, servindo apenas para
garantir sua participação no processo de homologação.
A utilização da arquitetura MVC no projeto também resultou em vantagens óbvias.
O já citado desacoplamento entre a interface e o núcleo do sistema é resultante da adoção
do MVC. Em especial, a implementação do MVC através do Zend Framework, permitiu
realizar uma implementação modular com as seguintes características: