TCC Teste Teste

UNIVERSIDADE FEDERAL DE SANTA CATARINA
SEGURANÇA EM BANCO DE DADOS
Gabriel Garcia Becker, Lucas Pandolfo Perin
Florianópolis
2013/2
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
Trabalho de conclusão de curso apresen-

tada como parte dos requisitos para obten-
ção do grau de Bacharel em Ciências da
Computação
Florianópolis
2013/2
Trabalho de conclusão de curso apresentada como parte dos requisitos

para obtenção do grau de Bacharel em Ciências da Computação
Orientador: Msc. Marcelo Carlomagno Carlos
Banca Examinadora:
Msc.
Marcelo Carlomagno Carlos
Holloway University of London
Prof. Dr.
Ricardo Felipe Custódio
Universidade Federal de Santa Catarina
Anderson Luiz Silverio
Felipe Calos Werlang

AGRADECIMENTOS
Agradecemos em primeiro lugar aos nosso pais, por colocarem nossa

educação em primeiro lugar. Motivo pelo qual estamos aqui hoje. Agradece-
mos ao Professor Ricardo Custódio, pela oportunidade de trabalhar e crescer
dentro do LabSEC. Por último e não menos importante, agradecemos ao Mar-
celo Carlomagno, Anderson Luiz Silvério, Felipe Carlos Werlang e Lucas
Martins pelo esforço e ajuda no desenvolvimento deste trabalho.
"Do, or do not. There is no try."
(Yoda, The Empire Strikes Back)
RESUMO
Frequentemente os Sistemas de Gerenciamento de Banco de Dados (SGBDs)

são utilizados para assegurar o sigilo e a integridade de registros em Banco de
Dados (BD). Entretanto, os SGBDs que provêm esses recursos possuem custo
elevado, tornando-os inviáveis para organizações de pequeno e médio porte.
Baseado no uso de Hash-based Message Authentication Code (HMAC), inde-
pendente de SGBD, e aproveitando dispositivos criptográficos possívelmente
disponíveis tais como Trusted Platform Module (TPM) e smart cards, este
trabalho implementa uma biblioteca que propõe um modelo de verificação
de integridade e segurança de registros em (BD). Testes realizados durante
o desenvolvimento mostram a eficiência da proposta. Na média, o uso de
(HMAC) junto com os registros do BD mostrou-se extremamente eficiênte e
viável para aplicações de alto desempenho.
Palavras-chave: Criptografia, Integridade, Sigilo, Autenticidade, Rastreabi-
lidade, Banco de Dados
ABSTRACT
Unauthorized changes of database content can result in significant losses for

organizations and individuals, making it is extremely important to assure the
privacy and integrity of databases. The DBM provides features to encrypt the
database and protect it against unauthorized access. However, open-source
DBMs do not provide means to protect the database against unauthorized
modifications and advanced DBMs that do provide such features are too ex-
pensive for small business enterprises. In this work, data integrity verification
methods are analysed and implemented. Based on HMAC and taking advan-
tage of available devices such as TPM, smart cards and others, these methods
can be used without the need of specific DBM. Furthermore, we measured the
efficiency of the proposed method and analyze the results through benchmark
charts.
Keywords: Criptografy, Integrity, Secrecy, Autenticity, Traceability, Data-
base
LISTA DE FIGURAS
Figura 1 Exemplo de criptografia simétrica . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figura 2 Exemplo de criptografia assimétrica . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 3 getHmac() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 4 Representação do provider da biblioteca . . . . . . . . . . . . . . . . . . . 42
Figura 5 Ensaio de desempenho da operação INSERT . . . . . . . . . . . . . . . 50
Figura 6 Resultado dos testes de desempenho da operação INSERT . . . 51
Figura 7 Resultado dos testes de desempenho da operação UPDATE . . 52
Figura 8 Resultado dos testes de desempenho da operação DELETE . . 52
Figura 9 Resultado dos testes de desempenho da operação SELECT . . . 53
Figura 10 PKCS#12 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 11 KeyStoreManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 12 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 13 Diagrama de classes da biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . 64
LISTA DE TABELAS
Tabela 1 Tabela de exemplo de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Tabela 2 Tabela de Especificações do Ambiente de Teste . . . . . . . . . . . . . 48
Tabela 3 Tabela de Análise dos Resultados dos Testes . . . . . . . . . . . . . . . 54
LISTA DE ABREVIATURAS E SIGLAS
BD Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SGBD Sistema de Gerenciamento de Banco de Dados . . . . . . . . . . . . . 23
HMAC Hash-based Message Authentication Code . . . . . . . . . . . . . . . . . 27
ICP Infraestrutura de Chaves Públicas . . . . . . . . . . . . . . . . . . . . . . . . . 28
MAC Message Authentication Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
MD5 Message-Digest algorithm 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
SHA-1 Secure Hash Algorithm 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
SGML Standard Generalized Markup Language . . . . . . . . . . . . . . . . . . 32
JVM Máquina Virtual Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
DBA Administrador de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . 33
XML Extensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
HSM Hardware Security Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
TPM Trusted Platform Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4 PUBLICAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1 CRIPTOGRAFIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1 Criptografia Simétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Criptografia Assimétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 Resumo Criptográfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 Código de Autenticação de Mensagem . . . . . . . . . . . . . . . . . . . 29
2.1.5 PKCS#12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 SEGURANÇA EM BANCOS DE DADOS . . . . . . . . . . . . . . . . . 30
2.2.1 Sigilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.2 Integridade e Autenticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.3 Rastreabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 TECNOLOGIAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.3 LibCryptoDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 ADIÇÃO DO CÁLCULO DO HMAC NOS REGISTROS DA
BASE DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 EXEMPLO DE IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 ADICIONANDO REGISTROS . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 MODIFICANDO REGISTROS . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 VERIFICANDO A INTEGRIDADE DE REGISTROS . . . . 35
3.3 MEDIDAS DE PROTEÇÃO CONTRA REMOÇÃO NÃO AU-
TORIZADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 REMOVENDO UM REGISTRO . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 VERIFICANDO SE UM REGISTRO FOI REMOVIDO . . . 36
3.3.3 REMOÇÃO DO ULTIMO REGISTRO . . . . . . . . . . . . . . . . . . 36
4 IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 BIBLIOTECA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.1 Provedor de serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 PROVIDER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 PKCS12 Security Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Smart Card Security Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3 HSM Security Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.4 TPM Security Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.5 Remote Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 PKCS#12 MANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 KEYSTORE MANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 PROTÓTIPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 DESEMPENHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 AMBIENTE DE TESTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 OTIMIZAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 TESTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1 Inserção de Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.2 Atualização de Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.3 Remoção de Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.4 Consulta de Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 CONSIDERAÇÕES E ANÁLISES . . . . . . . . . . . . . . . . . . . . . . . . 53
6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Referências Bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
21
1 INTRODUÇÃO
O uso de Bando de Dados (BD) tornou-se recorrente para os mais

diversos tipos de aplicações, principalmente com o advento da Internet. Apli-
cações que utilizam BD online costumam armazenar dados sensíveis, como
salários, senha e número de cartão de crédito, entre outras informaçõees pes-
soais (KAMEL, 2009). Devido ao conteúdo potencialmente sigiloso, o acesso
ou a modificação não autorizada pode implicar em uma série de problemas
para o responsável e para os usuários destas aplicações. Outra ameaça possí-
vel é a falta de proteção contra super-usuários ou administradores do sistema.
Estes podem ter privilégio de acesso e fazer alterações não autorizadas e não
rastreáveis posteriormente. Por estes motivos a privacidade e a garantia de
não existirem alteração não autorizada de dados (sigilo e integridade) tem
atraído pesquisadores tanto da área de BD quanto da área de segurança.
Existem maneiras disponíveis no mercado para prevenção e minimi-
zação dos riscos envolvidos com o armazenamento de dados sensíveis em
BDs. Entre elas, o uso de Sistemas de Gerenciamento de Banco de Dados
(SGBDs) enriquecidos com funcionalidades de segurança. Estes costumam
ter alto custo de manutenção e de aquisição de licensa, providenciando solu-
ções de “caixa preta” para seus clientes. Desta forma, é necessário confiar-se
no provedor de serviços de segurança, sem conhecer realmente as garantias
propostas por eles.
Quanto ao objetivo deste trabalho, pode-se classificar as ameaças a
BDs em quatro tipos principais:
• leitura não autorizada de dados;
• modificação não autorizada de dados;
• remoção não autorizada de dados;
• adição não autorizada de dados.
1.1 OBJETIVO
1.1.1 Objetivo Geral
Este tabalho tem como objetivo geral demonstrar, através do uso de

operações criptográficas, como garantir a integridade, autenticidade e sigilo
de registros armazenados em BD independente de SGBD e protegendo-os
22
de ataques maliciosos e de modificações não autorizadas. Adicionalmente,

apresentar um método de validação do conteudo do BD, promovendo a ras-
treabilidade.
1.1.2 Objetivos Específicos
• Elaborar uma biblioteca em Java com a finalidade de prover suporte

para as soluções propostas neste trabalho;
• Providenciar suporte aos dispositivos criptográficos existentes no mer-
cado, criando novas camadas de segurança para aplicações que fizerem
uso da biblioteca;
• Facilitar o desenvolvimento de aplicações de software com garantia de
integridade de BD;
• Implementar as soluções propostas dentro de uma faixa de desempenho
atraente para aplicações que utilizarem a biblioteca criada.
1.2 JUSTIFICATIVA
Acontecimentos recentes podem ser tomados como exemplo para o

impacto resultante de ataques a sistemas que não sao devidamente protegidos.
No ano de 2011, a empresa Sony Entertainment declarou ter perdido cerca
de 170 milhões de dólares proveniente de ataques e acesso não autorizado à
informação de seus clientes (STANESCU, 2012).
O problema da leitura não autorizada de dados (sigilo dos dados) já
foi pesquisado extensivamente e, normalmente, é resolvido através da cifra-
gem do BD (CESELLI et al., 2005; SAMARATI; VIMERCATI, 2010), em
conjunto com métodos de indexação (CESELLI et al., 2005; DAMIANI et
al., 2003), para agilizar as consultas. Os problemas de modificações não au-
torizadas de dados (integridade dos dados) ainda necessitam de soluções efi-
cientes (SAMARATI; VIMERCATI, 2010). Os métodos existentes para esse
problema geralmente requerem o desenvolvimento de um novo SGBD ou al-
terações significativas nos SGBDs já existentes (XIE; WANG; YIN, 2007).
Adicionalmente, soluções disponíveis no mercado possuem custo elevado de
implantação e manutenção, inviáveis para empresas de pequeno e médio porte
que necessitam de tais serviços de segurança. Através de uma bibliotéca pro-
vedora de serviços, independente de SGBD, é possível eliminar estes riscos
de forma mais barata e também elaborar uma solução de domínio do desen-
volvedor, sem uso de “caixa preta”.
23
1.3 METODOLOGIA
Para a realização deste trabalho foram estudados métodos de autenti-

cação, validação de integridade e de cifragem de dados, de forma a alcançar
os objetivos determinados. Um modelo de solução foi elaborado e implemen-
tado atraves de uma biblioteca na linguagem Java. Em seguida foi construido
um protótipo afim de testar todas as funcionalidades levantadas e implemen-
tadas pela biblioteca. Por ultimo, com a finalidade de demonstrar a eficiência
das soluções propostas, foi elaborado um programa de teste de desempenho.
Por meio deste, foi possível classificar a eficiência em relação a cada operação
do BD, possibilitando avaliar qual a melhor solução dependendo de situações
especificas.
1.4 PUBLICAÇÕES
Este trabalho possibilitou a publicação de um artigo wotkshop de Tra-

balhos de Iniciação Científica (WTIC) no Simpósio Brasileiro em Segurança
da Informação e Sistemas Computacionais (SBSeg) 2012 (BECKER et al.,
2012).
1.5 ESTRUTURA DO TRABALHO
Nos seguintes capítulos serão introduzidos os conceitos abordados

neste trabalho. No capítulo 2, é desenvolvido o embasamento teórico fun-
damental para o entendimento dos métodos propostos. Serão discorrido con-
ceitos de criptografia.
No capítulo 3 serão abordados os conceitos sigilo, integridade, auten-
ticidade e rastreabilidade. Também são explicados os métodos utilizados para
solucionar o problema levantado por este trabalho. São utilizadas operações
criptográficas já explicadas no capítulo 2 para a garantia dos conceitos abor-
dados neste capitulo.
O capítulo 4 envolve a implementação de uma biblioteca criptográfica
com o objetivo de providenciar os métodos propostos de forma facilitada,
visando eficiência e eficácia na implementação de sistemas utilizem esta pro-
posta. Também são abordados as tecnologias e dispositivos suportados pela
biblioteca e o protótipo desenvolvido.
No capítulo 5 são demonstrados os resultados detestes realizados para
avaliar a eficiência computacional dos métodos propostos. É feito também
uma breve análise de cada cenário de teste e uma avaliação geral de desem-
24
penho.
No capítulo 6 são mencionados os trabalhos futuros e as considerações
finais relacionadas a este trabalho.
25
2 FUNDAMENTAÇÃO TEÓRICA
2.1 CRIPTOGRAFIA
Criptografia é o estudo e a arte de transformar informação de forma

que fique ilégivel ou incompreensível para todos exceto para quem ela for des-
tinada. Utilizada quase que exclusivamente em circunstâncias diplomaticas e
militares até decadas atrás, hoje é mais do que um meio de trocar informação
secreta (LUICIANO; PRICHETT, 1987). Existe uma necessidade urgente de
proteger a vasta quantidade de dados existêntes em meios digitais, mesmo
aqueles em ambientes supostamente seguros. De acordo com Housley, crip-
tografia pode ser definida como:
A palavra criptografia significa escondido ou escrita secreta. Criptografia é co-

nhecida geralmente como o embaralhamento e o desembaralhamento de mensa-
gens privadas. Uma mensagem é embaralhada para manter sua privacidade ou
para proteger sua confidencialidade. Técnicas modernas de criptografia são tam-
bém usadas para determinar caso uma mensagem foi alterada após o momento de
ter sido criada e para identificar a origem da mesma. Uma mensagem não adul-
terada tem integridade. O conhecimento da origem de uma mensagem significa
autenticidade. (HOUSLEY; POLK, 2001, p.-5, tradução nossa)
Existem diversos algoritmos criptográficos para cifragem e decifra-

gem de mensagens. Em sua maioria, faz-se uso de duas entradas para gerar
uma mensagem cifrada. Uma entrada é o conteudo da informação sigilosa e
a outra entrada é um valor secreto denominado chave. Esta chave pode ser
simétrica ou assimétrica.
2.1.1 Criptografia Simétrica
Na cripotografia simétrica, usa-se apenas uma chave secreta entre

quem envia e quem recebe a mensagem cifrada. Por este motivo, sistemas
que fazem uso de criptografia simétrica podem também ser chamados de sis-
temas de chaves secretas compartilhadas (HOUSLEY; POLK, 2001). Em um
cenário onde deseja-se enviar uma mensagem cifrada para alguém, deve-se
garantir que essa chave seja mantida em segredo entre destino e destinatá-
rio. Ela será utilizada no processo de cifragem por quem envia e também no
processo de decifragem por quem recebe.
A figura 1 mostra o funcionamento da criptografia simétrica, onde um
documento é cifrado com uma chave, e decifrado utilizando a mesma chave.
26
Figura 1 – Exemplo de criptografia simétrica
2.1.2 Criptografia Assimétrica
Enquanto o uso de chaves simétricas pode ser bastante conveniênte,

o gerenciamento das mesmas pode se tornar bastante complexo. Em alguns
casos, deseja-se manter uma vasta quantidade de chaves para comunicação
segura entre diversos periféricos. Nesses casos algoritmos de comunicação,
por exemplo, podem se tornar pouco eficiêntes devido a necessidade de ge-
renciar cada chave para um destino diferente.
Criptografia assimétrica ou criptografia de chaves públicas, utiliza
duas chaves distintas no lugar de uma. Uma delas chamada de chave privada
e a outra chamada de chave pública. Usualmente, a chave pública é distri-
buida em repositórios públicos para livre acesso, enquanto a chave privada
deve ser mantida em segredo. A figura 2 exemplica o uso de duas chaves,
uma para cifragem, e outra para decifragem. Ambas chaves são comple-
mentares, porém, nunca deve ser possível obter-se a chave privada através da
chave pública (HOUSLEY; POLK, 2001).
O uso de chaves públicas simplifica bastante o processo de gerencia-
mente de chaves pelo fato de reduzir drasticamente o numero de chaves que
serão gerenciadas. Por outro lado, algorítmos de cifragem de dados através do
uso de chaves públicas não são tão eficiêntes quando os de chave simétrica.
A cifragem com a chave pública é usada para garantir a confidenciali-
dade do documento cifrado, onde o emissor cifra o documento com a chave
pública do receptor, assim somente o receptor poderá decifrar o documento
através da sua chave privada (SCHNEIER, 1996).
27
Figura 2 – Exemplo de criptografia assimétrica
Existem diversos usos para criptografia de chaves públicas. Entre eles,

a troca de chaves públicas para gerar uma chave simétrica conhecida entre
apenas dois periféricos (DIFFIE; HELLMAN, 1976). Outro exemplo é a In-
fraestrutura de Chaves Públicas (ICP), mantendo uma cadeia de entidades
com posse de chaves privadas, é capaz de garantir autenticidade de documen-
tos eletrônicos para usuários (HOUSLEY; POLK, 2001).
2.1.3 Resumo Criptográfico
As funções de resumo criptográfico, também chamadas de funções

hash, tem como objetivo produzir uma saída única de tamanha fixo para cada
valor de entrada. Uma função de HASH deve ter as seguintes propriedades
(HOUSLEY; POLK, 2001, p.-9):
• É computacionalmente impraticavel recriar a mensagem original a par-

tir do valor de hash.
• É computacionalmente impraticavel criar duas mensagens diferentes
que gerem o mesmo valor de saída.
28
2.1.4 Código de Autenticação de Mensagem
Um autenticador de mensagem, também conhecido como Message

Authentication Code (MAC), é um valor carregado junto com a mensagem
usado para garantir a integridade e a autenticidade da mensagem enviada.
Para verificar a mensagem, o receptor calcula o MAC da mensagem recebida,
e compara o valor calculado com o MAC recebido junto com a mensagem, se
ambos forem iguais, o receptor terá a garantia da integridade e autenticidade
da mensagem. Para o calculo do MAC, ambas partes devem possuir uma
chave simétrica.
Algoritmos de MAC podem ser construídos a partir de outras funções
criptográficas, como funções de hash, chamada de HMAC.
O HMAC pode ser usado com qualquer função HASH, como Message-
Digest algorithm 5 (MD5), Secure Hash Algorithm 1 (SHA-1), entre ou-
tros, em combinação com uma chave secreta compartilhada. A força crip-
tográfica do HMAC depende das propriedades da função HASH utilizada.
(KRAWCZYK; BELLARE; CANETTI, 1997)
2.1.5 PKCS#12
PKCS#12 é um formato de arquivo para armazenar diversos objetos

criptográficos em um unico arquivo (PKCS#12, ). Normalmente utilizado
para armazenar uma chave privada com seu certificado.
Um arquivo PKCS#12 pode ser cifrado e assinado, assim como seus
conteudos, que também podem ser cifrados e assinados.
2.2 SEGURANÇA EM BANCOS DE DADOS
O termo Segurança de Bancos de Dados pode ser bastante vago, abran-

gendo diversos tópicos nesta linha de pesquisa. Adicionalmente, a maioria
dos SGBDs já possuem seu próprio sistema de segurança, geralmente garan-
tindo níveis de acesso de leitura e escrita.
Neste capítulo serão abordados os conceitos de Sigilo, Integridade,
Autenticidade e Rastreabilidade e como, através deles, pode-se garantir a se-
gurança e integridade de registros mantidos em BD.
29
2.2.1 Sigilo
Sigilo refere-se àquilo que é segredo, não público. Informação sigi-

losa deve ser mantida de forma que apenas aqueles com permissão possam
conhecer seu conteudo. É importante salientar a diferença entre permissão de
acesso e permissão de leitura, no caso de BD. Alguém que possua acesso a
um BD não necessariamente tem a permissão para conhecer todo o conteúdo
da informação armazenada neste (por exemplo a senha de usuários).
Um dos problemas mais comuns quando se trata do sigilo em base de
dados é a leitura não autorizada de informações sensíveis presentes nas apli-
cações. A proteção contra este tipo de acesso pode ser ser feita através do
cliente, pelo próprio SGBD ou através do uso de middlewares (SHMUELI
RONEN VAISENBERG YUVAL ELOVICI, 2010), fazendo uso da cifragem
dos dados desejados. Deve-se selecionar colunas onde existem informações
sigilosas nas tabelas e mantê-las cifradas. Para não afetar muito o desempe-
nho das consultas, é comum o uso de métodos de indexação juntamente com
a cifragem dos dados (CESELLI et al., 2005; DAMIANI et al., 2003).
2.2.2 Integridade e Autenticidade
Os conceitos integridade e autenticidade podem ser definidos da se-

guinte forma:
Autenticidade pode ser correlacionada com o conhecimento da identidade

da origem de uma informação. Uma vez que se confia nesta identidade
a informação passa a ser confiável também;
Integridade é a certeza de que uma informação em análise não sofreu alte-

rações indevidas desde sua origem até o seu destino.
A proposta deste trabalho consiste na aplicação do HMAC nos dados

de uma aplicação, possibilitando assim prover integridade e autenticidade aos
dados. Sem o conhecimento da chave da aplicação, um agente externo não
poderá adicionar novos dados na base de dados da aplicação e também não
podera alterar os dados ja existentes. Para garantir estas propriedades, basta
que aplique-se novamente o HMAC nos dados da aplicação e que comparare-
se com o valor já existente. Caso os valores não forem iguais, pode-se con-
cluir que aconteceu uma modificação ou adição não autorizada na base de
dados.
30
2.2.3 Rastreabilidade
Entende-se por rastreabilidade como o conhecimento da localidade de

um objéto em análise. No contexto deste trabalho, é relacionado a capacidade
de detectar a ausência de um registro integro e autêntico no BD.
O uso do HMAC cobre os casos de integridade e autenticidade. Porém,
um atacante ainda possui a possibilidade de remover dados da aplicação. Para
isso, é prosposto o uso de uma operação chamada Histórico Cifrado. Nela são
relacionados N valores de um BD, possibilitando identificar quando um valor
esta ausente.
2.3 TECNOLOGIAS UTILIZADAS
2.3.1 XML
A Extensible Markup Language (XML) é uma forma de texto sim-

ples e flexivel, derivado do Standard Generalized Markup Language (SGML)
(EXTENSIBLE-MARKUP-LANGUAGE, ).
Desenvolvida originalmente para os desafios da publicação eletronica
em larga escala, o XML também está aumentado de importancia em uma
grande variedade de dados da Web.
2.3.2 Java
Java é uma linguagem de programação extremamente popular e inde-

pendente de plataforma. Ela é executada pela Máquina Virtual Java (JVM).
Desde que foi criada, sua popularidade vem constantemente crescendo. Hoje
se encontra na segunda posição no ranking de popularidade, segundo TIOBE
(2013).
Isto influenciou na escolha desta linguagem para o desenvolvimento
da biblioteca proposta por este trabalho, de forma que existe bastante suporte
e clientes para a proposta no mercado. Ela se destaca pela definição explicita
de interfaces, classes abstratas e tipagem forte, permitindo a abordagem de
programação orientada a objetos.
31
2.3.3 LibCryptoDev
A biblioteca LibCryptoDev, desenvolvida pelo LabSEC, é uma bibli-

oteca feita em Java, que permite facilmente o acesso a dispositivos criptográ-
ficos conectados através de uma porta USB.
Com ela, podemos cifrar e decifrar um dado com o par de chaves
disponivel em um dispositivo.
32
33
3 SOLUÇÃO
Para evitar a modificação não autorizada de registros contidos na base

de dados, deve-se restringir e definir as permissões de cada usuário. O SGBD
também deve conter um mapeamento correto de usuários e seus respectivos
privilégios a fim de impedir a execução de ações não autorizadas. Entretanto,
existem perfis de usuários, como os administradores do servidor, Administra-
dor de Banco de Dados (DBA) e programadores, que podem acessar o SGBD
sem o conhecimento da aplicação, podendo ocorrer situações onde, embora
o usuário não seja autorizado a realizar determinada modificação, ele tenha
permissões suficientes no sistema que permitem que ele o faça, mesmo que
não intencionalmente.
A cifração de colunas que contém dados sensíveis já reduz conside-
ravelmente este problema, uma vez que um usuário mal-intencionado não
conseguirá modificar o registro por não possuir a chave, e possivelmente se-
quer será capaz de identificar qual registro ele deve modificar para obter os
efeitos que ele deseja. Embora as chances do atacante sejam reduzidas, ainda
há a possibilidade de realizar modificação de registros a fim de corromper o
sistema.
Infelizmente, os SGBDs mais comuns, como MySQL, PostreSQL, Fi-
rebird, etc, não possuem mecanismos para evitar tais problemas. Outros sis-
temas mais específicos possuem opções mais avançadas, porém também pos-
suem custo bastante elevado. Para prover tal funcionalidade, foi estudada
uma proposta que faz uso de HMAC (BELLARE; CANETTI; KRAWCZYK,
1996).
3.1 ADIÇÃO DO CÁLCULO DO HMAC NOS REGISTROS DA BASE DE

DADOS
Para se implementar este mecanismo, a aplicação será a única res-

ponsável pela manipulação dos registros da base de dados, e, para prover tal
garantia, a aplicação terá uma chave simétrica conhecida somente por ela.
Esta chave, por sua vez, será utilizada para gerar o HMAC dos registros.
Através da utilização do HMAC, é possível detectar qualquer modi-
ficação não autorizada realizada nos registros. Isto deve-se ao fato de que
o atacante não tem conhecimento da chave necessária para gerar o HMAC,
impossibilitando-o que consiga calcular um valor de HMAC válido. Este me-
canismo também soluciona a questão de adição de registros pelo atacante,
pois novamente, este necessitará da chave da aplicação para realizar o cálculo
34
do HMAC de forma correta, como pode ser visto na formula 3.1, onde k é
chave, e m são as informação que se deseja protejer.
HMAC(k, m) = HMAC(k, Nome||email) (3.1)
3.2 EXEMPLO DE IMPLEMENTAÇÃO
Para exemplificar o funcionamento do método utilizando HMAC, con-

sidere uma tabela exemplo, com as colunas id, nome, email e uma coluna
adicionada para armazenar o valor do HMAC. Considerenado uma aplicação
utilizando a chave k, e m como o resultado da operação concatenação das co-
lunas nome e e-mail, utlizando a formula 3.1 Os dados são apresentados na
Tabela 1.
Tabela 1 – Tabela de exemplo de dados.

id nome email hmac
1 Joao joao@foo.com.br abcd
2 Maria maria@foo.com.br qwer
3 Ana ana@foo.com.br kjhd
4 Roberto roberto@foo.com.br vpiu
3.2.1 ADICIONANDO REGISTROS
Para adicionar um novo registro, deve-se primeiramente calcular o va-

lor do HMAC para o novo registro. Esse cálculo é feito através da conca-
tenação dos valores de todas as colunas da tabela. Para adicionar uma nova
pessoa com o nome “Jose” e email “jose@foo.com.br”, o cálculo do HMAC
é apresentado na expressão (3.2).
HMAC(chave, Jose jose@ f oo.com.br) = ohn4 (3.2)

Após o calculo do HMAC, a aplicação envia o comando de insert ao
banco de dados, conforme ilustrado no trecho de código 3.1.
Trecho de código 3.1 – Código SQL para inserir um registro com HMAC
INSERT INTO exemplo ( nome , e m a i l , hmac )
VALUES ( ’ J o s e ’ ,
’ j o s e @ f o o . com . b r ’ ,
35
’ ohn4 ’ ) ;
3.2.2 MODIFICANDO REGISTROS
A modificação de um registro é semelhante à adição. Por exemplo,

para a alteração do registro número 3, da Tabela 1, primeiramente deve-se
consultar o banco de dados para obter o registro, conforme ilustrado no tre-
cho de código 3.2. O próximo passo é calcular o HMAC, apresentado na
expressão (3.3). Por fim, atualiza-se o registro com o comando update ilus-
trado no trecho de código 3.3.
Trecho de código 3.2 – Código SQL para selecionar um registro

SELECT nome , e m a i l FROM exemplo WHERE i d = ’ 3
’;
HMAC(chave, Anaana.new@ f oo.com.br) = m3cx (3.3)
Trecho de código 3.3 – Código SQL para atualizar um registro com HMAC
UPDATE exemplo SET e m a i l = ’ a n a . new@foo . com .
b r ’ , hmac= ’ m3cx ’
WHERE i d = ’ 3 ’ ;
3.2.3 VERIFICANDO A INTEGRIDADE DE REGISTROS
Por fim, para verificação da integridade de um registro, deve ser feita

uma consulta ao banco de dados pelo registro. Calcula-se o HMAC para o
registro e compara o HMAC calculado com o HMAC obtido do banco de
dados. A igualdade desses valores indica que o registro está íntegro.
3.3 MEDIDAS DE PROTEÇÃO CONTRA REMOÇÃO NÃO AUTORIZADA
Através da utilização do HMAC, já é possível detectar qualquer mo-

dificação e adição não autorizada de registros. Entretanto, não é possível
detectar a remoção não autorizada de registros.
Para o problema de remoção não autorizada de registros, sugere-se a
criação de uma nova coluna para as tabelas do banco de dados, chamada de
“Histórico cifrado”. O histórico cifrado possui as seguintes características:
36
• permite relacionar dois ou mais registros de forma que possa se detectar

a ausência de um deles, caso este seja removido;
• não permitir que uma terceira parte possa calcular o “histórico cifrado”
sem conhecer as chaves de cifração;
• utilização de operações de baixo custo computacional: criptografia si-
métrica e a operação lógica “ou exclusivo” (XOR);
• requer pouco espaço de armazenamento;
• não permite que sejam detectadas deleções dos n últimos registros.
Para calcular o histórico cifrado de um registro n, obtém-se o HMAC

desse registro e do registro anterior a ele. Em seguida é aplicada a função
XOR nestes HMACs e o resultado é cifrado com uma chave simétrica. Esse
cálculo é apresentado na expressão (3.4).
HistoricoCi f rado(chave, HMACn , HMACn−1 ) = Ci f rao(k, (HMACn ⊕ HMACn−1 ))

(3.4)
3.3.1 REMOVENDO UM REGISTRO
Para remover um registro n, deve-se excluir o registro e atualizar o

histórico cifrado do registro n + 1. Para atualizar o histórico cifrado, utiliza-
se o HMAC registro n + 1 e n − 1.
3.3.2 VERIFICANDO SE UM REGISTRO FOI REMOVIDO
Para verificar se um registro tn , de uma tabela T foi removido, a se-

guinte propriedade deve ser satisfeita:
∀tn ,tn+1 ∈ T : tn .HistoricoCi f rado = HistoricoCi f rado(chave,tn ,tn+1 )

(3.5)
3.3.3 REMOÇÃO DO ULTIMO REGISTRO
Esta proposta não cobre o caso da remoção do ultimo registro, o mé-

todo apresentado não detecta quando os últimos registros são removidos in-
devidamente, uma vez que a verificação é feita com base no registo anterior.
37
Uma possível solução para o problema consiste em adicionar ao final da ta-

bela uma enupla com valores aleatórios conhecidos. Dessa forma, se o último
registro for removido, poderá ser identificado, uma vez que os valores de con-
trole não estarão mais presentes.
Segundo Silverio, Mello e Custodio (2013), outra solução possível é
adição de um método circular, assim, para o primeiro registro, deve-se con-
siderar o ultimo registro como seu anterior. Ao excluir o ultimo registro, é
possivel detectar a exclusão verificando o primeiro registro. Assim, a verifi-
cação pode ser iniciada pelo primeiro registro, pois agora o primeiro registro
possui um antecessor (no modo normal, como o primeiro registro não tem um
antecessor, a verificação se inicia a partir do segundo registro).
38
39
4 IMPLEMENTAÇÃO
Utilizando a linguagem de programação Java, foram implementados,

além da biblioteca para prover os serviços propostos, diversas ferramentas de
apoio, como gerenciador de chaves em disco, módulo para integração com
TPM, além de um protótipo que utiliza a biblioteca desenvolvida. Para su-
porte as operações criptográficas, foi utilizado a biblioteca Bouncy Castle
(LEGION. . . , ).
4.1 BIBLIOTECA
Para a implementação das operações propostas, foi implementada uma

biblioteca, conforme o diagrama de classes 13 disponivel dos anexos.
Na biblioteca, existe uma classe para representar as chaves de cálculo
de HMAC, a classe HMacKey, e outra para o cálculo do histórico cifrado, a
SymmetricKey. Também existem as classes geradoras destas chaves, HMac-
KeyGenerator e SymmetricKeyGenerator, respectivamente.
Para o cálculo do HMAC, além das classes responsáveis pela chave
HMAC, exite uma responsável pelo cálculo do HMAC, a HMacCalculator, e
outra classe para representar um HMAC. O trecho de código 4.1 demonstra
como é feito o cálculo do HMAC de uma mensagem qualquer.
O diagrama de sequencia 3 mostra detalhadamente como a execução
do método getHmac faz o cálculo do HMac a partir de uma lista de dados.
Trecho de código 4.1 – Exemplo do cálculo do HMAC

HMacKey key = HMacKey : : g e n e r a t e ( "SHA1" ) ;
HMACCalculator hmacCalc = new
HMACCalculator ( key ) ;
hmacCalc . u p d a t e ( " mensagem " ) ;
HMAC hmac = hmacCalc . d o F i n a l ( ) ;
Para o histórico cifrado, tem-se a classe responsável pelo cálculo (En-

cryptedHistoryCalculator) e a classe que representa o histórico cifrado (En-
cryptedHistory). Para iniciar o cálculo do histórico, é necessário uma chave
simétrica (SymmetricKey). Para o cálculo do histórico, é necessário fornecer
uma lista de HMACs e uma chave simétrica, conforme ilustrado no trecho de
código 4.2, nele, fazemos uma cópia dos HMACs existentes, para não operar
diretamente sobre os mesmos. A seguir, é inicializado uma variavel tempo-
rária com o primeiro HMac, e em seguida, percorrido esta lista, é aplicada
a operação XOR sobre cada byte de cada HMAC com o resultado anterior
40
Figura 3 – getHmac()
sucessivamente, até se esgotar os HMACs. Em seguida, este resultado das

sucessecivas operações XOR é cifrado, com um cifrador inicializado anteri-
ormente com a chave simétrica da aplicação. Para o ciframento simétrico,
temos a classe SymmetricCipher.
Trecho de código 4.2 – Exemplo do cálculo do HMAC

p u b l i c E n c r y p t e d H i s t o r y g e n e r a t e ( L i s t <HMac>
hMacs ) throws S y m m e t r i c C i p h e r E x c e p t i o n ,
EncryptionException {
L i s t <HMac> h = new A r r a y L i s t <HMac > ( ) ;
f o r ( HMac hMac : hMacs )
h . add ( hMac . c l o n e ( ) ) ;
byte [ ] xor = h . get ( 0 ) . getBytes ( ) ;
f o r ( i n t i = 1 ; i < h . s i z e ( ) ; i ++) {
b y t e [ ] hmac = h . g e t ( i ) . g e t B y t e s
() ;
f o r ( i n t j = 0 ; j < hmac . l e n g t h
41
; j ++)
xor [ j ] = ( byte ) ( xor [ j ]
^ hmac [ j ] ) ;
}
byte [ ] r e s u l t = c i p h e r . doFinal ( xor ) ;
r e t u r n new E n c r y p t e d H i s t o r y ( r e s u l t ) ;
}
A biblioteca também possui classes para geração de chaves assimétri-

cas (LSKeyPairGenerator), e para representar estas chaves (LSKeyPair).
Finalmente, temos a classe abstrata ApplicationKeyStore, responsável
por gerar as chaves simétricas e assimétricas utilizadas pela aplicação. Esta
classe possui os métodos load e save abstratos, sendo assim possível imple-
mentar diversos formatos para salvar as chaves, sendo preciso somente im-
plementar estes métodos. Nesta implementação, foi utilizado o formato Ex-
tensible Markup Language (XML), tendo a classe XMLApplicationKeyStore
responsável pela implementação dos métodos para abrir e salvar as chaves em
formato XML.
4.1.1 Provedor de serviços
Existem também as classes SecurityService e SecurityServiceSPI. A

classe SecurityService possibilita efetuar diretamente o cálculo de HMAC,
Histórico Cifrado e ciframento, sendo preciso apenas usar os métodos corres-
pondentes diretamente, realizando toda a operação em apenas uma função,
por exemplo, para realizar o cálculo de um HMAC, devemos apenas chamar
o método getHMAC(fields:List<objs>) passando a lista de objetos que sera
utilizada no cálculo. As chaves simétricas e assimétricas usadas são definidas
pela classe SecurityServiceSpi.
A classe SecurityServiceSpi deve ser implementada por um prove-
dor, com a finalidade de suportar os mais diversos dispositivos criptográficos
através de uma mesma interface. Desta forma, pode-se adicionar diferentes
dispositivos criptográficos simplesmente implementando uma interface, não
sendo necessários realizar grandes alterações na aplicação. O diagrama de
classes da Figura 4 apresenta esta abstração das classes SecurityService e Se-
curityServiceSpi.
As chaves utilizadas são obtidas através de um arquivo de configura-
ção, disponivel no anexo 6.1, nele é definido o nome da chave HMAC e o
nome da chave simétrica, que devem estar no KeyStore da aplicação, o prove-
dor deve disponibilizar estas chaves decifrando o KeyStore.
42
Figura 4 – Representação do provider da biblioteca
4.2 PROVIDER
O provider, LSSecurityService, possui a implementação dos metódos

da classe SecurtyServiceSPI, segundo o diagrama 4, implementando opera-
ções comuns de todos os dispositivos criptográficos suportados, e que não os
envolve diretamente, como a leitura dos arquivos de configuração. Na imple-
mentação feita, as chaves de HMAC e Histórico Cifrado utilizadas no cálculo
pela biblioteca são definidas através de um arquivo de configuração. Existe
também outro arquivo de configuração para os dispositivos suportados, com
suas particularides. Todos possuem o caminho do KeyStore utilizado pela
biblioteca, e o nome da chave utilizada para cifrar o mesmo KeyStore.
4.2.1 PKCS12 Security Service
Para suportar chaves em disco, existe o PKCS12SecurityService. Ele

gerencia um KeyStore PKCS#12 e utiliza um arquivo de configuração PKCS12SecurityService.x
disponível no anexo 3. Neste arquivo, além do caminho e chave do KeyStore,
exite o caminho do KeyStore, um arquivo .p12.
Na inicialização do serviço, é criado uma instância do KeyStore do
Java, através de um callback é pedido a senha para abrir o arquivo p12. Em
seguida é aberto o KeyStore através do metodo load do KeyStore da biblio-
teca. Com ele aberto, é disponibilizado a chave HMAC e a simétrica.
Para o gerenciamento do KeyStore PKCS#12 foi implementado uma
nova aplicação, o PKCS#12 MANAGER, apresentado na sesão 4.3.
4.2.2 Smart Card Security Service
O SmartCardSecurityService provê suporte a SmartCards, com auxilio

da biblioteca LibCryptoDev. Ele faz a leitura do seu respectivo arquivo de
configuração, selecionando o alias da chave publica e o caminho do KeyStore.
43
Com o uso deste provider, é possível o uso de chaves em SmartCards

e Tokens para cifrar e decifrar o KeyStore.
4.2.3 HSM Security Service
O HSMSecurityService suporta Hardware Security Modules (HSM)

PKCS#12, também com auxilio da LibCryptoDev, funcionando similarmente
ao SmartCardSecurityService.
Adicionalmente, este service faz a leitura de outras informações ne-
cessárias para a utilização do HSM, definidas na geração do KeyStore através
do KeyStoreManager.
4.2.4 TPM Security Service
Já o TPMSecurityService, da suporte a Trusted Platform Modules (TPM)

com auxílio da biblioteca TPMj. Porém, esta biblioteca possui suas particula-
ridades, sendo preciso sobrescrever os métodos load e save do XMLApplica-
tionKeyStore. Assim, existe o modulo de extenção da biblioteca para suportar
TPMs.
As chaves exportadas pela biblioteca TPMj também não são compa-
tiveis com o KeyStoreManager, ela exporta apenas o número e da chave pú-
blica, não exportando o número n.
Então, também foi implementado um simples programa para conver-
ter chaves do formato disponibilizado pela biblioteca TPMj para uma chave
pública RSA. Nele, a chave chave pública RSA é construida a partir do nú-
mero e, obtido, e do número n, utilizando o número 65537, o mesmo utilizado
internamente pelo TPM.
4.2.5 Remote Callback
Cada dispositivo criptográfico é protegido por uma senha, sendo pre-

ciso digita-lá a cada inicialização do sistema. Então, para poder inicializar o
sistema remotamente, o que pode ser preciso em um ambiente real, foi im-
plementado o simples serviço Remote Callback Client. Sua implementação
consiste em simples cliente e servidor TCP.
Através da linha de comando, ele possibilita a realização da operação
de digitar o pin de um dispositivo utilizado a partir de um computador remoto.
Com o cliente se conectando no servidor, onde o servidor recebe o pin para
44
liberar o dispositivo.
4.3 PKCS#12 MANAGER
O programa o PKCS#12 Manager, possibilita o gerenciamento de cha-

ves em disco. Nele , existem opções para gerar pares de chaves RSA, e pos-
teriormente, salvar estas chaves, para salva-lás, é criado um certificado que
armazena o par de chaves criado juntamente com um nome. Também é pos-
sível exportar a chave pública para ser usada no KeyStore Manager.
o PKCS#12 Manager funcionana criando um novo KeyStore do Java,
nesse KeyStore adicionamos o alias do par de chaves, a chave privada, a ca-
deia de certificação (criada com apenas um certificado) e uma senha. Essa
senha sera a mesma para todos os pares de chaves adicionados neste KeyS-
tore.
A figura 10, disponível nos anexos, mostra esta aplicação. Nela, temos
um painel para visualizar as chaves geradas, com a opção de exportar cada
chave pública, um painel para gerar novas chaves, e um campo para digitar a
senha que será utilizada para cifrar o KeyStore.
4.4 KEYSTORE MANAGER
O KeyStore Manager tem como objetivo criar um novo KeyStore ou

editar um ja existente no formato XML, para utilização na biblioteca.
O KeyStore Manager cria uma nova instancia do gerenciador de KeyS-
tore da biblioteca. Nele é possível adicionar chaves simétricas e HMACs para
o uso nas operações da biblioteca, além de chaves públicas dos dispositivos
suportados (PKCS#12, SmartCard, HSM e TPM).
Para editar arquivos, existe opções separadas para abrir o KeyStore
a partir de chaves PKCS#12, SmartCard e HSM, ou TPM, pois como mos-
trando na seção 4.2, esses dispositivos possuem diferentes formas para aces-
sar suas chaves privadas. Ao editar, é possível adicionar ou excluir qualquer
tipo de chave, além de alterar seu alias.
Para abrir o KeyStore com PKCS#12, é necessário o caminho do KeyS-
tore, do caminho do arquivo p12 e a senha do p12. Enquanto para os outros
dispositivos, é preciso apenas do caminho do KeyStore, e de seua senha.
A figura 11, disponível nos anexos, mostra esta aplicação. Nele te-
mos paineis para gerar chaves HMACs e chaves Simétricas, um painel para
visualiza-las, e outros paineis para adicionar chaves públicas que serão utili-
zadas para cifrar o KeyStore.
45
4.5 PROTÓTIPO
Foi implementado um protótipo que faz uso de todas as funcionalides

providas pela biblioteca. Como a biblioteca e os demais programas auxiliares,
foi implementado utilizando a linguagem Java.
Nele, é exemplificado a implementação das funções disponibilizadas
da biblioteca. Existem algumas tabelas, e em cada uma delas, existem os
campos HMAC e Histórico cifrado. Ao adicionar novos dados nas tabelas,
primeiro é feito o cálculo do HMAC e do Histórico Cifrado, e em seguida,
são adicionados no BD.
O protótipo também faz a verificação da integridade do BD. Para isso,
é feito novamente o cálculo do HMAC e do Histórico Cifrado e estes são
comparados com o valor adicionado na tabela. Caso os valores não sejam
iguais, existe uma falha de integridade da base de dados.
Na figura 12, disponivel nos anexos, pode-se ver a tela responsável
pela verificação da integridade da base de dados.
46
47
5 DESEMPENHO
Devido a forma com que as soluções propostas neste trabalho são fei-
tas, as operações básicas de BDs sofrerão perdas de desempeho. Na operação
de atualização de registros, por exemplo, serão necessário os seguintes pas-
sos:
• Atualização do registro desejado;
• Cálculo do novo HMAC do registro alterado;
• Busca do HMAC do registro anterior;
• Atualização do Histórico Cifrado do registro alterado com o novo HMAC
calculado e com o HMAC do registro anterior.
Considerando a necessidade de posse do HMAC do registro anterior
para fazer a atualização de um registro qualquer, o custo da operação de atu-
alização de registros no BD será sempre incrementada no mínimo pelo custo
da operação de busca, além do custo das operações criptográficas.
Neste capítulo, serão demonstrados e analisados os resultados de testes
de desempenho. O propósito disto é verificar qual o custo computacional de
cada método proposto e como isto pode afetar aplicações que empregam estes
métodos.
Os testes realizados simulam apenas o custo da solução e não da bibli-
oteca implementada para este trabalho. Cada operação é executada 500 vezes
em um ambiente de teste pré-estabelecido, os resultados apresentados são os
valores médios destas execuções.
5.1 AMBIENTE DE TESTE
O protótipo feito para a execução dos testes de desempenho, detalhado

na tabela 2, foi escrito na linguagem de programação C. Isto permitiu que os
testes simulem apenas os métodos propóstos, com maior foco no desempe-
nho e simplicidade das operações implementadas. Utilizou-se a biblioteca
criptográfica OpenSSL junto da biblioteca para acesso ao BD MySQLClient.
A execução do programa foi feita no sistema operacional Ubuntu 12.04 64bits
utilizando o comando “nice -n -20”. Desta forma, é possível favorecer a apli-
cação de testes quanto ao escalonamento de processos de sistema. Isto é
necessário para que o número de operações interrompidas pelo sistema ope-
racional seja mínimo, tornando a média dos resultados mais próxima do valor
real.
48
Tabela 2 – Tabela de Especificações do Ambiente de Teste

Componente Especificação
CPU Intel Core i5-3450S
Memória 4Gb
Sistema Operacional Ubuntu 64bits 12.04
GCC 4.6.3
MySQL 14.14 Distrib 5.5.32
OpenSSL 1.0.1
Cifragem AES
Hash SHA-1
Chave 128bits
A tabela de BD utilizada para os testes é de formato simples, sem uso

de chaves estrangeiras. Foram utilizados registros com seis colunas: Identifi-
cador, Nome, E-mail, Senha, HMAC e Histórico Cifrado.
5.2 OTIMIZAÇÕES
Em alguns dos resultados de desempenho apresentados neste trabalho,

são comparados valores de operações com e sem otimização. Estas otimiza-
ções, sugeridas por Silverio, Mello e Custodio (2013), referem-se ao uso de
consultas específicas e ao uso de cache, melhorando o desempenho das ope-
rações no BD que correspondem à maior parcela do tempo de execução.
Para a otimização das operações no BD, utilizou-se consultas que bus-
cam ou atualizam mais de um registro por vez, evitando o uso excecivo de
comandos SELECT e UPDATE.
No trecho de código 5.1, é feita uma consulta SELECT que retorna um
bloco de três registros, o registro alvo (n), seu antecessor (n-1) e seu sucessor
(n+1).
Trecho de código 5.1 – Código SQL para consultar três registros consecutivos
no BD
SELECT i d , name , e m a i l , p a s s w o r d , HMAC, h i s t o r y
FROM benchmark . u s e r
WHERE i d IN ( n −1 , n , n +1 ) ;
No trecho de código 5.2, um bloco de dois registros são atualizados

dentro da mesma consulta UPDATE., desta forma o SGBD realiza as duas
operações de forma atômica e mais eficiente. A lógica deste código é se-
49
melhante ao operador switch case, presente em diversas linguagens de pro-

gramação. Definiu-se cada caso de atualização vinculado ao atributo id dos
registros.
Trecho de código 5.2 – Código SQL para atualizar dois registros simultanea-
mente no BD
UPDATE benchmark . u s e r SET

name = CASE i d
WHEN a THEN ’ J o a o ’
END,
e m a i l = CASE i d
WHEN a THEN ’ joao@foo . com . b r ’
END,
p a s s w o r d = CASE i d
WHEN a THEN ’ a l g u m a S e n h a ’
END,
hmac = CASE i d
WHEN a THEN ’ qpwer ’
END,
h i s t o r y = CASE i d
WHEN a THEN ’ b r n t a ’
WHEN b THEN ’ k r l t k ’
END
WHERE i d IN ( a , b ) ;
5.3 TESTE
Para que os testes de desempenho simulem de forma mais detalhada

possível, foi determinado que, além do tempo de execução total de cada ope-
ração, seja calculado também o tempo relativo a execução das consultas no
bado de dados e ao tempo de execução das bibliotécas criptográficas no cli-
ente de forma separada. Adicionalmente, foram simuladas soluções que fa-
zem o uso de consultas mais eficientes, como já visto na seção 5.2, e soluções
alternativas para o problema conhecido do último registro.
Na figura 5 apresenta-se em detalhe a execução dos testes para a ope-
ração INSERT. Cada par de pontos (BD e Total de acordo com a legenda)
corresponde a uma execução da operação de inserção, mostrando o tempo
total da execução e o tempo para o BD. No gráfico é possível observar o com-
portamento das execuções feitas durante o teste de desempenho, incluindo
os valores mais discrepantes correspondentes a possíveis escalonamentos de
50
Figura 5 – Ensaio de desempenho da operação INSERT
processo do Sistema Operacional.
5.3.1 Inserção de Registros
No caso da inserção de registros, todas as formas possíveis de utiliza-

ção do HMAC, do Histórico e do Histórico Circular tem desempenho dife-
rente. Na figura 6, observa-se que o uso de HMAC + Histórico quase triplica
o tempo de execução em relação a inserção de registros com HMAC sem o
Histórico Cifrado. Com a utilização do Histórico Circular, o tempo para in-
serção aumenta consideravelmente pela necessidade de atualizar o último e
primeiro registro. Por outro lado, se for abservado a operação que faz uso
apenas do HMAC, sem Histórico Cifrado, o tempo de BD é praticamente o
mesmo que o da inserção de registros sem proteção alguma. O tempo to-
tal diferencia-se apenas no tempo que o protótipo de teste leva para gerar o
HMAC do registro. Isto mostra a eficiêcia desta operação e viabilidade para
uso quando o alto desempenho é um fator crítico.
Para o caso da inserção com Histórico Circular, particularmente, é
possível que melhore-se o desempenho. Se forem armazenados os valores
de HMAC do primeiro e do último registro da tabela do BD em CACHE
(SILVERIO; MELLO; CUSTODIO, 2013), os testes mostram uma melho-
ria de aproximadamente 20% pelo fato de não haver a necessidade de fazer
esta busca no BD. Isto esta demonstrado na figura 6 pela coluna “Histórico
Circular Otimizado”.
51
Figura 6 – Resultado dos testes de desempenho da operação INSERT
5.3.2 Atualização de Registros
Considerando os resultados apresentados na Figura 7 e 6, pode-se ob-

servar que a operação de atualização de registros não é tão afetada quanto a
de inserção. O valor total para o tempo da operação de atualização é maior
do que o de inserção, mas proporcionalmente é mais eficiente. Comparando
o uso de HMAC e Histórico Cifrado separados, o tempo de execução chega a
triplicar assim como no caso da inserção. Por outro lado, a utilização do His-
tórico Cifrado Circular não afeta o desempenho. Desta forma pode-se optar
pela perda de desempenho na inserção sem afetar a operação de atualização
na utilização da solução circular.
Figura 7 – Resultado dos testes de desempenho da operação UPDATE

52
Assim como para a operação de inserção demonstrado na seção 5.3.1,

foi avaliado também uma solução otimizada para a operação de atualização.
Neste caso, a utilização de consultas mais eficiêntes como mencionado na
seção 5.2, reduzindo o tempo de execução pela metade.
5.3.3 Remoção de Registros
A remoção de registros é afetada apenas no uso do Histórico Cifrado.

Para o uso de HMAC apenas, não é necessário fazer consulta ao registro an-
terior ou validação de integridade.
Observa-se na Figura 8 que o tempo médio de execução da remoção de
registros com Histórico Cifrado e Histórico Circular é praticamente o mesmo.
Isto acontece pela necessidade de atualizar o Histórico do registro seguinte
com o HMAC do registro anterior. No caso da remoção do último registro,
quando não se utiliza o Histórico Circular, o tempo de execução da remo-
ção é igual ao tempo de execução utilizando apenas HMAC ou sem proteção
alguma.
Figura 8 – Resultado dos testes de desempenho da operação DELETE
Os testes executados demonstram um aumento de de cerca de 25%

de eficiência quando utilizado as otimizações da seção 5.2. Se comparado
com a operação de atualização da seção 5.3.2 (cerca de 50% de eficiência),
o aumento não foi tão grande. O motivo disto é pelo fato que a operação
de atualização possui mais consultas otimizadas, fazendo uso das consultas
SELECT e UPDATE de forma mais eficiente.
53
5.3.4 Consulta de Registros
A operação de consulta de registros do BD é de forma geral a mais

eficiênte. Para o caso de teste de consulta de registro com o uso de HMAC, o
tempo de BD não é afetado. O tempo de Cliente é afetado apenas pelo cálculo
do HMAC do registro e da verificação de integridade.
Mais uma vez, pode-se observar pela Figura 9 que o uso de Histórico
Circular não afeta o tempo de execução do uso de Histórico Cifrado. Pode-se
concluir finalmente que a solução de Histórico Circular, em comparação com
o modo não circular, afeta apenas o desempenho da operação de insersão.
Figura 9 – Resultado dos testes de desempenho da operação SELECT
A operação de consula também pode ser tornada mais eficiênte. O

resultado dos testes mostram que a otimização para este caso melhora o de-
sempenho em cerca de 23%. Muito próximo da melhoria vista na seção 5.3.3
sobre a operação de remoção.
5.4 CONSIDERAÇÕES E ANÁLISES
Antes de fazer a análise dos resultados, é preciso avaliar algumas con-

siderações. Os testes realizados para este capítulo foram feitos em tabelas
relativamente simples, sem o uso de chaves estrangeiras e operações em múl-
tiplas tabelas. Outro fato que pode influenciar nos testes são as espcifica-
ções da máquina onde eles foram executados e a eficiência dos algoritmos
(incluindo tamanho de chave) utilizados no programa de teste. Todos estes
fatores contribuem com os resultados obtidos.
Tendo todas as operações básicas de BD analisadas, em primeiro lugar,
54
fica evidente que o uso de HMAC é extremamente eficiente para a maior parte
dos casos. O pior caso mostrado pelos testes é o da atualização de registro,
onde o uso de HMAC dobra o tempo de execução. Ademais, com exceção da
operação de inserção e atualização utilizando Histórico Cifrado, as operações
criptográficas são extremamente eficiêntes. Isso é demonstrado a partir do
tempo de execução do cliente, correspondendo a menor parcela em todos os
testes realizados.
Tabela 3 – Tabela de Análise dos Resultados dos Testes

ATUALI-
INSERÇÃO REMOÇÃO CONSULTA
ZAÇÃO
Sem Proteção (ms) 67,88 107,66 76,77 27,78
HMAC (ms) 73,49 215,87 76,67 32,13
Histórico Cifrado (ms) 168,18 607,46 371,02 240,35
Histórico Circular (ms) 450,70 - - -
Histórico Circular
350,14 300,20 278,24 151,65
Otimizado (ms)
Custo HMAC(%) -8 -100 0 -15
Custo Histórico
-415 -178 -262 -445
Circular Otimizado(%)
Analisando a tabela 3, pode-se ter uma ideia melhor do custo percen-

tual das soluções propostas para cada uma das operações básicas. O custo da
operação de Histórico Cifrado (não circular) não está apresentado. Com ex-
ceção da operação de inserção, o custo dela é o mesmo que o custo da solução
circular (calculado ao final da tabela).
Apesar de não ter boa eficiência, o uso de HMAC junto com Histórico
cifrado ainda é viável. Existem tipos de aplicações que podem fazer o uso
destas soluções sem afetar o desempenho geral no meio de produção (Siste-
mas de Votação Online ou com Urna por exemplo).
55
6 CONSIDERAÇÕES FINAIS
Através da implementação da biblioteca de funções criptográficas, foi

possível resolver os problemas propostos como objetivo deste trabalho. Por
meio desta, ameaças como o a leitura e a escrita não autorizadas podem ser
solucionadas independente de SGBD. Esta biblioteca pode ser utilizada em
projetos da Universidade Federal de Santa Catarina (UFSC), por exemplo,
sem haver a necessidade de adquirir licença de SGBDs que já possuem estes
recursos.
Apesar destas vantagens, o custo de implantação deste trabalho ainda
deve ser considerado. A utilização da biblioteca, em sistemas já existentes,
pode significar gastos significantes em mão de obra refatorando código exis-
tente. Também deve ser tomado em consideração o custo de desempenho no
momento da sua utilização. Como já foi mostrado no capítulo 5, a utilização
do HMAC é uma solução atraente para aplicações que presam o alto desem-
penho. Já o uso de Histórico Cifrado (tanto o modo circular quanto o modo
normal) não mostrou a eficiência esperada como objetivo deste trabalho.
6.1 TRABALHOS FUTUROS
Como trabalhos futuros, propõe-se elaborar uma proposta eficiênte

para a solução do histórico cifrado. A utilização de HMAC apenas não é
suficiente para resolver o problema da remoção não autorizada.
Outra proposta para incrementar este trabalho é o suporte para o uso
da biblioteca em BDs distribuidos e/ou em nuvem. Para este problema, novas
abordagens podem ser tomadas fazendo o uso de esquemas criptográficos
como RSA, IBC, ABE e etc.. (APPENZELLER; MARTIN; SCHERTLER,
2009; MAJIY; PRABHAKARANY; ROSULEKZ, 2010)
Finalmente, propõe-se a incrementação da biblioteca Libcryptosec (LIB-
CRYPTOSEC, 2008) de forma a realizar todas as operações de integridade
abordadas por este trabalho. Desta forma será possível melhorar as aplica-
ções Ywapa e Ywyra (PROGRAMA-JOãO-DE-BARRO, 2008) - desenvol-
vidas no Laboratório de Segurança em Computação (LabSEC) em parceria
com o Insituto Nacional de Tecnologia da Informação (ITI) - no quesito de
segurança com verificações e validações importantes e inexistentes nestes sis-
temas hoje.
56
57
REFERÊNCIAS BIBLIOGRÁFICAS
APPENZELLER, G.; MARTIN, L.; SCHERTLER, M. Identity-Based

Encryption Architecture and Supporting Data Structures. IETF, jan.
2009. RFC 5408 (Informational). (Request for Comments, 5408).
Disponível em: <http://www.ietf.org/rfc/rfc5408.txt>.
BECKER, G. et al. Análise e implementação de um método para prover

sigilo e integridade a sistemas de banco de dados. In: SBSeg 2012 WTICG
(). http://sbseg2012.ppgia.pucpr.br/: [s.n.], 2012. Disponível em:
<http://sbseg2012.ppgia.pucpr.br/@docs/SBSeg2012Anais.pdf>.
BELLARE, M.; CANETTI, R.; KRAWCZYK, H. Keying hash functions for

message authentication. In: Proceedings of the 16th Annual International
Cryptology Conference on Advances in Cryptology. London, UK, UK:
Springer-Verlag, 1996. (CRYPTO ’96), p. 1–15. ISBN 3-540-61512-1.
Disponível em: <http://dl.acm.org/citation.cfm?id=646761.706031>.
CESELLI, A. et al. Modeling and assessing inference exposure in encrypted

databases. ACM Transactions on Information and System Security
(TISSEC), v. 8, n. 1, February 2005.
DAMIANI, E. et al. Balancing confidentiality and efficiency in untrusted

relational DBMSs. In: Proc. of the 10th ACM Conference on Computer
and Communications Security. Washington, DC, USA: [s.n.], 2003.
DIFFIE, B. W.; HELLMAN, M. E. New directions in criptography. IEEE

Transactions on Information Theory, IT-22, n. 6, p. 644–654, 1976.
EXTENSIBLE-MARKUP-LANGUAGE.
http://www.w3.org/TR/2008/REC-xml-20081126/. Acessado em:
2013-10-14.
HOUSLEY, R.; POLK, T. Planning for PKI: Best Practices Guide for
Deploying Public Key Infrastructure. [S.l.]: Wiley Computer Publishing,
2001.
KAMEL, I. A schema for protecting the integrity of databases. Computers

& Security, Elsevier Ltd, v. 28, n. 7, p. 698–709, out. 2009. ISSN
01674048. Disponível em:
<http://linkinghub.elsevier.com/retrieve/pii/S0167404809000297>.
58
KRAWCZYK, H.; BELLARE, M.; CANETTI, R. HMAC: Keyed-Hashing

for Message Authentication. IETF, fev. 1997. RFC 2104 (Informational).
(Request for Comments, 2104). Updated by RFC 6151. Disponível em:
<http://www.ietf.org/rfc/rfc2104.txt>.
LEGION of the Bouncy Castle. http://www.bouncycastle.org/.
Acessado em: 2013-10-14.
LIBCRYPTOSEC. 2008.
http://www.labsec.ufsc.br/en/bibliotecas-criptograficas/.
LUICIANO, D.; PRICHETT, G. From caesar ciphers to public-key
cryptosystems. The College Mathematics Journal, v. 18, n. 1, p. 2–17,
January 1987.
MAJIY, H. K.; PRABHAKARANY, M.; ROSULEKZ, M. ttribute-based
signatures. In: RSA Conference. [s.n.], 2010. Disponível em:
<http://eprint.iacr.org/2010/595.pdf>.
PKCS#12. http:
//www.emc.com/emc-plus/rsa-labs/standards-initiatives/
pkcs12-personal-information-exchange-syntax-standard.htm.
PROGRAMA-JOãO-DE-BARRO. 2008.
http://www.iti.gov.br/programas/programa-joao-de-barro.
SAMARATI, P.; VIMERCATI, S. D. C. di. Data protection in outsourcing
scenarios: issues and directions. In: Proceedings of the 5th ACM
Symposium on Information, Computer and Communications Security.
New York, NY, USA: ACM, 2010. (ASIACCS ’10), p. 1–14. ISBN
978-1-60558-936-7. Disponível em:
<http://doi.acm.org/10.1145/1755688.1755690>.
SCHNEIER, B. Applied cryptography: protocols, algorithms, and source
code in C. 2nd. ed. New York: Wiley, 1996. ISBN 0–471–12845–7.
SHMUELI RONEN VAISENBERG YUVAL ELOVICI, C. G. E. Database
encryption: an overview of contemporary challenges and design
considerations. ACM SIGMOD Record, v. 38, p. 29–34, 2010.
SILVERIO, A. L.; MELLO, R. dos S.; CUSTODIO, R. F. Efcient integrity
checking for untrusted database systems. In: Simpósio Brasileiro de Banco
59
de Dados - SBBD 2013. http://sbbd2013.cin.ufpe.br/sbbd/: [s.n.], 2013.

Disponível em:
<http://sbbd2013.cin.ufpe.br/Proceedings/artigos/pdfs/sbbdwtd0 6.pd f >.
STANESCU, B. Top 5: Corporate Losses Due to Hacking. 2012. Website.

Disponível em: <http://www.hotforsecurity.com/blog/top-5-corporate-
losses-due-to-hacking-1820.html>. Acesso em:
09/12/2013.
TIOBE. 2013. http://www.tiobe.com/index.php/content/
paperinfo/tpci/index.html. Acessado em: 2013-12-10.
XIE, M.; WANG, H.; YIN, J. Integrity auditing of outsourced data. Very
large data bases, p. 782–793, 2007. Disponível em:
<http://dl.acm.org/citation.cfm?id=1325940>.
60
61
ANEXOS
Trecho de código 1 – PKCS12SecuritySerice.xml

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" s t a n d a l o n e = " no " ? >
2 < !DOCTYPE p r o p e r t i e s SYSTEM " h t t p : / / j a v a . s u n . com / d t d /
p r o p e r t i e s . dtd ">
3
4 < !−− A r q u i v o de c o n f i g u r a o para o provider
P K C S 1 2 S e c u r i t y S e r v i c e −−>
5 <properties>
6
7 <comment> A r q u i v o de c o n f i g u r a o LibDBIntegrity
LabSEC − C l a s s e P K C S 1 2 S e c u r i t y S e r v i c e < / comment
>
8
9 < !−− N o e x i s t e nenhuma r e s t r i o q u a n t o ao
caminho p a r a o a r m a z e n a m e n t o d o s a r q u i v o s −−>
10
11 < !−− Caminho a b s o l u t o p a r a o a r q u i v o
X M L A p p l i c a t i o n K e y S t o r e −−>
12 < e n t r y key = "KEY_STORE_PATH" > / home / USUARIO / .
l s s e c u r i t y s e r v i c e / a p p K e y S t o r e . xml< / e n t r y >
13
14 < !−− A l i a s u t i l i z a d o p a r a a w r a p p i n g key do
X M L A p p l i c a t i o n K e y S t o r e . −−>
15 < !−− IMPORTANTE: o nome a l i a s d e v e s e r i g u a l na
w r a p p i n g k e y do X M L A p p l i c a t i o n K e y S t o r e e na
c h a v e do a r q u i v o PKCS12 −−>
16 < e n t r y key = "WRAPPING_KEY_ALIAS" > W r a p i n g K e y T e s t < /
entry>
17
18 < !−− Caminho a b s o l u t o p a r a o a r q u i v o PKCS#12 que
c o m t m a chave n e c e s s r i a para a b r i r o
19 < e n t r y key = " PKCS12_FILE_PATH " > / home / USUARIO / .
l s s e c u r i t y s e r v i c e / l i b i n t e g r i t y . p12< / e n t r y >
20
21 </ properties>
62

3
H S M S e c u r i t y S e r v i c e −−>
5 <properties>
6
LabSEC − C l a s s e H S M S e c u r i t y S e r v i c e < / comment>
8
9 < !−− N o e x i s t e nenhuma r e s t r i o q u a n t o ao
caminho p a r a o a r m a z e n a m e n t o d o s a r q u i v o s −−>
10
11 < !−− Caminho a b s o l u t o p a r a o a r q u i v o
12 < e n t r y key = "KEY_STORE_PATH" > / home / USUARIO / .
l s s e c u r i t y s e r v i c e / a p p K e y S t o r e . xml< / e n t r y >
13
14 < !−− A l i a s u t i l i z a d o p a r a a w r a p p i n g key do
X M L A p p l i c a t i o n K e y S t o r e . −−>
15 < !−− IMPORTANTE: o nome a l i a s d e v e s e r i g u a l na
w r a p p i n g k e y do X M L A p p l i c a t i o n K e y S t o r e e no
c e r t i f i c a d o do a r m a z e n a d o no HSM −−>
16 < e n t r y key = "WRAPPING_KEY_ALIAS" > a l i a s C e r t 0 1 < / e n t r y
>
17 </ properties>
63

3
S m a r t C a r d S e c u r i t y S e r v i c e −−>
5 <properties>
6
LabSEC − C l a s s e L S S e c u r i t y S e r v i c e < / comment>
8
9 < !−− IMPORTANTE: Os d o i s a l i a s n o podem s e r
iguais sen o haver c o n f l i t o e n t r e e l e s −−>
10
11 < !−− A l i a s da c h a v e s i m t r i c a u s a d a p e l a
aplica o −−>
12 < e n t r y key = "APP_SYMMETRIC_KEY_ALIAS" >
SymetricKey:KeyTestPrototipo</ entry>
13
14 < !−− A l i a s da c h a v e HMac u s a d a p e l a a p l i c a o −−
>
15 < e n t r y key = "APP_HMAC_KEY_ALIAS" >
HmacKey:KeyTestPrototipo< / e n t r y >
16
17 </ properties>
Figura 10 – PKCS#12 Manager

64
Figura 11 – KeyStoreManager
65
Figura 12 – Protótipo
66
Figura 13 – Diagrama de classes da biblioteca

Análise e implementação de um método para prover
integridade a sistemas de banco de dados
Gabriel Garcia Becker2 , Lucas Pandolfo Perin2 , Anderson Luiz Silvério2 ,
Marcelo Carlomagno Carlos1 , Ricardo Felipe Custódio2
1
Information Security Group
Royal Holloway University of London
TW20 0EX, Egham, United Kingdom
2
Laboratório de Segurança em Computação
Florianópolis – SC – Brazil
marcelo.carlos.2009@rhul.ac.uk,
{gabrielbecker, lucasperin, anderson.luiz, custodio}@inf.ufsc.br
Abstract. Unauthorized changes of database content can result in significant

losses for organizations and individuals and it is extremely important the assur-
ance of privacy and integrity of databases. The Database Management Systems
(DBMS) provides features to encrypt the database and protect it against unau-
thorized access. However, open-source DBMSs do not provide means to protect
the database against unauthorized modifications and advanced DBMSs that pro-
vides such features are too expensive. In this paper, we analyse and implement
a method to protect database systems against unauthorized modifications. Fur-
thermore we tested the analysed method, showing its efficiency.
Resumo. Modificações não autorizadas a sistemas de banco de dados podem

causar prejuízos para pessoas e organizações, sendo de extrema importância
a garantia de sigilo e integridade a tais sistemas. Geralmente as aplicações
utilizam os recursos disponibilizados por Sistemas Gerenciadores de Banco de
Dados (SGBDs) para assegurar o sigilo e a integridade dos dados armazena-
dos no SGBD. Entretanto, os SGBDs que provêm os recursos necessários para
garantir o sigilo e a integridade dos dados possuem um custo muito elevado,
muitas vezes inviável para organizações de médio e pequeno porte. Este tra-
balho analisa e implementa um método de verificação de integridade de dados,
baseado no uso de Hash-based Message Authentication Code (HMAC), inde-
pendente de SGBD. Os testes realizados mostram a eficiência do método. Em
média, a sobrecarga de processamento para o cálculo e verificação do HMAC
para um registro do banco de dados não ultrapassa 100% do tempo de execução
de determinada operação.
1. Introdução
O uso de sistemas de bancos de dados tornou-se recorrente para os mais diversos tipos de
aplicações. Com o uso extensivo da internet, as aplicações que utilizam sistemas de ban-
cos de dados online são cada vez mais comuns. Estas aplicações normalmente armazenam
dados sensíveis, como salários e outras informações pessoais [Kamel 2009]. Devido ao
conteúdo potencialmente sigiloso, o acesso ou a modificação não autorizada a tais dados
pode não ser desejado. Dessa forma, o sigilo e integridade de sistemas de banco de dados
tem atraído pesquisadores das áreas de banco de dados e segurança.
Os sistemas de banco de dados, quando utilizados em ambientes compartilhados,
possuem diversas ameaças de segurança provenientes de usuários não-autorizados, mau-
uso e ameaças externas. Baseando-se nestas características, pode-se classificar as ameaças
em quatro tipos principais:
1. leitura não autorizada de dados;

2. modificação não autorizada de dados;
3. remoção não autorizada de dados;
4. adição não autorizada de dados.
O problema da leitura não autorizada de dados (sigilo dos dados) já foi pesquisado
extensivamente e normalmente é resolvido através da cifração do banco de dados
[Ceselli et al. 2005, Samarati and di Vimercati 2010], em conjunto com métodos de in-
dexação [Ceselli et al. 2005, Damiani et al. 2003], para agilizar as consultas. Entretanto,
os problemas de modificações não autorizadas de dados (integridade dos dados) ainda ne-
cessitam de soluções eficientes [Samarati and di Vimercati 2010]. Os métodos existentes
para tal problema geralmente requerem o desenvolvimento de um novo Sistema geren-
ciador de banco de dados (SGBD) ou alterações significantes nos SGBDs já existentes
[Xie et al. 2007].
A seção 2 apresenta o método para tratar a integridade dos dados estudados neste
trabalho e os testes de desempenho realizados são apresentados na seção 3. A seção 4
apresenta a implementação do método e, por fim, na seção 5 são apresentadas as consid-
erações finais.
2. Integridade e sigilo de dados

Um dos problemas mais comuns quando se trata do sigilo em base de dados é a leitura
não autorizada de informações sensíveis presentes nas tabelas. A proteção contra este tipo
de acesso pode ser ser feita a nível de aplicação, o que é de fato realizada na maioria dos
casos. Para tal, sugere-se a cifração de dados em colunas das tabelas. Deve-se selecionar
colunas onde existem informações sigilosas nas tabelas e mante-las cifradas. A cifração
destes dados pode ser feita diretamente pela aplicação ou pelo SGBD.
Para não afetar muito o desempenho das consultas, é comum o uso de métodos de
indexação juntamente com a cifração dos dados [Ceselli et al. 2005, Damiani et al. 2003,
Hacigümüs et al. 2004].
Para evitar a modificação não autorizada de registros contidos na base de dados, a
aplicação deve restringir e definir as permissões de cada usuário. O SGDB também deve
conter um mapeamento correto de usuários e seus respectivos privilégios a fim de impedir
a execução de ações não autorizadas. Entretanto, existem perfis de usuários, como os
administradores do servidor, administrador de banco de dados (DBA) e programadores,
que podem acessar o SGDB sem o conhecimento da aplicação, podendo ocorrer situ-
ações onde, embora o usuário não seja autorizado a realizar determinada modificação, ele
tenha permissões suficientes no sistema que permitem que ele o faça, mesmo que não
intencionalmente. A cifração de colunas que contém dados sensíveis já reduz consid-
eravelmente este problema, uma vez que um usuário mal-intencionado não conseguirá
modificar o registro por não possuir a chave, e possivelmente sequer será capaz de iden-
tificar qual registro ele deve modificar para obter os efeitos que ele deseja. Embora as
chances do atacante sejam reduzidas, ainda há a possibilidade de realizar modificação de
registros a fim de corromper o sistema.
Infelizmente, os SGBDs mais comuns, como MySQL, PostreSQL, Firebird, etc,
não possuem mecanismos para evitar tais problemas. Outros sistemas mais específicos
possuem opções mais avançadas, porém também possuem custo bastante elevado. Para
prover tal funcionalidade, foi estudada uma proposta que faz uso de Hash-based Message
Authentication Code (HMAC) [Bellare et al. 1996, Turner and Chen 2011].
2.1. Adição do cálculo do HMAC nos registros da base de dados

Para se implementar este mecanismo, a aplicação será a única responsável pela manip-
ulação dos registros da base de dados, e, para prover tal garantia, a aplicação terá uma
chave simétrica conhecida somente por ela. Esta chave, por sua vez, será utilizada para
gerar o HMAC dos registros.
Através da utilização do HMAC, é possível detectar qualquer modificação não
autorizada realizada nos registros. Isto deve-se ao fato de que o atacante não tem conhec-
imento da chave necessária para gerar o HMAC, impossibilitando-o que consiga calcular
um valor de HMAC válido. Este mecanismo também soluciona a questão de adição de
registros pelo atacante, pois novamente, este necessitará da chave da aplicação para re-
alizar o cálculo do HMAC de forma correta.
Exemplo de implementação
Para exemplificar o funcionamento do método utilizando HMAC, considere uma tabela

de pessoas, com as colunas id, nome, email e a coluna para armazenar o valor do HMAC.
Os dados são apresentados na Tabela 1.
Tabela 1. Tabela de exemplo de dados.

id nome email hmac
1 Joao joao@foo.com.br abcd
2 Maria maria@foo.com.br qwer
3 Ana ana@foo.com.br kjhd
4 Roberto roberto@foo.com.br vpiu
Adicionando registros
Para adicionar um novo registro, a aplicação deve primeiramente calcular o valor do

HMAC para o novo registro. Esse cálculo é feito através da concatenação dos valores
de todas as colunas da tabela. Para adicionar uma nova pessoa com o nome “Jose” e
email “jose@foo.com.br”, o cálculo do HMAC é apresentado na expressão (1).
HM AC(chave, Josejose@f oo.com.br) = ohn4 (1)

Após o calculo do HMAC, a aplicação envia o comando de insert ao banco de
dados, conforme ilustrado no trecho de código 1.
Código Fonte 1. Código SQL para inserir um registro com HMAC

INSERT INTO exemplo ( nome , e m a i l , hmac )
VALUES ( ’ J o s e ’ ,
’ j o s e @ f o o . com . b r ’ ,
’ ohn4 ’ ) ;
Modificando registros
A modificação de um registro é semelhante à adição. Por exemplo, para a alteração do

registro número 3, da Tabela 1, primeiramente deve-se consultar o banco de dados para
obter o registro, conforme ilustrado no trecho de código 2. O próximo passo é calcular
o HMAC, apresentado na expressão (2). Por fim, atualiza-se o registro com o comando
update ilustrado no trecho de código 3.
Código Fonte 2. Código SQL para selecionar um registro

SELECT nome , e m a i l FROM exemplo WHERE i d = ’ 3 ’ ;
HM AC(chave, Anaana.new@f oo.com.br) = m3cx (2)
Código Fonte 3. Código SQL para atualizar um registro com HMAC

UPDATE exemplo SET e m a i l = ’ a n a . new@foo . com . b r ’ , hmac= ’ m3cx ’
WHERE i d = ’ 3 ’ ;
Verificando a integridade de registros
Por fim, para verificação da integridade de um registro, deve ser feita uma consulta ao
banco de dados pelo registro. Calcula-se o HMAC para o registro e compara o HMAC
calculado com o HMAC obtido do banco de dados. A igualdade desses valores indica que
o registro está íntegro.
2.2. Medidas de proteção contra remoção não autorizada

Através da utilização do HMAC, já é possível detectar qualquer modificação e adição não
autorizada de registros. Entretanto, não é possível detectar a remoção não autorizada de
registros.
Para o problema de remoção não autorizada de registros, sugere-se a criação de
uma nova coluna para as tabelas do banco de dados, chamada de “Histórico cifrado”. O
histórico cifrado possui as seguintes características:
• permite relacionar dois ou mais registros de forma que possa se detectar a ausência
de um deles, caso este seja removido;
• não permitir que uma terceira parte possa calcular o “histórico cifrado” sem con-
hecer as chaves de cifração;
• utilização de operações de baixo custo computacional: criptografia simétrica e a
operação lógica “ou exclusivo” (XOR);
• requer pouco espaço de armazenamento;
• não permite que sejam detectadas deleções dos n últimos registros.
Para calcular o histórico cifrado de um registro n, obtém-se o HMAC desse reg-
istro e do registro anterior a ele. Em seguida é aplicada a função XOR nestes HMACs e
o resultado é cifrado com uma chave simétrica. Esse cálculo é apresentado na expressão
(3).
HistoricoCif rado(chave, HM ACn , HM ACn−1 ) = Cif rao(k, (HM ACn ⊕ HM ACn−1 )) (3)
Removendo um registro
Para remover um registro n, deve-se excluir o registro e atualizar o histórico cifrado do

registro n + 1. Para atualizar o histórico cifrado, utiliza-se o HMAC do registro n + 1 e
n − 1.
Verificando se um registro foi removido
Para verificar se um registro tn , de uma tabela T foi removido, a seguinte propriedade

deve ser satisfeita:
∀tn , tn+1 ∈ T : tn .HistoricoCif rado = HistoricoCif rado(chave, tn , tn+1 ) (4)
Remoção do ultimo registro
Esta proposta possui uma vulnerabilidade, o método apresentado não detecta quando os
últimos registros são removidos indevidamente, uma vez que a verificação é feita com
base no registo anterior. Uma possível solução para o problema consiste em adicionar ao
final da tabela uma enupla com valores aleatórios conhecidos. Dessa forma, se o último
registro for removido, poderá ser identificado, uma vez que os valores de controle não
estarão mais presentes.
3. Análise da eficiência
Foi desenvolvido um protótipo utilizando a liguagem de programação PHP para verificar
a eficácia do método proposto. Os testes foram executados no ambiente descrito na Tabela
2
Foram executados testes simulando um ambiente de uso real de um software, com
o uso das operações Select, Insert, Updade e Delete. Executado também a verificação da
integridade do banco de dados, através do HMAC e do histórico cifrado.
Após a execução dos testes, verificou-se que para as operações básicas de um
banco de dados, o uso do HMAC não trouxe grandes alterações no desempenho. En-
tretanto o uso do Histórico Cifrado acarreta em uma grande sobrecarga na execução das
Tabela 2. Descrição do ambiente de simulação
Processador Intel Core 2 Duo 2.53Mhz
Memória RAM 4GB
Sistema Operacional Mac OS X 10.6.4
Linguagem PHP 5.3
. SGDB MySQL 5.1
Algoritmo de Hash SHA-1
Tamanho de Chave HMAC 128 bits
Algoritmo de cifração AES 128 bits
Tamanho de chave simétrica 128 bits
Figura 1. Tempo de execução em segundos.
operações. Nas operações de Delete e Select o impacto foi maior, pois é preciso atualizar
e consultar outros registros. Os resultados completos podem ser vistos na Figura 1.
Verificou-se também o custo para realizar o cálculo de HMAC e de Histórico
cifrado em tabelas já existentes. Para este cenário, foram realizados testes com diferentes
volumes de dados, entre mil e dez milhões de registros. Neste cenário é visível a diferença
no desempenho do cáclculo de HMAC e do Histórico cifrado, como mostrado na Figura
2. Entretanto, como em uma base de dados reais este cáclculo seria necessário apenas
uma vez, considera-se satisfatório o tempo de execução de ambas as soluções.
Por fim, foi simulado o custo de verificar a integridade de diversos registros.
Considera-se que este cenário em uma aplicação real seria executado em lote, em mo-
mentos em que o servidor de banco de dados está com uma sobrecarga menor. Assim
como no cenário anterior, o Histórico cifrado mostrou um desempenho muito inferior ao
do HMAC, conforme ilustrado na Figura 3.
Observa-se na Figura 3 que a operação de maior custo é do calculo do histórico
cifrado. Assim, o desenvolvedor deve analisar se o mecanismo de detecção de remoção é

relevante no escopo da aplicação.
Como os resultados obtidos nos testes foram satisfatórios, foi desenvolvido uma
biblioteca mais completa em java para prover os serviços de cálculo de HMAC e do
histórico cifrado. Para isso a biblioteca disponibiliza toda a estrutura necessária para
essas funções, como a geração de chaves HMAC e de chaves simétricas.
4. Implementação
Para o cálculo do HMAC há uma classe responsável pela geração das chaves (HMacK-
eyGenerator), uma pelo cálculo do HMAC (HMacCalculator), além das classes que rep-
resentam a chave para ser utilizada no cálculo do HMAC (HMACKey) e o HMAC em si
(HMAC). A partir de uma chave HMAC é possível inicializar o HMACCalculator. Nele,
é possível adicionar dados para o calculo do HMAC e finalizar a operação. O trecho de
código 4 demonstra como é feito o cálculo do HMAC de uma mensagem qualquer.
Código Fonte 4. Exemplo do cálculo do HMAC
HMacKey key = HMacKey : : g e n e r a t e ( "SHA1" ) ;
HMACCalculator hmacCalc = new HMACCalculator ( key ) ;
hmacCalc . u p d a t e ( " mensagem " ) ;
HMAC hmac = hmacCalc . d o F i n a l ( ) ;
Para o histórico cifrado, tem-se a classe responsável pelo cálculo (EncryptedHis-

toryCalculator) e a classe que representa o histórico cifrado (EncryptedHistory). Para
iniciar o cálculo do histórico, é necessário uma chave simétrica (SymmetricKey), que
pode ser gerada de forma semelhante à chave utilizada pelo HMAC, pela classe Symmet-
ricKeyGenerator. Para o cálculo do histórico, é necessário fornecer uma lista de HMACs
e uma chave simétrica, coforme ilustrado no trecho de código 5.

Código Fonte 5. Exemplo do cálculo do HMAC
p u b l i c E n c r y p t e d H i s t o r y g e n e r a t e ( L i s t <HMac> hMacs ) throws
SymmetricCipherException , EncryptionException {
L i s t <HMac> h = new A r r a y L i s t <HMac > ( ) ;
f o r ( HMac hMac : hMacs ) h . add ( hMac . c l o n e ( ) ) ;
byte [ ] xor = h . get ( 0 ) . getBytes ( ) ;
f o r ( i n t i = 1 ; i < h . s i z e ( ) ; i ++) {
b y t e [ ] hmac = h . g e t ( i ) . g e t B y t e s ( ) ;
f o r ( i n t j = 0 ; j < hmac . l e n g t h ; j ++)
x o r [ j ] = ( b y t e ) ( x o r [ j ] ^ hmac [ j ] ) ;
}
byte [ ] r e s u l t = c i p h e r . doFinal ( xor ) ;
r e t u r n new E n c r y p t e d H i s t o r y ( r e s u l t ) ;
}
A classe SecurityService possibilita efetuar diretamente o cálculo de HMAC,

Histórico Cifrado e cifração, sendo preciso apenas usar os métodos correspondentes di-
retamente, realizando toda a operação em apenas uma função, por exemplo, para realizar
o cálculo de um HMAC, devemos apenas chamar o método getHmac(fields:List<objs>)
passando a lista de objetos que sera utilizada no cálculo. As chaves simétricas e assimétri-
cas usadas são definidas pela clase SecurityServiceSpi. A classe SecurityServiceSpi deve
ser implementada por um provider, com a finalidade de suportar os mais diversos dis-
positivos criptográficos através de uma mesma interface. Desta forma, pode-se adicionar
diferentes dispositivos criptográficos simplesmente implementando uma interface, não
sendo necessários realizar grandes alterações na aplicação. O diagrama de classes da
Figura 4 apresenta esta abstração das classes SecurityService e SecurityServiceSpi.
Figura 4. Representação do provider da biblioteca
5. Considerações finais
Este trabalho apresenta a análise e a implementação de um método para verificar a inte-
gridade de sistemas de banco de dados.
Os trabalhos que tratam da integridade de dados em Bancos de dados relacionais
normalmente requerem o desenvolvimento de um novo SGBD ou alterações significativas
nos SGBDs já existentes. Entretanto, o método apresentado é independente de SGBD,
uma vez que todos os cálculos necessários são feitos pela aplicação.
Para verificar a eficácia do método foi implementado um protótipo em PHP. Foram
considerados diferentes cenários para os testes do método, que apresentaram resultados
satisfatórios. O primeiro cenário consistiu em testar a sobrecarga de operações SQL para
a alteração de registros únicos. Nestes testes constatou-se que a adição do cálculo do
HMAC é imperceptível na execução das operações INSERT, DELETE e UPDATE. No
segundo cenário foi considerado o custo para a verificação da integridade de diferentes
volumes de registros, enquanto que no terceiro cenário verificou-se o custo para a adição
das colunas de HMAC e histórico cifrado em bases de dados já existentes. Ambos os
testes executaram em um tempo satisfatório, considerando que são operações executadas
em lote.
Constada a eficácia do método, implementou-se uma biblioteca em Java. Esta
biblioteca fornece os serviços de cálculo de HMAC e histórico cifrado através de uma in-
terface simples, abstraindo todas as operações necessárias para os cálculos das operações.
Também foi criado uma interface que providers devem implementar para prover o suporte
para chaves em dispositivos criptográficos.
Referências
[Bellare et al. 1996] Bellare, M., Canetti, R., and Krawczyk, H. (1996). Keying hash func-
tions for message authentication. In Proceedings of the 16th Annual International
Cryptology Conference on Advances in Cryptology, CRYPTO ’96, pages 1–15, Lon-
don, UK, UK. Springer-Verlag.
[Ceselli et al. 2005] Ceselli, A., Damiani, E., De Capitani di Vimercati, S., Jajodia, S., Para-
boschi, S., and Samarati, P. (2005). Modeling and assessing inference exposure in en-
crypted databases. ACM Transactions on Information and System Security (TISSEC),
8(1).
[Damiani et al. 2003] Damiani, E., De Capitani di Vimercati, S., Jajodia, S., Paraboschi, S.,
and Samarati, P. (2003). Balancing confidentiality and efficiency in untrusted relational
DBMSs. In Proc. of the 10th ACM Conference on Computer and Communications
Security, Washington, DC, USA.
[Hacigümüs et al. 2004] Hacigümüs, H., Iyer, B. R., and Mehrotra, S. (2004). Efficient
execution of aggregation queries over encrypted relational databases. In DASFAA,
pages 125–136.
[Kamel 2009] Kamel, I. (2009). A schema for protecting the integrity of databases. Com-
puters & Security, 28(7):698–709.
[Samarati and di Vimercati 2010] Samarati, P. and di Vimercati, S. D. C. (2010). Data pro-
tection in outsourcing scenarios: issues and directions. In Proceedings of the 5th ACM
Symposium on Information, Computer and Communications Security, ASIACCS ’10,
pages 1–14, New York, NY, USA. ACM.
[Turner and Chen 2011] Turner, S. and Chen, L. (2011). Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms. RFC 6151 (Informa-
tional).
[Xie et al. 2007] Xie, M., Wang, H., and Yin, J. (2007). Integrity auditing of outsourced
data. Very large data bases, pages 782–793.

TCC Teste Teste

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Teste Teste

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DE SANTA CATARINA

SEGURANÇA EM BANCO DE DADOS

Gabriel Garcia Becker, Lucas Pandolfo Perin

SEGURANÇA EM BANCO DE DADOS

Gabriel Garcia Becker, Lucas Pandolfo Perin

Trabalho de conclusão de curso apresen-

SEGURANÇA EM BANCO DE DADOS

Trabalho de conclusão de curso apresentada como parte dos requisitos

Orientador: Msc. Marcelo Carlomagno Carlos

Felipe Calos Werlang

Agradecemos em primeiro lugar aos nosso pais, por colocarem nossa

Frequentemente os Sistemas de Gerenciamento de Banco de Dados (SGBDs)

Unauthorized changes of database content can result in significant losses for

Figura 1 Exemplo de criptografia simétrica . . . . . . . . . . . . . . . . . . . . . . . . . 28

Tabela 1 Tabela de exemplo de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

O uso de Bando de Dados (BD) tornou-se recorrente para os mais

• leitura não autorizada de dados;

• modificação não autorizada de dados;

• remoção não autorizada de dados;

• adição não autorizada de dados.

1.1.1 Objetivo Geral

Este tabalho tem como objetivo geral demonstrar, através do uso de

de ataques maliciosos e de modificações não autorizadas. Adicionalmente,

1.1.2 Objetivos Específicos

• Elaborar uma biblioteca em Java com a finalidade de prover suporte

Acontecimentos recentes podem ser tomados como exemplo para o

Para a realização deste trabalho foram estudados métodos de autenti-

Este trabalho possibilitou a publicação de um artigo wotkshop de Tra-

1.5 ESTRUTURA DO TRABALHO

Nos seguintes capítulos serão introduzidos os conceitos abordados

Criptografia é o estudo e a arte de transformar informação de forma

A palavra criptografia significa escondido ou escrita secreta. Criptografia é co-

Existem diversos algoritmos criptográficos para cifragem e decifra-

2.1.1 Criptografia Simétrica

Na cripotografia simétrica, usa-se apenas uma chave secreta entre

Figura 1 – Exemplo de criptografia simétrica

2.1.2 Criptografia Assimétrica

Enquanto o uso de chaves simétricas pode ser bastante conveniênte,

Figura 2 – Exemplo de criptografia assimétrica

Existem diversos usos para criptografia de chaves públicas. Entre eles,

2.1.3 Resumo Criptográfico

As funções de resumo criptográfico, também chamadas de funções

• É computacionalmente impraticavel recriar a mensagem original a par-

2.1.4 Código de Autenticação de Mensagem

Um autenticador de mensagem, também conhecido como Message

PKCS#12 é um formato de arquivo para armazenar diversos objetos

2.2 SEGURANÇA EM BANCOS DE DADOS

O termo Segurança de Bancos de Dados pode ser bastante vago, abran-

Sigilo refere-se àquilo que é segredo, não público. Informação sigi-

2.2.2 Integridade e Autenticidade

Os conceitos integridade e autenticidade podem ser definidos da se-

Autenticidade pode ser correlacionada com o conhecimento da identidade

Integridade é a certeza de que uma informação em análise não sofreu alte-

A proposta deste trabalho consiste na aplicação do HMAC nos dados

Entende-se por rastreabilidade como o conhecimento da localidade de

2.3 TECNOLOGIAS UTILIZADAS

A Extensible Markup Language (XML) é uma forma de texto sim-

Java é uma linguagem de programação extremamente popular e inde-

A biblioteca LibCryptoDev, desenvolvida pelo LabSEC, é uma bibli-

Para evitar a modificação não autorizada de registros contidos na base

3.1 ADIÇÃO DO CÁLCULO DO HMAC NOS REGISTROS DA BASE DE

Para se implementar este mecanismo, a aplicação será a única res-

HMAC(k, m) = HMAC(k, Nome||email) (3.1)