SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE DOCUMENTOS...
66
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE DOCUMENTOS ELETRÔNICOS RECÍGIO POFFO BLUMENAU 2010 2010/2-24
Transcript of SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE DOCUMENTOS...
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE
DOCUMENTOS ELETRÔNICOS
RECÍGIO POFFO
BLUMENAU 2010
2010/2-24
RECÍGIO POFFO
SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE
DOCUMENTOS ELETRÔNICOS
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.
Prof. Paulo Fernando da Silva - Orientador
BLUMENAU 2010
2010/2-24
SERVIÇO DE PROTOCOLAÇÃO DIGITAL DE
DOCUMENTOS ELETRÔNICOS
Por
RECÍGIO POFFO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Paulo Fernando da Silva, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Fernando dos Santos, Mestre – FURB
______________________________________________________ Membro: Prof. Everaldo Artur Grahl, Mestre – FURB
Blumenau, 13 de dezembro de 2010
Dedico este aos meus pais, que me serviram de exemplo e fizeram de mim o que sou. Aos meus amigos, fortes alicerces da minha vida.
AGRADECIMENTOS
À minha família, a qual sempre me apoiou.
Aos meus amigos, os quais em minhas ideias sempre acreditaram.
A todos que de alguma forma contribuíram para que este trabalho fosse um sucesso.
Uma mente que se abre a novas ideias nunca mais será a mesma.
Albert Einstein
RESUMO
O objetivo deste trabalho é a criação de uma protocoladora digital de documentos eletrônicos. Fazendo uso de mecanismos de segurança como criptografia, assinatura e datação, utilizando no processo uma data legalmente reconhecida. Pretende-se criar um serviço confiável que possa gerar um recibo, garantindo a integridade e autenticidade do documento. O serviço será disponibilizado via web, fazendo uso da linguagem PHP e do framework Zend Framework. Deve-se acessar o serviço para protocolar o documento e posteriormente para verificar sua autenticidade.
Palavras-chave: Protocolação digital. Criptografia. Assinatura digital. Datação.
ABSTRACT
The objective of this work is to create a digital protocol for electronic documents. The protocol uses security mechanisms such as encryption, signing and dating, using a date in the process legally recognized. It is intended to create a reliable service that can generate a receipt, ensuring the integrity and authenticity of the document. The service will be available via web, using the PHP Zend Framework and the framework. You should access the service for filing the document and then to verify its authenticity. Key-words: Digital protocol. Encryption. Digital signature. Dating.
LISTA DE ILUSTRAÇÕES
Quadro 1- Requisitos Funcionais. ............................................................................................ 29
Quadro 2 - Requisitos Não Funcionais. .................................................................................... 30
Quadro 3 - Detalhamento do caso de uso Cadastrar Usuário. .................................................. 32
Quadro 4 - Visualizar Usuários Cadastrados. ........................................................................... 32
Quadro 5 - Editar Usuário. ....................................................................................................... 33
Quadro 7 - Detalhamento do caso de uso de Protocolar Documento. ..................................... 34
Quadro 8 - Detalhamento do caso de uso Verifica Recibo. ...................................................... 35
Quadro 9 - Programa em C para iniciar aplicação. ................................................................... 45
Quadro 10 - Verificação da senha do sistema. ......................................................................... 46
Quadro 11 – KeyRepository. .................................................................................................... 47
Quadro 12 - Classe ProcoladoraAuto. ...................................................................................... 48
Quadro 13 - Sincronia de tempo. .............................................................................................. 49
Quadro 14 – Método protocolar da classe protocolação. ......................................................... 50
Quadro 15 - Criação do recibo. ................................................................................................ 51
Quadro 16 - Método verificaProtocolacao. .............................................................................. 53
Figura 1 - Codificação simétrica. ............................................................................................. 18
Figura 2 - Decodificação simétrica. .......................................................................................... 19
Figura 3 - Codificação assimétrica. .......................................................................................... 20
Figura 4 - Decodificação assimétrica. ...................................................................................... 20
Figura 5 - Processo de datação de um documento. .................................................................. 23
Figura 6 - Encadeamento linear. ............................................................................................... 24
Figura 7 - Estrutura de um ambiente web. ............................................................................... 26
Figura 8 – Bry PDDE. .............................................................................................................. 28
Figura 9 - Caso de uso que pode ser executado pelo visitante. ................................................ 31
Figura 10 - Casos de usos que podem ser executados pela empresa cadastrada. ..................... 31
Figura 11 - Casos de usos que podem ser executados pelo usuário. ........................................ 34
Figura 12 - Classes de modelo. ................................................................................................. 36
Figura 13 - Classes de controle. ............................................................................................... 37
Figura 14 - Classes de protocolação. ........................................................................................ 38
Figura 15 - Diagrama de sequência para Protocolar Documento. ............................................ 40
Figura 16 - Diagrama de sequencia de Verifica Recibo. .......................................................... 41
Figura 17 - Estrutura do banco de dados .................................................................................. 42
Figura 18 - Recibo Exemplo. .................................................................................................... 52
Figura 19 - Iniciando serviço de protocolação. ........................................................................ 54
Figura 20 - Tela inicial do sistema. .......................................................................................... 55
Figura 21 - Cadastro de nova empresa. .................................................................................... 55
Figura 22 - Tela de login do sistema. ....................................................................................... 56
Figura 23 - Cadastro de usuários de uma empresa. .................................................................. 57
Figura 24 - Lista de usuários cadastrados de uma empresa. ..................................................... 57
Figura 25 - Opções do usuário funcionário. ............................................................................. 58
Figura 26 - Tela "Protocolar Documento". ............................................................................... 58
Figura 27 - Recibo sendo emitido pela protocoladora. ............................................................. 59
Figura 28 - Verificar recibo. ..................................................................................................... 59
Figura 29- Resultado da validação de um recibo. .................................................................... 60
LISTA DE SIGLAS
AD – Autoridade de Datação
AES - Advanced Encryption Standard
CC-BY - Creative Commons
FTP – File Transporte Protocol
HLB – Hora Legal Brasileira
HTML - HyperText Markup Language
HTTP – Hypertext Transfer Protocol
MD5 – Message-Digest Algorithm 5
MIT – Massachusetts Institute of Technology
MVC - Model View Controller
NIST - Instituto Nacional de Padrões e Tecnologia dos EUA
NTP- Network Time Protocol
PDDE – Protocoladora Digital de Documentos Eletrônicos
PEAR - PHP Extension and Application Repository
PHP - Hypertext Preprocessor
RSA - Rivest Shamir Adleman
SHA-1 – Secure Hash Algorithm 1
SSL - Secure Sockets Layer
TSL - Transport Layer Security
UML - Unified Modeling Language
XML - Extensive Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 15
2.1 DOCUMENTOS ELETRÔNICOS ................................................................................... 15
2.2 ASSINATURAS DIGITAIS ............................................................................................. 16
2.2.1 Resumo de documentos eletrônicos ................................................................................ 16
2.2.2 Conceitos de criptografia ................................................................................................ 17
2.2.3 Chaves simétricas e assimétricas .................................................................................... 18
2.3 DATAÇÃO DE DOCUMENTOS DIGITAIS .................................................................. 21
2.3.1 A Hora Legal Brasileira .................................................................................................. 21
2.3.2 Método de datação relativa ............................................................................................. 22
2.4 AUDITORIA DOS RECIBOS .......................................................................................... 24
2.5 O ZEND FRAMEWORK .................................................................................................. 25
2.6 TRABALHOS CORRELATOS ........................................................................................ 27
3 DESENVOLVIMENTO .................................................................................................... 29
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 29
3.2 ESPECIFICAÇÃO ............................................................................................................ 30
3.2.1 Diagramas de casos de uso .............................................................................................. 30
3.2.1.1 Casos de usos de cadastros ........................................................................................... 31
3.2.1.2 Casos de uso de protocolação ....................................................................................... 33
3.2.2 Diagramas de classe ........................................................................................................ 35
3.2.2.1 Classes de Modelo ........................................................................................................ 35
3.2.2.2 Classes de Controle ....................................................................................................... 37
3.2.2.3 Diagrama de classes de protocolação ........................................................................... 38
3.2.3 Diagramas de Sequência ................................................................................................. 39
3.2.4 Estrutura do banco de dados ........................................................................................... 41
3.3 IMPLEMENTAÇÃO ........................................................................................................ 42
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 43
3.3.1.1 O OpenSSL ................................................................................................................... 43
3.3.1.2 O Crypt_RSA e o AES ................................................................................................. 44
3.3.1.3 O Repositório de chaves assimétricas e a senha mestre do sistema ............................. 44
3.3.1.4 Autenticação dos usuários ............................................................................................ 47
3.3.1.5 O serviço de NTP e a obtenção de uma hora legal. ...................................................... 49
3.3.1.6 Protocolação dos documentos ....................................................................................... 49
3.3.1.7 Validação e auditoria dos recibos ................................................................................. 52
3.3.2 Operacionalidade da implementação .............................................................................. 54
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 60
4 CONCLUSÕES .................................................................................................................. 62
4.1 EXTENSÕES .................................................................................................................... 63
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 64
13
1 INTRODUÇÃO
A escrita tem suma importância para história da humanidade. Não se sabe com certeza
absoluta a data de sua origem, porém, a primeira escrita apareceu na região entre os rios
Tigres e Eufrates, na Mesopotânia (SILVA JUNIOR, 1998) e desde cedo ela se mostrou útil
na vida política e econômica, da contabilidade das colheitas, às ordens dadas pelos reis aos
seus exércitos.
Tão logo a escrita e os papéis tornaram-se um recurso indispensável, surgiram também
os primeiros métodos de falsificação de documentos e a necessidade de garantir certos
requisitos de segurança como autenticidade e integridade. Várias técnicas foram criadas e
aperfeiçoadas ao longo do tempo, fruto de novas idéias.
A técnica de protocolação foi uma resposta a estas necessidades. Fazendo uso da
mesma é possível garantir, por meio de um comprovante, validado por uma entidade
responsável e reconhecida, que um documento existiu em determinada data.
Com o avanço da informática tornou-se popular o uso de documentos eletrônicos.
Transações eletrônicas ocorrem o tempo todo. Com os documentos eletrônicos, novamente
surge a necessidade de garantir certos requisitos de segurança para assegurar seus valores. Em
um processo jurídico, por exemplo, pode-se usá-los como provas confiáveis.
Diante do exposto, surge a idéia de criar um serviço web para protocolação digital de
documentos eletrônicos, um recurso que possa ser acessado a partir de qualquer computador
conectado a internet e que seja capaz de datar e assinar de forma segura estes documentos.
Sendo o documento eletrônico de um formato de texto ou imagem permitido pelo
sistema, o objetivo é gerar um recibo que servirá como garantia da existência do mesmo em
determinada data ou sua precedência em relação a outro documento, sendo este recibo
possível de auditoria para validação de sua autenticidade.
As técnicas de protocolação digital garantem a impossibilidade de se protocolizar um
documento eletrônico de forma retroativa com relação ao tempo, ao número do protocolo e ao
conteúdo do original. Se o documento eletrônico original for modificado, sua integridade será
verificada. A simples abertura do documento eletrônico original em algum aplicativo pode
alterar seu conteúdo e torná-lo inválido (TRIBUNAL REGINAL DO TRABALHO, 2002).
A Protocoladora Digital de Documentos Eletrônicos (PDDE) é um recurso que já vem
sendo testado e usado por várias empresas e pelo governo federal de alguns estados no meio
jurídico. Mostrando-se de suma importância para o judiciário, onde pode garantir que
14
determinados valores legais sejam assegurados aos documentos, principalmente sua
autenticidade e data de criação.
Com a segurança aprimorada, torna-se viável o abandono dos documentos impressos e
a substituição pelos mesmos em suas formas eletrônicas. O que resolve problemas como a
dificuldade de armazenamento, de localização e de deterioração pela qual sofrem os papéis.
De modo geral os documentos eletrônicos vêm sendo utilizados cada vez mais e se
mostram úteis na transação de informações por meio eletrônico. Basta a eles agora toda a
confiabilidade dada aos documentos impressos, para tal, a necessidade de uma protocoladora
digital de documentos eletrônicos.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho foi criar um serviço web de protocolação digital de
documentos eletrônicos.
Os objetivos específicos do trabalho são:
a) criar um serviço capaz de receber documentos eletrônicos e criar um resumo
(1hash);
b) aplicar um carimbo temporal no resumo documento;
c) assinar os resumos dos documentos eletrônicos para garantir a autenticidade da
protocoladora digital e gerar um recibo como comprovante do processo;
d) garantir que a assinatura possa ser confirmada e a existência de determinado
documento em determinado período do tempo possa ser verificada;
e) garantir a sincronia de tempo do serviço com a hora legal brasileira.
1 Um resumo (hash) pode ser entendido como uma grande quantidade de informação transformada em uma pequena quantidade de informação.
15
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo trata das questões teóricas e conceituais que envolvem a protocolação
digital de documento eletrônicos. O texto inicia descrevendo documentos eletrônicos,
resumos de documentos e depois trata de assinaturas digitais, sua divisão entre assimétricas e
simétricas, explicando suas diferenças enquanto fala de criptografia.
Neste capítulo também é abordado o conceito de datação relativa. É mostrada a
existência da Hora Legal Brasileira, e também o ambiente de desenvolvimento proposto para
a aplicação.
Ao fim, são apresentados os trabalhos correlatos que auxiliaram na compreensão e
resolução dos requisitos propostos.
2.1 DOCUMENTOS ELETRÔNICOS
Um documento eletrônico pode ser entendido como a representação de um fato
concretizado por meio de um computador e armazenado em formato específico (organização
singular de bits e bytes), capaz de ser traduzido ou aprendido pelos sentidos mediante o
emprego de programa (software) apropriado (CASTRO, 2003).
Os documentos eletrônicos são produzidos, manuseados e transmitidos com auxílio de
máquinas eletrônicas, porém, em si mesmo, tais documentos não são “eletrônicos”, pois não
são circuitos elétricos e nem possuem válvulas, semicondutores ou qualquer outro dispositivo
eletrônico (TADAMO 2002).
Não sendo os documentos por si próprios eletrônicos, o que se considera por
documentos eletrônicos são informações armazenadas e transmitidas por máquinas
eletrônicas, ou seja, documentos criados e armazenados de forma digital. Também são
chamados de “Documentos Digitais”, onde o processo de conversão para representar algo na
sua forma digital chama-se “digitalização”.
Essa informação, quando interpretada por máquinas eletrônicas, como um computador,
podem se apresentar de várias formas. Podem ser uma imagem ou um texto, como exemplo. É
a integridade e validade destes documentos que se pretende garantir. Mais que isso, essa
garantia também deve existir na forma digital, para se ter um real aproveitamento das
16
transmissões eletrônicas, onde se pode enviar ou armazenar o documento e também a prova
de sua existência.
2.2 ASSINATURAS DIGITAIS
Com a chegada da internet, a transação a longa distância popularizou-se e hoje
vivemos um período de ascensão do comércio eletrônico. Entretanto, este novo tipo de
comércio criou um paradigma quanto ao aspecto de impessoalidade nas transações, ou seja,
como confiar em algo escrito por alguém a milhares de quilômetros de distância? Novamente
a tecnologia apresentou alternativas para esclarecer dúvidas neste sentido. Uma destas
alternativas é a chamada assinatura digital (TADAMO, 2002, p. 13).
Quando um usuário envia sua mensagem, o outro, receptor, necessita garantir que a
mensagem realmente provém de quem a gerou, ou seja, que a mensagem é autêntica (SILVA,
2004, p. 182), neste ponto do processo fica clara a importância da assinatura digital.
A assinatura digital é composta basicamente de dois momentos, a criação de um
resumo do documento (hash) e logo após a encriptação do mesmo. Da união dos dois
processos é possível garantir os requisitos básicos da assinatura digital: autenticidade,
integridade e irretratabilidade.
2.2.1 Resumo de documentos eletrônicos
Por motivos de segurança, o que se usa e guarda dos documentos eletrônicos na
assinatura digital é apenas um resumo do mesmo e não a informação completa. Esse resumo é
gerado a partir de um algoritmo matemático, como MD5 (Message-Digest algorithm 5) ou
SHA-1 (Secure Hash Algorithm 1), que tem como resultado um conjunto de caracteres de
tamanho conhecido (hash).
Esse hash quando criado segue premissas básicas e deve ter certas propriedades, as
quais são:
a) deve ser impossível recuperar o documento original a partir do hash do mesmo;
17
b) o hash deve parecer aleatório, mesmo que o algoritmo seja conhecido. Uma função
de hash é dita forte se a mudança de um bit no documento original resulta em um
novo hash totalmente diferente;
c) deve ser impossível encontrar dois documentos diferentes que levam a um mesmo
hash.
Esse hash é bastante útil, pois possui várias características que são importantes para o
processo de protocolação e para a segurança do mesmo. Qualquer mudança no arquivo
original torna-se evidente no resultado final e é impossível obter-se o documento inicial
apenas com o resultado da protocolação. Além de ser improvável encontrar dois documentos
diferentes que levem a um mesmo hash como resultado.
Neste passo garantem-se duas características na assinatura: a integridade e
irretratabilidade. A integridade garante que o documento é integro, não sofreu alterações, a
irretratabilidade, que a partir do dado armazenado, o hash, é impossível de se obter o
documento original.
Resumir documentos proporciona outra característica benéfica, seu pequeno tamanho
quando se precisa armazenar muitos resumos de assinaturas e documentos, caso da PDDE.
2.2.2 Conceitos de criptografia
O termo criptografia surgiu da fusão das palavras gregas "kryptós" e "gráphein", que
significam "oculto" e "escrever", respectivamente. Trata-se de um conjunto de conceitos e
técnicas que visa codificar uma informação de forma que somente o emissor e o receptor
possam acessá-la. (ALECRIM, 2009).
As primeiras técnicas de criptografias são muito antigas, denotam de muito antes de
Cristo, aparecem na escrita hieroglífica dos egípcios e nos textos romanos, como exemplo.
Manter o sigilo entre as mensagens sempre foi um ponto importante para as civilizações.
No mundo moderno, na computação, as formas de criptografias mais conhecidas
utilizam chaves como elementos fundamentais. São algoritmos matemáticos que fazem uso
destas chaves como parâmetros junto da informação que se deseja criptografar para criar o
resultado que se deseja, a informação criptografada.
Na criptografia atual as chaves são longas sequências de bits. Visto que um bit pode ter
18
apenas dois valores, 0 ou 1, uma chave de três dígitos oferecerá 2³ = 8 possíveis valores para a
chave. (TADAMO 2002). Sendo assim, para uma maior confiabilidade recomendam-se
chaves de tamanhos maiores como 512 ou 1024 bits atualmente.
2.2.3 Chaves simétricas e assimétricas
As chaves criptográficas utilizadas para obter mensagens criptrografadas podem ser
separadas em dois conjuntos: chaves simétricas e chaves assimétricas.
Um algoritmo de chaves simétricas usa a mesma chave para encriptar e decriptar o
texto. A mensagem que se deseja criptografar é enviada a determinado algoritmo de
codificação junto da chave. Este algoritmo aplica determinado método matemático de
criptografia na mensagem usando a chave como parâmetro, tem-se como resultado a
mensagem codificada. A figura 1 ilustra o processo de codificação.
Fonte: Carvalho (2008). Figura 1 - Codificação simétrica
Para se obter novamente o texto original, é preciso estar de posse da mensagem
criptografada e da chave. Então, envia-se novamente ambos para o algoritmo e este retorna a
mensagem em seu estado original. A figura 2 ilustra esse processo de decodificação.
19
Fonte:Carvalho (2008). Figura 2 - Decodificação simétrica
Fazendo uma analogia com o mundo real, a criptografia simétrica é semelhante a se
colocar uma mensagem dentro de um cofre, e fechá-lo com um cadeado. Somente as pessoas
que possuem a chave do cadeado podem abrir o cofre e obter o conteúdo da mensagem.
(Carvalho, 2008). Este modelo de chaves é mais simples e menos custoso em relação ao
modelo de chaves assimétricas.
Um dos algoritmos utilizados para criptografia simétrica é o AES (Advanced
Encryption Standard), também sendo conhecido com o Rijndael. Ele foi anunciado ao mundo
pelo NIST (Instituto Nacional de Padrões e Tecnologia dos EUA) em 2002, como método
padrão de criptografia do governo americano depois de uma seleção entre vários algoritmos.
No método de chaves assimétricas, também conhecida como criptografia de chaves
públicas, são utilizadas duas chaves diferentes para realizar o processo de codificação e
decodificação. Uma destas chaves será pública e a outra privada. A chave pública pode ser
distribuída livremente enquanto a chave privada deve ser guardada sobre total sigilo, sendo
acessível somente a seu dono.
Segundo Carvalho (2008), toda mensagem codificada com a chave privada só pode ser
decodificada com a sua respectiva chave pública. Toda mensagem codificada com a chave
pública só pode ser decodificada com o uso de sua chave privada correspondente. Desta
forma, se o usuário A deseja enviar uma mensagem codificada para o usuário B, ele pode
codificá-la com a chave pública de B, e enviar para B. Somente o usuário B, que possui a
chave privada B, conseguirá ler o conteúdo da mensagem enviada por A.
Da mesma forma que as chaves simétricas, um mesmo algoritmo de codificação é
utilizado, mas neste caso, ele recebe duas chaves diferentes para o processo de criptografia e
descriptografia. Quando o usuário B deseja se comunicar com o usuário A de forma segura,
ele envia sua chave pública e aguarda a mensagem codificada a partir de sua chave. A figura 3
20
ilustra processo de codificação utilizando a chave privada.
Fonte: Carvalho (2008). Figura 3 - Codificação assimétrica
De posse da mensagem codificado, o usuário B então usa sua chave privada para
descriptografar a mensagem e obter o texto original. A figura 4 ilustra o processo de
decodificação utilizando a chave publica.
Fonte: Carvalho (2008). Figura 4 - Decodificação assimétrica
Sabendo as propriedades das chaves assimétricas garantem-se dois pontos importantes:
Quando o usuário A utiliza a chave pública de B para enviar sua mensagem, ele sabe que
somente o usuário B pode lê-la; Por sua vez, quando o usuário B utiliza sua chave privada
para codificar determinada mensagem, todo aquele que usar sua chave pública tem a garantia
de autenticidade da mensagem. Somente a chave privada de B poderia codificar de forma
correta o texto para se obter a mensagem decodificada de forma legível com sua chave
pública. A garantia de autenticidade é outra premissa fundamental para uma protocoladora.
Um algoritmo de chaves assimétricas muito utilizado é o Rivest Shamir Adleman
(RSA). O RSA foi criado no Massachusetts Institute of Technology (MIT) por três de seus
professores: Ronald Rivest, Adi Shamir e Leonard Adleman. Como o nome sugere, foi
batizado com a primeira letra do sobrenome destes professores. Como este algoritmo usa
21
números primos e a fatoração dos mesmos, o seu custo computacional é muito maior quando
comparado com outro que utiliza chaves simétricas.
2.3 DATAÇÃO DE DOCUMENTOS DIGITAIS
A datação digital tem como objetivo assegurar a existência de um documento
eletrônico em uma determinada data e hora (LIPMAA, 1999). A data e a hora anexadas ao
documento devem condizer com a data e a hora em que o documento foi submetido ao
processo de datação, de modo a garantir que o documento existiu em um determinado
momento no tempo (COSTA et al., 2003).
Apesar da aparência trivial (COSTA et al., 2003), fala que o processo de datação tem
certo grau de dificuldade. Adicionar data e hora corretas a um documento eletrônico não é
trivial. É preciso obter uma hora que seja considerada legal e inserí-la de forma que seja
possível, logo após, recuperá-la.
A data e hora anexadas ao documento devem condizer com a data e a hora em que o
documento foi submetido ao processo de datação, de modo a garantir que o documento existiu
em um determinado momento no tempo (COSTA at al., 2003).
Até o início dos anos 90 a única maneira de datar um documento digital era através de
Autoridades de Datação (AD), que precisavam ser legalmente reconhecidas. Hoje já existem
métodos confiáveis para fazer este trabalho. Sejam eles a partir do sincronismo com um
servidor que disponibilize a hora legal ou utilizando alguma forma de datação relata. Com
relação a esta última pode-se mencionar o método do encadeamento linear e o método da
árvore sincronizada.
2.3.1 A Hora Legal Brasileira
O Network Time Protocol (NTP) é um protocolo para sincronização dos relógios dos
computadores, ou seja, ele define um modo para um grupo de computadores conversarem
entre si e acertar seus relógios, baseados em alguma fonte confiável de tempo, como os
22
relógios atômicos do Observatório Nacional, que definem a Hora Legal Brasileira. (COMITE
GESTOR DE INTERNET DO BRASIL, 2009).
O NTP.br é um projeto que visa oferecer condições para que os servidores de internet
no Brasil estejam sincronizados. Fruto de um acordo entre o Observatório Nacional e o
Núcleo de Informação e Coordenação do Ponto BR, ele disponibiliza um meio de
sincronização para a Hora Legal Brasileira, que é gerada, conservada e disseminada pelo
Observatório Nacional.
O NTP.br mantém vários servidores os quais podem ser utilizados através do protocolo
NTP. O serviço disponível pelo NTP.br é rastreável e auditável em relação a hora
disponibilizada pelo Observatório Nacional.
2.3.2 Método de datação relativa
Um método de datação relativa não se baseia na data e hora correntes, mas na ordem
em que os documentos são enviados para a PDDE. Sua implementação se baseia na teoria da
complexidade de funções de sentido único. Neste tipo de datação não se sabe em que
momento do tempo um documento foi protocolado, mas é possível verificar entre dois
documentos, qual foi datado primeiro. Uma PDDE deve utilizar informações de data e hora o
mais confiável possível. Neste sentido é interessante adotar simultaneamente os dois tipos de
datação: absoluta e relativa. (COSTA et al., 2003).
COSTA et al. (2003) afirma que em um processo de datação seguro o resumo do
documento, o qual se deseja datar, deve ser enviado para uma AD. Esta se utilizando uma data
confiável, chamada Fonte de Tempo, aplica um carimbo temporal e emite um recibo,
armazenando posteriormente em um banco de dados para futura auditoria, este processo é
ilustrado pela figura 5.
23
Banco de Dados
7 56
121110
8 4
21
9 3
Fonte de Tempo
ClienteAutoridadede Datação
ResumoResumo
Internet
ReciboRecibo
ReciboRecibo
Fonte: Costa et al. (2003, p. 3).
Figura 5 - Processo de datação de um documento
Para conseguir formar uma datação relativa, além dos resumos dos documentos, é
necessário utilizar resumos de documentos anteriores, formando um encadeamento. Para isso
é utilizada uma função de sentido único G, que seja resistente a colisão. Todo esse
encadeamento deve ser mantido em um banco de dados para que seja possível fazer qualquer
auditoria posterior necessária. Chama-se esse processo de encadeamento linear.
O encadeamento é formado por links, onde o primeiro link da cadeia deve ser
escolhido de maneira randômica e tornado público, formando o 0L . Em seguida, o segundo
link 1L é gerado utilizando o link anterior 0L e o resumo do documento 0D enviado pelo
cliente. (COSTA et al, 2003). Sendo que a função matemática sugerida por COSTA (2003) de
forma genérica se apresenta da seguinte forma:
))(,,,( 1111 −−−−= nnnnn LHHIDtL
O elemento 1−nt representa a data e a hora em que o documento anterior foi datado,
1−nID é um identificador do cliente que emitiu o resumo do documento anterior, 1−nH é o
resumo do documento anterior e H(Ln-1) é resumo do link anterior. Esse encadeamento é
ilustrado pela figura 6.
24
Fonte: Costa et al. (2003, p. 3).
Figura 6 - Encadeamento linear
O nó inicial é criado com dados randômicos e sem ligação com algum nó anterior. O
diferencial deste método é a possibilidade de garantir a precedência entre dois documentos no
encadeamento e consequentemente no tempo. É impossível que um novo dado seja inserido
em algum ponto da cadeia sem que aconteça uma falha. É preciso ter todos os documentos
originais em mãos e reassiná-los novamente na ordem que se deseja.
Caso isso seja feito de forma a enganar o sistema, mesmo assim as datas serão
modificadas e os recibos antigos se tornarão inválidos, sendo possível, durante uma auditoria
descobrir o ataque. Um dos pontos negativos desse método é a ineficiência para se auditar um
recibo colocado em algum ponto na cadeia. É preciso refazer todo o processo a partir do
recibo que se deseja conferir.
2.4 AUDITORIA DOS RECIBOS
De nada vale todo processo de datar e assinar os documentos se não for possível
auditar todo seu processo e verificar a autenticidade das informações. O ato de auditar refere-
se a uma revisão das atividades e dos registros de um sistema de maneira independente
(NATIONAL COMPUTER SECURYTI CENTER, 1987).
O processo de datação, assinatura e criação do recibo é somente parte do objetivo
pretendido através da protocolação. De nada ele serviria se mais tarde não fosse passível de
auditoria. De posse do recibo e do documento original, a partir de um novo acesso ao site que
executará o serviço de protocolação, deve ser possível conferir a integridade do documento e
a validade do recibo.
Acessando novamente o serviço de protocolação na internet, reenviando o documento
25
digital, refazendo parte do processo e produzindo novamente um resumo do documento
original, um hash, junto das informações do recibo, tem-se todos os dados necessários para
fazer a comparação e validação do documento.
A data e assinaturas do recibo são conferidas e comparadas com o novo resumo e tem-
se uma verificação confiável do documento, sua autenticidade, integridade e existência em
determinada data e hora. Podendo-se inclusive verificar sua posição na corrente construída na
datação relativa.
2.5 O ZEND FRAMEWORK
Para tornar o serviço acessível para usuários de diversos lugares, o ambiente web se
mostra o ideal. A internet hoje possibilita que determinado serviço seja acessado quase de
qualquer lugar do mundo. Com o amadurecimento da grande rede, hoje é possível e seguro
efetuar boa parte das transações necessárias utilizando-a.
As linguagens de programação utilizadas nesse meio evoluíram e hoje possuem
diversos recursos, bibliotecas e frameworks. Utilizando páginas construídas com a linguagem
HyperText Markup Language (HTML) a partir de uma linguagem de programação mais
robusta, a parte visual de uma aplicação se torna acessível em diversos dispositivos. Boa parte
dos sistemas operacionais, inclusive para celulares, já possuem aplicativos para interpretar
páginas HTML.
As páginas em HTML são estáticas, por isso elas precisam de uma linguagem que trata
as informações de forma dinâmica, como por exemplo o JavaScript e o PHP. Quando o cliente
requisita uma página a um servidor na internet, este faz uso do PHP que por sua vez exibe o
resultado desejado no formato HTML. O fluxo é ilustrado na figura 7. Um computador
requisita uma página a um servidor na internet, sendo ela uma página em PHP, ela é
executada e um arquivo em formato HTML é enviado ao cliente.
26
Fonte: Alvarez (2004).
Figura 7 - Estrutura de um ambiente web
Todas as informações da aplicação são salvas no lado servidor, para tal, o servidor
utiliza um banco de dados para persistir as informações. O PHP se comunica diretamente com
ele, requisitando dados salvos e enviando novos para serem guardados. Por questões de
segurança, do lado do servidor, faz se uso da linguagem C para gerar uma camada de
segurança para proteger o servidor e dar início à aplicação.
O PHP sucede de um produto mais antigo, chamado PHP/FI. PHP/FI foi criado por
Rasmus Lerdorf em 1995, inicialmente como simples scripts Perl como estatísticas de acesso
para seu currículo online. (The PHP Group, 2010).
Ele é uma linguagem que roda no lado do servidor, executando em um computador na
internet que recebe dados a partir de uma camada de visualização, de um protocolo de acesso
ou disponibilizando um serviço como o padrão Web Service, que é baseado em requisições do
tipo Hypertext Transfer Protocol (HTTP) e escrito em Extensive Markup Language (XML).
Com o tempo várias novas funcionalidades foram requeridas para o PHP e o código
fonte da linguagem foi disponibilizado para a comunidade. Depois de tantos anos, a
linguagem teve seu nome reduzido a PHP, foi reescrita várias vezes e englobou conceitos
como Orientação a Objetos. Possui uma série de recursos e especializa-se em realizar funções
no mundo web.
Utilizando-se do PHP e de páginas de internet pretende-se criar todo o ambiente
27
necessário para o envio de documentos eletrônicos e criação de recibos.
Em 1997, Zeev Suraski e Andi Gutmans, contribuindo com o PHP, reescreveram todo
o cerne da linguagem, lançando o PHP 3. Em 1999, eles fundaram a Zend Technologies Ltd.,
empresa que hoje é responsável por boa parte das manutenções e mudanças no PHP.
Entre uma série de recursos e aplicações para a linguagem, a Zend Technologies Ltd
criou o Zend Framework, um framework para PHP com licença de código aberto. Dando
continuidade a filosofia do PHP, o Zend Framework tenta ser simples, orientado a objeto,
extensivamente testado e seguir diversos padrões de projetos reconhecidos, como o Model
View Controller (MVC), o Factory e o Singleton.
O Zend Framework permite a utilização de templates XHTML e auxilia abstraindo
parte da comunicação com o banco de dados. Além de facilitar a disponibilização de uma
outra série de recursos como internacionalização, comunicação com Web Services, e uso de
protocolos como o NTP.
2.6 TRABALHOS CORRELATOS
Existem vários artigos, mas poucos softwares que tratam da protocolação digital de
documentos eletrônicos. A única empresa brasileira homologada que tem posse da tecnologia
necessária (hardware e software) para o mesmo é a BRy Tecnologia (BRY CERTIFICAÇÃO
DIGITAL, 2010) localizada em Florianópolis.
Seu produto é a Bry PDDE, um misto de hardware e software capaz de protocolar
documentos eletrônicos. É um equipamento que pode ser instalado nas empresas e ser
acessado pelos computadores da mesma. Entre os artigos disponíveis, pode-se destacar o
Protocoladora Digital de Documentos Eletrônicos (COSTA et al, 2003). A figura 8 ilustra o
equipamento.
28
Fonte: BRy Certificação Digital (2010).
Figura 8 – BRy PDDE
A solução BRy PDDE é um sistema protocolador que garante a autoria de documentos,
a irretroatividade e a sua integridade. Permite afirmar se o documento eletrônico não sofreu
alteração desde o momento da protocolação, assegurando, desta forma, a validade jurídica da
informação (BRY CERTIFICAÇÃO DIGITAL, 2010). A solução é composta de uma série de
algoritmos postos dentro de um hardware conectado a internet. Para garantir a legitimidade
legal, ela faz uso da Hora Legal Brasileira (HLB), sincronizada com o uso do Network Time
Protocol (NTP), um protocolo utilizado para sincronizar relógios através da internet.
A partir de determinado sistema de acesso é criado um resumo do documento que
deseja-se protocolar e este resumo é enviado a BRy PDDE. A protocoladora recebe o resumo
e faz a solicitação da hora atual e sua localização a determinado servidor pré-configurado. Ao
receber a resposta, fazendo uso de vários algoritmos, a protocoladora assina e carimba
temporalmente o resumo, armazenando em um banco de dados o resultado do processo. Logo
após um recibo é criado e enviado ao sistema que solicitou a protocolação.
O artigo de nome Protocoladora Digital de Documentos Eletrônicos (COSTA et al,
2003) trata de requisitos básicos de segurança e propõe procedimentos padrões para uma
protocolação confiável de documentos digitais. Ele aborda as necessidades básicas do
processo, como criptografia e assinatura, sugerindo ao fim métodos matemáticos para garantir
a datação dos documentos eletrônicos, com ênfase na idéia de que um método de datação
relativo deve ser empregado. Fazendo uso de técnicas matemáticas, deve ser possível verificar
a precedência entre documentos, em relação a data de sua protocolação.
29
3 DESENVOLVIMENTO
As seções seguintes detalham o funcionamento do protótipo de serviço de protocolação
de documentos eletrônicos e seu funcionamento em ambiente web. Sua operacionalidade é
explicada com ajuda de casos de uso, telas, diagramas de classe e sequência para as situações
mais complexas, tendo por fim as conclusões do trabalho.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
O serviço de protocolação digital de documentos eletrônicos, para estar disponível e
utilizar determinados recursos na internet, precisa estar em meio web. Para tal ele deve ser
apresentar como um site e ter todos os requisitos necessários para a protocolação.
Para o processo de protocolação são necessários alguns requisitos de segurança para
garantir a validade dos recibos e a integridade da informação manipulada. A seguir são
apresentados os requisitos funcionais e não funcionais do serviço.
Requisitos Funcionais RF01 – O sistema deverá ser capaz de receber documentos eletrônicos e criar um resumo dos mesmos (hash). RF02 – O sistema deverá ser capaz de aplicar um carimbo temporal nos documentos enviados. RF03 – O sistema deverá ser capaz de assinar os documentos eletrônicos para garantir a autenticidade da protocoladora digital e gerar um recibo como comprovante do processo. RF04 – O sistema deverá ser capaz de confirmar a existência de determinado documento em determinado período do tempo. RF05 – O sistema deverá ser capaz de acessar algum serviço confiável de hora legal para obter a hora correta de datação dos documentos.RF06 – O sistema deverá ser capaz de gerar um recibo para o usuário como prova da protocolação. RF07 – O sistema deverá ser capaz de conferir o recibo a partir do seu envio junto do documento.
Quadro 1- Requisitos funcionais
30
Requisitos Não Funcionais
RNF01 – O sistema deverá fazer uso da linguagem PHP.
RNF02 – O sistema deverá utilizar o Zend Framework.
RNF03 – O sistema deverá funcionar em ambiente web e utilizar HTML na camada de visão. RNF04 – O sistema deverá utilizar o protocolo NTP e buscar a Hora Legal Brasileira para datar os documentos. RNF05 – O sistema deverá utilizar o banco de dados MySql para armazenar informações dos recibos e documentos. RNF06 – O sistema deverá utilizar o método de encadeamento linear para aplicar uma datação relativa nos documentos junto da datação absoluta.
Quadro 2 - Requisitos não funcionais
3.2 ESPECIFICAÇÃO
Para criar a especificação foi utilizada a ferramenta Enterprise Architect. A ferramenta
tem recursos para construir os artefatos propostos de acordo com a Unified Modeling
Language (UML), uma linguagem de modelagem que facilita a visualização do sistema por
partes ou como um todo. São apresentados a seguir, diagramas de caso de uso, classe e
sequência e as tabelas do banco de dados.
3.2.1 Diagramas de casos de uso
Os casos de uso são artefatos que mostram a iteração entre o usuário, sendo ele
humano ou máquina, e o sistema. No ambiente do serviço de protocolamento digital de
documentos eletrônicos existem três atores: visitante, empresa e usuário.
Fazendo uso desses atores, é possível dividir o conjunto de casos de uso em dois
grupos: casos de uso de cadastros e casos de uso de protocolação. Mesmo sendo o primeiro
indispensável, o foco e a complexidade encontram-se no segundo. Os principais casos de uso
são detalhados a seguir.
31
3.2.1.1 Casos de usos de cadastros
A figura 9 ilustra o caso de uso que é executado por um visitante. Em um primeiro
momento ao acessar o site, apenas encontra-se disponível o cadastro de novas empresas.
Figura 9 - Caso de uso que pode ser executado pelo visitante
Sendo que depois de cadastrada, uma empresa pode cadastrar novos usuários do
sistema. Sendo assim, todo usuário do sistema é ligado diretamente a uma empresa e uma
empresa pode ter vários usuários com a permissão de protocolar documentos. O cenário com
os casos de uso que podem ser executados pela empresa encontra-se na figura 10.
Figura 10 - Casos de usos que podem ser executados pela empresa cadastrada
Os casos detalhados dessa seção são: Cadastrar Usuário, Visualizar Usuários
Cadastrados, Editar Usuário e Remover Usuário.
No quadro 3 é apresentado o fluxo do detalhamento do caso de uso de Cadastro de
32
Usuário. Uma vez o ator empresa logado, apresenta-se um formulário com os campos de
informações necessárias para cadastros de usuários.
UC1.04 – Cadastrar Usuário: permite o cadastro de novos usuários com acesso ao serviço
Pré-condições Empresa possui um usuário previamente cadastrado no sistema
Cenário Principal
1) Usuário preenche campos com informações do usuário a ser cadastrado. 2) Sistema valida dados preenchidos. 3) Sistema envia um e-mail de boas vindas. 4) Sistema mostra uma mensagem de sucesso.
Exceção 01 No passo 3, caso o sistema não consiga enviar o e-mail, uma mensagem informando uma falha é exibida.
Exceção 02 No passo 2, caso os dados sejam inválidos, o sistema exibe um alerta e pede que estes sejam corrigidos.
Pós-condições Novo usuário com permissão de protocolar documentos é criado no sistema. E-mail de boas vindas é enviado.
Quadro 3 - Detalhamento do caso de uso Cadastrar Usuário
Nos quadros 4, 5 e 6, é apresentado o detalhamento do caso de uso de Visualizar
Usuários Cadastrados e os dois outros casos de uso que o estende: Remover Usuário e
Editar Usuário.
UC1.05 – Visualizar Usuários Cadastrados: permite a visualização de usuários cadastrados
Pré-condições Empresa possui um usuário previamente cadastrdo no sistema
Cenário Principal 1) Usuário clica no link “listar usuários”. 2) Sistema exibe lista de usuários cadastrado pelo usuário atual.
Fluxo alternativo 01 No passo 1, o usuário seleciona um usuário da lista e executa o UC1.06
Fluxo alternativo 02 No passo 1, o usuário seleciona um usuário da lista e executa o UC1.07
Quadro 4 – Detalhamento do caso de uso Visualizar Usuários Cadastrados
Na tela em que se apresenta a lista de usuários, encontram-se disponíveis os botões
para os casos de uso de estendem o Visualizar Usuários Cadastrados.
33
UC1.06 – Editar Usuário: permite a edição de usuários cadastrados pelo ator empresa
Cenário Principal 1) Usuário seleciona um usuário na lista e clica em "Remover". 2) Sistema pede uma confirmação. 3) Sistema remove o usuário escolhido.
Quadro 5 - Detalhamento do caso de uso Editar Usuário
UC1.07 – Excluir Usuário: permite a exclusão de usuários cadastrados pelo ator empresa
Cenário Principal
1) No passo 1, o usuário pode escolher algum usuário e clica em "Editar". 2) Sistema busca informações do banco de dados e exibe o formulário de edição com os dados do usuário. 3) Usuário altera as informações que desejar e clica em "Salvar". 4) Sistema valida os campos e salva as alterações.
Exceção 01 No passo 4, caso algum campo tenha um tipo de dado incorreto, é imitada uma alerta pedindo que as informações sejam corrigidas
Quadro 6 - Detalhamento do caso de uso Excluir Usuário
3.2.1.2 Casos de uso de protocolação
É nesta seção que se encontram os casos de usos principais do serviço: Protocolar
Documento e Validar Recibo.
Na figura 11 são mostrados os casos de uso que podem ser executados pelos usuários
que são cadastrados pelos atores empresas, etapa vista na seção anterior.
34
Figura 11 - Casos de usos que podem ser executados pelo usuário
No quadro 7 é detalhado o caso de uso de Protocolar Documento. Este é o caso de
uso utilizado para se protocolar um documento digital e receber um recibo do processo. O
documento eletrônico é enviado ao site e após a protocolação um recibo é emitido. Este recibo
é armazenado em banco na forma de uma corrente, onde cada nó referencia o anterior.
UC2.02 – Protocolar Documento: permite a protocolação de novos documentos
Pré-condições - Usuário estar logado no sistema. - Documento precisa estar disponível
Cenário Principal
1) Sistema requisita documento o qual deseja-se protocolar. 2) Usuário envia documento. 3) Sistema cria um hash do documento. 4) Sistema requisita informações de data e hora a um servidor externo. 5) Sistema assina documento. 6) Sistema salva informações e criar nó na corrente de recibos. 5) Sistema emite um recibo como comprovante do processo. 6) Sistema mostra uma opção de download do recibo ao usuário.
Exceção 01 No passo 4, caso o sistema não consiga acessar um servidor de data e hora externo, uma mensagem de erro é exibida.
Pós-condições Uma nova entrada na corrente de recibos é criada.
Quadro 6 - Detalhamento do caso de uso de Protocolar Documento
35
No quadro 8 é detalhado o caso de uso de Validar Recibo. É neste caso de uso que é
possível a um usuário cadastrado verifica a veracidade de um recibo e a integridade de um
documento. O documento digital é enviado a sistema junto do recibo e o sistema executas as
etapas necessárias para imitir uma resposta.
UC2.03 – Validar Recibo: permite verificar a veracidade de um recibo.
Pré-condições - Usuário estar logado no sistema. - Documento precisa estar disponível
Cenário Principal
1) Sistema requisita documento original e recibo da protocolação. 2) Sistema cria um hash do documento. 3) Sistema decodifica dados do recibo. 4) Sistema valida assinatura. 5) Sistema verifica se existe o recibo enviado na corrente armazenada. 5) Sistema exibe data de emissão do recibo, data da protocolação e o usuário responsável.
Exceção 01 No passo 3, caso a assinatura seja inválida, o sistema emite uma mensagem avisando que o recibo é inválido.
Exceção 02
No passo 3, caso a assinatura é valida mas não é encontrada nenhuma entrada no banco de dados para o recibo em específico, o sistema emite uma mensagem avisando da possível invalidade do recibo.
Quadro 7 - Detalhamento do caso de uso Validar Recibo
3.2.2 Diagramas de classe
Os diagramas de classe fornecem uma visão de como as classes do sistema estão
organizadas e como elas se relacionam entre si. Mostram seus atributos e métodos,
identificando onde é feito o uso de cada objeto.
Essa seção pode ser dividida em três partes distintas: Modelo, Controle e
Protocolamento.
3.2.2.1 Classes de Modelo
A figura 12 mostra como é organizada a parte de modelo e persistência do serviço de
protocolamento.
36
Figura 12 - Classes de modelo
Nessa seção estão representados os objetos que trafegam pelo sistema e são persistidos
no banco de dados. Tem-se o funcionário, que representa o usuário cadastrado pela empresa, a
empresa, que é a entidade que primeiramente cadastra-se no sistema, e o recibo, que é
guardado e encadeado para futuras auditorias.
Como na aplicação é utilizado o Zend Framework, parte da lógica de persistência é
abstraída. Os objetos que representam tabelas em banco estendem da classe
Zend_Db_Table_Abstract e classes de mapeamento, com o sufixo de Mapper são
responsáveis pela comunicação entre o sistema e as suas entidades.
Destaca-se a classe Application_Model_RecibeMapper que é responsável pelo
controle, criação e verificação da cadeia de recibo que é armazenada. Cria novos recibos a
partir do método save, busca recibos por diversos critérios diferentes com os métodos find,
findAll e findHash, e é capaz de verificar a ordem dos nós da cadeia com o método
verifyRecibeOrder.
37
3.2.2.2 Classes de Controle
A figura 13 mostra como estão organizadas as classes de controle do serviço.
Figura 13 - Classes de controle
As classes de controle são as que se comunicam diretamente com a interface. Quando
o usuário faz alguma requisição, são elas que recebem os dados enviados e processam a
resposta correspondente.
A associação do tipo “use” é utilizada para identificar quando uma classe faz uso de
outra. Neste caso a classe alvo não é um atributo, seu uso é feito através da criação de uma
nova instância enquanto seu uso é necessário.
O Zend Framework também abstrai parte da complexidade necessária para o controle e
diversas páginas do site são controladas por vários controles. Todos eles estendendo a classe
Zend_Controller_Action, classe essa que disponibiliza recursos para recepção de
parâmetros, instanciação de formulários, redirecionamentos e outros recursos. Os formulários,
por sua vez, estendem a classe Zend_Form, que é responsável pela criação dos formulários.
É nesta seção também que se encontra a classe Protocoladora_Auto, uma
implementação da interface Zend_Auth_Adapter_Interface. Esta classe é responsável pelo
controle de acesso e as restrições impostas a cada tipo de usuário cadastrado no sistema. As
38
classes de controle invocam seus métodos para obter informações para permitir ou não o
acesso a determinadas áreas do sistema.
Também existe uma classe utilitária para criar hash’s dos documentos, a
FileHashHandler, que é chamada para converter o documento enviado em um resumo para
ser utilizado pelas classes de protocolação.
3.2.2.3 Diagrama de classes de protocolação
A figura 14 mostra como estão organizadas as classes responsáveis pela protocolação
digital dos documentos eletrônicos.
Figura 14 - Classes de protocolação
Nesta seção estão dispostas as classes responsáveis pelo coração do sistema. São elas
que são requisitadas pelos controles e utilizam as bibliotecas envolvidas para efetuar a
protocolação e criação dos recibos. São elas também que invocam as classes de mapeamento
para persistir informação em banco de dados.
39
A classe de entrada é a Protocoladora, ela centraliza toda a entrada e saídas de dados.
Quando um novo documento precisa ser protocolado, é para ela que ele deve ser enviado.
Assim como também é responsável por validar um recibo criado anteriormente.
A classe Assinatura é responsável por criptografar, decriptografar e realmente assinar
os resumos dos documentos. Ela é invocada pela protocoladora durante o processo de
protocolação junto de outra classe, a NtpSync. Esta última classe que é responsável por buscar
uma hora legal e válida através do protocolo NTP.
Por motivos de segurança, as chaves utilizadas no sistema precisam estar armazenas de
forma segura e criptografadas. Para o acesso a essas chaves, a classe de assinatura utiliza a
classe KeyRepository, que é responsável pelo controle das chaves, controlando seu
repositório. A KeyRepository, por sua vez, utiliza a classe Security para obter informações
necessárias para ter acesso as chaves. O método getSystemKey da classe Security é
sublinhado pois é estático.
3.2.3 Diagramas de Sequência
Os diagramas de sequência servem para ilustrar as etapas de um processo, a trocas de
mensagens entre as diversas camadas do sistema. São apresentados de forma detalhada dois
diagramas de sequência, o Protocolar Documento (UC2.02) e o Verificar Recibo
(UC2.03).
A figura 15 ilustra o processo de Protocolação através do seu diagrama de sequência.
40
Figura 15 - Diagrama de sequência para Protocolar Documento
O processo se iniciar na camada de visão, na interface, onde o usuário envia o
documento eletrônico e o controle posteriormente requisita que seja feita um resumo do
mesmo. Do resumo feito, o controle solicita que esse resumo seja protocolado, mensagem
essa enviada a classe Protocoladora.
A Protocoladora busca as chave necessárias para o processo no repositório de chaves.
Uma vez obtida a chave, a Protocoladora requisita uma data e hora legal. De posse de
ambos, a assinatura é feita e o recibo criado. Ao final do processo, é persistida a informação
em banco e adicionado um nó na corrente de recibos.
A figura 16 ilustra o diagrama de sequência do processo de Verificar Recibo.
41
Figura 16 - Diagrama de sequencia para Verificar Recibo
Esse processo é bastante semelhante com o de protocolação, visto que parte do
processo é refeito mas com um objetivo inverso.
O processo se inicia com o usuário requisitando a auditoria da validade de um recibo,
ele envia então o documento original e seu respectivo recibo. O sistema cria um resumo do
documento e faz a leitura do recibo. De posse destes dois, o sistema invoca a protocoladora
para validar as informações.
A protocoladora busca a chave pública do sistema no repositório de chaves e testa a
validade do recibo. Mostrando ao fim a validade do recibo e a sua respectiva presença na
corrente persistida em banco.
3.2.4 Estrutura do banco de dados
A figura 17 ilustra as tabelas utilizadas pela aplicação.
42
Figura 17 - Estrutura do banco de dados
O banco de dados é responsável por armazenar todas as informações relativas a
aplicação. A tabela key guarda as chaves do sistema, a pública e privada, utilizadas para
efetuar as assinaturas dos resumos dos documentos digitais. A tabela user guarda
informações do usuário mestre do sistema, um usuário interno da aplicação.
As tabelas funcionário e empresa guardam informações dos usuários cadastrados no
sistema e a recibo, dos recibos protocolados. A tabela recibo guarda informações na forma de
uma corrente, cada nova entrada referencia a entrada anterior. Isso garante a datação relativa
dos documentos digitais protocolados.
3.3 IMPLEMENTAÇÃO
Nessa seção são apresentadas as ferramentas utilizadas, técnicas e informações
específicas da aplicação. Ela contém questões peculiares e explica como são resolvidos alguns
requisitos do sistema.
43
3.3.1 Técnicas e ferramentas utilizadas
A aplicação foi implementada utilizando a linguagem PHP (versão 5) no lado servidor,
para executar toda a lógica e persistir toda a informação necessária, e HTML para a camada
de interface, a qual interage com o usuário.
Como ambiente de desenvolvimento foi escolhido o Zend Studio (versão 7.0.0), uma
ferramenta criada pela Zend para maximizar a produtividade de profissionais que trabalham
com PHP. Como framework foi escolhido o Zend Framework (versão 1.10.0), por ser um dos
mais robustos e completos para utilizar na aplicação. Ele abstrai uma série de recursos que
teriam que ser implementados e testados (o qual já foi discutido na seção 2.4.1.1).
Para lidar com a parte da criptografia e assinatura, foram utilizadas duas bibliotecas, a
Crypt_RSA e a AES. Para gerar as chaves assimétricas utilizadas pela aplicação foi utilizada a
ferramenta OpenSSL. Para atender a requisitos de segurança, a linguagem C foi utilizada para
criar uma camada de segurança para iniciar o servidor da aplicação.
O servidor web escolhido foi o Apache e a solução para persistência em banco de
dados o MySQL. O Apache é uma ferramenta open source, que suporta scripts PHP,
disponibilizada pela Apache Software Foundation, organização responsável por vários
projetos disponibilizados a comunidade. O MySQL é uma solução também open source e
distribuída pela Oracle, sendo muito popular quando em conjunto com PHP.
3.3.1.1 O OpenSSL
O OpenSSL Project é um projeto colaborativo para a criação de uma ferramenta
robusta para criptografia que implementa também os protocolos de comunicação Secure
Sockets Layer (SSL) e Transport Layer Security (TSL).
Na implementação do projeto, a ferramenta teve o papel de criação das chaves
assimétricas utilizadas pelo algoritmo RSA. Ela não tem contato direto com a aplicação e
somente serviu para gerar as chaves. Chaves estas que ficam guardadas em banco de dados
criptografadas.
Qualquer outra ferramenta para gerar chaves RSA poderia ser utilizada em vez do
OpenSSL, mas ela foi escolhida devido sua praticidade e confiabilidade. Seu uso é somente
em um momento inicial ou na hora de uma possível troca de chaves do sistema.
44
3.3.1.2 O Crypt_RSA e o AES
Para fazer uso de métodos de criptografia e posteriormente assinar resumos de
documentos, é preciso escolher algoritmos já existentes ou criar um novo. Para garantir a
confiabilidade de aplicações escolheram-se dois algoritmos muito testados aos longos dos
anos, o RSA e o AES (ambos citados anteriormente na seção 2.2.3).
A biblioteca Crypt_RSA está disponível no repositório PHP Extension and
Application Repository (PEAR), um framework e sistema de distribuição para componentes
PHP. Atualmente a versão estável do Crypt_RSA é a 1.2.1, funcionando com o PHP versão 4
ou superiores.
Ela é capaz de manipular e criar chaves baseadas no algoritmo RSA, possuindo
funções para criptografia, decriptografia e assinatura de informações. É distribuída livremente
e pode ser utilizada sobre a mesma licença do PHP.
Chris Veness é o criador de uma implementação do algoritmo AES (Rijndael) para
PHP, a biblioteca é distribuída sobre a licença Creative Commons (CC-BY) versão 3.0. Ela é
utilizada como método de criptografia simétrica na aplicação. A biblioteca funciona com a
versão 4 do PHP ou superiores.
A integração do Crypt_RSA e do AES é demonstrado nas próximas seções.
3.3.1.3 O Repositório de chaves assimétricas e a senha mestre do sistema
As chaves que são usadas para assinar os resumos dos documentos estão armazenadas
em banco, criptografadas com o algoritmo AES. Este é um importante requisito de segurança.
A chave pública da aplicação pode ser distribuída livremente, sendo que com essa chave, caso
necessário, um software externo pode fazer a leitura das informações do recibo. Porém, a
chave privada deve ser secreta.
Para tal foi criado um mecanismo de segurança que deve ser usado para a aplicação
funcionar. Um programa escrito em C é utilizado para requisitar uma senha e dar inicio ao
servidor Apache e ao MySQL. O quadro 9 mostra o código.
45
Quadro 8 - Programa em C para iniciar aplicação
Esse mecanismo não faz nenhuma verificação de segurança, ele requisita uma senha e
a coloca em um escopo que seja acessível pelo Apache. Enquanto ele estiver executando, a
variável está disponível, em consequência, a senha. Esta senha por sua vez é capturada pelo
PHP como uma variável de ambiente do Apache.
Na aplicação então é feita uma verificação de segurança pela classe Security. A
classe faz a leitura da variável e compara a senha enviada com um arquivo contendo esta
mesma senha criptografada com AES. A aplicação decriptografa o arquivo usando a senha
como chave e caso o resultado seja a própria chave, então o serviço torna-se disponível. O
quadro 10 ilustra o funcionamento da classe.
46
Quadro 9 - Verificação da senha do sistema
Essa é a senha mestre do sistema, utilizada para permitir o início da aplicação e no
passo seguinte para decriptografar a chave privada da aplicação. Ela não deve ficar
armazenada em um local que deve ser de conhecimento apena do administrador a aplicação.
Caso a senha enviada ao iniciar o servidor seja inválida, ou tente-se iniciar o servidor de
alguma outra forma, o serviço fica indisponível.
Uma vez a senha sendo válida, então a aplicação pode recuperar as chaves assimétricas
do banco e decriptografá-las corretamente. O quadro 11 ilustra esse processo.
47
Quadro 10 – KeyRepository
A classe KeyRepository é responsável por carregar as chaves usadas pelo sistema. Ele
requisita a classe Security a chave mestra e ao banco as chaves criptografadas. Usando o
algoritmo AES e a chave mestra, ele decriptografa e carrega a chave pública e privada do
sistema. Deixando-a disponível para as classes que fazem o processo de protocolação.
Sendo as chaves criptografadas em banco, garante-se que mesmo com acesso a elas,
podendo-se copiar até o sistema inteiro, sem a chave mestra, é impossível utiliza-lo. Pode-se
trocar a chave privada do sistema por uma conhecida nesse processo de cópia, mas aí a chave
pública fornecida pelo sistema oficial não mais será funcional e perde-se a garantia de
autenticidade dos recibos.
3.3.1.4 Autenticação dos usuários
Existem dois tipos de usuários a nível de implementação na aplicação: a empresa e o
funcionário. A empresa é a primeira a ser cadastrada no sistema e ela por sua vez cadastra
novos usuários para efetivamente irão usar o serviço de protocolação, já que o usuário
empresa não tem esse recurso.
Para controlar os acessos e definir o escopo do usuário logado, as classes de controle
48
utilizam um recurso do Zend Framework, o Zend_Auth. Uma classe que abstrai questões
como a criação de sessões para os usuários. Para funcionar, o Zend_Auth precisa trabalhar em
conjunto com uma classe adaptadora que implemente a interface
Zend_Auth_Adapter_Interface, também disponibilizada pelo framework. O quadro 12
ilustra essa implementação.
Quadro 11 - Classe ProcoladoraAuto
No momento em que o usuário envia suas credenciais, o LoginController chama
uma instancia do Zend_Auth passando como adaptador o ProcoladoraAuto, então o método
authenticate é chamado. Esse método tenta logar o usuário primeiramente como empresa e
caso não obtenha sucesso, verifica se ele é um funcionário.
Caso obtenha sucesso em uma das duas tentativas, as informações do usuário são
armazenadas em sessão e ficam disponíveis para toda aplicação. Os controles utilizam os
métodos hasIdentity e getIdentity, disponibilizados pela classe Zend_Auth, para
verificar se o usuário está logado e buscar suas credenciais, respectivamente.
49
3.3.1.5 O serviço de NTP e a obtenção de uma hora legal.
O Observatório Nacional disponibiliza uma lista de servidores NTP para acessar a
Hora Legal Brasileira. O Zend Framework disponibiliza um recurso de sincronia de tempo
através da classe Zend_TimeSync. O Quadro 13 apresenta esse processo.
Quadro 12 - Sincronia de tempo
O Zend_TimeSync é instanciado e são adicionados os servidores de NTP. Logo após,
o método getDate é utilizado para buscar a data atual. O método roda a lista de servidores
disponíveis buscando a informação, caso nenhum deles responda, uma exceção então é
lançada.
3.3.1.6 Protocolação dos documentos
O processo de protocolação começa com o envio de um documento digital através de
um formulário no site. O ProtocoladoraController cria um novo
50
Application_Form_Documento, o qual é enviado para a tela. Uma vez o formulário
preenchido e enviado o documento, o ProtocoladoraController chama o método
createHash da classe FileHashHandler. Este método cria um hash do documento enviado
utilizando a função md5 nativa do PHP.
Tendo o resumo do documento, o ProtocoladoraController então chama a função
protocolar da classe Protocoladora passando o hash e o id do usuário atual logado
como parâmetro. O funcionamento do método protocolar é apresentado no Quadro 14.
Quadro 13 – Método protocolar da classe protocolação
Uma nova instancia da classe NtpSync é criada para buscar a data atual e uma nova
instância da classe Assinatura é criada para assinar o hash. As chaves são carregadas, a
data é buscada e então é assinado o hash. O processo de assinatura consiste em criptografar o
resumo atual com a chave privada do sistema usando o algoritmo RSA através da biblioteca
Crypt_RSA. Uma vez o hash assinado é criado um pré-recibo contendo a assinatura, a data
atual e o id do usuário. O pré-recibo então é salvo em banco.
A criação do recibo é apresentada no quadro 15.
51
Quadro 14 - Criação do recibo
O sistema inicia um nova transação e seta o usuário do recibo, no caso o
id_funcionário. O recibo recebe uma referência do recibo anterior com o método
getLastRecibeHash. Este método faz um hash do recibo anterior para formar uma corrente
que garante a datação relativa. Se tudo ocorrer corretamente, o recibo salvo é retornado e a
transação é fechada.
Uma vez o recibo criado, encadeado e salvo em banco, a última etapa é assiná-lo. O
hash do documento contido no mesmo já foi assinado, mas para afirmar autenticidade do
recibo, ele é transformado em texto pelo método makeRecibe visto no Quadro 14 e
reassinado. O formato do recibo é ilustrado na figura 18.
52
Figura 18 - Recibo Exemplo
O recibo possui a data da protocolação, a assinatura do documento, o hash anterior e o
usuário responsável pelo processo. Para futura leitura usou-se o símbolo “#-#” como
separador. O item 1 ilustra o formado, o item 2, um exemplo de recibo ainda não assinado e o
item 3 mostra como é a informação que chega até o usuário final.
3.3.1.7 Validação e auditoria dos recibos
Para validar a protocolação de um documento digital, desejando-se verificar a
integridade do documento ou validade do recibo é preciso reenviar ambos para o serviço de
protocolação. A classe ProtocoladoraController cria um novo
Application_Form_Verifica e este é enviado para tela, para ser preenchido pelo usuário.
Uma vez o formulário preenchido e enviado o documento digital original e o recibo, a
ProtocoladoraController cria novamente um hash do documento original e faz a leitura
do recibo. Logo após envia as informações para a classe Protocoladora chamando o método
verificaProtocolacao. O método é apresentado no quadro16.
53
Quadro 15 - Método verificaProtocolacao
O método instancia uma nova classe de assinatura e carrega as chaves do sistema
acessando o repositório de chaves. Logo após chama o método readRecibe da classe
Assinatura que faz a decriptografia do recibo usando o algoritmo de chaves assimétricas
RSA através da classe Crypt_RSA, utilizando a chave pública do sistema e lê os dados do
recibo.
Uma vez os dados decriptografados, então é chamado o método validate_sign da
classe Assinatura que valida a assinatura do recibo. O método recebe o hash do arquivo
original e a assinatura do mesmo. Utilizando-se o algoritmo RSA e da chave pública do
sistema ele decriptografa a assinatura e compara com o resumo do documento. Se ambos
forem idênticos, então a assinatura é valida e o recibo é verdadeiro.
No próximo passo o sistema instancia um novo Application_Model_RecibeMapper,
que faz o mapeamento dos recibos para a respectiva tabela em banco e chama o método
verifyRecibeOrder. Este método percorre a tabela de recibos, encontra o recibo qual se
deseja conferir e verifica a datação relativa refazendo a corrente do recibo atual até o início da
corrente. Processo baseado no sistema descrito na seção 2.3.2
Feito todos os passos, então o sistema informa a validade do recibo quanto a sua
assinatura e quanto a datação relativa. Mostrando também a data de protocolação e o usuário
responsável.
54
3.3.2 Operacionalidade da implementação
Nesta seção é apresentado como é iniciada a aplicação e como é seu funcionamento.
Como acontece o processo de protocolação de um documento digital, a emissão e validação
de um recibo.
Antes de tudo é preciso dar inicio a aplicação e isto deve ser feito pelo administrador
do serviço. Ele irá iniciar o servidor Apache e o banco de dados MySQL através de um
executável, o qual requisita a ele um usuário e senha. O processo de solicitação de senha e
inicio do servidor é ilustrado na figura 19.
Figura 19 - Iniciando serviço de protocolação
Se a senha digitada é incorreta, então ao tentar acessar a aplicação é exibida uma
mensagem de erro.
Quando a senha digitada é válida, então o serviço mostra-se disponível, com a opção
de fazer um novo cadastro ou efetuar login. Como ilustrado na figura 20.
55
Figura 20 - Tela inicial do sistema
Caso o usuário já esteja cadastrado como uma empresa ou como um funcionário de
determinada empresa, então ele pode apenas logar no serviço, caso contrário ele deve
cadastrar-se como ilustra a figura 21.
Figura 21 - Cadastro de nova empresa
A tela de login é a mesma para os dois tipos de usuário e é mostrada na figura 22.
56
Figura 22 - Tela de login do sistema
Uma vez logado no sistema, o usuário que se cadastrou como uma empresa tem a
opção de cadastrar novos usuários do tipo funcionário, para protocolar documentos ou editar
os já existentes. O cadastro de usuário é ilustrado na figura 23 e a lista de usuários para
edição na figura 24.
57
Figura 23 - Cadastro de usuários de uma empresa
Figura 24 - Lista de usuários cadastrados de uma empresa
Ainda nessas telas o usuário empresa logado pode editar seus dados clicando no link
Editar e sair clicando em Sair.
Uma vez o usuário funcionário cadastrado pela empresa, ele então pode fazer uso do
serviço de protocolação. As opções disponíveis para este tipo de usuários estão ilustradas na
figura 25.
58
Figura 25 - Opções do usuário funcionário
Na tela de entrada o usuário visualiza uma lista dos últimos protocolos realizados,
podendo baixar novamente o recibo. Nesta tela estão disponíveis os links para protocolar um
novo documento, verificar um protocolo, listar os protocolos e sair do sistema.
A figura 26 ilustra como é a tela do link Protocolar Documento. É exibido um
formulário com um campo de envio de arquivos onde o usuário escolhe o documento que
deseja protocolar.
Figura 26 - Tela do link Protocolar Documento
A figura 27 mostra o sistema emitindo o recibo e dando a opção de download do
mesmo.
59
Figura 27 - Recibo sendo emitido pela protocoladora
A figura 28 mostra como é exibida a tela de Verificar Documento onde o usuário
pode enviar um documento digital o qual deseja-se conferir com seu protocolo.
Figura 28 – Tela Verificar Documento
O recibo e o documento digital são enviados e todo processo de verificação é
executado. O exemplo de um resultado pode ser visto na figura 29.
60
Figura 29 - Resultado da validação de um recibo
Nesta pode-se observar que o recibo foi considerado válido e foi encontrado na
corrente de recibos no banco de dados. O sistema também mostra o usuário responsável pela
protocolação e a empresa que o cadastrou.
Como pode-se observar durante todo o processo, o serviço é bem simples e intuitivo de
se usar. Toda complexidade fica abstraída pelo sistema.
3.4 RESULTADOS E DISCUSSÃO
Os resultados obtidos ao término da aplicação são satisfatórios, conseguiu-se atender
todos os requisitos propostos no início e um serviço que, com mais alguns incrementos, ficará
em um estado maduro o suficiente para ser testado em alguma empresa ou instituição.
Com relação ao produto da BRY CERTIFICAÇÃO DIGITAL (2010), conseguiu-se
desenvolver parte da funcionalidade proposta pela solução mista da empresa. De um ponto de
vista externo, visto que não se tem acesso aos códigos do equipamento, considera-se que o
trabalho conseguiu-se atingir os requisitos básicos de segurança também atingidos pelo
equipamento.
Da monografia de Costa et al (2003), que elencava a importância da datação relativa,
conseguiu-se implementar neste trabalho um dos métodos descritos, o da corrente de recibos.
Este mostrou-se muito interessante para firmar certos requisitos de segurança, como a
integridade e precedência entre documentos.
A criação dos resumos dos documentos atendeu as exigências de segurança, após o
upload, transformando os documentos em hash’s, tem-se a garantia de que somente
61
determinado documento pode gerar um hash único correspondente e qualquer modificação é
identificada. Também se ganha na confidencialidade por que nenhum arquivo é armazenado
no servidor, somente os resumos.
Com o uso do protocolo NTP e do serviço disponibilizados pelo NTP.br, tem-se uma
hora legal Brasileira para o processo de protocolação. Isso garante a confiabilidade da data de
assinatura e criação dos recibos, já que ela não fica atrelada ao servidor que disponibiliza o
serviço. No âmbito jurídico é essencial que a hora de protocolação seja provida por um órgão
confiável.
Para as assinaturas e criação dos recibos, usou-se uma biblioteca escrita em PHP que
faz uso do algoritmo RSA. A biblioteca se mostrou bastante simples, o armazenamento das
chaves ocorreu em banco de dados, criptografadas com uma chave mestre.
Criptografando as chaves com esta senha mestre, tornou-se muito difícil criar uma
cópia falsa do sistema que seja capaz de protocolar documentos e gerar recibos válidos. Como
a autoria dos recibos é garantida pela chave privada do sistema, que está criptografada, criar
recibos falsos como se fossem verdadeiros torna-se muito difícil.
O método de datação relativa proposto agregou muito valor ao serviço, tem-se uma
segurança a mais já que necessariamente seu recibo precisa estar na corrente de recibos. Isso
possibilita também que a precedência entre dois documentos possa ser fortemente garantida.
Afinal eles estão obrigatoriamente em um ponto anterior ou sucessor na corrente.
Os recibos mostraram-se bastante confiáveis. Apesar do processo de verificação dos
mesmos ser feita também pelo serviço de protocolação, qualquer um que possua a chave
pública da assinatura pode verificar sua validade. Somente ficando impossibilitada a
verificação de precedência, já que a corrente ficar armazenada no servidor.
De uma forma geral, por estar na internet e possibilitando cadastros de empresas e
usuários, o serviço se mostrou bastante flexível. Após o término, ficou claro que alguns
recursos poderiam ser agregados para dar valor ao serviço. Enviar documentos protocolados
junto de seus recibos por e-mail ou ter a opção de armazená-los para futuro download, seriam
recursos que agregariam bastante valor e estão na sessão 4.1.
62
4 CONCLUSÕES
Ao início do trabalho não estava bem claro todos os requisitos necessários de
segurança para uma protocoladora digital de documentos eletrônicos e foi uma tarefa difícil
elencá-los, pouca informação sobre protocolamento foi encontrada. Em parte por que o
processo é composto de várias etapas distintas, em parte por que há ainda pouca coisa
existente.
Os recibos foram criados de forma a ser possível verificar fortemente a autenticidade
da protocolação. Além de informações como data e o hash do documento, viu-se a
necessidade de anexar um identificador relacionado ao nó da corrente de recibos salva em
banco de dados.
Uma dificuldade encontrada foi a manipulação de chaves do sistema. As bibliotecas
envolvidas foram estudadas e satisfizeram as necessidades, mas houve um esforço para
garantir a segurança das chaves, de forma que as senhas não ficassem disponíveis em nenhum
lugar.
Nesse momento, para resolver o problema das senhas, foi utilizado um recurso externo
a linguagem PHP, o qual foi incluído em um momento final e não estava previsto
anteriormente, o uso da linguagem C e a criação de um pequeno programa para iniciar os
servidores, o web e o de banco de dados.
Uma vez as chaves seguras, mostrou-se a necessidade de dar um acabamento no
serviço criando os cadastros de empresa e funcionários, os usuários reais do sistema. Supondo
que o ambiente ideal era um que fosse possível validar determinado recibo e verificar seu
autor. Tornando a aplicação realmente um serviço e não apenas um recurso.
Tomou-se o cuidado, ao longo do desenvolvimento, de criar classes orientadas a
objetos e na forma de uma biblioteca. Em parte obteve-se sucesso, ficando apenas faltando
um menor acoplamento entre os controles e a criação dos resumos dos documentos.
A aplicação pode ser estendida e utilizada de diversas formas para incrementar outras
aplicações. Aplicações que gerenciam o armazenamento de documentos digitais são um bom
exemplo. Assim como serviços que lidam com transferências de informações.
O Zend Framework ajudou na resolução de alguns problemas como o de conexão com
o protocolo NTP. Nenhuma classe distinta foi implementada, o serviço somente fez uso de um
recurso já existente no framework. O trabalho apenas se deu em um momento inicial, na
busca por uma hora legal e por um serviço que a disponibilizasse.
63
A Hora Legal Brasileira pode ser obtida através dos servidores NTP disponibilizados
pelo projeto NTP.br, ligados ao Observatório Nacional que é responsável por manter a hora
oficial do Brasil.
Essa inclusão foi feita de forma a não impedir que qualquer sistema externo, de posse
da chave pública do serviço possa fazer a leitura dos dados e verificar a auditoria. Esse
identificador a mais não impede que a assinatura seja validade e a data conferida, mas neste
caso, não é possível verificar a data relativa, a corrente de recibos, visto que ela é armazenada
e acessada somente pelo serviço.
De uma forma geral, o trabalho estendeu o conhecimento sobre segurança, sobretudo
sobre o processo de protocolação. Hoje parte do assunto foi desmistificado e tem-se uma
visão mais abrangente sobre o assunto.
4.1 EXTENSÕES
Existem recursos que podem ser estendidos ou agregados à aplicação, a maioria está
ligada ao controle, armazenamento ou envio de documentos eletrônicos. Já que hoje somente
existe o processo de protocolação. As extensões sugeridas são:
a) integrar o serviço com alguma ferramenta que gerencie o armazenamento de
documentos eletrônicos (GED). Além de efetuar a protocolação, com esta
extensão, o serviço seria capaz de armazenamento e versionar documentos
eletrônicos.
b) criar um serviço de envio e recebimento de arquivos junto com o processo de
protocolação. Junto da protocolação estaria disponível um recurso de envio de
documentos para outros computadores com diretórios compartilhados na rede ou
para transferência dos mesmos a um servidor através de um protocolo como o File
Transport Protocol (FTP).
c) criar um serviço de protocolação e e-mails. Disponibilizar um serviço capaz de
protocolar e enviar e-mails emitindo um recibo ao fim.
64
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, Emerson. Entendendo a certificação digital. [S.l.], 2009. Disponível em: <http://www.infowester.com/assincertdigital.php>. Acesso em: 20 mar. 2010.
ALVARES, Miguel A. O que é PHP. [S.l], 2004. Disponível em: <http://www.criarweb.com/artigos/202.php >. Acesso em: 28 ago. 2010.
BRY CERTIFICAÇÃO DIGITAL. Protocolação digital. [S.l], 2010. Disponível em: <http://www.bry.com.br/index.php?class=solucoes&page=proto>. Acesso em: 04 abr. 2010.
CARVALHO, Eiji T. PKI - Infra-estrutura de Chaves Públicas. [S.l], 2008. Disponível em: < http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2008_2/hugo/index.html>. Acesso em: 20 set. 2010.
CASTRO, Aldemario A. O documento eletrônico e o novo código civil. [S.l.], 2003. Disponível em: <http://www.elvecio.com/artigos/O_DOCUMENTO_ELETRoNICO_E_O_NOVO_CoDIGO_CIVIL.doc>. Acesso em: 18 mar. 2010.
COMITE GESTOR DE INTERNET DO BRASIL. Projeto NTP.br. [S.l], 2009. Disponível em: <http://ntp.br/>. Acesso em: 10 set. 2010.
COSTA, Vanessa et al. Protocolação digital de documentos eletrônicos. [S.l.], 2003. Disponível em: <http://www.iti.gov.br/twiki/bin/viewfile/OLD/Forum/ArtigoG02?rev=1.1;filename=g02-costa-custodio-dias-rolt.rtf>. Acesso em: 16 mar. 2010.
LIPAA, Helger. Secure and efficient time-stamping systems. [S.l.], 1999. Disponível em: <http://www.cyber.ee/cms-et/firmainfo/infomaterjalid/failid-1/lipmaa-thesis.pdf>. Acesso em: 03 abr. 2010. NATIONAL COMPUTER SECURITY CENTER. A guide to understanding audit in trusted systems. [S.l.], 1987. Disponível em: <http://www.fas.org/irp/nsa/rainbow/tg001.htm>. Aceso em: 03 abr. 2010.
SILVA, Lino Carlos da. Public Key Infrastructure – PKI. São Paulo: Novatec Editora Ltda, 2004. SILVA JUNIOR, José T. Da evolução da escrita ao livro. [S.l.], 1998. Disponível em: <http://www.forum.ufrj.br/biblioteca/escrita.html>. Acesso em: 20 mar. 2010.
65
TADAMO, Katiucia Y. GED: assinatura digital e validade jurídica de documentos eletrônicos. 2002. 98 f. Trabalho de Conclusão de Curso (Bacharelado em de Ciências da Computação) - Universidade Federal de Mato Grosso do Sul, Cuibá. Disponível em: <http://www.prontuarioeletronico.odo.br/docs/GEDAssinaturaDigital.pdf >. Acesso em: 03 abr. 2010.
THE PHP GROUP. A história do PHP. [S.l], 2010. Disponível em: <http://www.php.net/manual/pt_BR/history.php> Acesso em: 10 set. 2010.
TRIBUNAL REGIONAL DO TRABALHO. PDDE: protocoladora digital de documentos eletrônicos. [S.l.], 2002. Disponível em: <https://seguro.trt12.jus.br/peticao/scripts/peticao/msg/pdde-detalhado.asp>. Acesso em: 20 mar. 2010.
![TCC2010-1-14-AP-JoanaSimon [Modo de Compatibilidade]campeche.inf.furb.br/tccs/2010-I/TCC2010-1-14-AP-JoanaSimon.pdf · Realizou-se atividade com a turma de TIGN do primeiro semestre](https://static.fdocumentos.tips/doc/165x107/5c13537909d3f2e3218c60e8/tcc2010-1-14-ap-joanasimon-modo-de-compatibilidade-realizou-se-atividade-com.jpg)
