RESUMO
Qualquer tipo de informação médica de pacientes é protegida por sigilo médico e profissional (art. 102 do Código de Ética Médica e art. 154 do Código Penal Brasileiro). Para transmitir dados desse tipo por uma rede pública (como a Internet) é necessário mecanismos de segurança para impedir que tais informações sejam lidas por pessoas não autorizadas. Esse documento descreve o funcionamento de uma ferramenta que cuida da transmissão de dados médicos do projeto VGDN.
1.0-INTRODUÇÃO
O projeto VGDN (Viral Genetic Diversity Network – Rede de Diversidade Genética de Vírus) tem como objetivo fazer o sequenciamento genético de quatro vírus, guardando essas informações em uma base de dados, para posterior análise, junto com o histórico médico de cada pessoa portadora do vírus. A FAPESP coordena o projeto e o IME é o responsável pela parte computacional. O projeto pretende estudar, de início, a variedade genética dos vírus HIV-1, HCV, Hantavírus e RSV.
A base de dados central do projeto está localizada no Laboratório de Banco de Dados do BIOINFO-IME-USP e os dados que serão armazenados nessa central são gerados por diversos institutos diferentes. Para atender requisitos de projeto, os institutos cadastram e validam os dados localmente, para depois enviá-los para o banco de dados central.
Cada instituto gerador de dados clínicos possuirá uma cópia do software “Sistema para Cruzamento de Dados Clínico-Genéticos”, desenvolvido pelo Laboratório de Banco de dados do BIOINFO-IME-USP. Assim, cada instituto possuirá uma base local de dados.
Para que as informações existentes nas bases locais de dados possam ser enviadas para a base central de dados (localizada no BIOINFO-IME-USP), é necessária a utilização de uma ferramenta de transmissão dessas informações. O objetivo da minha iniciação científica foi desenvolver tal ferramenta.
Conforme informações do Prof. João Eduardo Ferreira, a ferramenta deve fazer a transmissão desses dados de forma compactada e, principalmente, criptografada, pois as informações médicas de qualquer paciente são protegidas por sigilo médico.
2.0-TECNOLOGIAS UTILIZADAS
Para desenvolver esta ferramenta, utilizei as seguintes tecnologias :
-Linguagem de programação : Delphi – Borland;
-Forma de transmissão de dados : TCP/IP (sockets);
-Criptografia : algoritmos RSA e IDEA (PGP-Pretty Good Privacy);
-Compactação de dados : TAR/GZIP e ZipMaster.
3.0-ARQUITETURA DO SOFTWARE
A ferramenta desenvolvida é baseada na arquitetura cliente/servidor. O software cliente é responsável pela geração do pacote de dados, compactação, criptografia e transmissão. O software servidor gerencia a recepção dos dados, descompactação e descriptografia.
3.1-A APLICAÇÃO SERVIDORA
A aplicação servidora fica “escutando” uma porta TCP, aguardando uma conexão. Quando uma conexão é estabelecida, o software servidor envia (utilizando um protocolo próprio, que será descrito no item "O protocolo de comunicação" deste texto) a chave pública que possui, para permitir que a aplicação cliente faça a criptografia dos dados.
Em seguida, a aplicação servidora aguarda a transmissão do pacote de dados gerado pela aplicação cliente. Quando esse pacote chega, a descriptografia é feita (pois a aplicação servidora possui a chave privada), ocorre a descompactação e, por fim, acontece a abertura do pacote de dados.
Se não ocorrer nenhum problema nos passos descritos anteriormente, a aplicação servidora informa que a transmissão foi um sucesso e a base de dados recebida é armazenada para futura carga no banco de dados principal. Caso contrário, informa a aplicação cliente sobre o erro que aconteceu e encerra a transmissão.
Todas as etapas anteriormente descritas são “logadas” pela aplicação servidora.
3.2-A APLICAÇÃO CLIENTE
Primeiramente, a aplicação cliente deve ser devidamente configurada para se comunicar com a aplicação servidora. Devem ser informados o IP da máquina servidora, a porta do servidor utilizada na comunicação, o nome da entidade que está enviando a base de dados e a localização da base de dados do VGDN na máquina cliente.
Após a configuração do software cliente, o usuário pode escolher dois tipos de transmissão : completa ou parcial. A transmissão completa envia toda a base de dados armazenada no cliente para o computador servidor. A transmissão parcial envia somente os arquivos que foram modificados desde a última transmissão de dados. A principal vantagem da transmissão parcial em relação à transmissão completa aparece quando as bases de dados locais começarem a ficar muito grandes.
Depois da escolha do tipo de transmissão, o software cliente gera um pacote contendo os arquivos da base de dados (todos os arquivos, no caso da transmissão completa, ou só os arquivos modificados desde a última transmissão, no caso da transmissão parcial). Esse pacote é compactado e em seguida é aberta a comunicação com o software servidor. Através de um protocolo próprio (que será descrito no item “O protocolo de comunicação”), o software servidor envia a chave pública para o software cliente. Com a chave pública, o software cliente criptografa o pacote compactado e o transmite ao software servidor.
Após a transmissão, o software cliente aguarda a resposta do software servidor (que pode ser positiva ou negativa) e a conexão é encerrada. Em todas as transmissões, o software cliente registra quais foram os arquivos que foram enviados e suas características (para saber quais arquivos selecionar no caso de uma transmissão parcial for escolhida pelo usuário).
4.0-O PROTOCOLO DE COMUNICAÇÃO
No inicio do projeto, a comunicação entre o cliente e o servidor era baseada em um protocolo extremamente simples. Esse protocolo inicial funcionava assim :
1o.) Quando a conexão era iniciada, o servidor enviava o tamanho do arquivo que continha a chave pública concatenado com o caracter ”#”. Por exemplo, se o arquivo que continha a chave pública possuísse 3744 bytes, a string enviada seria “3744#”
2o.) Em seguida, o servidor enviava o conteudo do arquivo que possuia a chave pública.
3o.) Após o cliente receber a chave pública, o cliente enviava o nome do arquivo que armazenava o pacote de dados gerado. Esse nome era concatenado com o caracter “#”. Por exemplo, se o arquivo se chamasse arq_pacote.tcz, a string enviada seria “arq_pacote.tcz#”
4o.) O cliente enviava o tamanho do arquivo de pacote seguido pelo caracter “#”. Por exemplo, se o arquivo de pacote tivesse o tamanho de 345222 bytes, a string transmitida era “345222#”.
5o.) O cliente transmitia o arquivo de pacote.
6o.) Após a chegada do pacote, se o pacote transmitido possuisse algum erro, o servidor retornava uma mensagem no seguinte formato :
Server: <nome_do_arquivo_pacote> ERRO <codigo_erro>#
Por exemplo, conforme o arquivo de exemplo descrito anteriormente :
Server : arq_pacote.tcz ERRO 1#
7o.) Após a chegada do pacote, se o pacote transmitido estivesse perfeito, o servidor retornava uma mensagem no seguinte formato :
Server: <nome_do_arquivo> OK#
Por exemplo :
Server: arq_pacote.tcz OK#
8o.) A conexão era encerrada.
Com o aprimoramento do software, decidi criar outro procotolo, pois com o protocolo anterior, seria complicado acrescentar novas funcionalidades ao software. O novo protocolo é formado por diversas mensagens. Todas as mensagens são terminadas pelo caracter ASCII 13 (que será apresentado como <\13>).
Essas mensagens possuem o seguinte formato :
<mensagem><\13>
ou
<mensagem> <parametro><\13>
Abaixo estão descritas as mensagens disponíveis :
SERVIDOR_LIVRE : Informa a aplicação cliente que o servidor não está atendendo nenhuma outra requisição.
SERVIDOR_OCUPADO : Informa a aplicação cliente que o servidor está atendendo outra requisição.
ERRO <erro> : Informa a aplicação cliente que ocorreu um erro do tipo <erro> no pacote. Por exemplo, se ocorrer erro no processo de descriptografia, o servidor retorna a mensagem “ERRO 1”.
PROTOCOLO <prot> : Informa a aplicação servidora que o cliente usa o protocolo <prot>. Por exemplo, “PROTOCOLO 1”.
TRANSMISSAO_PERFEITA : Informa a aplicação cliente que a transmissão do pacote foi um sucesso.
ENVIAR_TAMANHO_CHAVE_PÚBLICA : Mensagem gerada pelo cliente para solicitar ao servidor que envie o tamanho do arquivo de chave pública.
TAMANHO_CHAVE_PÚBLICA <tam> : Mensagem que o servidor usa para informar o tamanho do arquivo de chave pública. Por exemplo, se o arquivo de chave pública possuir 3744 bytes, a mensagem será “TAMANHO_CHAVE_PÚBLICA 3744”.
ENVIAR_CHAVE_PÚBLICA : Mensagem para fazer com que o servidor envie a chave pública.
CHAVE_PÚBLICA : Mensagem que o servidor emite para informar que, após essa mensagem, será transmitida a chave pública.
NOME_PACOTE <nome> : Mensagem que informa ao servidor sobre o nome do pacote a ser enviado pelo cliente. Por exemplo, se o cliente for transmitir o arquivo arq_pacote.tcz, a mensagem seria “NOME_PACOTE arq_pacote.tcz”.
TAMANHO_PACOTE <tam> : Mensagem que informa ao servidor sobre o tamanho do pacote a ser transmitido. Por exemplo, se o pacote a ser transmitido possuir 345222 bytes, a mensagem seria “TAMANHO_PACOTE 345222”.
ENVIANDO_PACOTE : Mensagem que o cliente emite para informar que, após essa mensagem, será transmitido o pacote.
A próxima figura "simula" a comunicação entre a aplicação cliente e a aplicação servidora quando a transmissão do pacote é feita com sucesso.
Se, no futuro, alguém quiser acrescentar outras funcionalidades que necessite de alguma comunicação entre cliente e servidor, basta acrescentar mais um tipo de mensagem a esse protocolo.
5.0-O PGP- PRETTY GOOD PRIVACY
O Pretty Good Privacy (PGP) é um software para criptografia de dados desenvolvido, inicialmente, por Phil Zimmermann. Para criptografar os dados, o PGP usa dois algoritmos de criptografia : o IDEA e o RSA. O IDEA é um algoritmo de criptografia de chave secreta desenvolvido por X. Lai e J. Massey. O RSA é um algoritmo de criptografia de chave pública desenvolvido por Ron Rivest, Adi Shamir e Len Adleman.
O PGP funciona da seguinte forma para criptografar dados :
a) é gerada uma chave pseudo aleatória K para o algoritmo IDEA (que será descartada após a utilização);
b) Os dados são criptografados com a chave K do IDEA. Assim, é gerado um novo conjunto de dados Y;
c) Com a chave pública RSA do usuário W (destinatário), a chave K é criptografada, gerando L;
d) L e Y são enviados para o outro usuário.
O PGP funciona da seguinte forma para descriptografar dados :
a) L é descriptografada com a chave secreta RSA do usuário W. Assim, a chave K do IDEA é recuperada;
b) O conjunto de dados Y é descriptografado usando a chave K do IDEA. Assim, o conjunto original de dados é recuperado.
Percebe-se que a criptografia dos dados é feita pelo algoritmo IDEA (e não pelo algoritmo RSA, conforme muitas pessoas acham). O algoritmo RSA é utilizado apenas para transmitir, de forma segura, a chave de criptografia utilizada pelo IDEA. Para aumentar a segurança, o PGP solicita que o usuário digite uma senha quando estiver criando seu par de chaves (pública/secreta). Essa senha sempre será solicitada quando o usuário tiver que usar sua chave secreta.
Nesse trabalho, na parte de descriptografia, o PGP é invocado usando o seguinte código em DELPHI :
grave_arquivo2('decod.bat',
‘pgpv –zQWERT <'+arq_c+'\'+arq_c+' > '+arq_c+'\'+arq_d+' '+#13+#10+
'del decod.bat'+#13+#10);
executar('decod','');
A primeira função cria um arquivo de lote chamado “decod.bat” que possui o comando completo para descriptografar o pacote criptografado (o nome do pacote criptografado está armazenado na variável “arq_c”). O pacote descriptografado é gravado no arquivo que possui o nome armazenado na variável “arq_d”. A opção –z informa ao PGP a senha da chave privada (que, neste exemplo, por questões de segurança, foi trocada por QWERT). Por default, o programa “pgpv” busca o arquivo da chave secreta (SECRING.SKR) em seu diretório corrente.
A segunda função apenas executa o arquivo de lote “decod.bat”, utilizando a biblioteca SHELLAPI do DELPHI.
Se algum erro acontecer, o arquivo com nome armazenado em “arq_d” terá tamanho zero. Caso contrário, o tamanho será diferente de zero.
6.0-TAR/GZIP e ZIPMASTER
No inicio deste trabalho, foi utilizado os aplicativos TAR e GZIP para gerar e compactar o pacote de dados que seria enviado para o servidor. Infelizmente, o processo de comunicação entre os aplicativos TAR/GZIP e as aplicações desenvolvidas nesse trabalho era feita de uma forma complicada (tive que usar a biblioteca SHELLAPI do Delphi para permitir a execução dos aplicativos TAR/GZIP).
Para incorporar o processo de geração e compactação/descompactação nas aplicações cliente e servidora, uma biblioteca que opera arquivos ZIP chamada ZIPMASTER (desenvolvida por Eric W. Engler) passou a ser usada.
A forma de utilização da biblioteca ZIPMASTER é extremamente simples e é descrita abaixo :
1o.) deve-se incluir a biblioteca no projeto usando o seguinte comando :
uses ZipMstr;
2o.) Um objeto da classe ZipMstr deve ser instanciado :
zip1 : TzipMaster;
zip1 := TZipMaster.Create(self);
3o.) Deve ser registrada uma função que receberá as mensagens (informativas e de erro) geradas pelo objeto instanciado e informar ao objeto para emitir mensagens.
zip1.OnMessage := analisa_mensagem_zip;
zip1.Verbose := true;
4o.) Deve ser informado ao objeto o nome do arquivo zip que será criado/modificado ou que será descompactado :
zip1.ZipFilename := ‘teste.zip’;
5o.) para operações de descompactação, deve-se usar :
zip1.Extract;
6o.) Para operações de compactação, deve-se usar :
zip1.FSpecArgs.Assign (lista);
zip1.Add;
Neste último exemplo, “lista” é um objeto da classe TstringList do Delphi (essa classe armazena uma lista de strings, que nesse exemplo, armazena o nome dos arquivos a serem compactados).
7.0-OUTRAS FUNCIONALIDADES A SEREM IMPLEMENTADAS
1-Transmissão incremental do pacote de dados no caso de queda da transmissão : no caso de queda do canal de comunicação durante a transmissão de algum pacote, a transmissão pode ser iniciada a partir do ponto final da última transmissão (para evitar a retransmissão de dados que já foram transmitidos). Como sugestão, dois comandos poderiam ser implementados no protocolo de comunicação. O primeiro comando requisita ao servidor o total de bytes que o mesmo recebeu de um determinado pacote. Assim, o cliente fica sabendo a partir de que ponto deve começar a transmitir o pacote de dados. O segundo comando informa ao servidor que a transmissão de dados que está sendo feita complementa o pacote de dados especificado no primeiro comando.
2-Identificação do servidor : Conforme informações de criptografia, essa funcionalidade pode ser feita utilizando mais um par de chaves (pública/secreta) do algoritmo RSA. Esse novo par de chaves seria utilizado apenas para a identificação do servidor.
3-Identificação do cliente : Acredito que um sistema de username/senha para cada cópia do software cliente possa ser usado na implementação dessa funcionalidade;
4-Busca automática da base de dados do VGDN na máquina cliente : essa funcionalidade pode ser implementada usando uma busca recursiva com as funções FindFirst, FindNext e FindClose do Delphi, junto com a classe TsearchRec.
5-Seleção mais refinada dos dados modificados : se um arquivo Z da base de dados instalada no computador cliente for modificado, todo esse arquivo é enviado pela transmissão parcial. Futuramente, pode ser implementado um meio de enviar somente as linhas que foram alteradas/adicionadas no arquivo Z ou informar ao servidor quais linhas do arquivo Z foram excluídas deste a última transmissão. Para resolver o problema de novas linhas adicionadas ou modificadas, todas as linhas de todos os arquivos da base de dados do VGDN instalado no cliente deverão possuir um campo que registra a data e a hora em que aquela linha foi transmitida para o software servidor. Infelizmente, ainda não consegui desenvolver uma idéia para identificar as linhas que forem excluídas de algum arquivo da base de dados do cliente.
6-Agendamento de transmissões automáticas : O usuário do software cliente informa ao software os horários e datas de quando uma transmissão deve ser feita.
8.0 – CONCLUSÕES
Acredito que esta ferramenta será utilizada por membros da área computacional e da área médica. Pensando nos membros da área médica, tentei projetar uma interface simples, que necessite de pouco aprendizado para que possa ser utilizada.
9.0-BIBLIOGRAFIA UTILIZADA
A seguir estão descritas as principais fontes de informações (livros e web sites) utilizadas para o desenvolvimento deste trabalho :
-Dominando o Delphi 5 : a bíblia – Marco Cantú;
-Redes de Computadores e Internet – Douglas E. Comer
-Segurança de dados : criptografia em redes de computador – Routo Terada
-The International PGP Home Page - http://www.pgpi.org
-DelphiZip ZipMaster Project Page – http://www.geocities.com/rjpeters_au/zipmaster.html
Desafios e frustações encontrados
Um dos primeiros desafios foi relembrar a forma de utilização do DELPHI. Essa linguagem foi escolhida por determinação dos usuários de bioinformática. Entretanto a migração para outras linguagens não será problema considerando a modularidade do código e a documentação das funcionalidades. Antes deste trabalho, havia programado apenas uma vez em Delphi, mas, felizmente, conhecia a linguagem base do DELPHI, a linguagem PASCAL (que aprendi quando fiz o curso Técnico em Processamento de dados). Infelizmente, como fazia muito tempo que não usava DELPHI/PASCAL, tive que gastar muito tempo para relembrar o funcionamento dessa linguagem.
Outro desafio foi desvendar as idéias de criptografia. Meu conhecimento de criptografia antes desse trabalho se resumia a colocar senha em arquivos ZIP e, como não fiz a disciplina de criptografia oferecida pelo IME, tive que aprender por conta própria as idéias utilizadas em criptografia e buscar uma maneira de implementá-las nesse trabalho.
Minha principal frustação foi não ter conseguido tempo suficiente para implementar todos os tópicos sugeridos no item "Outras funcionalidades a serem implementadas".
Disciplinas do BCC mais relevantes neste trabalho
MAC-242 - Laboratório de programação II (Prof. Paulo Silva) : A linguagem DELPHI é uma linguagem orientada a objetos. Nos últimos anos, o primeiro contato que um aluno do BCC tinha com a orientação a objetos era na disciplina de Laboratório de Programação II (Atualmente, o aluno do BCC já tem contato com orientação a objetos no primeiro ano do curso, através da linguagem JAVA). Diversos conceitos obtidos naquele curso foram úteis na manipulação da linguagem Delphi.
MAC 448 – Redes de computadores-Uma perspectiva de sistemas de software (Prof. Manoel Marcílio) : Nessa disciplina obtive muito conhecimento teórico sobre a manipulação de sockets.
PCS-210 – Redes de computadores (Profa. Graça Bressan - POLI-USP) : Sem dúvida foi a disciplina onde mais aprendi sobre programação utilizando sockets (teórico e prático) e toda a estrutura da internet.
MAC-211 – Laboratório de Programação I (Prof. Fabio Kon) e MAC-332 – Engenharia de Software (Profa. Ana Cristina): Essas duas disciplinas foram úteis pois em ambas foram desenvolvidos projetos que duraram todo o semestre do curso (isto é, projetos grandes), obrigando o aluno a ter disciplina no código desenvolvido e planejamento.
MAC 426 – Sistemas de Banco de Dados (Prof. João Eduardo Ferreira) e MAC-439 – Laboratório de Banco de Dados (Prof. João Eduardo Ferreira): Em algumas situações, tive que analisar o funcionamento interno da base de dados do VGDN. O conhecimento obtido nessas duas disciplinas me auxiliaram nessa tarefa.
Interação com membros da equipe que tenham agido como mentores do trabalho
Durante esse trabalho, fui apoiado pelo Luciano Vieira de Araújo, mestre formado pelo IME-USP em 2002, que trabalha junto com o Prof. Dr. João Eduardo Ferreira. Ele supervisionava o trabalho e me avisava da necessidade de modificações no código.
Diferenças notadas entre a forma de cooperação com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho no desenvolvimento desta ferramenta
Nesse trabalho, duas pessoas estavam envolvidas : eu e o Luciano Vieira de Araújo. Enquanto eu desenvolvida a parte de código e gerava idéias, o Luciano era responsável pela supervisão. Assim, essa forma de trabalho está mais próxima da relação aluno-professor.
Observações sobre a aplicação de conceitos estudados nos cursos no contexto prático de aplicações reais
Umas das características do BCC é sua forte base teórica. Em um ambiente de produção, muitas pessoas acreditam que é suficiente apenas uma base prática. Mas, pelo que percebi, a base teórica auxilia (e muito) na forma como você irá criar uma solução. Por exemplo, certamente não iria conseguir trabalhar com transmissão de dados conhecendo apenas programação por sockets (parte prática). É necessário conhecer o funcionamento interno da INTERNET (parte teórica).
Se o aluno fosse continuar atuando na área em que exerceu o estágio, que passos tomaria para aprimorar os conhecimentos técnicos/metodológicos/comerciais/científicos/etc relevantes para esta atividade ?
Iria aumentar meus conhecimentos de Banco de Dados para aumentar a vinculação deste software com a base de dados do VGDN, isto é, aumentar seu foco na base de dados (e não apenas somente na transmissão da mesma).