Cart_rio_Digital___Redes

Prévia do material em texto

Cartório Digital - Um sistema descentralizado
Allan Pereira da Silva
1Universidade Estadual de Feira de Santana (UEFS)
Feira de Santana, BA - Brasil
2Departamento de Tecnologia - DTEC
allanpereira016@gmail.com
Abstract. This article describes the procedure for developing the Digital Re-
gistry system. Here are the reasons for implementing this system, how it was
architected and its fundamental features. Among its features, we can see th-
roughout the sections that system is decentralized, using concepts of P2P, en-
cryption, Multicast and digital certificates through SSL (Secure Sockets Layer)
and TLS (Transport Layer Security).
Resumo. Este artigo descreve o procedimento de desenvolvimento do sistema
do Cartório Digital. Nele estão os motivos pelos quais implementar esse sis-
tema, como ele foi arquitetado e suas caracterı́sticas fundamentais. Dentre
suas caracterı́sticas, podemos perceber ao longo das seções que, o sistema é
descentralizado, usando conceitos de P2P, criptografia, Multicast e certificados
digitais através de SSL (Secure Sockets Layer) e TLS (Transport Layer Security).
1. Introdução
A função maior do Cartório de Imóveis é o arquivamento do histórico completo do imóvel,
com todos os dados da propriedade, de maneira autêntica e segura. Quem necessitar de
informações sobre qualquer imóvel buscará e encontrará no Cartório de Imóveis. Atos que
produzam efeitos jurı́dicos que tenham relação com imóveis deverão ser registrados nos
livros do Registro de Imóveis, passando, assim, a ter validade jurı́dica. Provas de proprie-
dade e alterações no imóvel, assim como demais atos jurı́dicos passam a ser reconhecidos
de acordo com a lei, como esclarece a cartilha do TJDFT, O Tribunal de Justiça do Distrito
Federal e dos Territórios. De maneira mais detalhada, os Registros de Imóveis possuem
as atribuições de realizar a matrı́cula, o registro e averbações de atos que tenham relação
com imóveis. Dentre esses atos, podemos citar a compra, a venda, doação, loteamento,
permuta, benfeitorias, usucapião, hipoteca, penhora e outros contratos.[de Lima 2017]
Dito isso, podemos perceber que o cartório é uma entidade centralizadora de re-
cursos e serviços, que, por muitas vezes, acaba por dificultar certas ações necessitadas
pelos cidadãos justamente por sua caracterı́stica burocrática e central. Sabendo disso, foi
solicitado que uma start-up inovadora do Brasil desenvolvesse o sistema digital que seja
capaz de agir como um cartório, porém de maneira descentralizada e mesmo assim man-
tendo algumas caracterı́sticas como segurança, publicidade, autenticidade e eficácia dos
atos jurı́dicos.
2. Fundamentação Teórica
Nesta seção serão explicados os conceitos teóricos fundamentais para o desenvolvimento
do sistema do Cartório Digital.
2.1. Multicast
Diferente do broadcast (difusão) que manda o mesmo pacote para todos, o multicast é
um serviço para um grupo, no qual o pacote é entregue para apenas um subgrupo de
máquinas na rede. Uma série de aplicações emergentes de rede requer a entrega de pa-
cotes de um ou mais remetentes a um grupo de destinatários. Entre essas aplicações
estão a transferência de dados em grandes volumes (por exemplo, a transferência de uma
atualização de software do desenvolvedor do software para os usuários que necessitam da
atualização), mı́dia de fluxo contı́nuo (por exemplo, transferência de áudio, vı́deo e texto
de uma palestra ao vivo para um conjunto de participantes distribuı́dos), as aplicações de
dados compartilhados (por exemplo, quadro branco ou videoconferência, compartilhados
por muitos participantes distribuı́dos), a alimentação de dados (por exemplo, cotação de
ações), a atualização de cache da Web e os jogos interativos (por exemplo, ambientes
virtuais interativos distribuı́dos ou jogos multiusuários). Na comunicação para um grupo,
enfrentamos imediatamente dois problemas — como identificar os destinatários de um pa-
cote desse tipo e como endereçar um pacote enviado a um desses destinatários. No caso
da comunicação individual, o endereço IP do destinatário (receptor) é levado em cada da-
tagrama IP individual e identifica o único destinatário; no caso do serviço para um grupo,
temos vários destinatários. Tem sentido que cada pacote desse tipo carregue os endereços
IP de todos os vários destinatários? Embora essa abordagem possa ser funcional com
um número pequeno de destinatários, não pode ser expandida com facilidade para o caso
de centenas de milhares de destinatários; a quantidade de informações de endereçamento
no datagrama ultrapassaria a quantidade de dados que é de fato carregada no campo de
carga útil do pacote. A identificação explı́cita dos destinatários pelo remetente também
exige que o remetente conheça as identidades e os endereços de todos os destinatários. O
grupo de destinatários associados a um endereço classe D é denominado grupo multicast.
[KUROSE 2014]
2.2. SSL e TLS
Essa versão aprimorada do TCP é denominada Camada Segura de Sockets (Secure Soc-
kets Layer — SSL). Uma versão levemente modificada da versão 3 do SSL, denominada
Segurança na Camada de Transporte (Transport Layer Security —TLS), foi padronizada
pelo IETF [RFC 4346].[KUROSE 2014]
O SSL foi na origem projetado pela Netscape, mas as ideias básicas por trás da
proteção do TCP antecedem o trabalho da Netscape (por exemplo, consulte Woo [1994]).
Desde sua concepção, o SSL obteve uma ampla implementação. Ele é suportado por todos
os navegadores Web e servidores Web, e usado basicamente por todos os sites populares
(incluindo Amazon, eBay, Yahoo!, MSN etc.). Dezenas de bilhões de dólares são gastos
com o SSL a cada ano. Na verdade, se você já comprou qualquer coisa pela Internet com
seu cartão de crédito, a comunicação entre seu navegador e servidor para essa compra foi
quase certamente por meio do SSL. (Você pode identificar que o SSL está sendo usado por
seu navegador quando a URL se iniciar com https: em vez de http:.). [KUROSE 2014]
O SSL aprimora o TCP com sigilo, integridade dos dados, autenticação do servi-
dor e autenticação do cliente. [KUROSE 2014]
Muitas vezes, o SSL é usado para oferecer segurança em transações que ocorrem
pelo HTTP. Entretanto, como o SSL protege o TCP, ele pode ser empregado por qualquer
aplicação que execute o TCP. O SSL provê uma Interface de Programação de Aplicação
(API) com sockets, semelhante à API do TCP. Quando uma aplicação quer empregar o
SSL, ela inclui classes/bibliotecas SSL. Embora o SSL resida tecnicamente na camada de
aplicação, do ponto de vista do desenvolvedor, ele é um protocolo de transporte que provê
serviços do TCP aprimorados com serviços de segurança.[KUROSE 2014]
2.3. Criptografia
Técnicas criptográficas permitem que um remetente disfarce os dados de modo que um
intruso não consiga obter nenhuma informação dos dados interceptados. O destinatário, é
claro, deve estar habilitado a recuperar os dados originais a partir dos dados disfarçados.
O interessante é que em muitos sistemas criptográficos modernos, incluindo os usados na
Internet, a técnica de codificação é conhecida — publicada, padronizada e disponı́vel para
qualquer um (por exemplo, [RFC 1321; RFC 3447; RFC 2420; NIST, 2001]), mesmo para
um potencial intruso! Evidentemente, se todos conhecem o método para codificar dados,
então deve haver alguma informação secreta que impede que um intruso decifre os dados
transmitidos. É aqui que entra a chave. [KUROSE 2014]
Na Figura 1, Alice fornece uma chave, KA, uma cadeia de números ou de caracte-
res, como entrada para o algoritmo de criptografia. O algoritmo pega essa chave e o texto
aberto da mensagem, m, como entrada e produz texto cifrado como saı́da. A notação
KA(m) refere-se à forma do texto cifrado (criptografado usando a chave KA) da mensa-
gem em texto aberto, m. O algoritmo criptográfico propriamente dito,que usa a chave
KA, ficará evidente do próprio contexto. De maneira semelhante, Bob fornecerá uma
chave, KB, ao algoritmo de decriptação, que pega o texto cifrado e a chave de Bob como
entrada e produz o texto aberto original como saı́da. Isto é, se Bob receber uma mensa-
gem criptografada KA(m), ele a decriptará calculando KB(KA(m)) = m. Em sistemas de
chaves simétricas, as chaves de Bob e de Alice são idênticas e secretas. Em sistemas de
chaves públicas, é usado um par de chaves. Uma delas é conhecida por Bob e por Alice
(na verdade, é conhecida pelo mundo inteiro). A outra chave é conhecida apenas por Bob
ou por Alice (mas não por ambos). [KUROSE 2014]
Figura 1. Componentes criptográficos
3. Metodologia
Inicialmente foi dada a ideia de usarmos Multicast para a comunicação entre os servi-
dores, ideia essa que foi levada até o fim e provou-se ser de extrema importância para a
sincronização dos servidores, ou seja, para que todos estejam no mesmo estado no que se
refere à cadastro de cidadãos, documentos e transferências. Fazendo todos os cartórios te-
rem todos os dados, estamos atendendo ao requisito de publicidade que o programa deve
ter. O Multicast, em Java, é uma subclasse UDP, sabendo disso, devemos usar alguma
estratégia para manter a segurança dos dados que trafegam na rede, não somente entre os
servidores, mas também entre os clientes e os servidores.
Para manter a segurança, autenticidade e integridade de dados entre cliente e ser-
vidor, utilizamos o protocolo SSL, que nos obriga a gerar chaves, certificados digitais
e arquivos de confiança que guardam as assinaturas de quem pode criar uma conexão,
ou seja, cliente e servidor. Para gerar esses arquivos são utilizados comandos dentro do
Prompt de Comando, na pasta do projeto onde se encontra o cliente e na pasta onde se
encontra o servidor. Para segurança no armazenamento de dados e no tráfego de dados
entre os servidores (Cartórios) foram usadas técnicas de criptografia. Por exemplo na se-
nha do usuário foi usado o Message Digest em Java, que incorpora vários algoritmos de
criptografia, desde o MD5 até o alguns mais complexos da famı́lia SHA1 e SHA2. Com
isso consegue-se pegar a cadeia de caracteres da senha do usuário e criptografar, tanto
na hora de salva em arquivo quanto na hora de mandar os dados entre servidores. Entre
cliente e servidor não é necessário fazer essa criptografia pois o SSL/TLS, que também
dá suporte ao Java, já faz esse trabalho.
O sistema foi desenvolvido através de bibliotecas em Java que dão suporte a
comunicação e segurança e é baseado em conceitos de Redes de Computadores, Siste-
mas Operacionais (com as threads criadas durante a execução do programa), Blockchain,
Sistemas Distribuı́dos e os trâmites existentes no cenário dos cartórios do Brasil. Tudo
isso produzido sob no sistema operacional Windows 10 e na IDE Netbeans 8.2.
4. Resultados e Discussão
O sistema está divido em duas parte, sendo elas, a parte do cliente e a do servidor. Pri-
meiro será explicado o funcionamento do cliente, depois o do servidor e por último como
eles interagem, dando exemplos de fluxos básicos possı́veis de serem realizados no pro-
grama.
O cliente possui dois pacotes, o pacote cliente e o pacote de view. No pacote
cliente se encontram as classes:
• Cidadão: Essa classe é a representação do cidadão no sistema, nela temos os
atributos nome, CPF (que serve como login), senha, lista de documentos e lista de
transferências.
• Cliente: Essa classe é responsável por lidar com os pedidos de cidadão, protocolar
esses pedidos e fazer requisições ao servidor.
• Documento: Essa classe é a representação de um documento no sistema, nela
temos os atributos ID (composto por latitude e longitude do imóvel), proprietário
(nome), CPF do proprietário, o texto que descreve o documento, a data de criação
ou transferência do documento e o valor do imóvel.
• Protocolo: O protocolo contém as funções que podem ser realizadas no software,
sendo algumas delas, cadastrar usuário (Cidadão), cadastrar documento, transferir
documento, recusar transferência, entre outras.
• Transferência: A transferência é a classe que vai ser utilizada quando um usuário
quiser transferir um documento para outro usuário, nela existem os atributos CPF
do vendedor, CPF do comprador, o documento a ser transferido, a data da trans-
ferência e o valor da venda.
O pacote view possui as telas do sistema. Através delas, o usuário é capaz de ter
acessa à todas as funções contidas no protocolo.
A partir dessa figura podemos ver quais possı́veis opções o cidadão tem ao lo-
gar no sistema. Em ”cadastrar documentos” ele vai poder fazer o registro do imóvel
deseja, inserindo informações como latitude, longitude, valor e descrição. Em ”ver do-
cumentos” ele é capaz de visualizar todos os documentos que estão em sua posse, pode
selecionar um desses, transferir para outro usuário e aguardar esse usuário aceitar ou re-
cusar a transferência do imóvel. Em ”ver transferências recebidas” ele pode ver se
alguém fez transferência para o seu nome e, a partir daı́, selecionar o documento e clicar
em aceitar ou recusar.
O servidor possui três pacotes, o pacote cliente, o pacote servidor e o pacote view
(estranho um servidor ter uma tela? Será explicado o motivo a seguir). No pacote cliente
ele possui as mesmas classes do cliente e a única classe que muda é a classe cliente,
tendo apenas um método (além dos tradicionais de entrada, saı́da e conexão) utilizado
para sincronizar um servidor com outro. Já no pacote servidor temos:
• Handler: O Handler é quem manipula os dados, ou seja, quem faz praticamente
tudo no sistema, no que se refere à cadastros, criptografia, verificações e ler e
escrever em arquivo.
• MulticastReceiverCidadao: Ela é a thread que vai se juntar ao grupo de rece-
bimento de dados de cadastros de cidadãos para se manter sincronizada com os
outros servidores (cartórios).
• MulticastReceiverDocumento: Ela é a thread que vai se juntar ao grupo de re-
cebimento de dados de cadastros de documentos para se manter sincronizada com
os outros servidores (cartórios).
• MulticastReceiverTransferência: Ela é a thread que vai se juntar ao grupo de
recebimento de dados de cadastros de transferências para se manter sincronizada
com os outros servidores (cartórios).
• MulticastSender: Essa classe contém os métodos responsáveis por enviar uma
mensagem Multicast para cada um dos grupos existentes, de acordo com a ne-
cessidade, ou seja, quando for feito o cadastro de um cidadão, ela vai enviar a
mensagem para todos os servidores no grupo MulticastReceiverCidadao, por
exemplo.
• Servidor: É onde são iniciadas as threads necessárias para o funcionamento do
sistema.
• ThreadTCP: É a thread que se comunica via SSL com o cliente (usuário).
Para explicar como funciona o sistema, explicaremos como funciona um de seus
fluxos básicos, o cadastro do documento.
O usuário ao executar o programa deverá indicar através de IP e Porta a qual
servidor (cartório) ele deseja se conectar, após isso é possı́vel ser feito o login (caso ele
já esteja cadastrado). Quando o usuário digita o seu login e sua senha corretamente, é
criado um objeto da classe Cliente que vai chamar o método de login, nesse método será
enviado o protocolo de login para a ThreadTCP que por sua vez vai entrar na condicional
responsável por fazer login. Nessa condicional será chamado o método do Handler que
vai verificar se esse usuário já é cadastrado e assim retorna para o cliente o resultado
da verificação. Depois disso, o usuário vai estar, finalmente, no menu principal e vai
clicar em cadastrar documento, sendo assim, redirecionado para a tela de ”cadastro de
documento”. Nessa tela ele preencherá os dados necessários da maneira correta e vai
clicar em ”enviar”. Quando clicado em enviar ocorre um procedimento parecido com o
de login, só queao invés de mandar o login e a senha para o servidor, para o servidor
saber se ele pode logar, ele enviará o protocolo de cadastro de documento e o documento
a ser cadastrado. O servidor então retorna se o documento foi cadastrado ou houve algum
erro.
O pacote view do servidor tem uma tela chamada TelaSincronizar, nessa tela tem
os campos IP e porta que serão preenchidos por algum gestor do servidor, dessa forma,
informando com qual servidor ele deseja sincronizar os dados. Isso é necessário porque
caso o servidor tenha sido criado depois de algum tempo em relação aos antigos, ou caso
ele seja iniciado depois e até mesmo ele caia e volte tempo depois, ainda assim, com essa
funcionalidade ele poderá sincronizar com os servidores mais atuais e manter seus dados
consistentes no sistema como um todo.
5. Conclusão
Foram encontradas muitas dificuldades para começar a desenvolver o sistema. Eram
muitos conceitos desconhecidos, porém com a ajuda da equipe de desenvolvimento foi
possı́vel fazer esse protótipo.
É protótipo por vários motivos, mas principalmente por não ter sido implemen-
tado o algoritmo de relógio lógico de Lamport, que auxiliaria no quesito de tolerância
a falhas do sistema. Ele serviria para dar fim a TelaSincronizar, pois esse processo de
sincronização seria automático e não manual.
Fora esse quesito, acreditamos ter cumprido boa parte, senão todos os tópicos
mencionados no barema disponibilizado pela tutora Elisângela. A parte da transferência
foi a que mais inspirou o desenvolvimento de uma boa solução para este problema.
Enfim, esperamos que esse Cartório Digital diminua a burocracia e dificuldade de
trâmites dos cartórios reais além de torná-lo um sistema independente de uma entidade
centralizadora, que é como esse sistema foi desenvolvido.
Referências
de Lima, L. B. (2017). Funções do cartório de registro de imóveis – quais certidões
emitem? Disponı́vel em: https://cartorioregistrodeimoveis.com.br/blog/cartorio-de-
registro-de-imoveis-certidoes-emitem/. Acessado em 08 de agosto de 2019.
KUROSE, J. F. e ROSS, K. (2014). Redes de Computadores e a Internet. Pearson, 6th
edition.