Anais - Engenharia de Redes de Comunicação - UnB

redes.unb.br

Anais - Engenharia de Redes de Comunicação - UnB

ANAIS


Organização do SBSeg 2011

Coordenadores Gerais

Anderson Clayton Alves Nascimento, UnB

Rafael Timóteo de Sousa Júnior, UnB

Comitê de Organização Local

Anderson Clayton Alves Nascimento, UnB

Aletéia Patrícia Favacho de Araújo, UnB

Dino Macedo Amaral,UnB

Edna Dias Canedo, UnB

Flávio Elias Gomes de Deus, UnB

Maristela Terto de Holanda, UnB

Laerte Peotta de Melo, UnB

Priscila América Solis M. Barreto, UnB

Rafael Timóteo de Sousa Júnior, UnB

Ricardo Staciarini Puttini, UnB

Coordenadores do Comitê de Programa

Jeroen van de Graaf, UFMG

Luiz Fernando Rust da Costa Carmo, UFRJ

Coordenadores de Minicursos

Célia Ghedini Ralha, UnB

Antonio Cândido Faleiros, UFABC

Coordenadora do WTICG

Michelle Nogueira, UFPR

Coordenadores do WGID

Michelle S. Wangham, UNIVALI

Prof. Joni da Silva Fraga, UFSC

Coordenador do Fórum de Segurança Corporativa

Rafael Timóteo de Sousa Júnior, UnB

2


Mensagem da Coordenação Geral

O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais (SBSeg)

é um evento científico promovido anualmente pela Sociedade Brasileira de Computação (SBC). A

partir de 2005, concomitantemente à criação da Comissão Especial em Segurança da Informação

e de Sistemas Computacionais, o SBSeg deixou de ser organizado como um workshop e passou

a ser um simpósio completo. Isso permitiu que, imediatamente, passasse a atender às demandas

crescentes da comunidade brasileira de pesquisadores e profissionais atuantes na área e assumisse a

posição de principal fórum no País para a apresentação de pesquisas e atividades relevantes ligadas

à segurança da informação e de sistemas.

Desde que se estabeleceu como simpósio em 2005, o evento foi organizado, com grande

sucesso, nas cidades de Florianópolis, Santos, Rio de Janeiro, Gramado, Campinas e Fortaleza.

A 11ª. edição do simpósio ocorre entre 6 e 11 de novembro de 2011 em Brasília, DF, organizada

pelo grupo de Engenharia de Redes do Departamento de Engenharia Elétrica e pelo Departamento

de Ciência da Computação, ambos da Universidade de Brasília. O simpósio conta com uma rica

variedade de atividades, a saber: 7 sessões técnicas de artigos completos e resumos estendidos,

6 minicursos, 4 palestras proferidas por especialistas estrangeiros, Painel de Segurança e Defesa

Cibernética, Fórum de Segurança Corporativa e Workshop de Trabalhos de Iniciação Científica e de

Graduação e o 1º. Workshop de Gestão de Identidades.

Um aspecto fundamental do SBSeg é o comprometimento com a qualidade. Tem operado

seguindo, rigorosamente, indicadores visando ao atendimento do padrão Qualis A, conforme critérios

da CAPES. Entre esses critérios, destacamos a taxa de aceitação de artigos completos inferior de

33% e a composição de Comitês de Programa por pesquisadores brasileiros e estrangeiros com

grande renome e inserção na área.

Para a realização do SBSeg 2011, o envolvimento e a colaboração de várias pessoas e

entidades foram imprescindíveis. Em especial, gostaríamos de agradecer aos membros do comitê

de organização geral e local que, por conta de seu trabalho voluntário e incansável, ajudaram a

proporcionar à comunidade de segurança um evento que julgamos de ótimo nível técnico. Gostaríamos

de agradecer, também, à SBC, pelo apoio prestado ao longo das muitas etapas da organização, e

aos patrocinadores, pelo incentivo à divulgação de atividades de pesquisa conduzidas no País e

pela confiança depositada neste Simpósio. Por fim, nossos agradecimentos aos alunos, técnicos e

professores do Laboratório de Engenharia de Redes (LabRedes), Laboratório de Tecnologias da

Tomada de Decisão (Latitude), Grupo de Pesquisa Crypto&InformationTheory e Programa de Pós-

Graduação em Engenharia Elétrica (PPGEE), da UnB, por viabilizarem a realização de um evento

do porte do SBSeg.

Nesta semana de 6 a 11 de novembro estão reunidos em Brasília estudantes, professores,

pesquisadores, governo e profissionais da indústria, todos com o objetivo de trocar ideias,

compartilhar experiências e estabelecer laços pessoais. Brasília é, portanto, o centro da discussão

sobre avanços realizados e desafios a serem superados na área de segurança da informação e de

sistemas. Sejam bem-vindos ao Planalto Central e desfrutem de uma semana agradável e proveitosa!

Anderson Clayton Alves Nascimento, UnB

Rafael Timóteo de Sousa Júnior, UnB

Coordenadores Gerais do SBSeg 2011

3


Mensagem dos Coordenadores do Comitê de Programa

O Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

(SBSeg) é um evento já consolidado como um dos importantes eventos científicos no país.

O E, na Simpósio sua décima Brasileiro primeira em edição, Segurança continua da a mostrar Informação a sua e importância. de Sistemas Foram Computacionais 81 registros

(SBSeg) para submissão é um evento de artigos, já consolidado dos quais como sessenta um dos e um importantes (61) foram eventos integralmente científicos realizados, no país.

E, abrangendo na sua décima os diversos primeira tópicos edição, definidos continua para a mostrar o evento. a sua Desse importância. conjunto foram Foram selecionados 81 registros

para dezenove submissão (19) artigos de artigos, completos dos quais e um (1) sessenta na forma e um de (61) artigo foram curto. integralmente realizados,

abrangendo os diversos tópicos definidos para o evento. Desse conjunto foram selecionados

dezenove Com estes (19) números artigos estamos completos compondo e um (1) na um forma programa de artigo bastante curto. diversificado, com sete

sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa

Com realizada estes no números país na área estamos de Segurança. compondo um programa bastante diversificado, com sete

sessões técnicas, que expressa através dos trabalhos selecionados a qualidade da pesquisa

realizada O Simpósio no país Brasileiro na área em de Segurança. da Informação e de Sistemas Computacionais vem

nos últimos anos se caracterizando por um processo de seleção de artigos bastante

O criterioso, Simpósio envolvendo Brasileiro várias em Segurança etapas. Neste da Informação trabalho árduo e de participa Sistemas uma Computacionais parte considerável vem

nos da comunidade últimos anos científica se caracterizando brasileira de Segurança. por um processo E neste de momento seleção é bom de artigos que se divida bastante o

criterioso, reconhecimento envolvendo e os elogios várias com etapas. todas Neste estas trabalho pessoas árduo que participaram uma deste parte processo considerável que

da resultou comunidade no programa científica do SBSeg brasileira 2011. de Segurança. E neste momento é bom que se divida o

reconhecimento e os elogios com todas estas pessoas que participaram deste processo que

resultou Em primeiro no programa lugar, é importante do SBSeg 2011. o agradecimento aos 239 autores, na sua maioria formada

por brasileiros (236), que reconhecem a importância do SBSeg e que a cada nova edição

Em ajudam primeiro a manter lugar, os é números importante de submissões o agradecimento em níveis aos 239 expressivos. autores, na É a sua continuidade maioria formada destes

por números brasileiros de submissões (236), que e de reconhecem autores envolvidos a importância que definitivamente do SBSeg e que consolidou a cada nova o simpósio. edição

ajudam a manter os números de submissões em níveis expressivos. É a continuidade destes

números É importante de submissões também o e agradecimento autores envolvidos e o reconhecimento que definitivamente a todos os consolidou colegas membros o simpósio. do

Comitê de Programa que este ano contou com 42 especialistas nos temas do simpósio.

É Destes, importante 3 são também convidados o agradecimento instituições e o reconhecimento estrangeiras, e os a todos demais os colegas atuam no membros Brasil. do O

Comitê trabalho destes Programa colegas, que completamente este ano contou voluntário, com 42 foi especialistas muito importante nos temas nesta do edição. simpósio. Este

Destes, trabalho 3 que são não convidados se encerra de com instituições o processo estrangeiras, de seleção, continua e os demais ainda atuam com a no coordenação Brasil. O

trabalho das sessões destes técnicas. colegas, completamente voluntário, foi muito importante nesta edição. Este

trabalho que não se encerra com o processo de seleção, continua ainda com a coordenação

das No processo sessões técnicas. de seleção, tivemos a participação de 91 revisores e nisto se inclui também os

membros do comitê de programa, gerando um total de 201 revisões. Foram pelo menos três

No revisões processo para de cada seleção, artigo tivemos submetido. a participação Agradecemos 91 todo revisores o empenho e nisto destes se inclui revisores também para os a

membros confecção do de comitê diagnósticos de programa, técnicos gerando e precisos, um total e para de a 201 imprescindível revisões. Foram contemporização pelo menos três na

revisões hora da solução para cada de artigo conflitos. submetido. Agradecemos todo o empenho destes revisores para a

confecção de diagnósticos técnicos e precisos, e para a imprescindível contemporização na

hora da solução de conflitos.

Gostaríamos também de agradecer à Coordenação Geral do SBSeg 2011 pelo convite honroso

e a confiança que nos depositou ao nos fazer coordenadores do Comitê de Programa

Gostaríamos do SBSeg 2011. também Os demais agradecer participantes à Coordenação da Organização Geral do do SBSeg simpósio 2011 pelo foram convite também honroso

incansáveis e a confiança na tarefa que nos de fornecer depositou os ao meios nos fazer necessários coordenadores para que do o Comitê de de Programa

do atingisse SBSeg todos 2011. os Os seus demais objetivos. participantes da Organização do simpósio foram também

incansáveis na tarefa de fornecer os meios necessários para que o Comitê de Programa

Finalmente, queremos desejar aos participantes que são a razão maior do nosso evento, que

atingisse todos os seus objetivos.

tenham um excelente SBSeg!!

Jeroen van de Graaf (DCC/UFMG)

Luiz Fernando Rust da Costa Carmo (INMETRO)

Coordenadores do Comitê de Programa do SBSeg 2011

4


Mensagem da Coordenadora do WTICG

Mensagem do Coordenador do WTICG/SBSeg 2011

O Workshop de Trabalhos de Iniciação Científica e de Graduação (WTICG) do

Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais

(SBSeg) visa incentivar a participação de recém-­‐graduados e de alunos de graduação

na produção e divulgação de trabalhos científicos, fortalecendo a comunicação e a

troca de conhecimentos sobre pesquisas já concluídas e em andamento. Nesta

quinta edição, o WTICG contou com 18 artigos submetidos. Dentre estes, há artigos

das mais diversas unidades federativas do Brasil, apontando a crescente

atratividade e visibilidade do evento.

O Comitê de Programa desta edição do WTICG foi constituído por 12 pesquisadores.

Esse comitê contou ainda com o apoio de 8 avaliadores externos, sendo 3 destes

avaliadores anônimos, formando uma equipe de 20 profissionais para a condução

do processo de avaliação dos artigos. Cada artigo recebeu pelo menos 3 avaliações

independentes e, ao final do processo de avaliação dos artigos submetidos, tivemos

ao todo 56 revisões. Dentre os 18 artigos submetidos, 10 artigos foram selecionados

para a publicação e apresentação oral no evento. Ressalto que todos os artigos

selecionados atenderam à restrição dos autores serem estudantes de graduação

regularmente matriculados, ou ainda, recém-­‐graduados que tenham concluído a

graduação após 30 de junho de 2010.

A programação do WTICG está divida em 3 sessões técnicas que cobrem temas

variados nas áreas de segurança da informação e segurança de sistemas

computacionais. A primeira sessão trata especificamente de problemas relacionados

ao Gerenciamento de Chaves e de Certificados. A segunda sessão contém artigos que

investigam problemas relacionados à Segurança em Redes e Sistemas. Finalmente, a

terceira sessão é dedicada a artigos sobre Gerência de Identidade e Anonimato.

Gostaria de agradecer aos membros do comitê de programa e aos revisores por

terem aceitado participar voluntariamente dos processos de divulgação e avaliação

neste evento. Agradeço-­‐os também pela competência e dedicação na realização do

processo de avaliação dos artigos. Gostaria de expressar também os meus

agradecimentos aos coordenadores gerais do SBSeg 2011 pela oportunidade e

confiança ao me atribuírem essa função. Finalmente, gostaria de agradecer aos

autores que submeteram os seus trabalhos e que anualmente fortalecem o interesse,

visibilidade e sucesso crescentes do WTICG.

Saúdo a todos os participantes do V Workshop de Trabalhos de Iniciação Científica e

de Graduação com os votos de um excelente workshop e de uma excelente estadia

em Brasília!

Michele Nogueira

5


Mensagem dos Coordenadores do WGID

O Workshop de Gestão de Identidades (WGID), evento integrante do SBSeg,

visa ser um fórum para discussões e apresentações técnicas de trabalhos recentes e/ou em

andamento em torno do estado da arte de tecnologias relacionadas com gestão de identidades.

Além disso, busca-se também identificar os desafios de pesquisa na área e possibilitar o

mapeamento dos grupos de pesquisa.

Pesquisadores foram convidados a submeter trabalhos originais relacionados à Gestão

de Identidades, sendo que quatro trabalhos foram selecionados e serão apresentados na sessão

técnica. Gostaríamos de agradecer todo o empenho dos membros do comitê de programa

pela alta qualidade do trabalho realizado nas revisões. Registramos um agradecimento

especial a todos os autores que prestigiaram o I WGID ao submeterem trabalhos relatando

suas pesquisas.

O programa do Workshop contemplará ainda duas palestras do pesquisador David

Chadwick (University of Kent), uma palestra do Sr. Ruy Ramos, representante do ITI

(Instituto Nacional de Tecnologia da Informação), uma palestra do Sr. Paulo Ayran, represente

do Comitê Gestor do RIC (Registro de Identidade Civil), uma palestra da equipe de serviços

da RNP (Rede Nacional de Ensino e Pesquisa), uma palestra sobre o projeto EduRoam.br

e um painel com pesquisadores brasileiros que discutirá os desafios de segurança na gestão

de identidades.

Gostaríamos também de agradecer a todos que colaboraram na organização do

WGID, especialmente, ao André Marins (RNP) e aos professores Noemi Rodriguez e

Ricardo Custódio (coordenadores do Comitê Técnico de Gestão de Identidades da RNP).

Agradecemos ainda o apoio financeiro da Rede Nacional de Ensino e Pesquisa (RNP) e o

apoio da Comissão Especial em Segurança da Informação e de Sistemas Computacionais da

SBC e da Coordenação Geral do SBSeg 2011 e de toda a sua equipe do comitê local.

Em nome do Comitê de Programa, saudamos a todos os participantes do WGID 2011,

com votos de um evento bastante profícuo.

Prof. Joni da Silva Fraga, UFSC

Profa. Michelle S. Wangham, UNIVALI

Coordenadores do Comitê de Programa do WGID 2011

6


Comitê de Programa e Revisores do SBSeg

Aldri dos Santos - UFPR

Alexandre Alexandre - FEEC

Altair Santin - PUCPR

Anderson Nascimento -UNB

André dos Santos - UECE

André Grégio - CTI

Antonio Maio - Kryptus

Arlindo L. Marcon Jr. - PUCPR

Arun Lakhotia - University of Louisiana USA

Bruno Augusti Mozzaquatro - UFSM

Carla Merkle Westphall - UFSC

Carlos Maziero - UTFPR

Carlos Westphall - UFSC

Célio Vinicius Neves de Albuquerque - UFF

Charles Prado - INMETRO

Cinthia Freitas - PUCPR

Claudio Miceli de Farias - UFRJ

Cleber Kiel Olivo - PUCPR

Cleber Souza - UNICAMP

Craig Miles - University of Louisiana USA

Daniel Fernandes Macedo - UFMG

Dario Fernandes - UNICAMP

Davi Böger - UFSC

Davidson Boccardo - INMETRO

Dener Didoné - UFPE

Diogo Mattos - UFRJ

Djamel H. Sadok -UFPE

Dorgival Guedes - UFMG

Elisa Mannes - UFPR

Emerson Ribeiro de Mello - IF-SC

Fernando Gielow - UFPR

Fernando Teixeira - UFMG

Flavia Delicato - UFRJ

Gabriel Cavalcante - UNICAMP

George Cavalcanti - UFPE

Gliner Alencar - UFPE

Hao Chi Wong - Intel USA

Henrique Arcoverde - UFPE

Hugo Carvalho - UFRJ

Jacques Facon - PUCPR

Jean Martina - University of Cambridge GB

Jeroen van de Graaf - UFMG

Joaquim Celestino Júnior - UECE

José De Souza - UFC

Joni da Silva Fraga - UFSC

Julio Hernandez - UNICAMP

Lau Cheuk Lung - UFSC

Leonardo Fagundes - Unisinos

Leonardo Oliveira - UNICAMP

Leonardo Ribeiro - INMETRO

Lisandro Zambenedetti Granville - UFRGS

Luci Pirmez - UFRJ

Luciano Paschoal Gaspary - UFRGS

Luiz Fernando Rust da Costa Carmo - UFRJ

Luiz Carlos Albini - UFPR

Lyno Ferraz - UFRJ

Maicon Stihler - PUCPR

Marinho Barcellos - UFRGS

Mauro Fonseca - PUCPR

Michel Abdalla - École Normale Supérieure FR

Michele Nogueira - UFPR

Michelle Wangham - Univali

Natalia Castro Fernandes - UFRJ

Otto Carlos Muniz Bandeira Duarte UFRJ

Paulo Barreto - USP

Paulo Mafra - UFSC

Paulo Padovan - UFPE

Paulo André da Silva Gonçalves - UFPE

Pedro Pisa - UFRJ

Pedro Velloso - UFF

Rafael Obelheiro - UDESC

Raphael Machado - INMETRO

Raul Ceretta Nunes - UFSM

Raul Weber - UFRGS

Reinaldo Braga - UFC

Ricardo Custódio - UFSC

Ricardo Dahab - UNICAMP

Ricardo Tombesi Macedo - UFSM

Roben Lunardi - UFRGS

Roberto Gallo - Kryptus

Robson Gomes de Melo - UFPR

Rossana Andrade - UFC

Routo Terada - USP

Silvana Rossetto - UFRJ

Thiago Rosa - PUCPR

Tiago Nascimento - UFRJ

Vinícius Thiago - Exército Brasileiro

Vinicius Moll - UFSC

Vitor Afonso - UNICAMP

Weverton Luis da Costa Cordeiro - UFRGS

Wilton Speziali Caldas - Empresa1

7


Comitê de Programa e Revisores do WTICG

Coordenação Geral do SBSeg2011

Anderson Nascimento, UnB

Coordenação do Workshop

Michelle S. Wangham, UNIVALI

Ricardo Custódio, UFSC

Noemi Rodriguez, PUC-RIO

André Marins, RNP

Coordenação do Comitê de Programa

Joni Fraga, UFSC

Michelle Wangham, UNIVALI

Comitê de Programa

Aldri dos Santos, UFPR

Altair Santin, PUC-PR

Débora Muchaluat, UFF

Eleri Cardozo, UNICAMP

Emerson Ribeiro de Mello, IFSC

Jeroen van der Graaf, UFMG

Joni Fraga, UFSC

Marinho Barcellos, UFRGS

Michelle Wangham, UNIVALI

Michele Nogueira, UFPR

Noemi Rodriguez, PUC-Rio

Ricardo Custódio, UFSC

Roberto Samarone, UFPA

Vinod Rebello, UFF

8


Comitê de Programa e Revisores do WGID

Coordenação Geral do SBSeg2011

Anderson Nascimento, UnB

Coordenação do Workshop

Michelle S. Wangham, UNIVALI

Ricardo Custódio, UFSC

Noemi Rodriguez, PUC-RIO

André Marins, RNP

Coordenação do Comitê de Programa

Joni Fraga, UFSC

Michelle Wangham, UNIVALI

Comitê de Programa

Aldri dos Santos, UFPR

Altair Santin, PUC-PR

Débora Muchaluat, UFF

Eleri Cardozo, UNICAMP

Emerson Ribeiro de Mello, IFSC

Jeroen van der Graaf, UFMG

Joni Fraga, UFSC

Marinho Barcellos, UFRGS

Michelle Wangham, UNIVALI

Michele Nogueira, UFPR

Noemi Rodriguez, PUC-Rio

Ricardo Custódio, UFSC

Roberto Samarone, UFPA

Vinod Rebello, UFF

Revisores

Aldri dos Santos, UFPR

Altair Santin, PUC-PR

Débora Muchaluat, UFF

Eleri Cardozo, UNICAMP

Emerson Ribeiro de Mello, IFSC

Jeroen van der Graaf, UFMG

Joni Fraga, UFSC

Maicon Stihler, PUCPR

Marinho Barcellos, UFRGS

Michelle Wangham, UNIVALI

Michele Nogueira, UFPR

9


Sumário dos Anais dos Artigos SBSeg 2011

Um Mecanismo de Proteção de Quadros de Controle para Redes IEEE

802.11

Tratamento Automatizado de Incidentes de Segurança da Informação em

Redes de Campus

15

29

Uma Ontologia para Mitigar XML Injection 43

Carimbos do Tempo Autenticados para a Preservação por Longo Prazo de

Assinaturas Digitais

57

SCuP - Secure Cryptographic Microprocessor 71

Fault Attacks against a Cellular Automata Based Stream Cipher 85

Zero-knowledge Identification based on Lattices with Low Communication

Costs

95

A Framework for Fully Simulatable Oblivious Transfer 108

Syndrome-Fortuna: A viable approach on Linux random number generation 122

SpSb: um ambiente seguro para o estudo de spambots 135

Fatores que afetam o comportamento de spammers na rede 141

Segmentação de Overlays P2P como Suporte para Memórias Tolerantes a

Intrusões

Caracterização e Modelagem da Disseminação de Conteúdo Ilícito em

Sistemas Par-a-Par de Compartilhamento de Arquivos

155

169

Método Heurístico para Rotular Grupos em Sistema de Detecção de

Intrusão baseado em Anomalia

183

10


Detecção de Intrusos usando Conjunto de k-NN gerado por Subespaços

Aleatórios

Combinando Algoritmos de Classificação para Detecção de Intrusão em

Redes de Computadores

197

211

Static Detection of Address Leaks 225

Um esquema bio-inspirado para tolerância à má-conduta em sistemas de

quórum para MANETs

239

Aumentando a segurança do MD6 em relação aos ataques diferenciais 253

Acordo de Chave Seguro contra Autoridade Mal Intencionada 265

11


Sumário dos Anais WTICG

Especificação de Propriedades Temporais do Protocolo de Chaves Públicas

Needham Schroeder

280

Troca de Chaves Criptográficas com Redes Neurais Artificiais 290

Análise e implementação de um protocolo de gerenciamento de certificados 300

Mobile Steganography Embedder 310

Avaliação do Impacto do Uso de Assinaturas Digitais em uma Aplicação

Distribuída que Utiliza Redes Veiculares

Uma Avaliação de Segurança no Gerenciamento de Mobilidade nas Redes

em Malha sem Fio

320

329

Análise Visual de Comportamento de Código Malicioso 339

Uma Maneira Simples de Obter Regiões de Interesse em Imagens de

Impressões Digitais

349

Uma aplicação de privacidade no gerenciamento de identidades em nuvem

com uApprove

A New Scheme for Anonymous Communication in Wireless Mesh

Networks

359

369

12


Sumário dos Anais WGID

Avaliação de um Sistema de Gestão de Identidade e Acesso em uma

Organização Pública Federal

378

Uma Plataforma para Gerenciamento de Identidades de Software como

Serviço em uma Infraestrutura como Serviço

388

Electronic Documents with Signature Constraints 397

Using Notary Based Public Key Infrastructure in Shibboleth 405

13


ANAIS

14


Um Mecanismo de Proteção de Quadros de Controle

para Redes IEEE 802.11

Marcos A. C. Corrêa Júnior, Paulo André da S. Gonçalves

Centro de Informática (CIn)

Universidade Federal de Pernambuco (UFPE)

50.740-560 – Recife – PE – Brasil

{maccj, pasg}@cin.ufpe.br

Abstract. Only control frames of all the frame types defined by IEEE 802.11

stardard are not yet protected by any kind of security mechanism. This makes it

easier for malicious entities to exploit them in order to carry out deny-of-service

attacks on the network. Techniques to forge or tamper control frames as well as

techniques to reinject them into the network are typically used under such attacks.

This paper proposes a mechanism for protecting IEEE 802.11 control

frames against such attacks. The proposed mechanism protects all the control

frames by using sequence numbers and Message Authentication Codes. Compared

to similar studies that aim to protect all the control frames, the proposed

mechanism has reduced overhead and provides increased security.

Resumo. De todos os quadros definidos pelo padrão IEEE 802.11, apenas

os quadros de controle ainda não possuem qualquer tipo de mecanismo de

segurança. Isso permite que entidades maliciosas, mesmo não pertencentes à

rede, se utilizem de técnicas de forjamento, manipulação e reinjeção desses quadros

a fim de gerar algum tipo de negação de serviço na rede. Este artigo propõe

um mecanismo de segurança para os quadros de controle do IEEE 802.11. O

mecanismo proposto se vale do uso de números de sequência e da geração de

Códigos de Autenticação de Mensagem a fim de evitar que estações maliciosas,

não pertencentes à rede, tenham sucesso ao forjar, manipular ou reinjetar quadros

de controle que levariam à negação de serviços. Além de proteger todos

os quadros de controle indistintamente, o mecanismo proposto possui um maior

grau de segurança e introduz, nesses quadros, um overhead significativamente

menor em comparação aos trabalhos relacionados que também se propõem a

proteger todos os quadros de controle.

1. Introdução

As redes locais sem fio que seguem o padrão IEEE 802.11 [IEEE Standard 802.11 2007]

vêm sendo amplamente adotadas em residências, empresas e locais públicos como shoppings,

aeroportos e restaurantes. Os mecanismos de segurança que atuam na camada

enlace dessas redes têm evoluído frequentemente devido à descoberta recorrente de vulnerabilidades

[Tews 2007]. Em geral, essas vulnerabilidades são exploradas através do

uso malicioso dos diferentes tipos de quadros que trafegam na rede. O padrão IEEE

802.11 define três tipos de quadros: quadros de dados, quadros de gerenciamento e quadros

de controle. Os quadros de dados são utilizados para transportar dados e algumas

15


informações de controle em seu cabeçalho. Os quadros de gerenciamento são usados,

entre outras coisas, para sinalizar a presença de uma rede sem fio, iniciar e encerrar a

associação de estações com o Ponto de Acesso ou AP (Access Point). Os quadros de controle,

por sua vez, são usados principalmente para a reserva do canal de comunicação e

para a confirmação do recebimento de alguns tipos de quadros.

Em relação à proteção dos quadros de dados, os seguintes protocolos de segurança

foram definidos ao longo dos anos: o WEP (Wired Equivalent Privacy) [IEEE Standard

802.11 1999], o WPA (Wi-Fi Protected Access) [Wi-Fi Alliance 2003] e o WPA2 [IEEE

Standard 802.11i 2004]. Dentre os protocolos citados, o WEP é considerado ultrapassado

dada a sua longa lista de vulnerabilidades [Tews 2007]. Já a proteção aos quadros de

gerenciamento é especificada na emenda IEEE 802.11w [IEEE Standard 802.11w 2009],

a qual complementa as especificações do WPA e do WPA2. Essa ementa foi ratificada

somente uma década após o surgimento do padrão IEEE 802.11, o que permitiu uma

ampla janela de tempo para o desenvolvimento de vários ataques efetivos aos quadros

de gerenciamento. Exemplos incluem o pedido falsificado de desassociação de clientes

legítimos da rede e a captura de informações sensíveis sendo transportadas nesses quadros

(e.g. dados sobre recursos de rádio, identificadores baseados em localização e dados para

execução de handoffs rápidos) [IEEE Standard 802.11k 2008] [IEEE Standard 802.11r

2008] [IEEE Standard 802.11v 2011].

A emenda IEEE 802.11w associada ao WPA2 resolve grande parte das vulnerabilidades

conhecidas nas redes IEEE 802.11. Contudo, ainda não existe um padrão

IEEE que se proponha a proteger os quadros de controle dessas redes contra qualquer tipo

de ataque. Também não há qualquer grupo de trabalho IEEE desenvolvendo emendas

para a segurança desses quadros. A ausência de mecanismos de segurança nos quadros

de controle permite a qualquer estação maliciosa, pertencente ou não à rede, efetuar diversos

ataques de negação de serviço ou DoS (Denial-of-Service). Exemplos incluem o

bloqueio do uso do canal de comunicação por um período de tempo pré-determinado, a

confirmação falsa de recebimento de informações que não foram efetivamente recebidas

e a solicitação falsificada de transmissão de informações armazenadas no AP que seriam

destinadas a estações que não estariam prontas para recebê-las, causando, na prática, o

descarte dessas informações.

Por causa do impacto dos vários ataques aos quadros de controle, diversas pesquisas

vêm sendo realizadas com o intuito de prover mecanismos efetivos para a segurança

desses quadros [Myneni and Huang 2010], [Khan and Hasan 2008]. Este artigo propõe um

mecanismo de segurança para a proteção dos quadros de controle de redes IEEE 802.11.

O mecanismo proposto se vale do uso de números de sequência e da geração de Códigos

de Autenticação de Mensagem ou MACs (Message Authentication Codes) a fim de evitar

que estações maliciosas, não pertencentes à rede, tenham sucesso ao forjar, manipular

ou reinjetar quadros de controle que levariam à negação de serviços. Além de proteger

todos os quadros de controle indistintamente, o mecanismo proposto possui um maior

grau de segurança e introduz, nesses quadros, um overhead significativamente menor em

comparação aos trabalhos relacionados que também se propõem a proteger todos os quadros

de controle.

O restante deste artigo está organizado da seguinte forma: a Seção 2 apresenta

os quadros de controle do IEEE 802.11 e os ataques existentes contra eles. A Seção 3

16


apresenta os trabalhos relacionados e como o trabalho proposto se diferencia de cada um

deles. A Seção 4 apresenta o mecanismo proposto neste artigo para a proteção dos quadros

de controle IEEE 802.11. A Seção 5 apresenta um estudo do overhead introduzido

pelo mecanismo proposto no tráfego total de uma rede sem fio. Finalmente, a Seção 6

apresenta as conclusões deste trabalho.

2. Quadros de Controle do IEEE 802.11

Esta seção apresenta as funcionalidades dos 8 tipos de quadros de controle definidos pelo

padrão IEEE 802.11 [IEEE Standard 802.11 2007]. Os diversos ataques contra tais quadros

também são apresentados. É importante ressaltar que o foco deste artigo está nos

ataques de origem externa, ou seja, naqueles executados por entidades maliciosas não

pertencentes à rede sem fio.

2.1. RTS (Request To Send) e CTS (Clear to Send)

O mecanismo RTS/CTS é utilizado em redes IEEE 802.11 para a redução de colisões no

meio de comunicação. Um nó que deseja transmitir dados inicia um handshake com o

destinatário, enviando um quadro RTS. Ao receber o RTS, o destinatário responde com

um quadro CTS. Qualquer outro nó da rede, ao escutar o RTS ou o CTS enviados, deve

postergar suas transmissões por um determinado período de tempo. Tal período engloba

o tempo necessário para a subsequente transmissão dos dados e recepção da confirmação

de seu recebimento. Assim sendo, o mecanismo RTS/CTS permite a reserva do canal

de comunicação para a troca de dados. Tipicamente, o uso do mecanismo RTS/CTS só

ocorre quando o tamanho do quadro com os dados excede um limiar pré-definido que

pode variar de 0 a 2347 bytes.

O RTS possui 20 bytes de comprimento, sendo dividido em 5 campos: FC (Frame

Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). O campo

FC possui 2 bytes. Ele permite identificar o tipo de quadro e provê algumas informações

de controle. O campo Duração possui 2 bytes e informa o tempo de reserva do canal.

Seu valor máximo é de 32.767 µs [IEEE Standard 802.11 2007]. Os campos Endereço

1 e 2 possuem 6 bytes cada e representam, respectivamente, o endereço do receptor e do

transmissor. O campo FCS possui 4 bytes e é preenchido com um CRC-32 para a detecção

de erros. O quadro CTS possui 4 dos 5 campos do quadro RTS. O campo ausente no CTS

é o campo Endereço 2, tornando o comprimento do quadro igual a 14 bytes.

Existem dois ataques conhecidos contra o mecanismo RTS/CTS [Myneni and Huang

2010]: o ataque de replay e o ataque de injeção de RTS e CTS falsificados. No

primeiro ataque, uma estação maliciosa escuta o canal para capturar quadros RTS ou CTS

e reinjetá-los na rede. No segundo ataque, uma estação maliciosa cria quadros RTS ou

CTS com um ou mais campos forjados e os envia à rede. Este último ataque pode ser

potencializado se a estação maliciosa preencher o campo Duração desses quadros com o

valor máximo permitido.

Ambos os ataques são efetivos porque o IEEE 802.11 não provê qualquer mecanismo

de autenticação de quadros de controle, nem de identificação de quadros de controle

previamente transmitidos. Assim, as estações que escutam os quadros RTS e CTS usados

nesses ataques executam as ações previstas pelo protocolo, bloqueando temporariamente

suas transmissões e, portanto, sofrendo uma negação de serviço.

17


2.2. ACK (Acknowledgement)

Os quadros ACK são usados para confirmar o recebimento de alguns tipos de quadros.

O ACK possui o mesmo formato e tamanho do CTS. Os ataques conhecidos aos quadros

ACK são os seguintes: injeção de ACK falsificado e ataque de replay. Em [Chen

and Muthukkumarasamy 2006], é mostrado como forjar ACKs para a manipulação do

tempo de reserva do canal de comunicação. Os autores demostram que os quadros ACK

podem ser utilizados de forma tão efetiva quanto os quadros RTS/CTS para a negação

de serviços. Em [Rachedi and Benslimane 2009], é apresentado um ataque denominado

False Packet Validation. Nesse ataque, a entidade maliciosa força a ocorrência de uma

colisão num receptor-alvo para, em seguida, enviar um ACK falsificado que confirma ao

emissor a correta recepção das informações enviadas. Caso a colisão tenha sido efetuada

com sucesso, o emissor, ao receber o ACK forjado, concluirá erroneamente que as

informações transmitidas foram corretamente recebidas no receptor.

2.3. BAR (Block Ack Request) e BA (Block Ack)

Os quadros BAR e BA foram introduzidos pela emenda IEEE 802.11e [IEEE Standard

802.11e 2005] e tiveram suas funcionalidades estendidas pela especificação IEEE

802.11n. Esses quadros são usados para permitir a confirmação de um bloco de quadros

usando apenas um quadro de confimação. O quadro BAR é usado para se requisitar a

confirmação de recepção de um bloco de quadros enquanto o quadro BA serve como resposta.

O quadro BA pode ainda ser utilizado para a confirmação de recepção de um bloco

de quadros sem a necessidade de uso do quadro BAR.

O quadro BAR possui 24 bytes de comprimento e é formado por 7 campos: FC

(Frame Control), Duração, Endereço 1, Endereço 2, BAR control, Block Ack Starting

Sequence Control e FCS (Frame Check Sequence). O campo BAR control possui 2 bytes

e é usado, entre outras coisas, para informar parâmetros de qualidade de serviço. O campo

Block Ack Starting Sequence Control possui 2 bytes e inclui, entre outras informações, o

número de sequência do primeiro quadro em um bloco. O campo Duração possui 2 bytes

e informa um tempo maior ou igual ao necessário para a recepção do quadro BA a ser

enviado como resposta. Os demais campos possuem o mesmo tamanho e descrição já

apresentados para os quadros RTS.

O quadro BA possui 152 bytes de comprimento e inclui 8 campos: FC (Frame

Control), Duração, Endereço 1, Endereço 2, BA control, Block Ack Starting Sequence

Control, Block Ack Bitmap e FCS (Frame Check Sequence). O campo BA control possui

2 bytes e armazena informações de controle específicas do quadro. O campo Block Ack

Starting Sequence Control, também de 2 bytes, é usado para informar a qual quadro BAR

pertence a resposta. O campo Block Ack Bitmap possui 128 bytes e informa, através de

um mapa de bits, quais quadros de um bloco não foram recebidos. O campo Duração

possui 2 bytes e a informação de tempo contida nele depende do quadro ser ou não uma

resposta a um quadro BAR. Os demais campos possuem tamanho e descrição similares

aos apresentados para o quadro RTS.

O mecanismo de confirmação em bloco de quadros também pode ser explorado

através da falsificação de informações em quadros BAR. Um estudo sobre o uso malicioso

dos quadros BAR é apresentado em [Cam-Winget et al. 2007]. Os autores mostram

que é possível manipular o número de sequência informado nos quadros BAR, causando

18


o descarte de qualquer quadro com número de sequência menor do que o informado.

Um único quadro BAR manipulado pode causar uma negação de serviço na rede por 10

segundos [Koenings et al. 2009].

2.4. PS-Poll (Power Save Poll)

Os APs são projetados para dar suporte a toda estação que esteja utilizando gerenciamento

de energia em sua interface de comunicação. Nesse caso, a estação desliga e liga sua

interface de comunicação periodicamente para economizar energia. O AP deve armazenar

os quadros destinados à estação até que a mesma esteja pronta para a recepção de quadros.

Ao religar sua interface, a estação procura por beacons do AP que informam se existem

quadros armazenados para ela. Caso haja, a estação deve enviar um quadro de controle

PS-Poll para recuperar os quadros armazenados pelo AP. A estação pode voltar a desligar

sua interface após recuperar todos os quadros armazenados ou após ouvir do AP algum

beacon indicando que não há quadros armazenados para aquela estação.

O quadro PS-Poll possui 20 bytes de comprimento e é formado por 5 campos: FC

(Frame Control), AID (Association ID), Endereço 1, Endereço 2 e FCS (Frame Check

Sequence. O campo AID representa um identificador de associação da estação e possui

2 bytes. Os demais campos possuem tamanho e descrição idênticos aos já apresentados

para o RTS.

Em [Qureshi et al. 2007], é mostrado como o quadro PS-Poll pode ser utilizado

para que uma estação maliciosa assuma, perante ao AP, a identidade de uma estação

legítima para a qual o AP possua quadros armazenados. Ao receber o quadro falso, o

AP enviará os quadros armazenados que seriam destinados à estação legítima. Assim

sendo, o ataque causa o “descarte” de informações pertencentes a outra estação, efetivando

uma negação de serviço. Mais uma vez, o ataque só é possível por causa da falta

de autenticação dos quadros PS-Poll.

2.5. CF-End (Contention Free End) e CF-End+CF-Ack (CF-End+Contention Free

Ack)

A PCF (Point Coordination Function) é uma forma opcional de acesso ao meio definido

no IEEE 802.11 e utilizada para a oferta, por parte do AP, de períodos livres de contenção

às estações. Por ser um método opcional, poucos dispositivos o implementam. Quando

um período livre de contenção termina, o AP transmite um quadro CF-End para liberar

as estações das regras de operação do modo PCF e informá-las do início do serviço baseado

em contenção sob o método DCF (Distributed Coordination Function). O quadro

CF-End+CF-Ack combina duas funções, sendo utilizado pelo AP quando o mesmo precisa

informar o término de um período livre de contenção e confirmar, ao mesmo tempo,

quadros anteriormente recebidos.

Ambos os quadros possuem 20 bytes de comprimento divididos em 5 campos: FC

(Frame Control), Duração, Endereço 1, Endereço 2 e FCS (Frame Check Sequence). Em

particular a esses quadros, o campo Endereço 1 deve conter o endereço de broadcast da

rede e o campo Duração deve conter o valor zero. O significado dos demais campos e

seus tamanhos são idênticos aos já descritos para o RTS.

Em [Malekzadeh et al. 2010], é mostrado experimentalmente que a manipulação

do campo Duração dos quadros CF-End e CF-End+CF-Ack permite lançar ataques que

19


tornam a rede indisponível, bloqueando a comunicação de dispositivos legítimos. Os efeitos

são idênticos aos obtidos com ataques similares a outros tipos de quadros de controle.

3. Trabalhos Relacionados

Em [Bellardo and Savage 2003], são apresentadas propostas para se minimizar os efeitos

de ataques ao mecanismo RTS/CTS. Uma das propostas consiste na limitação do valor

máximo informado no campo Duração dos quadros de controle. Outra proposta consiste

na observação da sequência de transmissões a partir de um RTS. A ausência de dados

transmitidos após o RTS é considerada uma indicação de que a rede está sendo atacada.

Nesse caso, as estações voltariam imediatamente a concorrer pelo uso do canal. Em [Ray

and Starobinski 2007], a mesma ideia de observação da sequência de transmissões a partir

de um RTS é utilizada para se propor técnicas não-criptográficas de mitigação de ataques

ao mecanismo RTS/CTS, mas no contexto de redes sem fio multihop. Em [Qureshi et al.

2007], é apresentada uma proposta para se proteger apenas os quadros PS-Poll contra

ataques de falsificação e replay. A medida proposta se concentra no uso de artifícios

criptográficos exclusivamente sobre o campo Association ID.

A primeira proposta de proteção criptográfica de todos os quadros de controle

do IEEE 802.11 é apresentada em [Khan and Hasan 2008]. Nessa proposta, o campo

FCS dos quadros de controle deixa de ser preenchido com um CRC-32 para conter um

código de autenticação de 16 bits seguido de um CRC-16. Isso objetiva a manutenção do

tamanho original dos quadros de controle. O código de autenticação é gerado por uma

versão modificada de uma PRF (Pseudo Random Function) do WPA2 para produzir uma

saída de 16 bits. Contudo, o uso de apenas 16 bits para o código de autenticação torna

a proteção provida pelo mecanismo fraca [Whiting et al. 2003]. As PRFs usadas em

especificações do IEEE 802.11, por exemplo, têm saída de pelo menos 128 bits, podendo

alcançar 512 bits em caso de necessidade de aumento do nível de segurança. A proposta

apresentada por [Khan and Hasan 2008] também não traz mecanismos contra ataques de

replay.

Outra proposta que visa proteger de forma criptográfica todos os quadros de controle

é apresentada em [Myneni and Huang 2010]. Para identificar ataques de replay e

poder torná-los sem efeito, os autores se valem do uso de um número de sequência de 32

bits em todos os quadros de controle. O framework IAPP (Inter-Access Point Protocol) ou

IEEE 802.11F é utilizado para a distribuição e gerenciamento da chave criptográfica a ser

utilizada. O IEEE 802.11F era uma extensão opcional do IEEE 802.11 para o provimento

de serviços de comunicação entre APs compondo um ESS (Extended Service Set). O protocolo

permite a troca de contextos de segurança entre APs durante períodos de handoff

das estações. Em 2006, o IEEE retirou a extensão 802.11F do padrão 802.11.

Ainda em relação ao trabalho apresentado em [Myneni and Huang 2010], o

mesmo também se propõe a proteger os quadros de controle por meio de um código de

autenticação de mensagem (MAC). O MAC possui 160 bits e é gerado através do HMAC-

SHA1. Como o MAC pode ser usado para verificação de integridade, o campo FCS dos

quadros de controle é eliminado. O uso do MAC de 160 bits dificulta a falsificação dos

quadros de controle em relação à proposta em [Khan and Hasan 2008], porém introduz

neles um overhead significativo. Além disso, há estudos que mostram fraquezas do

HMAC-SHA1 [Kim et al. 2006], [Rechberger and Rijmen 2008]. Em particular à SHA-

20


1, a mesma apresenta diversas vulnerabilidades importantes [Cannière and Rechberger

2006], [Manuel 2008]. Um dos ataques mais rápidos contra a versão completa da SHA-

1 possui complexidade de tempo O(2 63 ) ao passo que a complexidade de tempo de um

ataque de força bruta é O(2 80 ) [Bellovin and Rescorla 2005].

Dentre os trabalhos relacionados, apenas [Myneni and Huang 2010] e [Khan and

Hasan 2008] se propõem a proteger todos os quadros de controle, sendo que o primeiro

apresenta uma proposta mais segura e completa, embora incorra em um overhead significativo.

Neste artigo, é proposto um mecanismo de proteção de quadros de controle contra

ataques que levariam à negação de serviços. O objetivo principal é, em comparação à proposta

em [Myneni and Huang 2010], prover um maior grau de segurança com um menor

overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE

802.11. Além disso, a proposta faz uso de chave criptográfica já empregada no protocolo

de segurança WPA2, evitando a necessidade de se usar o IEEE 802.11F dado que o

mesmo foi removido do padrão IEEE 802.11.

4. O Mecanismo de Proteção Proposto

O mecanismo aqui proposto também se vale do uso de números de sequência e da geração

de códigos de autenticação de mensagens para proteger os quadros de controle. Contudo,

a geração desses códigos emprega partes do protocolo CCMP (Counter Mode with

Cipher Block Chaining Message Authentication Code Protocol) já utilizado pelo WPA2.

O CCMP usa o modo de operação do AES (Advanced Encryption Standard) conhecido

por CCM, o qual combina o CTR (Counter Mode) com o CBC-MAC (Cipher Block Chaining

Message Authentication Code). O CTR é utilizado para prover confidência enquanto

o CBC-MAC é utilizado para prover autenticação e integridade. A seguir, a proposta é

detalhada.

4.1. Novos Quadros de Controle

O mecanismo proposto neste artigo introduz 8 novos tipos de quadros de controle no

padrão IEEE 802.11. Esses quadros de controle são versões seguras dos quadros de

controle originais. O padrão IEEE 802.11 utiliza 4 bits para a identificação de tipos

de quadros de controle. Como já existem 8 tipos de quadros de controle definidos, a

especificação consegue acomodar os novos quadros definidos pelo mecanismo proposto.

A versão segura dos quadros de controle se diferencia dos quadros de controle originais

apenas por não possuir o campo FCS e, em seu lugar, haver o campo NS (Número de

Sequência) de 4 bytes seguido do campo MAC (Message Authentication Code) de 8 bytes.

A Figura 1 apresenta, como exemplo, o ACK atual do padrão IEEE 802.11 e sua

versão a ser utilizada no mecanismo de segurança proposto.

Octetos: 2 2 6 4

Octetos: 2 2 6

4 8

Frame

Control

Duração

RA

FCS

Frame

Control

Duração

RA

NS

MAC

Cabeçalho MAC

(a) ACK no padrão IEEE 802.11.

Cabeçalho MAC

(b) Versão segura do ACK no mecanismo proposto.

Figura 1. Formato dos quadros de controle ACK.

21


O campo MAC permitirá, ao nó receptor, verificar a autenticidade e a integridade

do quadro de controle recebido. Como o campo MAC permitirá a detecção de mudanças

no quadro de controle, não há necessidade de se manter o campo FCS original para a

detecção de erros. O campo NS carregará a informação do número de sequência do quadro.

Assim, cada nó da rede deve manter um contador de 32 bits, o qual deverá ser

incrementado de 1 unidade a cada novo quadro de controle. O campo NS deverá ser preenchido

com o valor atual desse contador e nunca poderá ser repetido durante a utilização

da mesma chave de segurança utilizada no cálculo do MAC.

4.2. Cálculo do Valor do Campo MAC

O CBC-MAC [Whiting et al. 2003] considera uma mensagem B, a ser autenticada, dividida

em uma sequência de blocos B 0 ,B 1 ,B 2 ...B n , onde n+1 é o número total de blocos

da mensagem. O CBC-MAC também define E() como sendo a função de criptografia por

blocos a ser utilizada, K como sendo a chave criptográfica e T como sendo o código de

autenticação. O cálculo de T é feito de acordo com o Algoritmo 4.1. Inicialmente, B 0 é

criptografado e o resultado é armazenado em X 1 . Em seguida, é realizada um XOR entre

X 1 e o próximo bloco B 1 . O resultado é armazenado em X 2 . O processo se repete para

cada bloco seguinte até a obtenção de X (n+1) , sendo este último o código de autenticação

e o qual pode ser truncado para os M primeiros bytes se necessário.


Algoritmo 4.1: T (K,B,n,M)

X 1 ← E(K,B 0 )

para i = 1 até n faça

X (i+1) ← E(K,X i ⊕ B i )

T ← M primeiros bytes de X (n+1)




Em particular, a mensagem a ser autenticada precisa ter o primeiro bloco B 0 formatado

como mostra a Tabela 1. Nessa tabela, l(m) é o número de bytes da mensagem

m, onde 0 ≤ l(m) ≤ 2 (8L) . O Nonce é um valor único que nunca deverá ser repetido com

o uso de uma mesma chave criptográfica. As Flags ocupam 1 byte e também possuem

formatação pré-definida conforme descrição a seguir: o primeiro bit de ordem mais alta

é reservado para uso futuro e deve ser sempre zero. O segundo bit de ordem mais alta,

Adata, indica a utilização da técnica de autenticação de dados adicionais ou AAD quando

igual a 1. Caso a técnica não seja utilizada, Adata deve ser zero. Os 3 bits seguintes

codificam M contendo o valor (M − 2)/2. Assim, M só pode assumir valores pares de 0

a 16. Os 3 bits de ordem mais baixa codificam L contendo o valor L − 1. Valores válidos

para L estão no intervalo de 2 a 8.

Byte Nº 0 1 . . .(15 − L) (16 − L)...15

Conteúdo Flags Nonce l(m)

Tabela 1. Composição do Bloco B 0 .

O CBC-MAC foi projetado para uso com algoritmos de cifra por blocos de 128

bits, sendo o tamanho da chave dependente do algoritmo de cifra por bloco utilizado. Os

22


locos com menos de 128 bits devem ser completados com zeros. No caso do CCMP

definido pelo WPA2, é utilizado o AES com operações com chaves e blocos de 128 bits.

Assim sendo, toda a operação para o cálculo do código de autenticação com o mecanismo

proposto segue esse mesmo princípio. O cômputo do valor do campo MAC é feito através

do uso da implementação do CBC-MAC no CCMP. A Figura 2 ilustra esse processo. O

bloco inicial a ser criptografado possui 128 bits e é representado pelo IV (Initialization

Vector). Sua formação é explicada como segue:

IV

Nonce

Flag

Priority

Octet

A2(TA)

NS

l(m)

64

bits

64

bits

AES(K)

AES(K)

AES(K)

AES(K)

Cálculo

MAC

...

Quadro

Texto em Claro

Cabeçalho do Quadro

... 128 bits

NS

MAC

Figura 2. Geração do valor do campo MAC.

• Flag - possui 1 byte. Contém as informações previstas para o campo Flags definido

em [Whiting et al. 2003] e possui valor igual a (00011011) b . Ou seja, não é

utilizada a técnica AAD, M = 8 e L = 4;

• Nonce - possui 11 bytes e é formado pela concatenação do Priority Octet (1 byte)

com os 48 bits do endereço do transmissor ou A2(TA) e o número de sequência

NS de 32 bits do quadro de controle. Esse tipo de construção respeita a formação

de nonces usada pelo CCM no WPA2 e é usada aqui para fins de compatibilidade.

O CCM no WPA2 especifica que o campo Priority Octet deve ser preenchido

com zeros quando não houver o campo de controle de QoS (Quality of Service)

no cabeçalho do quadro como é o caso dos quadros de controle. A forma de

construção do nonce permite que os nós da rede usem sempre nonces distintos

entre eles.

• l(m) - possui 4 bytes e segue a definição em [Whiting et al. 2003] para informar

o tamanho da mensagem a ser autenticada.

O processo de construção do MAC segue o algoritmo 4.1 tendo o IV como bloco

inicial B 0 . Os próximos blocos são obtidos dividindo-se o quadro de controle em pedaços

de 128 bits mas com a exclusão dos campos NS e MAC. No caso do ACK e do CTS,

haverá apenas 80 bits de informação que devem ser concatenados com 48 bits iguais a

zero para compor o próximo e último bloco B 1 . No caso dos quadros RTS, CF-End e

CF-End+Cf-Ack, o próximo e último bloco B 1 já conterá exatos 128 bits. O quadro BAR

gerará mais dois blocos (B 1 e B 2 ), sendo que o último deverá ser completado com 96

bits iguais a zero. O quadro BA gerará mais dez blocos (B 1 ...B 10 ), sendo que o último

também deverá ser completado com 96 bits iguais a zero.

Para que um nó da rede possa construir o MAC e permitir a qualquer outro verificar

a autenticidade e a integridade do quadro, é necessário que uma chave K em comum

23


seja empregada. A chave criptográfica comum utilizada no WPA2 é a GEK (Group encryption

Key) que faz parte da chave hieráquica GTK (Group Temporal Key). A GEK é

a chave usada para a criptografia de tráfego destinado a múltiplos nós da rede. A GTK

é distribuída durante o processo de 4-Way Handshake e renovada periodicamente usando

o protocolo GKH (Group Key Handshake). Adicionalmente aos critérios de renovação

da GTK definidos pelo WPA2, o uso do mecanismo proposto requer a renovação dessa

chave para evitar que um nó utilize um mesmo número de sequência com uma mesma

GTK. Assim, o nó que esgotar seus números de sequência deve solicitar a renovação da

GTK da rede através do uso do protocolo GKH (Group Key Handshake).

Ao receber um quadro de controle do mecanismo proposto, o nó da rede sem

fio deve recalcular o MAC e comparar o valor obtido com aquele informado no campo

MAC. Para isso, ela precisará da chave K e do IV . A chave K é conhecida por todas

as estações da rede. O IV possui duas partes: uma parte com valor fixo e pré-definido

(Flag, Priority Octet e l(m)), o qual é conhecido pelas estações e uma parte com valor

variável composta pelo NS e pelo endereço do transmissor. O NS que é transportado

em claro pelo quadro. O endereço do transmissor está presente em todos os quadros de

controle, exceto nos quadros CTS e ACK. Para os quadros CTS e ACK, o padrão IEEE

802.11 prevê que o receptor obtenha o endereço do transmissor a partir dos respectivos

RTS ou dos respectivos quadros sendo confirmados de acordo com o caso. Ao recalcular o

MAC, caso o valor obtido seja diferente daquele informado no campo MAC, a mensagem

foi alterada e deve ser desconsiderada. Caso o valor do MAC recalculado seja igual ao

informado no campo MAC do quadro recebido, o nó deve verificar se não é um quadro

repetido usando como base o número de sequência esperado. Caso o quadro não seja uma

repetição, o nó receptor deverá considerar a mensagem e a origem da mesma autenticadas.

4.3. Segurança

A segurança do mecanismo proposto está intimamente ligada à segurança do WPA2. Em

redes IEEE 802.11 protegidas pelo WPA2, é possível encontrar a chave GTK através

de um ataque de dicionário quando a rede usa o método de autenticação pessoal em

conjunto com uma passphrase. Contudo, esse ataque só é praticável se a passphrase

possuir menos de 20 caracteres [Fogie 2005]. Essa vulnerabilidade é considerada do

usuário/administrador e não do protocolo de segurança. Em [Rogaway 2011], é apresentado

um estudo que mostra que o CCM apresenta propriedades de segurança suficientemente

adequadas. O estudo também mostra que as principais críticas ao CCM estão

ligadas à sua eficiência de execução. Em relação à segurança do AES, o ataque mais

rápido de recuperação de chave contra sua versão completa de 128 bits possui complexidade

de tempo O(2 126,1 ) enquanto a complexidade de tempo de um ataque de força bruta

é O(2 128 ) [Bogdanov et al. 2011].

4.4. Resumo Comparativo

A Tabela 2 apresenta um resumo da proteção oferecida pelo mecanismo proposto e pelos

trabalhos relacionados para cada tipo de quadro de controle. A existência de proteção

contra forja e manipulação do quadro é indicada por X. A existência de proteção contra

ataques de replay é indicada por 0.

24


RTS CTS ACK BA BAR PS-

Poll

CF-

End

CF-End +

CF-Ack

[Bellardo and Savage 2003] X X X

[Qureshi et al. 2007]

X

[Ray and Starobinski 2007] X

[Khan and Hasan 2008] X X X X X X X X

[Rachedi and Benslimane 2009] X X X

[Myneni and Huang 2010] X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0

Proposta neste artigo X/0 X/0 X/0 X/0 X/0 X/0 X/0 X/0

Tabela 2. Comparativo da proteção oferecida pelas diversas propostas.

5. Estudo de Caso

Esta seção estuda o impacto do mecanismo proposto neste artigo e em [Myneni and Huang

2010] no tráfego global de uma rede sem fio. Para esse estudo, foram capturados quadros

ao longo de 1 hora na rede sem fio do Centro de Informática da UFPE, gerando um

arquivo trace com aproximadamente 1.500.000 quadros. Todos os quadros capturados

eram provenientes de um único AP escolhido ou direcionados a ele.

A Figura 3(a) apresenta a quantidade capturada dos 3 tipos de quadros. Note

que há uma predominância dos quadros de controle. A Figura 3(b) detalha os tipos de

quadros de controle capturados. Em particular, observa-se que foram capturados quadros

de controle de todos os tipos, exceto o quadro CF-End+CF-Ack.

Quantidade

1e+07

1e+06

100000

10000

1000

100

Gereciamento

Controle

Dados

Quantidade

1e+07

1e+06

100000

10000

1000

100

Gereciamento

Dados

Ack

CTS

RTS

PS-Poll

CF-End

BA

BAR

10

10

1

1

0.1

Quadros

0.1

Quadros

(a)

(b)

Figura 3. Distribuição da frequência dos quadros.

A partir do trace obtido, foram acrescentados aos quadros de controle o overhead

do mecanismo proposto e da proposta em [Myneni and Huang 2010] para fins de

comparação. A ideia é simular o mesmo tráfego de quadros sob esses dois mecanismos

de segurança. A Figura 4(a) apresenta o número cumulativo de bytes transferidos

em função da quantidade de quadros. Note que o mecanismo proposto possui um menor

overhead cumulativo do que a proposta em [Myneni and Huang 2010].

A Figura 4(b) apresenta o overhead normalizado do tráfego considerando as duas

propostas avaliadas. Note que até aproximadamente os 300.000 primeiros quadros capturados,

o mecanismo proposto têm um impacto de próximo de 57% enquanto a proposta do

Myneni tem um impacto de quase 143%. A medida que o volume de quadros aumenta,

25


9e+07

8e+07

7e+07

Padrao

Myneni

Proposta

1.8

1.6

1.4

Proposta

Myneni

6e+07

1.2

Bytes

5e+07

4e+07

3e+07

Overhead

1

0.8

0.6

2e+07

0.4

1e+07

0.2

0

0 350000 700000 1.05e+06 1.4e+06

Quadros Capturados

0

0 350000 700000 1.05e+06 1.4e+06

Quadros Capturados

(a) Bytes usados para transmitir a mesma

informação útil.

(b) Overhead normalizado em relação ao formato

padrão dos quadros.

Figura 4. Comparação entre propostas.

observa-se que o impacto do mecanismo proposto tende à 20% enquanto o impacto do

mecanismo proposto por Myneni tende à 40%.

6. Conclusões

Este artigo apresentou um mecanismo de proteção de quadros de controle contra ataques

de negação de serviço. O mecanismo foi construído de forma a manter a compatibilidade

com o padrão IEEE 802.11. O objetivo principal da proposta, em comparação à proposta

em [Myneni and Huang 2010], foi o de prover um maior grau de segurança com um menor

overhead, fazendo uso dos mecanismos de segurança mais recentes presentes no IEEE

802.11. Adicionalmente, a proposta fez uso da chave de grupo já empregada no protocolo

de segurança WPA2, evitando a necessidade de se utilizar um mecanismo de gerenciamento

e distribuição de chaves abandonado pelo IEEE. Para dar proteção aos quadros

de controle contra os ataques estudados, o mecanismo proposto se utilizou de números

de sequência e de códigos de autenticação de mensagens obtidos através do emprego do

CBC-MAC do CCMP. O overhead introduzido com o uso do mecanismo proposto é, por

quadro de controle, 2,5 vezes menor do que aquele introduzido pela proposta de Myneni.

Um estudo de caso enfatizou que o mecanismo proposto produziu um impacto significativamente

menor no tráfego global da rede do que aquele produzido pela proposta de

Myneni. Como trabalho futuro, será realizado um estudo da vazão da rede ao se utilizar o

mecanismo proposto.

Referências

Bellardo, J. and Savage, S. (2003). 802.11 Denial-of-Service Attacks: Real Vulnerabilities

and Practical Solutions. In Proc. of the 12th USENIX Security Symposium (SSYM),

pages 15–28, Washington, DC, USA.

Bellovin, S. and Rescorla, E. (2005). Deploying a New Hash Algorithm. Technical report.

Bogdanov, A., Khovratovich, D., and Rechberger, C. (2011). Biclique Cryptanalysis of

the Full AES. In Proc. of the 17th Annual International Conference on the Theory and

Application of Cryptology and Information Security (ASIACRYPT), Seoul, Korea, (To

appear).

26


Cam-Winget, N., Smith, D., and Walker, J. (2007). IEEE 802.11-07/2163r0 - A-MPDU

Security Issues. Technical report.

Cannière, C. D. and Rechberger, C. (2006). Finding SHA-1 Characteristics: General

Results and Applications. In Lecture Notes in Computer Science - ADVANCES IN

CRYPTOLOGY (ASIACRYPT), volume 4284, pages 1–20.

Chen, B. and Muthukkumarasamy, V. (2006). Denial of Service Attacks Against 802.11

DCF Abstract.

Fogie, S. (2005). Cracking Wi-Fi Protected Access (WPA), Part 2. http://www.

fermentas.com/techinfo/nucleicacids/maplambda.htm.

IEEE Standard 802.11 (1999). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications.

IEEE Standard 802.11 (2007). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications.

IEEE Standard 802.11e (2005). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 8: Medium Access

Control (MAC) Quality of Service Enhancements.

IEEE Standard 802.11i (2004). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 6: Medium Access

Control (MAC) Security Enhancements Interpretation.

IEEE Standard 802.11k (2008). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 1: Radio Resource

Measurement of Wireless LANs.

IEEE Standard 802.11r (2008). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 2: Fast Basic Service

Set (bss).

IEEE Standard 802.11v (2011). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 8: IEEE 802.11 Wireless

Network Management.

27


IEEE Standard 802.11w (2009). IEEE Standards for Information technology - Telecommunications

and information exchange between systems - Local and metropolitan area

networks - Specific requirements - Part 11: Wireless LAN Medium Access Control

(MAC) and Physical Layer (PHY) Specifications - Amendment 4: Protected Management

Frames.

Khan, M. and Hasan, A. (2008). Pseudo random number based authentication to counter

denial of service attacks on 802.11. In Proc. of 5th IFIP International Conference on

Wireless and Optical Communications Networks (WOCN), pages 1–5.

Kim, J., Biryukov, A., Preneel, B., and Hong, S. (2006). On the Security of HMAC

and NMAC Based on HAVAL, MD4, MD5, SHA-0, and SHA-1. Designs, Codes

Cryptography, 4116:242–256.

Koenings, B., Schaub, F., Kargl, F., and Dietzel, S. (2009). Channel Switch and Quiet

attack: New DoS Attacks Exploiting the 802.11 Standard. In Proc. of the 34th IEEE

Conference on Local Computer Networks (LCN), Zurich, Switzerland.

Malekzadeh, M., Ghani, A. A. A., and Subramaniam, S. (2010). Design of Cyberwar

Laboratory Exercises to Implement Common Security Attacks against IEEE 802.11

Wireless Networks. J. Comp. Sys., Netw., and Comm., pages 5:1–5:15.

Manuel, S. (2008). Classification and Generation of Disturbance Vectors for Collision

Attacks against SHA-1. Cryptology ePrint Archive, Report 2008/469.

Myneni, S. and Huang, D. (2010). IEEE 802.11 Wireless LAN Control Frame Protection.

In Proc. of the 7th IEEE Conference on Consumer communications and Networking

Conference (CCNC), pages 844–848, Piscataway, NJ, USA. IEEE Press.

Qureshi, Z. I., Aslam, B., Mohsin, A., and Javed, Y. (2007). A Solution to Spoofed

PS-Poll Based Denial of Service Attacks in IEEE 802.11 WLANs. In Proc. of the

11th WSEAS International Conference on Communications, pages 7–11, Stevens Point,

Wisconsin, USA. World Scientific and Engineering Academy and Society (WSEAS).

Rachedi, A. and Benslimane, A. (2009). Impacts and Solutions of Control Packets Vulnerabilities

with IEEE 802.11 MAC. Wireless Communications and Mobile Computing,

9(4):469–488.

Ray, S. and Starobinski, D. (2007). On False Blocking in RTS/CTS-Based Multihop

Wireless Networks. IEEE Transactions on Vehicular Technology, 56(2):849–862.

Rechberger, C. and Rijmen, V. (2008). New Results on NMAC/HMAC when Instantiated

with Popular Hash Functions. Universal Computer Science, 14(3):347–376.

Rogaway, P. (2011). Evaluation of Some Blockcipher Modes of Operation. Technical

report, Cryptography Research and Evaluation Committees (CRYPTREC).

Tews, E. (2007). Attacks on the WEP Protocol. Cryptology ePrint Archive, Report

2007/471.

Whiting, D., Housley, R., and Ferguson, N. (2003). RFC 3610 - Counter with CBC-MAC

(CCM).

Wi-Fi Alliance (2003). Wi-Fi Protected Access: Strong, Standards-based, Interoperable

Security for Today’s Wi-Fi Networks.

28


Tratamento Automatizado de Incidentes de Segurança da

Informação em Redes de Campus

Italo Valcy 1,2 , Luciano Porto Barreto 1,2 , Jerônimo Bezerra 1,2

1 Universidade Federal da Bahia (UFBA)

Salvador, BA – Brasil

2 Grupo de Resposta a Incidentes de Segurança - Bahia/Brasil (CERT.Bahia)

Salvador, BA – Brasil

{italovalcy, lportoba, jab}@ufba.br

Resumo. O crescimento atual da Internet tem alavancado o número de

incidentes de segurança da informação em diversas instituições. Os prejuízos

causados por tais incidentes e sua dificuldade de prevenção requerem o

estabelecimento de políticas e mecanismos eficientes de tratamento e resposta

a incidentes de segurança. Entretanto, a correta identificação de equipamentos

comprometidos ou participantes em um incidente de segurança é severamente

prejudicada pela ampla existência de redes que utilizam técnicas de tradução

ou atribuição dinâmica de endereços IP (como o NAT ou DHCP), as quais

dificultam a identificação precisa dos equipamentos internos. Este trabalho

descreve o projeto, a implementação e avaliação da ferramenta TRAIRA, a

qual automatiza o procedimento de detecção, identificação e isolamento dos

equipamentos geradores de incidentes de segurança em redes com estas características.

A ferramenta está atualmente em produção e uso efetivo em uma rede

de campus com cerca de 12.000 equipamentos conectados.

1. Introdução

A popularização da Internet tem proporcionado relevante democratização do acesso às

informações em rede, porém, paralelo a esse fenômeno, é notório o aumento substancial

na ocorrência de incidentes relacionados à segurança da informação. Tais incidentes

são diversos e variam sobremaneira em gravidade, impacto e escala. Exemplos abrangem

desde a infecção e disseminação de software malicioso, apropriação de senhas e

informações privadas até fraudes bancárias, violação de sigilo e propriedade intelectual,

ataque a sites comerciais e ciberterrorismo. No âmbito das empresas e instituições

governamentais, torna-se fundamental atuação efetiva da alta administração visando à

prevenção, detecção e tratamento adequado de tais eventos adversos com o intuito de

proteger os ativos organizacionais (patrimônio, imagem, pessoas).

Instituições lidam com a questão geralmente através da atuação em dois eixos.

O primeiro estabelece uma Política de Segurança da Informação (PSI) que normatiza

regras, condutas e planos de ação, bem como possíveis sanções aos usuários em caso do

descumprimento das regras estatuídas. O segundo eixo perpassa a constituição de um

grupo especializado de resposta a incidentes de segurança (CSIRT, do inglês, Computer

Security Information Response Team) responsável pelas questões operacionais desde a

fase de identificação até a resolução dos incidentes de segurança. Seguindo essa linha de

29


atuação em segurança da informação, nossa instituição contempla a administração de uma

rede de campus que interliga diversas instituições acadêmicas e de pesquisa perfazendo

aproximadamente 12.000 equipamentos (desconsiderando equipamentos conectados em

redes sem fio). Ademais, no período compreendido entre janeiro e julho de 2011, foram

reportados aproximadamente 2.000 incidentes de segurança da informação referentes às

instituições de pesquisa e ensino monitoradas pelo nosso CSIRT [CERT.Bahia 2010], o

que atesta a necessidade de tratamento efetivo e eficaz de tais incidentes.

Os prejuízos causados por tais incidentes aliados à sua dificuldade de prevenção

[Scarfone et al. 2008] demandam o estabelecimento de políticas e mecanismos eficientes

de tratamento e resposta. A grande maioria desses incidentes são reportados por CSIRTs

externos à instituição, a exemplo do CERT.br e do CAIS/RNP. Lentidão, leniência no

tratamento do incidente, bem como a reincidência podem ensejar sanções severas e indesejáveis,

tais como o bloqueio de acesso e a recusa de e-mails originários da instituição

comprometida. A infecção e disseminação de malware, a exemplo do vírus Conficker,

ou a participação (ainda que involuntária) de máquinas em botnets (redes de ataques

em larga escala) são exemplos dos tipos de incidentes mais frequentes na geração de

notificações externas. Portanto, os prejuízos institucionais decorrentes de tais sanções são

consideráveis em nosso contexto (instituições acadêmicas e de pesquisa), o que requer

atuação rápida e efetiva do time de resposta a incidentes.

Entretanto, um dos principais entraves à correta identificação de equipamentos

comprometidos ou participantes em um incidente de segurança consiste na ampla

existência de redes configuradas com faixas de endereços IP “falsos” (i.e., nãoroteáveis

na Internet [Rekhter et al. 1996]) e NAT (do inglês, Network Address Translation)

[Egevang and Francis 1994]. Estas redes geralmente utilizam o serviço de DHCP

(do inglês, Dynamic Host Configuration Protocol) [Droms 1997], o qual pode atribuir

temporariamente e aleatoriamente endereços às máquinas da rede. Essa configuração,

adotada em grande parte das instituições, oculta a identidade precisa das máquinas internas

comprometidas, o que dificulta sobremaneira o tratamento adequado de incidentes.

Outros fatores complicadores, nesse contexto, incluem o elevado volume de

notificações recebidas e a heterogeneidade dos elementos da rede. O uso de roteadores

e switches de fabricantes diversos (caso geral nas instituições) compromete ou limita

a utilização de soluções proprietárias. Ainda que o parque organizacional de equipamentos

seja o mais homogêneo possível, as soluções proprietárias existentes são significativamente

onerosas, o que pode inviabilizar sua adoção. Por fim, mesmo instituições de

médio e grande porte carecem de equipe e ferramentas de segurança especializadas para

tratar os principais tipos de incidentes.

De fato, a automatização adequada do processo de tratamento de incidentes pode

reduzir substancialmente os custos financeiros do tratamento de incidentes (especialmente

o de pessoal alocado para esta tarefa) além de resolução mais célere dos problemas. No

cenário ideal, concretamente, uma ferramenta pode automaticamente detectar e isolar as

máquinas comprometidas para, em seguida, acionar a equipe de apoio (helpdesk) a fim

de proceder a desinfecção das máquinas. Assim, os analistas de segurança, cujo custo de

contratação é comumente alto, podem se ater ao tratamento de incidentes mais importantes

ou complexos.

30


Diante deste cenário de problemas reais, este trabalho descreve o desenvolvimento

e avaliação de uma ferramenta, chamada TRAIRA (Tratamento de Incidentes de

Rede Automatizado), que automatiza as principais etapas do processo de tratamento de

incidentes de segurança (detecção e contenção da máquina interna causadora do incidente).

A ferramenta desenvolvida foi avaliada em um ambiente real, na rede de campus

da Universidade Federal da Bahia (UFBA), onde é utilizada como base do processo de

tratamento de incidentes de segurança gerados pela instituição há aproximadamente um

ano, ajudando a equipe de segurança a tratar e responder uma média de 30 notificações

de incidentes por semana. O baixo custo de implantação e execução da ferramenta indica

a viabilidade de sua aplicação prática em outros ambientes corporativos.

O restante deste artigo está estruturado da seguinte maneira. A seção 2 destaca os

principais desafios acerca do processo de tratamento de incidentes de segurança; fatores

motivadores para desenvolvimento da ferramenta . Em seguida, descrevemos a arquitetura

e funcionamento da ferramenta TRAIRA (seção 3), bem como os resultados obtidos

mediante sua utilização em ambientes reais (seção 4). Por fim, discutimos trabalhos correlatos

quanto à automatização do processo de tratamento de incidentes de segurança na

seção 5 e apresentamos as considerações finais e trabalhos futuros na seção 6.

2. Fases e desafios no tratamento de incidentes de segurança

O guia para tratamento de incidentes de segurança do NIST (do inglês, National Institute

of Standards and Technology) [Scarfone et al. 2008] decompõe o processo de resposta a

incidentes em quatro fases: Preparação, Detecção e Análise, Contenção, Mitigação e

Recuperação e Ações Pós-Incidente. A fase de Preparação envolve o estabelecimento e

treinamento de um grupo de resposta a incidentes, aquisição de ferramentas e recursos necessários,

armazenamento dos registros de atividades dos sistemas para futuras auditorias

etc. A fase de Detecção e Análise visa detectar ou identificar a existência de um incidente.

A fase Contenção, Mitigação e Recuperação, por sua vez, objetiva evitar que os efeitos

do incidente se propaguem ou afetem outros recursos da rede, e restaurar o funcionamento

normal dos serviços afetados. Por fim, a etapa Ações Pós-Incidente consiste em avaliar o

processo de tratamento de incidentes e verificar a eficácia das soluções adotadas.

Cada uma destas fases requer ações específicas de mitigação ou controle. Por

exemplo, na fase de detecção e análise, deve-se registrar os recursos afetados (no caso

de incidentes contra a organização) ou a origem do incidente (no caso de incidentes

originados na organização). Na fase de contenção e mitigação deve-se isolar os sistemas

diretamente relacionados ao incidente e efetuar o tratamento do recurso em questão

(desinfecção de uma máquina contaminada com vírus/worm, remoção de um artefato malicioso,

recuperação de uma página web modificada, etc). No entanto, alguns serviços

comumente utilizados na configuração de redes, a exemplo do NAT e DHCP, podem dificultar

consideravelmente a consecução dessas ações corretivas.

A técnica de NAT visa traduzir os endereços IP utilizados na rede interna em um

endereço IP (ou faixa de endereços) utilizado na rede externa (Internet). Os endereços IP

internos são, portanto, desconhecidos dos equipamentos externos, tal qual o número de

um ramal de um telefone é escondido quando efetuada uma ligação via PABX. Assim, a

rede externa desconhece o verdadeiro emissor do pacote. No que tange ao tratamento de

incidentes de segurança, a principal dificuldade adicionada pelo NAT consiste em deter-

31


minar com precisão o endereço IP interno que foi traduzido no endereço IP externo, uma

vez que as notificações de incidentes recebidas de fontes externas (e.g. outros CSIRTs)

contêm apenas o endereço IP externo.

Outro agravante reside no uso disseminado do Protocolo de Configuração

Dinâmica de Hosts (DHCP) [Droms 1997], que permite a um host obter endereço(s) IP, e

outros parâmetros de configuração da rede, automaticamente. Em uma rede com DHCP, é

possível que um mesmo dispositivo possua diferentes endereços IP ao longo do dia, da semana

ou do mês, a depender da política de tempo de concessão (lease time) utilizada. Por

isso, limitar a identificação da máquina a um endereço IP pode ser ineficaz ou produzir

resultados errôneos (o que seria bastante prejudicial em caso de bloqueio automatizado da

máquina comprometida). Portanto, atualmente considera-se mais adequada a utilização

do endereço MAC (Media Access Control) como identificador único do host.

Um terceiro desafio para o tratamento de incidentes é a falta de gerenciamento

dos registros de atividades (logs) de dispositivos. Esses registros são de grande valia

quando da ocorrência de um incidente, pois auxiliam a auditoria dos sistemas afetados.

Não obstante, a quantidade, volume e variedade dos logs de segurança dos sistemas têm

crescido bastante, comprometendo e, por vezes, até inviabilizando, a investigação de

incidentes de segurança gerados por uma instituição. Essa investigação consiste geralmente

em efetuar buscas nos logs do dispositivo de NAT por uma ocorrência do IP e

porta listados na notificação e cuja data e hora estejam em concordância com os dados.

Vale salientar que, considerando os entraves supracitados, o processo de tratamento de

incidentes de segurança, em muitos casos, tende a ser interrompido nessa etapa. Portanto,

a automatização adequada dessa etapa é de fundamental importância para o tratamento

efetivo de incidentes de segurança em tempo hábil.

3. TRAIRA: uma ferramenta para Tratamento Automatizado de Incidentes

de Rede

O TRAIRA é um programa que atua em todas as fases do tratamento de incidentes (a

saber, preparação, detecção e análise, contenção, mitigação e recuperação e ações pósincidente

[Scarfone et al. 2008]) de forma que a detecção e contenção da máquina interna

causadora do incidente são totalmente automatizadas. Na fase de preparação destacam-se

dois recursos requeridos pelo TRAIRA: i) a configuração do serviço de logging remoto

do equipamento de NAT e ii) a utilização de um sistema de registro sobre a atribuição de

IPs, associando-os aos endereços físicos dos dispositivos de rede: os endereços MAC.

Já na fase de detecção e análise, o TRAIRA utiliza os recursos configurados anteriormente

para automaticamente extrair as informações relevantes de uma notificação;

buscar por evidências nos logs do dispositivo de NAT que informem o(s) IP(s) interno(s)

responsável(veis) pela notificação recebida; associar o endereço IP interno a um endereço

MAC da máquina, de forma que sua identificação seja única; gerar relatórios e estatísticas

sobre os incidentes recebidos; e responder à organização que reportou o incidente. A fase

de contenção implementa políticas de cessação da atividade maliciosa através do isolamento

da máquina comprometida como, por exemplo, bloqueio no switch gerenciável

ou roteador mais próximo. Ao final do tratamento de uma notificação, o TRAIRA gera

uma resposta automática à organização que reportou o incidente e também um relatório

detalhado para a equipe de apoio a fim de que as medidas cabíveis sejam aplicadas. No

32


Figura 1. Visão geral da arquitetura do TRAIRA

âmbito desse artigo, serão enfatizadas as fases de preparação e detecção e analise e alguns

aspectos relacionados à contenção.

No nosso contexto e em diversas outras instituições, há utilização disseminada

do Request Tracker (RT) [BestPractical 2011] e como sistema de helpdesk e tratamento

inicial de incidentes. A fim de preservar o conhecimento e a utilização dessas ferramentas,

o TRAIRA foi idealizado como um aprimoramento do RT através de extensões específicas

para o tratamento automatizado de incidentes em redes. Tal decisão de projeto reduziu o

tempo e custo de desenvolvimento, permitindo a reutilização de diversas funcionalidades

existentes nessas ferramentas (autenticação, backup, atualização) e da própria base de

incidentes de segurança pré-existente. Além disso, isso facilita a adoção do TRAIRA por

outras instituições interessadas em incrementar a automatização dos procedimentos de

tratamento de incidentes.

Na subseção seguinte, a arquitetura e funcionamento do TRAIRA será apresentada

em maiores detalhes.

3.1. Arquitetura do TRAIRA

A concepção do TRAIRA foi estruturada em uma arquitetura modular, apresentada na

Figura 1. Nessa figura, os componentes em formato de elipse representam os módulos que

foram desenvolvidos como parte do TRAIRA e os componentes em formato de retângulo

representam programas ou recursos externos necessários ao funcionamento do TRAIRA.

Os cinco módulos do TRAIRA são: Parser, NAT Mapping, IP2MAC, Post-Detection e

Containment. A seguir, apresentamos uma breve descrição das funcionalidades desses

módulos.

• Parser: Responsável pelo recebimento da notificação e pela extração das

informações essenciais ao tratamento do incidente: endereço IP e porta de origem,

data e horário.

• NAT Mapping: Utiliza as informações extraídas pelo parser e realiza

uma busca nos logs do dispositivo de NAT para associar a tupla

a um endereço IP interno, responsável de

fato pelo incidente.

33


• IP2MAC: aqui é feita a associação do IP interno ao endereço MAC da máquina.

Esse passo é importante em instituições que utilizam o DHCP, pois um IP pode

ter sido usado por mais de uma máquina ao longo do tempo.

• Post-Detection: Responsável pela extração de dados da notificação e do tratamento

realizado a fim de gerar estatísticas sobre os incidentes, gerar relatórios

à equipe de helpdesk (para, por exemplo, efetuar o isolamento e desinfecção da

máquina) e responder à instituição que reportou o incidente.

• Containment: Neste módulo é feito o isolamento do host que causou o incidente

para evitar que ele continue com a atividade maliciosa na rede ou afete outros

recursos.

O TRAIRA foi desenvolvido como uma extensão do RT, permitindo que o tratamento

dos incidentes de segurança seja feito tanto pela interface web, onde o usuário

fornece manualmente a notificação do incidente, quanto via e-mail quando a organização

que reporta o incidente envia uma mensagem para um endereço de e-mail especialmente

designado para este fim. Foi utilizada a linguagem de programação Perl, com a qual o

próprio RT foi implementado. Em sua primeira versão, possui aproximadamente 2.500

linhas de código entre interfaces de usuário, núcleo da aplicação, módulos de interface

com recursos externos (logs, tabela de endereços MAC, etc) e demais componentes. O

TRAIRA é distribuído sob a licença GPLv2 ou superior 1 e encontra-se disponível para

download em [TRAIRA 2011].

Tratamento de Incidentes no TRAIRA

O tratamento de incidentes automatizados pelo TRAIRA segue um fluxo de trabalho composto

pelas etapas a seguir.

1. Uma entidade (interna ou externa) submete uma notificação ao TRAIRA reportando

um incidente de segurança. Essa notificação deve conter evidências suficientes

para comprovar a atividade maliciosa e incluir, no mínimo, o endereço

IP, porta de origem, data, hora e timezone da ocorrência. A entidade que reporta

incidentes pode ser materializada nos CSIRTs (e.g., CAIS, CERT.br), em sensores

de monitoramento de atividades maliciosas (IDSs, honeypots etc) ou até mesmo

em usuários que submetem incidentes através da interface web;

2. O TRAIRA verifica se existe um parser específico para o tipo de notificação recebido.

Em caso afirmativo, o parser extrai os dados importantes da notificação e

o tratamento avança para a detecção da máquina interna. Caso inexista um parser

apropriado, a notificação permanece em aberto no RT aguardando pelo tratamento

manual da equipe de segurança;

3. A partir dos dados extraídos da notificação (tupla

) é feita uma busca nos logs do dispositivo

de NAT para determinar o respectivo endereço IP da máquina da rede

interna;

4. De posse do endereço IP da máquina causadora do incidente, é realizada uma

busca para descobrir o respectivo endereço MAC;

1 GPL é uma sigla usada para GNU Public License, uma licença de software livre especificada pela Free

Software Foundation.

34


5. Caso o módulo de Contenção esteja habilitado para executar automaticamente, a

máquina em questão (representado pelo MAC obtido na etapa anterior) é bloqueado

ou movido para uma Rede Virtual (VLAN) de quarentena;

6. De posse do endereço MAC e do resultado do módulo de Contenção, o TRAIRA

notifica a equipe de helpdesk para tomada das medidas cabíveis;

7. Uma resposta automática (e-mail) é enviada à instituição produtora da notificação

para informar a identificação da máquina causadora do incidente e o início dos

procedimentos de tratamento e recuperação.

Diante do exposto, o TRAIRA automatiza completamente o processo inicial de

tratamento de incidentes de segurança. Cabe ainda ao administrador executar as providências

necessárias para resolução do incidente, a exemplo da desinfecção de máquinas

contaminadas com vírus/worm ou aplicar as medidas administrativas cabíveis à uma

violação de copyright. Vale salientar, entretanto, que, em virtude do considerável volume

de notificações recebidos pelas instituições e a carência de pessoal especializado

e em número suficiente para responder às notificações, a etapa de detecção tende, muitas

vezes, a nem ser iniciada. As etapas descritas acima são executadas de forma on-line.

Portanto, assim que um incidente é reportado ao TRAIRA, seu tratamento tem início imediato.

Assim, o TRAIRA proporciona uma importante contribuição para o processo de

tratamento e resposta aos incidentes de segurança de uma instituição.

As subseções seguintes visam detalhar duas etapas importantes do tratamento do

incidente pelo TRAIRA: detecção e isolamento do host responsável pelo incidente.

3.2. Detecção do host responsável pelo incidente

Apesar de suas desvantagens [Egevang and Francis 1994, Seção 4], o NAT é uma técnica

bastante utilizada pelas instituições de ensino e pesquisa conectadas à Internet, principalmente

pela possibilidade de economia de endereços IPv4 e ocultação da topologia da

rede interna. Por outro lado, sua utilização traz implicações no tratamento de incidentes

de segurança, uma vez que o endereço listado na notificação não representa diretamente a

máquina da rede interna que realmente causou o incidente. Nesse caso, faz-se necessário

um mapeamento entre o IP e porta listados na notificação e o IP interno que causou o

incidente. Para realizar esse mapeamento, o módulo NATMapping utiliza as informações

extraídas pelo Parser e as correlaciona aos logs do(s) dispositivo(s) de NAT, retornando

o(s) IP(s) internos responsáveis pelo incidente.

O processo de correlacionar essas duas entradas, no entanto, não é uma tarefa trivial.

É necessário considerar a grande diversidade de dispositivos de NAT disponíveis

(cada um deles pode produzir logs de forma específica), o grande volume de dados a serem

processados e, ainda pior, a correspondência entre a data/horário que é listado na

notificação e aqueles listados nos logs. Para lidar com este último problema, a ferramenta

incorpora a definição de um valor, configurável, de tolerância temporal entre os horários

da notificação e dos logs. O valor mais adequado para uma instituição depende das características

da rede. Um fator obrigatório a ser observado nessa definição é a relação

de máquinas da rede interna por IP de NAT: quanto mais máquinas são associadas a um

único NAT, maior será a taxa de reaproveitamento de portas e, consequentemente, menor

poderá ser a tolerância à diferença nos relógios.

Para tratar da diversidade na utilização de dispositivos de NAT nas instituições,

35


e, até mesmo internamente à uma instituição (com diferentes dispositivos de NAT

por segmento de rede), o módulo NATMapping foi desenvolvido de forma que seja

possível definir um dispositivo de NAT para cada segmento de rede (levando-se em

consideração a sobreposição entre segmentos) e um dispositivo padrão a ser usado

caso não haja uma definição específica para determinado segmento de rede. Por

exemplo, o administrador pode definir que a rede 200.128.99.0/24 utiliza o

ASA/Cisco, já a rede 200.128.196.0/23 utiliza IPTables/Netfilter com exceção

da sub-rede 200.128.197.0/28 que também utiliza ASA/Cisco e, finalmente, a

rede 200.128.199.0/24 não utiliza NAT. Note que o mapeamento acima é sobre

uma visão externa ou, mais especificamente, considerando os dados da notificação.

Essa flexibilidade de configuração permite, por exemplo, definir as redes privadas

[Rekhter et al. 1996] como “sem NAT”, o que viabiliza também o tratamento de

incidentes internos (detectados a partir de sensores posicionados na rede interna).

3.3. Isolamento do host responsável pelo incidente

A etapa de isolamento efetua a contenção do host detectado anteriormente para evitar

que ele continue com a atividade maliciosa na rede ou comprometa outros recursos.

Esta contenção pode acontecer por diversas vias: desligamento da máquina, remoção

do cabo de rede, bloqueio no dispositivo de rede gerenciável mais próximo etc. Essa

última alternativa é mais interessante do ponto de vista de automatização. Em contrapartida,

o inconveniente é que o usuário desconhece a razão pela qual sua estação está

sem comunicação na rede. Nesse sentido, uma técnica mais apropriada, proposta em

[Kaiser et al. 2006], consiste em direcionar o tráfego de rede do host comprometido para

uma VLAN de quarentena. Nesta VLAN, as requisições do usuário seriam encaminhadas

a uma página web da instituição que informa sobre o bloqueio preventivo da máquina e

ações que este deve tomar (e.g., contactar imediatamente o helpdesk).

Tal abordagem de contenção tem sido reiteradamente considerada na literatura,

principalmente, através do uso de ferramentas como firewall e IDS. Não obstante, essa

abordagem mostra-se ineficiente do ponto de vista de propagação da atividade maliciosa

na rede local do host detectado, pois, para os segmentos diretamente conectados, os pacotes

não trafegam pelo firewall ou IDS. De fato, o bloqueio mais eficaz pode ser realizado

na camada 2 (Layer 2), por exemplo, nos switches gerenciáveis ao qual o host comprometido

está conectado. Devido à possível variação no ambiente de rede das instituições,

o TRAIRA considera três estratégias possíveis para etapa de isolamento do processo de

tratamento de um incidente: i) bloqueio do host no equipamento de firewall, ii) bloqueio

no switch gerenciável mais próximo ao host detectado, iii) direcionamento do host para

uma VLAN de quarentena.

Cada uma dessas estratégias possui vantagens, desvantagens e requisitos de

implantação específicos. Portanto, a decisão final acerca da política mais apropriada depende

das características de cada instituição. A opção mais simples consiste no bloqueio

do host no equipamento de firewall. Essa estratégia mostra-se eficaz para contenção de

ataques cujo destino seja outra instituição ou esteja em outro segmento de rede ao qual

host detectado pertence. Também possibilita a criação de regras para redirecionar de

forma transparente o tráfego oriundo do host comprometido para uma página web, a qual

informa ao usuário o bloqueio de sua máquina e explica a razão para tal ação. Contudo,

não atende ao tratamento da propagação de atividade maliciosa na rede local. O requisito

36


de implantação consiste basicamente no suporte à criação de filtros de pacotes e regras

de redirecionamento baseadas em endereço MAC no firewall da instituição (característica

comumente encontrada nos firewalls mais usados).

Outra variante mais completa consiste em direcionar o tráfego do host comprometido

para uma VLAN de quarentena no nível da camada de enlace, o que evita o

problema supracitado de atividade maliciosa na rede local e simplifica sobremaneira o

procedimento de contenção. Entretanto, esta opção tem requisitos de implantação mais

complexos. É necessário que a máquina esteja conectada em algum switch que possibilite

a criação de filtros (ACLs) para modificar a VLAN baseado no endereço MAC de origem

dos pacotes. Tal funcionalidade é também conhecida como MAC-based VLAN. Todavia,

em pesquisas realizadas, constatamos que apenas um fabricante de equipamentos de rede

implementa essa funcionalidade. Considerando a efetividade dessa solução, decidimos

reorientar nossos procedimentos de compra para a aquisição de novos equipamentos com

esta funcionalidade.

4. Avaliação experimental e resultados obtidos

Desde a implantação do TRAIRA na rede da UFBA em setembro de 2010, todas as

notificações de incidentes de segurança recebidas pela equipe (sejam aquelas enviadas

por ferramentas de monitoramento interno, tais como honeypots, IDSs, ou as enviadas

pelos grupos de segurança, tais como CAIS e CERT.br) tem sido tratados automaticamente.

Por exemplo, as notificações de incidente relacionadas ao projeto Honeypot.BR

do CERT.br [Honeynet.BR 2011], do qual a UFBA participa, correspondem a uma média

diária de 5 a 10 notificações, e cada notificação contém cerca de 20 incidentes.

Um recurso fundamental aos grupos de resposta a incidentes de segurança

(CSIRTs) consiste na produção de estatísticas relevantes ao contexto de tratamento

de incidentes e tomada de decisão para a alta administração [Arvidsson et al. 2001].

A obtenção de tais dados auxiliam os CSIRTs a detectar tendências, prever futuros

ataques em grande escala e direcionar atividades, dentre outros. A implementação

atual do TRAIRA fornece estatísticas importantes geradas automaticamente a partir de

informações retiradas da notificação recebida e do tratamento efetuado. A seguir, discutiremos

os resultados obtidos a partir dessas estatísticas.

Situação e taxa de tratamento dos incidentes. O gráfico quantitativo (Figura 2)

pode ser utilizado para aferir a efetividade do tratamento de incidentes de segurança na

instituição. Neste âmbito, são listados os incidentes reportados versus os que foram resolvidos.

No caso ideal, espera-se que a linha de incidentes resolvidos esteja o mais próximo

possível da linha dos incidentes reportados.

Tendo em vista que a rede da UFBA conta mais de 12.000 equipamentos, o tratamento

de todas essas notificações era extremamente custoso, do ponto de vista de alocação

de pessoal qualificado. Conforme pode ser visto na Figura 2 (extraída do TRAIRA),

desde o início de 2011, nossa instituição recebeu mais de 550 notificações, sendo que a

grande maioria delas foi tratada automaticamente pelo TRAIRA. Nesta figura, uma linha

representa os incidentes reportados, enquanto a outra indica quais destes incidentes foram

tratados automaticamente pelo TRAIRA. Portanto, a proximidade das linhas indica a

eficácia do uso da ferramenta no tratamento de incidentes de segurança.

37


Figura 2. Situação do tratamento de incidentes reportados a UFBA entre janeiro

a julho de 2011

Segmentação de incidentes por Rede Virtual (VLAN). Nossa rede institucional é estruturada

em VLANs a fim de estabelecer políticas de controle de acesso e segmentação

de tráfego. Atualmente, diversas instituições têm adotado esse modelo como facilitador

da administração de grupos de usuários e recursos em redes de campus e de larga escala.

A Figura 3 apresenta tal gráfico para a UFBA no período de janeiro a julho de

2011. Esse gráfico ressalta as VLANs (cujos nomes reais foram sombreados por questões

de segurança e privacidade) que mais impactam na geração de incidentes de segurança,

o que permite direcionar medidas de prevenção específicas. Tais dados são fundamentais

para redes de campus ou extensas, visto que há forte tendência nas instituições em

administrar redes por meio de uma estruturada combinada de VLANs.

Figura 3. As dez principais VLANs geradoras de incidentes na rede UFBA (janeiro

a julho de 2011)

Em nosso ambiente institucional, a análise das estatísticas produzidas pelo

TRAIRA permitiram a identificação precisa das principais sub-redes geradoras de

incidentes. Com base nesse resultado, pôde-se iniciar um trabalho específico e direcionado

aos usuários, dirigentes e administradores destas sub-redes visando identificar o

motivo da atividade maliciosa e implantar estratégias de controle e mitigação.

38


Identificação de máquinas reincidentes. Esta métrica indica a taxa de reincidência na

geração de incidentes em determinado host. Pode ser usada como indicador qualitativo

do tratamento e pós-tratamento de incidentes. A interpretação desse dado pode levantar

diversas hipóteses, tais como: a fase de isolamento e desinfecção está sendo ineficaz; no

caso dos incidentes de vírus/worm pode indicar inexperiência ou desleixo do usuário no

uso do recurso, propiciando novas infecções com facilidade; dentre outros.

A automatização proporcionada pelo TRAIRA simplifica o procedimento de tratamento

dos principais incidentes, pois a equipe de helpdesk apenas recebe o endereço

MAC dos dispositivos suspeitos identificados pelo sistema e realiza o tratamento das

máquinas. A resposta às notificações que envolvem contenção automática é praticamente

instantânea, quando comparada à abordagem manual em que cada incidente era resolvido

em cerca de 30 minutos. Tal demora ensejava, por vezes, o não atendimento de algumas

notificações por restrições de tempo da equipe. A economia de tempo na identificação e

contenção da máquina comprometida representa um ganho qualitativo fundamental frente

às instituições externas que reportam incidentes, bem como em celeridade e precisão em

relação ao cessamento da propagação de atividades maliciosas na rede interna.

5. Trabalhos correlatos

A literatura apresenta uma série de trabalhos que versam sobre a definição de políticas

de segurança e tratamento dos incidentes [Ceron et al. 2009, Scarfone et al. 2008,

Werlinger et al. 2007, Lundell 2009], porém, no melhor de nosso conhecimento, poucos

deles têm se preocupado com a automatização do procedimento a fim de minorar custos

e reduzir o tempo de tratamento dos incidentes.

De maneira geral, a maioria dos CSIRTs usa sistemas de helpdesk customizados

(também conhecidos como sistemas de chamados) para tratar seus incidentes, a fim de

melhor atender às demandas do processo de tratamento de incidentes [Kaiser et al. 2006].

Dois sistemas bem conhecidos são o Request Tracker (RT) [BestPractical 2011] e o Open

Source Ticket Request System (OTRS) [OTRS 2011]. Existe ainda uma extensão para

o RT chamada Request Tracker for Incident Response (RTIR), que se concentra na resposta

aos incidentes de segurança (classificação de incidentes, geração de estatísticas,

etc.). Até nosso conhecimento, nenhuma dessas ferramentas, no entanto, atua especificamente

na automatização do processo de tratamento e resposta a incidentes. Outros

frameworks e ferramentas específicos incluem o SIRIOS [KLINGMÜLLER 2005], que

apresenta algumas funcionalidades interessantes, como a de gerenciamento de contatos de

segurança de uma instituição e a possibilidade de troca de informações de segurança com

outros CSIRTs. O SANS Institute desenvolveu o Orion [Jarocki 2010], uma distribuição

em Live-CD baseada no BackTrack para o tratamento de incidentes de segurança. Apesar

de prover boas ferramentas para tratamento, o Orion ainda lida precariamente com a

contenção de incidentes em redes.

Em [Kaiser et al. 2006] os autores propõem um gerenciamento semiautomatizado

dos incidentes de segurança, onde os incidentes menos importantes

são tratados pelo próprio usuário envolvido, ao passo que os incidentes mais sérios são

encaminhados para uma equipe de segurança qualificada. Para possibilitar ao usuário

não-especializado tratar um incidente, a instituição deve prover documentação suficiente

e compreensível sobre as questões técnicas e organizacionais relacionadas. Os autores

39


propõem um sistema de gerenciamento de incidentes, o PRISM (Portal for Reporting

Incidents and Solution Management), que consiste em três componentes. O primeiro

recebe as notificações no formato IDMEF 2 . O segundo componente contém a lógica

para tratamento de incidentes e medidas corretivas relacionadas. Por fim, o terceiro

componente é responsável pela geração de páginas web dinâmicas que informam aos

usuários as soluções indicadas para o incidente reportado. Entretanto, essa solução não

contempla o tratamento de notificações externas, as quais requerem, por exemplo, a

resolução de mapeamento entre o NAT efetuado e as máquinas internas.

Farnham [Farnham 2009] apresenta uma solução proprietária da Cisco, chamada

Cisco Security Agent (CSA), e seu impacto nas várias fases do tratamento de incidentes.

O CSA é um sistema de prevenção de intrusão baseado em hosts (HIPS, do inglês Host

Intrusion Prevention System) que pode ser usado tanto em servidores quanto em máquinas

clientes. No CSA, cada host possui um agente e um centro de gerenciamento, que define

as políticas de segurança do host e centraliza o registro de eventos (logging). O software é

baseado em regras e examina as atividades do sistema (no agente) e o tráfego de rede a fim

de diferenciar comportamentos normais daqueles indicadores de uma anomalia ou ataque.

O autor analisa a adequação do CSA nas etapas de tratamento de um incidente, usando

como estudo de caso o software malicioso Conficker 3 . As desvantagens dessa solução

estão relacionados, principalmente, ao alto custo de implantação e de sua inadequação a

ambientes heterogêneos de rede.

Em [Ceron et al. 2010], propõe-se uma arquitetura voltada para detecção e

contenção automatizada de máquinas participantes de botnets. A arquitetura i) coleta arquivos

binários maliciosos (e.g., através de honeypots), ii) extrai informações dos binários

coletados (tais como tentativas de acesso a endereços IP suspeitos), iii) utiliza essas

informações na geração de assinaturas e monitoramento do tráfego de rede da instituição,

e iv) prevê a contenção automatizada dessas máquinas por meio, por exemplo, do bloqueio

no firewall daqueles endereços IPs identificados. Até nosso conhecimento, o trabalho não

considera a tradução automática de endereços via NAT e DHCP, enfatizando o tratamento

de um tipo específico de incidente: máquinas participantes de botnets. Outra limitação

reside no fato da contenção basear-se apenas no endereço IP do host detectado e ser realizada

no firewall da instituição. Tal bloqueio, infelizmente, não previne a propagação de

atividade maliciosa na rede local. Por essas razões, o TRAIRA utiliza o endereço MAC

como identificador de host (que, apesar da possibilidade de alteração, requer conhecimentos

avançados para efetuá-la) e permite a escolha da estratégia de contenção: bloqueio no

equipamento gerenciável mais próximo ou direcionamento para VLAN de quarentena.

2 Motivado pela necessidade de se definir um padrão de arquitetura e comunicação para Sistemas de

Detecção de Intrusão (IDS, do inglês Intrusion Detection System), o IETF, através do grupo de trabalho

IDWG (Intrusion Detection Working Group) especificou o protocolo IDXP (Intrusion Detection Exchange

Protocol) [Feinstein and Matthews 2007] e um formato para troca de alertas entre IDSs, denominado ID-

MEF (Intrusion Detection Message Exchange Format) [Debar et al. 2007]. Apesar de originalmente concebidos

para uso em sistemas IDS, esses padrões também são bastante utilizados para notificações de

incidentes de segurança.

3 O Conficker, também conhecido como Downadup ou Kido, é um worm que ficou bastante conhecido

pelo número de sistemas que conseguiu infectar ao redor do mundo. Ele explora uma vulnerabilidade

conhecida do MS Windows Server (MS08-067) e pode comprometer uma série de versões do Windows

[CWG 2011].

40


6. Considerações finais

Este trabalho apresentou o projeto, implementação e avaliação de uma ferramenta para

automatizar o processo de tratamento de incidentes de segurança em redes de campus

e de larga escala. A ferramenta atua em todas etapas do tratamento de um incidente,

o que permite melhor aproveitamento dos recursos humanos destinados à gestão e

operacionalização da segurança da informação.

Os requisitos de hardware e software necessários à implantação e execução dessa

solução são triviais e muito pouco onerosos, o que reforça a viabilidade de sua aplicação

prática em ambientes complexos e heterogêneos, tais como instituições acadêmicas de

ensino e pesquisa, governamentais ou corporações privadas.

Atualmente, o TRAIRA encontra-se em produção e uso efetivo na rede de campus

da UFBA desde setembro de 2010, sendo usado como ferramenta primária no tratamento

do ciclo de incidentes de segurança das notificações recebidas pela instituição e produzidas

internamente. Em verdade, baseados em nossas demandas e na situação existentes

em outras instituições parceiras, consideramos que os problemas solucionados pela

ferramenta são úteis a diversas instituições. Assim, nossa intenção é compartilhar nossa

experiência no desenvolvimento e uso dessa ferramenta a fim de aprimorar os processos

de tratamento de incidentes de segurança em outras instituições brasileiras e, como

consequência, estabelecer parcerias de pesquisa e inovação com potenciais usuários e desenvolvedores

interessados.

Como trabalhos futuros, destacam-se a necessidade de otimização no armazenamento

e consulta dos logs, principalmente das traduções NAT (e.g. através de informações

resumidas em bancos de dados); adoção de padrões para notificações (e.g. IDMEF)

no parser; extensão para outros mapeamentos de endereço de rede, como no caso do

uso de proxy de cache http, onde uma requisição HTTP é intermediada pelo proxy e

assim o endereço de origem visto no servidor remoto é o endereço do proxy e não

do cliente original; adicionar suporte a outros dispositivos de NAT, por exemplo o PF-

Sense/FreeBSD.

7. Agradecimentos

Este trabalho foi parcialmente financiando pela FAPESB.

Referências

Arvidsson, J., Cormack, A., Demchenko, Y., and Meijer, J. (2001). TERENA’S Incident

Object Description and Exchange Format Requirements. RFC 3067 (Informational).

Disponível em: http://www.ietf.org/rfc/rfc3067.txt. Último acesso em Julho de 2011.

BestPractical (2011). RT: Request Tracker. Disponível em:

http://www.bestpractical.com/rt/. Último acesso em Julho de 2011.

Ceron, J., Boos Jr, A., Machado, C., Martins, F., and Rey, L. (2009). O processo de

tratamento de incidentes de segurança. IV Workshop de TI das IFES.

Ceron, J., Granville, L., and Tarouco, L. (2010). Uma Arquitetura Baseada em Assinaturas

para Mitigação de Botnets. In X Simpósio Brasileiro em Segurança da Informação e

de Sistemas Computacionais (SBSEG’10), pages 105–118. SBC.

41


CERT.Bahia (2010). Estatísticas do CERT.Bahia. Disponível em:

http://www.certbahia.pop-ba.rnp.br/Estatisticas. Último acesso em Julho de 2011.

CWG (2011). Conficker Working Group. Disponível em:

http://www.confickerworkinggroup.org/wiki/. Último acesso em Julho de 2011.

Debar, H., Curry, D., and Feinstein, B. (2007). The Intrusion Detection Message

Exchange Format (IDMEF). RFC 4765 (Experimental). Disponível em:

http://www.ietf.org/rfc/rfc4765.txt. Último acesso em Julho de 2011.

Droms, R. (1997). Dynamic Host Configuration Protocol. RFC 2131 (Draft Standard).

Updated by RFCs 3396, 4361, 5494.

Egevang, K. and Francis, P. (1994). The IP Network Address Translator (NAT). RFC

1631 (Informational). Obsoleted by RFC 3022.

Farnham, G. (2009). Cisco Security Agent and Incident Handling. SANS Institute InfoSec

Reading Room.

Feinstein, B. and Matthews, G. (2007). The Intrusion Detection Exchange

Protocol (IDXP). RFC 4767 (Experimental). Disponível em:

http://www.ietf.org/rfc/rfc4767.txt. Último acesso em Julho de 2011.

Honeynet.BR (2011). Brazilian Honeypots Alliance. Disponível em:

http://www.honeypots-alliance.org.br/. Último acesso Julho de 2011.

Jarocki, J. (2010). Orion Incident Response Live CD.

Kaiser, J., Vitzthum, A., Holleczek, P., and Dressler, F. (2006). Automated resolving of security

incidents as a key mechanism to fight massive infections of malicious software.

In GI SIDAR International Conference on IT-Incident Management and IT-Forensics

(IMF 2006), volume LNI P-97, pages 92–103.

KLINGMÜLLER, T. (2005). SIRIOS: A Framework for CERTs. FIRST Conference on

Computer Security Incident Handling.

Lundell, M. (2009). Incident Handling as a Service. SANS Institute InfoSec Reading

Room.

OTRS (2011). Open source trouble ticket system. Disponível em: http://www.otrs.org/.

Último acesso em Julho de 2011.

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear, E. (1996). Address

Allocation for Private Internets. RFC 1918 (Best Current Practice). Disponível em:

http://www.ietf.org/rfc/rfc1918.txt. Último acesso em Julho de 2011.

Scarfone, K., Grance, T., and Masone, K. (2008). Computer Security Incident Handling

Guide. NIST Special Publication, 800–61.

TRAIRA (2011). TRAIRA – Tratamento de Incidentes de Rede Automatizado. Disponível

em: http://www.pop-ba.rnp.br/files/sw/rt-traira.tgz. Último acesso em Julho

de 2011.

Werlinger, R., Botta, D., and Beznosov, K. (2007). Detecting, analyzing and responding

to security incidents: a qualitative analysis. In Proceedings of the 3rd symposium on

Usable privacy and security, pages 149–150. ACM.

42


Uma Ontologia para Mitigar XML Injection

Thiago M. Rosa, Altair O. Santin, Andreia Malucelli

Programa de Pós-Graduação em Informática (PPGIa) – Pontifícia Universidade Católica

do Paraná (PUCPR) – Curitiba – PR – Brasil

{tmattosr,santin,malu}@ppgia.puc.br

Abstract. The underlying technologies used by web services bring well-known

vulnerabilities from other domains to this new environment. Anomaly-based

intrusion detection approaches produce high false positive rates, while

signature-based intrusion detection approaches do not detect attack

variations. This paper presents a novel hybrid attack detection engine that

brings together the main advantages of these classical detection approaches.

An ontology is applied as a strategy-based knowledge-base to assist mitigating

XML injection attacks, while maintaining low false positive detection rates.

Resumo. As tecnologias utilizadas em web services trazem vulnerabilidades

conhecidas em outros domínios para este novo ambiente. As abordagens de

detecção de intrusão baseadas em anomalia geralmente produzem alta taxa

de falsos positivos, enquanto que abordagens baseadas em assinatura não

detectam variações de ataque. Este artigo apresenta um mecanismo híbrido

de detecção de ataques que agrega as principais vantagens destas abordagens

clássicas. Aplica-se uma ontologia como a base de conhecimento de ataques

baseada em estratégia (sequencia encadeada de ações) para mitigar ataques

de XML injection, mantendo baixas as taxas de falsos positivos.

1. Introdução

Web services vem sendo usados crescentemente em sistemas distribuídos na internet, já

que provêm um meio padrão de interoperabilidade entre diferentes aplicações, que

podem estar executando em uma variedade de plataformas e frameworks [Booth et al.

2004]. Entretanto, as tecnologias utilizadas por web services (e.g. SOAP − Simple

Object Access Protocol, HTTP − Hypertext Transfer Protocol e XML − Extensible

Markup Language) favoreceram a exploração de vulnerabilidades conhecidas neste

novo ambiente.

De acordo com o relatório anual de segurança do Open Web Application

Security Project [OWASP 2009], ataques de injection estariam entre as

vulnerabilidades mais exploradas em 2010. Esta estatística se confirma no ranking das

25 falhas de software mais perigosas [CWE e SANS 2010], pois as duas primeiras

posições da lista são relacionadas a injections.

Este artigo aborda especialmente ataques de XML injection − XML Cross-Site

Scripting e XPath/XQuery injection. XML injections são ataques que produzem alguma

mudança nos componentes internos de um documento XML tentando comprometer

aplicações que executam web services. Isto pode ser alcançado inserindo conteúdo

malicioso em uma mensagem XML, por exemplo, através da inserção de caracteres

XML inválidos [CWE 2011].

Uma maneira de proteger web services de ataques de injection é através de

43


sistemas de detecção baseados em assinaturas [Siddavatam e Gadge 2008]. Uma

assinatura é um payload que identifica um ataque através de um conteúdo malicioso.

Sistemas de detecção baseados em assinaturas normalmente produzem baixa taxa de

erros de classificação dos ataques – conhecidos como falsos positivos. Entretanto, uma

limitação importante da detecção de ataques baseada em assinaturas é que esta

abordagem não detecta ataques desconhecidos (novos), mesmo que estes representem

pequenas variações de um payload conhecido.

Outra forma de proteger web services contra ataques de injection é através de

sistemas de detecção baseados em anomalias [Yee, Shin e Rao 2007], que aplicam uma

técnica normalmente baseada em algum tipo de comportamento (implementado como

um perfil). Por exemplo, os ataques podem ser modelados/classificados em duas classes

distintas, uma para comportamentos normais − contendo todas as ações esperadas para

tal perfil − e outra representando ataques, i.e., envolvendo ações que não são

consideradas normais. Técnicas de detecção baseadas em anomalias conseguem detectar

novos ataques, mas na maioria das vezes produzem alta taxa de falsos positivos (erros

de avaliação) na detecção.

A técnica de detecção baseada em assinaturas é a mais utilizada, porém, permite

ataques do tipo zero-day, que ocorrem quando uma vulnerabilidade (falha de software)

se torna publicamente conhecida antes que sua correção esteja disponível para ser

inserida na base de assinaturas do sistema de detecção [Zero Day Initiative 2011].

Independentemente de como uma vulnerabilidade se torna publicamente

conhecida, a efetividade de um ataque zero-day pode variar de horas até meses [Zero

Day Initiative 2011].

A abordagem de detecção clássica constrói sua base de assinaturas catalogando

os ataques independentemente um do outro. Neste caso, não é levado em consideração

que a estratégia (engine) de um ataque é similar para a maioria das categorias e que

geralmente só há variações no payload, gerado em função de alterações na estratégia de

cada ataque. Porém, os resultados desta mudança são suficientes para confundir a

abordagem de detecção por anomalias, produzindo alertas falhos (falsos positivos), ou

driblar a engine de detecção da abordagem por assinaturas.

O objetivo deste trabalho é modelar os ataques através de uma estratégia

representada por classes e seus relacionamentos em uma ontologia. Acredita-se que

conhecendo a estratégia de um ataque, que define o relacionamento semântico entre

elementos do mesmo, pode-se facilmente detectar variações nos payloads e, como

consequência, adicioná-los automaticamente à base de conhecimento da ontologia.

A contribuição desta proposta consiste em prover uma abordagem de sistema de

detecção para XML injection baseado em estratégia (XID), para também mitigar

ataques zero-day resultantes de variações dos ataques contidos na ontologia. Já que

ataques novos (desconhecidos) são derivados de estratégias conhecidas, deverá ser

observada uma baixa taxa de falsos positivos na detecção. Para este propósito

apresenta-se o sistema de detecção baseado em estratégia como uma abordagem híbrida

− suportando detecção baseada em anomalias, derivada da detecção baseada em

assinaturas. Aplica-se uma ontologia para construir a base de ataques de XML injection

contra web services.

O restante do artigo está organizado da seguinte forma: a seção 2 aborda

brevemente ontologia; a seção 3 explica como foi construída a ontologia baseada em

estratégia; a seção 4 apresenta a proposta (XID) e alguns cenários de avaliação; na

seção 5 são descritos alguns trabalhos relacionados e a seção 6 conclui o trabalho.

44


2. Ontologia

Uma ontologia descreve um vocabulário comum usando conceitos (objetos) e

propriedades (relacionamentos) que são importantes para um determinado domínio.

Esta descrição é alcançada através de um conjunto de definições que associam os

conceitos à linguagem humana, descrevendo seus significados e um conjunto de

axiomas (formais) que restringem a interpretação e o uso destes conceitos

[Konstantinou, Spanos e Mitrou 2008]. Por exemplo, no domínio “alunos de uma

universidade”, conceitos poderiam ser aluno, professor, curso, disciplina, etc. Os

relacionamentos poderiam ser “é aluno de”, “é professor de”, “é disciplina de”, etc.

Outro recurso de uma ontologia é permitir interoperabilidade entre sistemas

através de seu vocabulário comum, permitindo que inferências sejam feitas de acordo

com os axiomas pré-definidos [Dou, McDermott e Qi 2004]. Axiomas são definições,

expressas através de lógica de primeira ordem, que envolvem classes, instâncias,

relacionamentos e operadores lógicos. Axiomas são utilizados para representar uma

verdade reconhecida para um determinado domínio de conhecimento. Os mesmos são

avaliados por máquinas de inferência – software que faz deduções a partir do

conhecimento expresso em uma ontologia, com o intuito de derivar desta ontologia um

novo conhecimento. Tomando como exemplo o domínio de conhecimento “alunos de

uma universidade” citado acima, um axioma para tal domínio poderia ser “todo aluno

do curso de matemática é aluno da disciplina álgebra”, apresentado aqui em lógica de

primeira ordem:

“AlunoDisciplinaAlgebra ≡ ∃éAlunoDe.CursoMatematica”

De acordo com Gruber [1993], os critérios preliminares que devem ser levados

em consideração antes de se construir uma ontologia são clareza, coerência,

extensibilidade e um mínimo compromisso ontológico.

Observando esses critérios, algumas escolhas devem ser feitas quando se vai

construir uma ontologia. Por exemplo, definições de classes e axiomas devem restringir

o número de interpretações possíveis para satisfazer o critério da clareza. Porém,

minimizar o compromisso ontológico significa admitir vários possíveis modelos para

um domínio de conhecimento. Portanto, decisões de modelagem devem ser tomadas de

acordo com o objetivo da ontologia.

A principal vantagem de se utilizar ontologia para modelar dados é o fato desta

prover uma semântica explícita e formal. Além disto, a ontologia pode ser

compartilhada (utilizada em vários sistemas escritos em linguagens diferentes) e

reutilizada − adaptada para contemplar outros objetivos. Através do uso de inferências,

ontologias também podem prover informações sobre um determinado domínio que não

estejam explicitamente definidas na base de conhecimento [Konstantinou, Spanos e

Mitrou 2008]. Usando o exemplo do domínio de conhecimento “alunos de uma

universidade”, se existe um aluno do curso de matemática na base de conhecimento da

ontologia, a informação de que esse aluno está inscrito na disciplina álgebra não

precisaria ser manualmente adicionada na ontologia, pois esta informação seria

automaticamente inferida a partir de um axioma.

3. Ontologia Baseada em Estratégia

Para satisfazer os critérios propostos por Gruber [Gruber 1993] na construção da

ontologia, utilizou-se inicialmente a taxonomia de ataques apresentada pelo website da

CAPEC [CAPEC 2011]. A CAPEC descreve mecanismos utilizados para explorar

falhas de software de acordo com a perspectiva do atacante. Esta descrição é feita em

45


alto nível, por isto a ontologia foi refinada baseando-se também em algumas

ferramentas de teste de segurança (seção 4.1).

A ontologia proposta é composta de classes e propriedades (Fig. 1), instâncias

(Fig. 2) e axiomas. Para facilitar o entendimento, neste artigo utiliza-se somente uma

classe de ataques a web services (XMLInjection) e três subclasses (XPathInjection,

XQueryInjection e XSSInjection) para exemplificar a estratégia dos ataques. As duas

superclasses da ontologia são AttackAction e WebServicesAttack. AttackAction possui

subclasses contendo instâncias de ações suspeitas (payloads) capturadas na rede.

Figura 1. Diagrama de classes da ontologia

A classe WebServicesAttack possui subclasses representando categorias de

ataques a web services. Cada uma destas subclasses possui instâncias representando

assinaturas de ataques conhecidos. A assinatura de uma instância de ataque é

representada na ontologia por relacionamentos que a mesma tem com ações –

implementados através da propriedade hasAttackAction. Uma instância de ataque pode

ter uma ou mais ações e uma ação pode ser parte de várias instâncias de ataque.

Figura 2. Exemplos de instâncias da ontologia

Na ontologia, os axiomas definidos para uma classe (categoria de ataque)

restringem o número e o tipo de ações que as instâncias daquela classe terão. Além

disso, neste caso os axiomas também podem ajudar a máquina de inferência a deduzir se

um tipo de ataque ocorreu quando o padrão identificado (instância) ainda não está na

base de conhecimento da ontologia, permitindo que este novo conhecimento seja

adicionado à ontologia a partir desta dedução. Os axiomas foram modelados para cada

“XQueryInjection ≡ ∃hasAttackAction.Discovery ⨅ ∃hasAttackAction.ProbeXPath ⨅

∃hasAttackAction.InjectXQuery” (1)

46


classe de ataque baseando-se nas estratégias de ataque propostas pela CAPEC, e foram

validados/ajustados baseando-se em ferramentas de teste de segurança para web

services (seção 4.1). Por exemplo, na ontologia criou-se o axioma (1) para a classe

XQueryInjection, representado aqui através de lógica de primeira ordem.

Este axioma instrui a máquina de inferência a deduzir que qualquer ataque

possuidor de uma ação do tipo Discovery, uma ação do tipo ProbeXPath, e uma ação do

tipo InjectXQuery terá que obrigatoriamente ser uma instância da classe

XQueryInjection. Na lógica de detecção do XID isto significa que um ataque do tipo

XQueryInjection ocorreu.

Um exemplo prático do uso deste axioma específico é representado pelos

pacotes (2), (3) e (4), detectados pelo XID antes da instância de ataque xqueryInjection1

ser adicionada na ontologia.

“GET /WSDigger_WS/WSDigger_WS.asmx?wsdl HTTP/1.0\r\n” (2)

O pacote (2) representa um usuário acessando o documento WSDL de um web

service, fazendo com que o XID crie um relacionamento (através da propriedade

hasAttackAction) com a ação específica getWSDL (Fig. 2) − uma das instâncias da

classe Discovery na ontologia.

“//*” (3)

O pacote (3) contém caracteres (‘//*’) que não deveriam estar presentes em

nenhum campo de um pacote enviado por um usuário em uma operação XPath. Com

isto, o XID cria outro relacionamento, desta vez com a ação probeXPath1 (Fig. 2) −

instância da classe ProbeXPath que representa o payload ‘//*’.

“count(/child::node())” (4)

Finalmente, o pacote (4) contém o payload ‘count(’, que representa uma ação

ilegal de um usuário, neste caso tentando obter o número de ocorrências de algum

elemento da estrutura da base de dados XML. Isto fez o XID criar um relacionamento

com a ação injectXQuery1 (Fig. 2), instância da classe InjectXQuery na ontologia.

O XID então inferiu na ontologia para verificar se essas ações poderiam

representar um ataque. Observe que mesmo a base de conhecimento da ontologia não

contendo esta instância de ataque específico, a máquina de inferência considerou o

conjunto de eventos capturados como uma instância da classe XQueryInjection – de

acordo com o axioma definido. Isto permitiu à ontologia aprender um novo ataque, pois

em seguida o mesmo foi automaticamente adicionado pelo XID à base de conhecimento

na forma de uma instância da classe XQueryInjection. Ou seja, na próxima vez que este

ataque ocorrer será detectado sem que a máquina de inferência precise ser acionada.

As instâncias e relacionamentos na ontologia podem ser comparados com os

padrões de ataques conhecidos em uma abordagem de detecção baseada em assinaturas.

Porém, o padrão de ataque na ontologia representa a estratégia do ataque (sequência

bem definida de ações), enquanto que na abordagem de detecção baseada em

assinaturas o padrão é apenas um payload. Adicionalmente, as classes e axiomas da

ontologia permitem que a máquina de inferência deduza que um ataque ocorreu mesmo

que esse ainda não esteja na base de conhecimento, dando à abordagem proposta

similaridade com a abordagem de detecção baseada em anomalias. Esta similaridade do

XID com as outras duas abordagens de detecção de ataques o torna uma abordagem

híbrida que explora as melhores características das outras duas.

4. Detecção de XML Injection Baseada em Ontologia

A ontologia proposta foi modelada utilizando a ferramenta Protégé [Stanford 2011] e a

47


linguagem Web Ontology Language [McGuinness e Harmelen 2009].

Utilizando o diagrama de classes da Fig. 1 modelou-se a estrutura das classes na

ontologia (lado esquerdo da Fig. 3), criou-se instâncias de ataques (e.g.

xqueryInjection1) e suas propriedades e relacionamentos (lado direito da Fig. 3).

Figura 3. Visão parcial da ontologia proposta catalogada no Protégé

A máquina de inferência Pellet [Clarck&Parsia 2011] foi invocada através da

interface DIG [Bechhofer 2006] no Protégé para inferir na ontologia. Na fase de

modelagem da ontologia a máquina de inferência pode sugerir mudanças estruturais e

identificar inconsistências, baseando-se nos axiomas criados para as classes.

Primeiramente, as classes XQueryInjection e XPathInjection estavam no mesmo

nível (classes irmãs) abaixo da classe XMLInjection, como sugerido pela taxonomia da

CAPEC. Entretanto após a execução do Pellet, esse sugeriu que XQueryInjection

deveria ser uma subclasse de XPathInjection. Depois de analisar tal inferência,

concluiu-se que esta sugestão fazia sentido, já que a XQueryInjection possui todas as

restrições da XPathInjection. Também é possível encontrar fundamentação para isto no

site da W3C [Boag et al. 2011], que sugere que a linguagem XQuery seja uma extensão

da XPath. A inferência, neste caso, ajudou a aperfeiçoar a organização das classes de

ataque na ontologia e, por conseguinte, a tornar os resultados da detecção mais efetivos.

4.1. Protótipo

Para avaliar a ontologia proposta foi desenvolvido um protótipo de sistema de detecção

de intrusão (Fig. 4), utilizando a tecnologia Java [Oracle 2011].

Para capturar pacotes na rede foi utilizada a Jpcap [SourceForge 2011], uma

biblioteca de captura de pacotes de rede para aplicações Java. A Jpcap pode filtrar

pacotes IP e TCP, que são então transferidos para o módulo de detecção, cuja função é

analisar conteúdos relativos a web services – conteúdo codificado em XML que serve

para detecção no XID.

A base de conhecimento da ontologia foi manipulada pelo protótipo em tempo

de execução utilizando o framework Jena [SourceForge 2011], que já possui uma

interface nativa do Pellet. As instâncias de ataque foram consultadas utilizando

SPARQL [Prud'hommeaux e Seaborne 2008], uma linguagem para consulta em

arquivos RDF e OWL (arquivo da ontologia).

As estratégias dos ataques (extraídas inicialmente da CAPEC) foram refinadas e

validadas utilizando o framework Metasploit [Metasploit 2011] e algumas das

ferramentas de teste de segurança sugeridas pelo Open Web Application Security

Project [OWASP 2011] para gerar ataques de XPath/XQuery injection. Também foram

utilizados scripts contidos no site ha.ckers [Hansen 2008] para gerar ataques de XML

48


Cross-Site Scripting. O sniffer Wireshark [Combs 2011] foi utilizado para capturar

pacotes na rede para análise funcional dos módulos do protótipo.

Figura 4. Visão geral da arquitetura do XID

Uma visão geral do funcionamento do módulo de detecção e inferência do XID

é apresentada na Fig. 5. É possível observar que quando uma ação é detectada (evento i)

em um pacote da rede pela primeira vez o protótipo cria uma instância (evento ii) de

ataque (por enquanto sem persisti-la na ontologia), criando também um relacionamento

da instância com esta ação (evento iii). Ou seja, a estratégia de um possível ataque

começa a ser perseguida.

A seguir o protótipo verifica se existe alguma instância na base de conhecimento

da ontologia que seja idêntica à criada anteriormente (evento iv) – o que indicaria que o

ataque é conhecido (evento v). Isto é feito através de uma busca na ontologia por uma

instância de ataque que esteja relacionada exatamente com as mesmas ações

encontradas na detecção até este evento.

Figura 5. Fluxograma de detecção do XID

Quando não é encontrada uma instância idêntica a criada no evento ii, o

protótipo tenta inferir um novo ataque a partir das informações contidas na base de

49


conhecimento da ontologia (evento vi), verificando se a instância pode ser considerada

uma variação de ataque.

É através desta inferência, levando em conta classes e axiomas na ontologia, que

a abordagem tenta aprender novos ataques e adicioná-los à base de conhecimento. Não

chegando a uma inferência conclusiva, o protótipo continua analisando os próximos

pacotes até encontrar uma nova ação. Esta nova ação é adicionada à instância (contendo

agora duas ações) e novamente é verificado se um ataque ocorreu.

Este ciclo de eventos ocorre até que uma instância seja apontada como um

ataque de acordo com o conjunto de ações detectadas, quando então a sequência do

algoritmo de detecção é reiniciada.

Um ataque pode ser alertado pelo protótipo (evento v) se for encontrada uma

instância idêntica na ontologia (através do SPARQL) ou se for inferida uma instância

como um novo ataque (através do Pellet).

Quando um ataque é inferido, antes de alertar o ataque o protótipo verifica se a

classe da instância inferida contém subclasses, o que significa que há possibilidade do

ataque ser mais específico. Caso encontre subclasses na ontologia, o protótipo aguarda a

próxima ação a ser detectada e faz uma nova inferência. Se esta nova inferência não

alertar nenhuma subclasse mais específica, o protótipo alerta o ataque inferido

inicialmente como uma mensagem informativa (evento viii), o que significa que o

ataque pode não estar completo ou que se trata de uma nova categoria (subclasse) de

ataques. Em caso contrário alerta o ataque – porque a subclasse mais específica foi

alcançada.

Além de emitir o alerta o protótipo adiciona a nova instância à base de

conhecimento da ontologia (evento vii), abaixo da classe correspondente. Assim, o

protótipo e a ontologia (XID) podem ser considerados um sistema de detecção com uma

abordagem híbrida. O XID permite detecção baseada em assinaturas através das

instâncias, mas também permite a detecção de variações de ataques através de

inferência nas classes e axiomas.

4.2. Avaliação quantitativa

Para avaliar a eficiência do XID foram desenvolvidos três cenários. No primeiro foi

aplicado SPARQL, no segundo Pellet e no terceiro um arquivo texto – base de

assinaturas Snort [Sourcefire 2011].

O objetivo dos experimentos foi comparar a escalabilidade e o desempenho da

base de conhecimento da ontologia com os da base de dados baseada em assinaturas,

pois havia a dúvida se devido à necessidade de inferências em alguns casos da detecção

de ataques tal abordagem seria viável.

Para avaliação foi utilizada uma base composta de até 128 ataques catalogados

no Protégé. Esta base iniciou com quatro classes de ataques pré-cadastradas

(XMLInjection, XPathInjection, XQueryInjection e XSSInjection) e quatro instâncias de

ataques (xpathInjection1, xpathInjection2, xqueryInjection1 e xssInjection1).

Adicionando incrementos de 2 x (x = 2, 3, 4, ...) instâncias de ataques por vez a base foi

sendo aumentada até totalizar os 128 ataques. Para compor a base, diversas instâncias

de ataques e ações foram simuladas com o intuito de imitar as variações de ataques que

vão sendo incorporadas à ontologia em uma aplicação real da proposta.

O primeiro experimento testou a ontologia consultando-a com apoio do

SPARQL. Esta abordagem analisou os pacotes da rede procurando por ações

maliciosas, que já estavam pré-cadastradas na base de conhecimento da ontologia,

50


elacionando as mesmas com instâncias de ataques que foram previamente introduzidas

utilizando o Protégé.

O segundo experimento utilizou o Pellet para avaliar a ontologia em tempo de

execução. Neste experimento não havia instâncias de ataques na ontologia quando a

mesma foi consultada pelo SPARQL, portanto a máquina de inferência tentou derivar

novos ataques baseando-se em axiomas pré-definidos para cada classe de ataques. Em

outras palavras, já que o módulo SPARQL falhou, o módulo de inferência foi invocado

para determinar se os conjuntos de ações sendo capturadas poderiam ser considerados

novos ataques.

Figura 6. Tempo de detecção relativo (Assinaturas x SPARQL)

Sempre que uma nova sequência de ações é inferida como sendo um ataque

(nova assinatura), uma nova instância para este ataque é automaticamente adicionada à

base de conhecimento da ontologia. Assim, não se desperdiça tempo invocando o

módulo de inferência caso este ataque específico seja capturado no futuro, pois o

SPARQL irá detectá-lo primeiro, eliminando a possibilidade de ataques zero-day.

O terceiro experimento não utilizou a ontologia como base de conhecimento; foi

utilizado o arquivo de texto contendo regras do Snort como base de dados de assinaturas

– sem nenhuma técnica de otimização de consultas.

Figura 7. Tempo de detecção relativo (Assinaturas x Pellet)

O terceiro experimento foi executado duas vezes. Na primeira vez o arquivo de

assinaturas foi consultado para procurar payloads (aleatoriamente inseridos do início ao

final do arquivo), com o objetivo de comparação com o desempenho do SPARQL (Fig.

6). Na segunda vez, o arquivo de assinaturas foi consultado buscando-se por payloads

(em número, variando entre 4 e128) que não se encontravam no mesmo – o objetivo foi

comparar seu desempenho com o Pellet (Fig. 7).

51


O gráfico da Fig. 6 compara o experimento de detecção baseada em assinaturas

com o experimento utilizando o SPARQL em um cenário onde os ataques estão précadastrados

no arquivo de texto e na base de conhecimento da ontologia.

O gráfico da Fig. 7 compara o experimento de detecção baseada em assinaturas

com o experimento do Pellet, em um cenário onde as assinaturas sendo procuradas não

estão presentes no arquivo texto e os conjuntos de ações sendo capturadas não

correspondem a nenhuma instância de ataque na base de conhecimento da ontologia.

As Fig. 6 e Fig. 7 mostram gráficos comparando o tempo de detecção relativo,

tomando como referência o tempo de busca por quatro ataques através de detecção

baseada em assinaturas. A motivação para tal escolha é que, observando-se o ponto de

partida da curva do Pellet na Fig. 7, nota-se que o mesmo gastou um tempo extra (se

comparado a abordagem baseada em assinaturas), necessário para derivar novas

instâncias através dos axiomas das classes de ataques da ontologia. Foi observado que o

tempo gasto para avaliar as classes de ataques sem sucesso utilizando Pellet e o tempo

gasto para inferência e adição de uma nova instância abaixo de uma das classes é

similar.

O gráfico da Fig. 7 mostrou o pior caso para detecções do XID, pois as consultas

resultam em perda de tempo de processamento pelo fato dos ataques não estarem na

base, logo toda a base é consultada sem sucesso. Entretanto, mesmo o Pellet

consumindo três vezes mais tempo do que a detecção baseada em assinaturas, sua

abordagem ainda é vantajosa (em relação à detecção baseada em assinaturas) pelo fato

de que esse módulo é executado uma única vez para cada nova variação de ataque. Uma

vez que o Pellet infere uma nova instância de ataque, este módulo não será mais

executado no futuro se o mesmo ataque for capturado novamente, pois o SPARQL irá

detectar o ataque primeiro na sua próxima ocorrência. Já na detecção baseada em

assinaturas este processamento sempre significará perda de tempo.

Observando a Fig. 6 constata-se uma tendência do desempenho do SPARQL

ultrapassar a detecção baseada em assinaturas quando a base chegar a 512 ataques. Em

aplicações reais as bases de ataques são muito amplas, logo a abordagem proposta teria

a vantagem quantitativa de maior escalabilidade no tempo de detecção.

Baseando-se nos resultados relatados acima é possível concluir que a proposta

deste trabalho, que mistura o primeiro e o segundo cenário, é vantajosa em relação ao

terceiro cenário (abordagem clássica), obtendo a melhor relação custo benefício de

detecção – baseada em assinaturas (SPARQL) vs baseada em conhecimento (Pellet).

4.3. Avaliação qualitativa

Em ontologias as definições de conceitos devem ser feitas através de axiomas lógicos

[Gruber 1993]. Além disso, Gruber menciona que estas definições devem ser completas,

ou seja, especificadas explicitando-se as condições necessárias e suficientes que as

instâncias devem atender para serem classificadas por tais conceitos. Isto porque se uma

instância atende às condições necessárias e suficientes (definidas através de axiomas) de

uma classe, obrigatoriamente será inferida como instância daquela classe.

Considerando as afirmações de Gruber, em um mundo perfeito não haveria a

possibilidade de alertas falsos serem gerados pelo XID, já que instâncias detectadas ou

inferidas necessariamente atendem aos axiomas definidos para suas classes de ataques.

Porém, Gruber também ressalta que se o resultado de uma inferência gerar um

conhecimento que não corresponde à definição formal do domínio sendo representado,

a ontologia pode estar incoerente. Ou seja, mesmo que os axiomas garantam que nada

52


diferente do que foi definido será detectado ou inferido pela proposta, sempre há a

possibilidade de uma entrada incorreta na definição da ontologia por erro humano –

assim como em qualquer outro sistema automatizado, se a entrada está incorreta, o

resultado será impreciso. No caso da proposta a possibilidade de erro de especificação

do ataque na ontologia é minimizada devido ao uso da taxonomia da CAPEC.

Se o ataque está completamente descrito (contendo as condições necessárias e

suficientes que refletem a estratégia do ataque no mundo real) a probabilidade de falso

positivo é nula. Porém, se o conjunto de atributos (relacionamentos) e restrições não

estiver precisamente descrito há possibilidade de ocorrência de falsos positivos.

A partir destas considerações, dois cenários foram criados para testar a taxa de

falsos positivos da abordagem proposta na detecção através do Pellet (módulo de

inferência do XID que se utiliza dos axiomas para deduzir ataques), visando garantir

que a ontologia tenha sido projetada de forma coerente.

Para o teste dos cenários foram criadas 128 instâncias (reais e simuladas) para

avaliar os axiomas das quatro classes de ataques da proposta (XMLInjection,

XPathInjection, XQueryInjection e XSSInjection). No primeiro cenário a lógica de

detecção alertou ataques a cada inferência conclusiva, ou seja, assim que as restrições

(axiomas) de qualquer classe eram atendidas o ataque era alertado. Já no segundo

cenário (abordagem do XID), o protótipo verificou se os ataques continham subclasses

(indícios de que um ataque mais específico estaria ocorrendo) antes de alertá-los.

A avaliação dos cenários foi dividida em duas fases. Na primeira fase, 64 dos

128 ataques criados foram utilizados, com o intuito de se fazer uma avaliação

(treinamento) inicial da ontologia e ajustar as classes e axiomas caso fosse necessário.

Portanto, 50% da amostragem de instâncias já estavam na ontologia ao término da

primeira fase. Pequenos ajustes foram feitos na lógica de detecção do protótipo após os

resultados deste treinamento, nenhuma alteração foi feita na ontologia. Na segunda fase,

as 64 instâncias de ataque restantes foram simuladas para testar a porcentagem de acerto

da proposta nas inferências feitas em tempo de execução, para ambos os cenários.

O resultado da avaliação para o primeiro cenário foi que 7/64 instâncias de

ataque não foram detectadas corretamente. Estas sete instâncias continham três ações

cada uma, uma ação da classe Discovery, uma da classe ProbeXPath e uma da classe

ProbeXQuery. Estas sequências de três ações deveriam alertar um ataque do tipo

XQueryInjection de acordo com o axioma definido para esta classe. Porém, o protótipo

alertou para cada uma das sete instâncias como ataques de XPathInjection e de

XMLInjection, respectivamente (totalizando 14 ataques alertados). Isto ocorreu porque a

primeira parte dos ataques gerados (ação de Discovery e ação de ProbeXPath) satisfaz o

axioma da classe de ataque XPathInjection, e a parte restante (ação de ProbeXQuery)

satisfaz sozinha o axioma da classe genérica XMLInjection.

Assim, no primeiro cenário o resultado da dedução foi impreciso em alguns

casos porque não foi considerado integramente o conjunto de ações que atendem as

restrições da classe mais específica. Isto é, a dedução considerou apenas um

subconjunto de ações que satisfaziam as restrições dos axiomas de classes mais

genéricas – primeiras a serem testadas na lógica de detecção.

No segundo cenário, o protótipo foi programado para apenas alertar um ataque

mais genérico após verificar as classes mais específicas do ataque sendo inferido. Desta

forma, todas as 64 instâncias de ataque foram inferidas com sucesso e adicionadas às

classes corretas na ontologia. Como neste cenário o protótipo aguardou a detecção da

próxima ação antes de alertar um ataque – quando havia a possibilidade de um ataque

53


mais específico estar ocorrendo – não houve imprecisões na detecção.

Imprecisões de inferência não são consideradas como falsos positivos para o

XID na abordagem do segundo cenário (ataque genérico alertado mesmo depois de

verificadas as subclasses), porque falsos positivos são resultantes de classificação

errônea de ações normais consideradas como ataques. Na abordagem proposta estas

imprecisões são deduzidas em classes mais genéricas e, portanto, são alertadas como

mensagens informativas e não como ataques. Isto é, quando o nível de especificidade do

ataque sendo deduzido não é suficiente para atingir um grau de precisão confiável

(depois de verificadas suas subclasses na ontologia), o mesmo é alertado como

informativo ao invés de ataque.

Neste caso, quando a dedução não é conclusiva pode haver indícios de que o

ataque detectado pode não estar completo (alguma ação das estratégias das subclasses

foi perdida na detecção, por exemplo), ou uma nova categoria de ataque pode ter sido

detectada. Este tipo de informação pode então ser investigado por um

administrador/especialista para verificar se uma nova subclasse teria que ser criada ou

se a instância se encaixa em alguma subclasse existente.

4.4. Considerações

Apesar de aplicar ontologia, a performance da detecção utilizando SPARQL é similar à

abordagem baseada em assinaturas, levando em conta que instâncias de ataques estão

pré-cadastradas na base de conhecimento. Além disso, o Pellet trabalha inferindo na

ontologia para derivar novos ataques quando o SPARQL não encontra combinações

exatas dos ataques. A inferência neste caso mantém a taxa de falsos positivos na

detecção similar à de abordagens baseadas em assinaturas, pois novos ataques só podem

ser derivados de classes e axiomas pré-cadastrados na ontologia.

A falha encontrada no primeiro cenário da avaliação qualitativa, que gerou

imprecisão na detecção, foi devida a adoção de uma estratégia de detecção que buscava

apenas identificar condições necessárias e suficientes, nem sempre levando em conta os

axiomas das subclasses mais específicas. No segundo cenário esta falha não ocorreu, já

que os axiomas das subclasses eram sempre verificados. Porém, quando classes de

ataque mais específicas não eram encontradas, as instâncias deduzidas eram alertadas

como mensagens informativas ao invés de ataques.

A inferência na ontologia pode ser utilizada tanto em tempo de execução

(quando necessário) para aprender novos ataques, quanto na fase de modelagem para

sugerir mudanças estruturais e encontrar inconsistências, otimizando a hierarquia de

classes. Além disso, dependendo do tamanho da ontologia, redundâncias na definição

da mesma que levariam horas para serem encontradas por um humano podem ser

encontradas por uma máquina de inferência em alguns segundos.

5. Trabalhos Relacionados

A grande maioria das propostas encontradas na literatura técnica utiliza abordagens de

detecção clássicas [Siddavatam e Gadge 2008][Yee, Shin e Rao 2007][Bravenboer,

Dolstra e Visser 2010] e as que utilizam outras abordagens não trabalham com ataques a

web services [Undercoffer et al. 2004].

Siddavatam e Gadge [Siddavatam e Gadge 2008] propuseram submeter

requisições SOAP a uma série de algoritmos de teste para determinar se as mesmas

poderiam representar algum tipo de ataque. Todas as requisições que não passam no

teste são separadas para que ações posteriores possam ser tomadas. Os autores

apresentam testes e resultados para sua proposta, porém não detalham suficientemente

54


os algoritmos e os mecanismos de detecção dos ataques.

Yee e seus colegas [Yee, Shin e Rao 2007] aplicaram um framework adaptável

para tentar compensar as diferenças entre a detecção baseada em anomalias e

assinaturas, através da integração de agentes, técnicas de mineração de dados e técnicas

de lógica difusa. Para os autores, o uso destas técnicas permite tomar decisões em

ambientes incertos e imprecisos. Porém, nenhum resultado concreto foi apresentado.

A abordagem de Bravenboer e seus colegas [Bravenboer, Dolstra e Visser 2010]

sugere a incorporação de sintaxe, de acordo com as linguagens utilizadas no guest e

host (e.g. XPath com Java), para gerar automaticamente o código que irá prevenir

vulnerabilidades para ataques de injection (e.g. adicionando funções para filtrar

caracteres inválidos). Os autores argumentam que a proposta é genérica, podendo ser

aplicada com facilidade a qualquer combinação de linguagens. Porém, uma limitação

apontada é o fato de nem todas as linguagens possuírem uma sintaxe livre de contexto.

A proposta de Undercoffer e seus colegas [Undercoffer et al. 2004] aplica

ontologia para categorizar classes de ataques baseando-se principalmente no

componente alvo dos mesmos, também considera os meios e as conseqüências do

ataque e a localização do atacante. Esta ontologia é compartilhada por diversos sistemas

de detecção de intrusão – o intuito é disseminar a todos um ataque descoberto por um

deles. Porém, não é mencionado o uso de axiomas ou inferência, além disto, os autores

não avaliam a proposta com testes.

Vorobiev e Han [Vorobiev e Han 2006] propuseram a abordagem que está mais

próxima deste trabalho, os autores aplicaram uma ontologia especificamente para

abordar o domínio de ataques a web services. Entretanto, a implementação da ontologia

não foi encontrada e a proposta não utiliza inferência para detectar novos ataques. A

ontologia é principalmente um ‘dicionário’ comum para diferentes ambientes.

6. Conclusão

Este artigo apresentou uma abordagem baseada em ontologia (XID) para proteger web

services de ataques de XML injection e para mitigar o problema dos ataques que são

variações de ataque conhecidos. Os ataques de XML injection que já estavam na base

de conhecimento foram detectados com sucesso utilizando SPARQL para consultar a

ontologia. Adicionalmente, as variações de payload foram detectadas utilizando

inferência com nenhuma ocorrência de falsos positivos, já que novos payloads

(instâncias) foram detectados baseando-se somente em classes e axiomas de ataques

pré-existentes. Os novos payloads foram automaticamente adicionados à base de

conhecimento da ontologia como instâncias – abaixo das classes relacionadas,

eliminando os ataques que são variantes de ataques conhecidos.

O XID agrega as principais vantagens das abordagens clássicas de detecção.

Permite a detecção de ataques conhecidos, como na abordagem baseada em assinaturas,

e permite a detecção de novos ataques, como na abordagem baseada em anomalias. Esta

segunda abordagem de detecção é feita pelo XID através de inferência na ontologia.

Como relação ao desempenho a proposta é comparável à detecção baseada em

assinaturas quando os ataques são conhecidos. Quando os ataques não são conhecidos a

proposta perde em desempenho quando comparada à abordagem por assinaturas, porém,

neste caso podem ser detectadas variações de payloads com taxa nula de falsos

positivos, mitigando ataques zero-day, por exemplo. Esta inferência de ataques que não

estão pré-cadastrados na base não é possível na abordagem clássica de detecção baseada

em assinaturas e imprecisa na baseada em anomalias.

55


Referências

Bechhofer, S. (2006) “DIG 2.0: The DIG Description Logic Interface”,

http://dig.cs.manchester.ac.uk.

Boag, S., Chamberlin, D., Fernández, M. F., Florescu, D., Robie, J. e Siméon, J. (2011)

“XQuery 1.0: An XML Query Language (Second Edition)”, http://www.w3.org/TR/xquery.

Booth, D., Haas, H., Mccabe, F., Newcomer, E., Champion, M., Ferris, C. e Orchard, D. (2004)

“Web Services Architecture”, http://www.w3.org/TR/ws-arch.

Bravenboer, M., Dolstra, E. e Visser, E. (2010). Preventing injection attacks with syntax

embeddings. In Science of Computer Programming archive, pages 473-495.

CAPEC (2011) “Common Attack Pattern Enumeration and Classification”,

http://capec.mitre.org/data/graphs/1000.html.

Clarck&Parsia (2011) “Pellet: OWL 2 Reasoner for Java”, http://clarkparsia.com/pellet.

Combs, G. (2011) “Wireshark – Go Deep”, http://www.wireshark.org.

CWE e SANS (2010) “2010 CWE/SANS Top 25 Most Dangerous Software Errors”,

http://cwe.mitre.org/top25/index.html.

CWE (2011) “Common Weakness Enumeration”, http://cwe.mitre.org/data/definitions/91.html.

Siddavatam, I. e Gadge, J. (2008). Comprehensive Test Mechanism to Detect Attack on Web

Services. In 16th IEEE International Conference on Networks, pages 1-6.

Dou, D., McDermott, D. e Qi, P. (2004). Ontology Translation on the Semantic Web. In Journal

on Data Semantics (JoDS) II, pages 35-57.

Gruber, T. R. (1993). Toward Principles for the Design of Ontologies Used for Knowledge

Sharing. In International Journal Human-Computer Studies 43, pages 907-928.

Hansen, R. (2008) “XSS (Cross Site Scripting) Cheat Sheet”, http://ha.ckers.org/xss.html.

Konstantinou, N., Spanos, D. e Mitrou, N. (2008). Ontology and Database Mapping: A Survey

of Current Implementations and Future Directions. In Journal of Web Engineering, pg. 1-24.

McGuinness, D., e Harmelen, F. (2009) “OWL 2 Web Ontology Language”,

http://www.w3.org/TR/owl-features.

Metasploit (2011) “Metasploit - Penetration Testing Resources”, http://www.metasploit.com.

Oracle (2011) “For Java Developers”, http://www.oracle.com/technetwork/java/index.html.

OWASP (2009) “The Open Web Application Security Project”,

http://www.owasp.org/images/3/3f/2009AnnualReport.pdf.

OWASP (2011) “The Open Web Application Security Project”, http://www.owasp.org.

Prud'hommeaux, E., e Seaborne, A. (2008) “SPARQL Query Language for RDF”,

http://www.w3.org/TR/rdf-sparql-query.

Sourcefire (2011) “Sourcefire VRT Certified Rules - The Official Snort Ruleset”,

http://www.snort.org/snort-rules.

SourceForge (2011) “Jena – A Semantic Web Framework for Java”, http://jena.sourceforge.net.

SourceForge (2011) “Network Packet Capture Facility for Java”,

http://sourceforge.net/projects/jpcap.

Stanford (2011) “The Protégé Ontology Editor and Knowledge Acquisition System”,

http://protege.stanford.edu.

Undercoffer, J., Pinkston, J., Joshi, A. e Finin, T. (2004). A Target-Centric ontology for

intrusion detection. In Proceedings of the IJCAI W. on Ontologies and Dist. Sys., pg. 47-58.

Vorobiev, A. e Han, J. (2006). Security Attack Ontology for Web Services. In Proceedings of

the Second International Conference on Semantics, Knowledge, and Grid, paper 42 (6pp).

Yee, C. G., Shin, W. H. e Rao, G. S. V. R. K. (2007). An Adaptive Intrusion Detection and

Prevention (ID/IP) Framework for Web Services. In Proceedings of IEEE International

Conference on Convergence Information Technology, pages 528-534.

Zero Day Initiative (2011) “Zero Day Initiative”, http://www.zerodayinitiative.com/

advisories/upcoming/.

56


Carimbos do Tempo Autenticados para a Preservação por

Longo Prazo de Assinaturas Digitais

Nelson da Silva 1 , Thiago Acórdi Ramos 1 , Ricardo Felipe Custódio 1

1 Laboratório de Segurança em Computação (LabSEC)

Universidade Federal de Santa Catarina (UFSC)

Caixa Postal 476 – 88040-900 – Florianópolis – SC – Brasil

{nelson, thg, custodio}@inf.ufsc.br

Abstract. Digital signatures are usually employed as the digital counterpart of

handwritten signatures, allowing the authentication of electronic documents.

These signatures, however, may quickly lose its validity, creating a preservation

challenge for those documents that must be kept for a longer period of time. In

this paper, we improve the efficiency and reliability of the usual approach for

this problem, through a new time-stamp scheme. Such time-stamps carries a

Certificate of Authenticity, with reduces its storage and validation costs, while

protecting the signature even in the presence of an adversary able to compromise

the Time Stamping Authority’s private key or its signature scheme.

Resumo. Assinaturas digitais são comumente usadas como a contraparte digital

das assinaturas manuscritas, possibilitando a autenticação de documentos

eletrônicos. Tais assinaturas, contudo, podem rapidamente perder sua validade,

criando um desafio para a preservação daqueles documentos que precisam ser

guardados por um tempo maior. Neste trabalho, aumentamos a eficiência e confiabilidade

da abordagem usual para o problema, através de um novo esquema

de datação. Esses carimbos carregam um Certificado de Autenticidade, que reduz

seus custos de armazenamento e validação, enquanto protege a assinatura

mesmo na presença de um adversário capaz de comprometer a chave privada

da Autoridade de Carimbo do Tempo ou seu esquema de assinatura.

1. Introdução

Assinaturas digitais são comumente usadas como a contraparte digital das assinaturas

manuscritas, possibilitando a autenticação de documentos eletrônicos. Diversos

países vêm, inclusive, atribuindo a elas o mesmo valor legal das assinaturas manuscritas,

como forma de facilitar o uso de documentos eletrônicos como meio de prova. Na União

Européia, por exemplo, essa questão é abordada na Diretiva Européia 1999/93/EC. No

Brasil, isso é assunto da Medida Provisória 2.200-2.

Apesar de amplamente usadas, as assinaturas digitais podem rapidamente perder

sua validade, o que constitui um desafio para a preservação daqueles documentos

eletrônicos que precisam ser guardados por um longo período de tempo. Na

implementação usual dessas assinaturas, por exemplo, tal problema ocorre por diversos

fatores, tais como o enfraquecimento do esquema de assinatura usado pelo signatário e

a perda de validade de seu caminho de certificação X.509. Nesses casos, a segurança

oferecida pela assinatura acaba sendo comprometida.

57


Tal problema torna necessária alguma forma de preservação que permita manter

a validade dessas assinaturas pelo tempo que for necessário. Assim várias estratégias já

foram propostas, sendo a sobreposição de carimbos do tempo, criada por Bayer, Haber e

Stornetta [6], a principal delas. É essa a estratégia usada nas principais recomendações

técnicas que atualmente abordam o problema [12, 13, 14], sendo igualmente uma das mais

estudadas na literatura. Do mesmo modo, é essa a estratégia usada no Padrão Brasileiro de

Assinatura Digital, publicado pelo Instituto Nacional de Tecnologia da Informação (ITI).

A preservação por carimbos do tempo, contudo, implica em custos cumulativos

para o usuário, além de não garantir que a assinatura realmente mantenha sua validade

pelo tempo necessário. Tais custos dificultam a preservação e validação dessas assinaturas

em dispositivos com poucos recursos computacionais, bem como a preservação de

grandes volumes de documentos [24]. A baixa confiabilidade dessa estratégia, por sua

vez, acaba tornando necessárias medidas preventivas, como o uso de carimbos do tempo

redundantes [14], que terminam por aumentar ainda mais os custos de preservação.

Neste trabalho aumentamos a eficiência e confiabilidade da preservação por carimbos

do tempo através de um novo esquema de datação, os Carimbos do Tempo Autenticados.

O uso desse esquema permite reduzir drasticamente os custos de armazenamento

e validação das assinaturas preservadas, assim como ter maiores garantias quanto

a preservação da assinatura pelo tempo que for necessário. Além disso, seu uso torna

possível a validação off-line de assinaturas, uma vez que essas se tornam auto-contidas.

O restante deste trabalho é organizado da seguinte forma. A Seção 2 apresenta o

estado da arte sobre a preservação de assinaturas digitais. A Seção 3 descreve o esquema

de datação tradicional e revisa a preservação por carimbos do tempo. A Seção 4 apresenta

o esquema de datação proposto, assim como as suas implicações sobre os procedimentos

de preservação e validação de assinaturas. A Seção 5 avalia os benefícios e limitações da

proposta. Finalmente, a Seção 6 apresenta as considerações finais.

2. Trabalhos Relacionados

A preservação de assinaturas digitais é um tema quase tão antigo quanto a própria

criptografia assimétrica. Já no final da década de 70, Popek e Kline [21] sugeriam que

a validade de uma assinatura fosse preservada por meio de “carimbos do tempo”, emitidos

por terceiras partes confiáveis, onde constaria o momento em que a assinatura fora

produzida. A ideia era que assinaturas autênticas seriam aquelas realizadas antes de sua

falsificação se tornar viável.

Massias e Quisquater [18], por outro lado, propuseram a preservação de assinaturas

digitais através da autenticação de outro fato, a sua própria validade. Esse ateste

seria uma alternativa para a comprovação da validade da assinatura quando, através das

verificações tradicionais, essa já fosse inválida.

Ambas as estratégias de notarização, como ficaram conhecidas por remeter aos

atos praticados pelos notários no mundo real [16], foram tema de diversos trabalhos.

Carimbos do tempo, por exemplo, foram aprimorados por Haber e Stornetta [15], que

sugeriram seu encadeamento como forma de reduzir a confiança necessária nas entidades

responsáveis por sua produção. Blibech e Gabillon [7], por sua vez, reduziram os custos

decorrentes da validação desses carimbos, redefinindo a forma como são encadeados.

58


Atestes da validade de assinaturas, por outro lado, foram aprimoradas por Ansper

et al. [3], que sugeriram a agregação das assinaturas em Árvores de Merkle [19], de modo

a reduzir o esforço computacional necessário para a sua produção. Por outro lado, Custodio

et al. [10], propuseram a associação do método de NOVOMODO a esses atestes,

como forma de minimizar os recursos computacionais necessários à sua validação.

Além das estratégias de notarização, uma outra abordagem vem sendo usada na

literatura para a preservação de assinaturas digitais, focada nas primitivas criptográficas

envolvidas em sua geração e validação. São os esquemas especiais de assinatura, com

propriedades que as tornam menos vulneráveis ao efeito do tempo. São exemplos desses

esquemas o de chave evolutiva e as assinaturas incondicionalmente seguras.

Esquemas de chave evolutiva [2] são voltados à proteção das assinaturas produzidas

contra o comprometimento da chave privada do signatário. Nesses esquemas a chave

privada evolui de modo que o comprometimento da chave privada atual, não invalidaria

assinaturas realizadas com as chaves anteriores.

Esquemas de assinaturas incondicionalmente seguras, por sua vez, tratam do problema

relacionado ao enfraquecimento dos algoritmos criptográficos [8]. Diferentemente

dos esquemas convencionais, tais esquemas não baseiam sua segurança em suposições

quanto ao poder computacional do adversário. Poder esse que tende a aumentar com o

tempo.

Nenhuma das estratégias citadas, contudo, é capaz de preservar assinaturas digitais

por um prazo arbitrariamente grande. Carimbos do tempo e atestes, por exemplo,

perdem com o tempo sua validade assim como as próprias assinaturas. Esquemas especiais

de assinatura, por sua vez, tendem a tratar apenas uma parte dos problemas, sempre

deixando as assinaturas vulneráveis a problemas remanescentes.

Um dos primeiros trabalhos a tratar da preservação por longo prazo de assinaturas

digitais foi o trabalho de Bayer, Haber e Stornetta [6]. Na proposta, parcialmente apresentada

num trabalho anterior [15], uma assinatura digital seria preservada pela sobreposição

de carimbos do tempo. A idea era que novos carimbos seriam adicionados na medida

que os anteriores estivessem por perder sua validade. Cada um dos carimbos demonstraria

que o anterior fora produzido antes de se tornar falsificável. Ideia semelhante à

sobreposição de carimbos do tempo foi posteriormente proposta para atestes da validade

de assinaturas [17, 24].

3. Preservação por Carimbos do Tempo

Dentre as estratégias até então propostas para a preservação por longo prazo de

assinaturas digitais, a preservação por carimbos do tempo é aquela adotada pelas principais

recomendações técnicas sobre o tema [12, 13, 14], sendo, igualmente, uma das mais

estudadas na literatura. Nessa estratégia, carimbos do tempo são usados para demonstrar

a validade da assinatura e dos próprios carimbos usados no processo.

3.1. Carimbos do Tempo

Em sua forma mais comum, usada em recomendações técnicas como a

RFC 3161 [1], carimbos do tempo são documentos eletrônicos assinados por uma terceira

parte confiável, denonimada Autoridade de Carimbo do Tempo (ACT), onde constam

tanto o resumo criptográfico da informação datada, quanto a data em que o carimbo

59


foi emitido. São duas as operações relacionadas a esses carimbos, a sua solicitação e

validação. A primeira segue o protocolo representado a seguir:

U −→ ACT : H(x)

ACT −→ U : {H(x), t}, Sign ACT ({H(x), t})

} {{ }

ts

Nele, um usuário solicita um carimbo do tempo para uma informação qualquer

x ∈ {0, 1} + , enviando seu resumo criptográfico H(x). Ao receber o resumo, a ACT

então anexa a data atual t, assina o conjunto e retorna o carimbo formado. A partir de

então é possível comprovar que x existia em t. Para tanto, é necessário validar o carimbo.

Um carimbo do tempo é válido se:

• a assinatura da ACT for válida;

• o resumo criptográfico presente no carimbo for igual a H(x) e H for uma função

de resumo criptográfico segura.

Tais condições visam comprovar, respectivamente, a autenticidade do carimbo e

a integridade da informação datada. A função H deve ser segura pois, do contrário,

essa integridade acaba se tornando duvidosa. Em maiores detalhes, H poderá ser apenas

resistente à segunda inversão, desde que em t tenha sido resistente, igualmente, à colisão.

Dessas condições é possível concluir o prazo de validade de um carimbo. Esse termina

com a perda de validade da assinatura da ACT ou com o enfraquecimento de H, o que

ocorrer primeiro.

3.2. Preservação de Assinaturas

A preservação de uma assinatura digital por meio de carimbos do tempo segue

os seguintes passos, onde s, d, C s e R s , são, respectivamente, a assinatura, o documento

assinado, os certificados do caminho de certificação do signatário e os dados de revogação

atuais:

1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s , R s }, obtendo

{{s, d, C s , R s }, ts 1 , C 1 ts};

2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer

antes de o carimbo perder sua validade, sendo, em geral, agendada para um

momento próximo da expiração do certificado da ACT;

3. sobreposição: no momento agendado, validar ts 1 . Sendo válido, adicionar ts 2

sobre {{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, obtendo {{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 ,

C 2 ts}. Caso ts 1 já tenha perdido sua validade, a preservação falha;

4. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário

preservar a validade da assinatura. Dessa forma, na adição do n-ésimo

carimbo, obtêm-se {{...{{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 , C 2 ts, R 2 ts}, ...}, ts n ,

C n ts}.

3.3. Validação de Assinaturas

Uma assinatura preservada {{...{{{s, d, C s , R s }, ts 1 , C 1 ts, R 1 ts}, ts 2 , C 2 ts, R 2 ts},

...}, ts n , C n ts} é válida se:

• o carimbo do tempo ts n for atualmente válido;

• para todo ts i , com 1 ≤ i ≤ n − 1, ts i era válido na data indicada por ts i+1 ;

• a assinatura s era válida na data indicada por ts 1 .

60


4. Carimbos do Tempo Autenticados

Neste trabalho aumentamos a eficiência e confiabilidade da preservação baseada

em carimbos do tempo por meio de um novo esquema de datação, chamado Carimbos

do Tempo Autenticados. Esse esquema estende o convencional adicionando duas novas

operações, as operações de autenticação e renovação de carimbos, viabilizadas pela

cooperação entre a Autoridade de Carimbo do Tempo (ACT) e a Âncora de Confiança do

usuário, comumente, a Autoridade Certificadora Raiz (AC-Raiz). Tal esquema tem como

objetivo reduzir a velocidade com que crescem os custos relacionados às assinaturas preservadas

assim como aumentar as chances de a assinatura permanecer válida pelo tempo

necessário.

A operação de autenticação busca reduzir os custos por carimbo adicionado.

Através dela é possível substituir as informações necessárias à verificação da autenticidade

do carimbo, tais como seu caminho de certificação, por um Certificado de Autenticidade,

onde a própria Âncora de Confiança confirma essa propriedade. A operação de

renovação, por sua vez, busca reduzir o número de carimbos do tempo adicionados durante

a preservação. Por meio dela é possível renovar o Certificado de Autenticidade do

carimbo, prolongando sua validade, e assim postergando a adição de novos carimbos.

4.1. Certificados de Autenticidade

Certificados de Autenticidade são documentos eletrônicos, assinados pela Âncora

de Confiança, onde ela reconhece a autenticidade dos carimbos do tempo emitidos pela

ACT. Por meio desse certificado a Âncora de Confiança persiste a autenticidade do carimbo,

tornando desnecessária a validação de sua assinatura bem como do caminho de

certificação relacionado. Como resultado, é possível minimizar os custos de armazenamento

e validação do carimbo, bem como tolerar a maioria dos fatores que tradicionalmente

levariam a perda de sua validade.

De maneira simplificada, tal conceito poderia ser implementado através de um

serviço online, oferecido pela Âncora de Confiança, onde ela publicaria um Certificado

de Autenticidade para cada carimbo do tempo a ela apresentado. Nesse caso, cada carimbo

emitido pela ACT, seria encaminhado a Âncora de Confiança, que então validaria

sua assinatura e, sendo válida, publicaria um documento eletrônico assinado, onde reconheceria

a autenticidade do carimbo.

Apesar de funcional, uma implementação como essa possui problemas de ordem

prática que a tornam inviável. Um dos principais problemas está na necessidade de manter

a Âncora de Confiança online de modo a atender às solicitações recebidas. Algo que

contraria boas práticas de segurança caso, por exemplo, essa âncora seja uma AC-Raiz.

Outro problema reside no volume de informações necessárias para a produção dos Certificados

de Autenticidade. Ela requer o envio de cada um dos carimbos do tempo para a

Âncora de Confiança.

Dessa forma, na abordagem adotada, a Âncora de Confiança publica um Certificado

de Autenticidade para cada conjunto de carimbos emitido. Nesse caso, ao invés de

receber cada um dos carimbos, ela recebe pequenas representações desses conjuntos, calculadas

por meio de construções criptográficas como as Árvores de Merkle. O Certificado

de Autenticidade de cada carimbo é então formado pelo certificado do conjunto ao qual

61


ele pertence, e por sua Prova de Associação, capaz de comprovar que o carimbo é um dos

elementos desse conjunto.

Tal abordagem permite à Âncora de Confiança operar de maneira periódica, publicando

Certificados de Autenticidade apenas ao fim desses períodos, de modo semelhante

ao que já ocorre na publicação de Listas de Certificados Revogados (LCRs) [9]. Algo

particularmente interessante caso, por exemplo, a Âncora de Confiança seja mantida offline

em uma Sala Cofre. Essa abordagem igualmente reduz o volume de informações

necessárias para a produção desses certificados.

4.2. Serviços de Suporte

Nesse sentido, a produção de Carimbos do Tempo Autenticados depende de três

serviços, o de emissão de carimbos do tempo e os de publicação e renovação de Certificados

de Autenticidade. O fornecimento desses serviços ainda requer a manutenção de

estruturas de dados pela ACT e pela Âncora de Confiança, respectivamente, o Repositório

de Provas de Associação (RPA) e o Repositório de Certificados para Conjuntos (RCC).

A emissão desses carimbos ocorre mediante a solicitação do usuário, seguindo

uma versão estendida do protocolo tradicional representada a seguir:

U −→ ACT : H(x)

ACT −→ U : {H(x), t}, Sign ACT ({H(x), t}) , p a

} {{ }

ts

Nessa versão estendida, a ACT registra o resumo criptográfico H(ts) de cada

carimbo do tempo emitido no RPA, e informa, por meio de uma extensão não assinada

do carimbo, o período pelo qual o seu Certificado de Autenticidade ficará disponível,

chamado de Período de Autenticação. Nesse registro, a função de resumo criptográfico

usada deve ser segura e igual aquela usada no carimbo.

A publicação do Certificado de Autenticidade de cada carimbo emitido ocorre no

início de seu Período de Autenticação e é precedida por uma fase de preparação, onde se

dá a solicitação e posterior produção do certificado para o conjunto ao qual ele pertence.

Tais Certificados para Conjuntos são solicitados periodicamente pela ACT.

Em cada solicitação a ACT calcula uma representação do conjunto de carimbos do

tempo registrados durante o período no RPA, enviando para a Âncora de Confiança um documento

eletrônico assinado contendo essa representação, e seus dados de identificação.

Por meio de tal solicitação a ACT declara ter emitido os carimbos do tempo ali representados.

A representação desses carimbos, por sua vez, é o nó raiz da Árvore de Merkle

formada a partir deles e calculada por meio de algoritmos como o TREEHASH [23].

Por igualmente operar de maneira periódica, a Âncora de Confiança apenas valida

e registra a solicitação no RCC, aguardando o fim do período para assinar o Certificado

de Autenticidade do conjunto ali representado. É com a publicação desse certificado e

da Prova de Associação correspondente, que termina a fase de preparação. Tais provas,

por sua vez, são os caminhos de autenticação de cada carimbo na Árvore de Merkle,

calculados pela ACT por meio de algoritmos de travessia como o de Szydlo [23].

Iniciado o Período de Autenticação, é possível obter o Certificado de Autenticidade

do carimbo por meio dos protocolos de solicitação de Provas de Associação e de

Certificados para Conjuntos. O primeiro é apresentado a seguir:

62


U −→ ACT : H(ts)

ACT −→ U : Auth ts

Nele, o usuário solicita a Prova de Associação de um carimbo, enviando o seu resumo

criptográfico H(ts). Ao receber o resumo, a ACT obtêm a Prova de Associação correspondente

no RPA e a retorna para o usuário. Certificados de Conjunto, por sua vez, são

obtidos através do seguinte protocolo:

U −→ Âncora : φ

Âncora −→ U : {id ACT , φ}, SignÂncora ({id ACT , φ})

} {{ }

sl φ

Nesse protocolo, o usuário solicita o Certificado para Conjuntos de um carimbo, enviando

a representação de seu conjunto. Ao receber a representação, a Âncora de Confiança

obtêm o Certificado para Conjuntos correspondente no RCC e o retorna para o usuário.

Tal representação pode ser calculada a partir da Prova de Associação do carimbo, empregando

o algoritmo para validação de caminhos de autenticação em Árvores de Merkle

[19].

Terminado o Período de Autenticação do carimbo, ocorre a destruição de sua

Prova de Associação pela ACT. Tal destruição tem por objetivo limitar os custos de armazenamento

relacionados a essas provas. Certificados para Conjuntos, por outro lado,

permanecem no RCC de modo a suportar futuras renovações do Certificado de Autenticidade

do carimbo.

A renovação de Certificados de Autenticidade ocorre mediante a solicitação do

usuário, e segue o protocolo a seguir:

U −→ Âncora : φ

Âncora −→ U : {id ACT , φ}, Sign ′ Âncora ({id ACT , φ})

} {{ }

sl ′ φ

Nele, o usuário solicita a renovação de seu Certificado de Autenticidade, enviando a

representação presente no Certificado para Conjuntos. Ao receber tal representação, a

Âncora de Confiança obtêm a nova versão do Certificado para Conjuntos no RCC e a

retorna para o usuário. O Certificado de Autenticidade é renovado pela substituição do

antigo Certificado para Conjuntos pelo novo.

Novas versões do Certificado para Conjuntos ficam disponíveis a medida que as

anteriores perdem sua validade. Tal problema ocorre com a revogação ou expiração do

certificado de chaves públicas da Âncora de Confiança, ou com o enfraquecimento do

esquema de assinatura usado no Certificado para Conjuntos. Nesses casos, cabe a Âncora

de Confiança contornar tais problemas e se preciso reassinar o certificado no RCC. Para

tanto, pode ser necessário que ela primeiramente renove seu certificado de chaves públicas

ou atualize seu esquema de assinatura.

Por fim, de modo a limitar os custos relacionados à renovação dos Certificados de

Autenticidade, ocorre periodicamente a otimização do Repositório de Certificados para

Conjuntos. Nessas otimizações são removidos do RCC todos os registros cuja função

de resumo criptográfico usada não seja mais resistente à segunda inversão. Quando essa

resistência é perdida, tanto o registro perde sua serventia, quanto o carimbo do tempo

perde sua capacidade de comprovar a integridade da informação datada.

63


4.3. Preservação de Assinaturas

A preservação de uma assinatura digital por meio de Carimbos do Tempo Autenticados

segue os seguintes passos, onde s, d, C s e R s , são, respectivamente, a assinatura, o

documento assinado, os certificados do caminho de certificação do signatário e os dados

de revogação atuais:

1. inicialização: adicionar um carimbo do tempo ts 1 sobre {s, d, C s , R s }, obtendo

{{s, d, C s , R s }, ts 1 , C 1 ts};

2. agendamento: agendar a sobreposição do carimbo. Essa sobreposição deve ocorrer

antes de o carimbo não poder mais ser renovado, sendo, em geral, agendada

para um momento próximo ao enfraquecimento da função de resumo criptográfico

usada;

3. autenticação: autenticar o carimbo durante o seu Período de Autenticação, obtendo

{{s, d, C s , R s }, ts 1 , sl 1 ts};

4. sobreposição: no momento agendado, validar ts 1 . Se inválido, renovar o carimbo.

Sendo ts 1 o carimbo possivelmente renovado, adicionar ts 2 sobre {{s, d, C s , R s },

ts 1 , sl 1 ts} obtendo {{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , C 2 ts}. Caso ts 1 já tenha perdido

sua validade, e sua renovação não seja possível, a preservação falha;

5. repetição: para os próximos carimbos, repetir os passos 2 e 3 enquanto for necessário

preservar a validade da assinatura. Dessa forma, na adição do n-ésimo

carimbo, obtêm-se {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n , C n ts}.

4.4. Validação de Assinaturas

Uma assinatura preservada {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n ,

C n ts} ou {{...{{{s, d, C s , R s }, ts 1 , sl 1 ts}, ts 2 , sl 2 ts}, ...}, ts n , sl n ts} é válida se:

• o carimbo do tempo ts n for atualmente válido. Caso já esteja inválido, pode ser

preciso autenticar e/ou renovar o carimbo;

• para todo ts i , com 1 ≤ i ≤ n − 1, ts i era válido na data indicada por ts i+1 , sendo

que a autenticidade de cada carimbo deve ser verificada através de seu Certificado

de Autenticidade.

• a assinatura s era válida na data indicada por ts 1 .

Um Certificado de Autenticidade {Auth ts , sl φ }, por sua vez, é válido se:

• seu caminho de autenticação, presente na Prova de Associação, for válido;

• a assinatura da Âncora de Confiança, presente no Certificado para Conjuntos, for

válida.

5. Análise

Os principais benefícios trazidos pelo uso de Carimbos do Tempo Autenticados

são o aumento na eficiência e confiabilidade na preservação das assinaturas digitais. Um

outro benefício está na possibilidade de validação off-line dessas assinaturas, permitindo

que essa ocorra em dispositivos sem conexão de rede. O suporte à emissão, autenticação

e renovação desses carimbos, todavia, implica em custos adicionais para a Autoridade de

Carimbo do Tempo (ACT) e Âncora de Confiança.

64


5.1. Custos na Preservação e Validação de Assinaturas

O esquema de datação proposto é capaz de reduzir os custos na preservação e

validação de assinaturas digitais por diminuir tanto a quantidade de carimbos adicionados

durante a preservação, quanto os custos por carimbo adicionado. Tais melhorais podem

ser observadas considerando o modelo matemático apresentado abaixo.

θ U (p p ) =

n ∑ pp

(α(ts i ) + α(V i )) (1)

i=1

n pp =


pp

p ts


(2)

A função 1 reflete as informações armazenadas durante a preservação por carimbos

do tempo, onde o custo de armazenamento após um certo período de preservação p p

é dado pelo espaço necessário para cada carimbo adicionado α(ts i ), bem como para as

informações necessárias a sua validação, representado por α(V i ). O número de carimbos

adicionados n pp , por sua vez, é dado pelo período de preservação divido pelo tempo médio

pelos quais os carimbos permanecem válidos, até que a sua sobreposição seja necessária.

A quantidade de carimbos do tempo adicionados é reduzida graças as operações

de autenticação e renovação que permitem postergar a sobreposição dos carimbos. Graças

a elas, dentre todos os problemas que tradicionalmente demandariam essa sobreposição,

fica restando apenas um, o enfraquecimento da função de resumo criptográfico usada,

geralmente um dos últimos a ocorrer. Essa redução pode ser observada considerando a

forma como o período entre as sobreposições passa a ser calculado.

Tradicionalmente, esse período pode ser aproximado pelo prazo de validade médio

dos certificados da ACT, pois a sua expiração tende a ser o primeiro problema a demandar

a sobreposição do carimbo. De maneira mais realista, é usual considerar a metade desse

prazo, pois os carimbos tendem a ser obtidos tanto em seu início quanto no fim. Nos Carimbos

do Tempo Autenticados, por outro lado, esse período é dado pela metade daquele

pelo qual as funções de resumo criptográfico usadas geralmente permanecem seguras.

Assim, o número de carimbos adicionados diminui pois o período entre as

sobreposições aumenta, uma vez que a segurança de funções de resumo criptográfico

tende a durar mais que certificados. Algo que pode ser observado ao se considerar

recomendações técnicas sobre o período de validade desses certificados [4, 20], bem

como o histórico das principais funções de resumo criptográficas até então publicadas.

Enquanto o NIST, por exemplo, recomenda prazos de até 3 anos, funções de resumo tendem

a permanecer seguras por mais de 10 anos [11, 22].

Os custos por carimbo adicionado, por sua vez, são reduzidos graças a operação de

autenticação que modifica a forma como a autenticidade desses carimbos deve ser verificada

bem como as informações necessárias para essa verificação. O que tradicionalmente

ocorreria pela validação da assinatura do carimbo e de seu caminho de certificação X.509,

passa a ocorrer pela validação de seu Certificado de Autenticidade, que tende a requerer

tanto um espaço de armazenamento, quanto um tempo para validação, menores.

Os custos de armazenamento por carimbo são reduzidos pois, enquanto os tradicionais

requerem a guarda de cada certificado do caminho de certificação, bem como dos

65


Variável Valor Variável Valor Variável Valor

α(ts) 700 bytes p H 10 anos n i ts, n tr

ts 604.800 carimbos

α(C ts ) 3700 bytes α(Auth ts ) 380 bytes p tr 7 dias

α(R ts ) 111600 bytes α(sl φ ) 500 bytes n pa

tr 4 períodos

p ACT 3 anos α(h ts ) 20 bytes n i ACT 100 ACTs

Tabela 1. Valores usados nas simulações.

dados de revogação relacionados, tais como Listas de Certificados Revogados (LCR) ou

respostas OCSP, nos Carimbos do Tempo Autenticados é necessário apenas o armazenamento

do Certificado de Autenticidade. Esse último formado por um Certificado para

Conjuntos, e por uma cadeia de resumos criptográficos que cresce logaritmicamente em

função do número de carimbos que o certificado autentica.

O tempo para validar o carimbo, por sua vez, é menor principalmente por tornar

desnecessária a obtenção de informações complementares pela rede. Nos carimbos tradicionais

isso é requerido para permitir a validação do caminho de certificação com dados

de revogações atuais. Nos Carimbos do Tempo Autenticados isso não ocorre porque o

Certificado de Autenticidade é auto-contido. Nesse caso, considerando a implementação

tradicional, onde uma Âncora de Confiança é válida se estiver cadastrada no repositório

de âncoras do usuário.

De modo a estimar os ganhos trazidos na prática por essa proposta, foram realizadas

simulações da preservação de uma assinatura por 50 anos, empregando valores

tipicamente encontrados em infraestruturas de chaves públicas (ICP) de grande porte.

Dois desses valores requerem maiores considerações, sendo eles o prazo de validade dos

certificados da ACT e o período de uso das funções de resumo criptográfico.

O prazo de validade desses certificados é o prazo máximo citado em

recomendações técnicas como a do NIST [4], sendo, igualmente, aquele usado na Infraestrutura

de Chaves Públicas Brasileira (ICP-Brasil). O período de uso das funções de

resumo criptográfico, por sua vez, considera o histórico das principais funções já publicadas,

assim como previsões quanto a segurança das funções atualmente em uso [11, 5, 22].

Tal período pode ser considerado conservador, uma vez que no esquema proposto

a resistência à segunda inversão é suficiente para a renovação dos carimbos, e essa tende

a se perder certo tempo após tais funções serem consideradas inseguras. Considerando

ataques de força bruta, por exemplo, a quebra da resistência à colisão, que já tornaria a

função insegura, requer o cálculo de 2 n/2 resumos criptográficos, sendo n o número de

bits do resumo. A quebra da resistência à segunda inversão, por outro lado, requer 2 n

operações.

Os valores relacionados ao esquema proposto, usados na simulação, por sua vez,

foram obtidos a partir de uma implementação dos Carimbos do Tempo Autenticados, realizada

sobre uma especificação ASN.1 dos protocolos. Esses valores, assim como aqueles

usados na configuração desse esquema de datação, são apresentados na tabela 1. Como

alguns deles crescem com o tempo, assume-se que sejam os valores médios encontrados

durante o período de preservação, considerando que tenha começado no passado e que

continue no futuro.

66


Nas simulações, os custos de armazenamento com carimbos tradicionais chegaram

a 3,65 MB. Na preservação com Carimbos do Tempo Autenticados, por outro lado,

esse custo foi de apenas 15,42 KB, uma redução de 99,59%. Essa redução foi particularmente

influenciada pelo espaço necessário para o armazenamento das informações de

validação desses carimbos, esse foi 99,23% menor que o requerido pelos carimbos tradicionais.

5.2. Confiabilidade na Preservação de Assinaturas

O esquema de datação proposto é capaz de aumentar a confiabilidade do processo

de preservação por carimbos do tempo por tornar toleráveis a maioria dos problemas que

tradicionalmente levariam a preservação a falhar. Particularmente, aqueles problemas que

impediriam futuras sobreposições do último carimbo até então adicionado, por torná-lo

inválido antes do previsto no agendamento. Tradicionalmente tais problemas compreendem:

1. revogação do certificado da Âncora de Confiança;

2. quebra do esquema de assinatura usado pela Âncora;

3. revogação do certificado de alguma das ACs do caminho de certificação;

4. quebra de algum esquema de assinatura usado por essas ACs;

5. revogação do certificado da ACT;

6. quebra do esquema de assinatura usado pela ACT;

7. quebra da função de resumo criptográfico usada pela ACT.

No caso dos Carimbos do Tempo Autenticados, a maioria desses problemas (3,

4, 5 e 6) já é anulada na autenticação do carimbo. Os restantes são tolerados por meio

da operação de renovação do carimbo que permite restabelecer a sua validade quando

perdida. As únicas exceções são a revogação da Âncora de Confiança, devido a perda de

integridade do Repositório de Certificados para Conjuntos (RCC), e a quebra da função

de resumo criptográfico usada no carimbo pela ACT. Particularmente, a perda de sua

resistência à segunda inversão. Nesses casos, mesmo a renovação do carimbo não é mais

possível.

5.3. Serviços de Suporte

Apesar dos benefícios oferecidos por esse novo esquema de datação, seu suporte

implica em custos adicionais para a ACT e Âncora de Confiança. No caso da ACT, tais

custos estão particularmente relacionados à produção e armazenamento das Provas de

Associação, no Repositório de Provas de Associação (RPA).

A produção dessas provas possui custos de memória e processamento que dependem

principalmente do algoritmo adotado para a travessia da Árvore de Merkle. No de

Szydlo [23], por exemplo, a geração de cada caminho de autenticação requer o cálculo de

no máximo 2log 2 (n) resumos criptográficos, e o armazenamento de menos de 3log 2 (n)

resumos em memória, onde n é o número de carimbos do tempo emitidos no período. Os

custos de armazenamento dessas provas, por sua vez, podem ser representados por meio

do seguinte modelo:

θ ACT (p o ) =

tr−1 n

∑ ∑

i ts

(

i=tr−n otr j=1

α(Auth i,j

ts )) +

n tr

ts


α(h i ts) (3)

i=1

67


tr − npa tr + |tr − n pa

tr |

n otr = tr −

2

⌈ ⌉

po

tr =

p tr

(4)

(5)

A função 3 reflete as informações armazenadas no RPA durante as operações da ACT.

Nessa função, o custo de armazenamento após um período de operação p o , é dado pelo

caminho de autenticação de cada um dos n i ts carimbos emitidos, nos n otr períodos anteriores

que ainda estão em Período de Autenticação, somado ao espaço necessário para o

resumo criptográfico h i ts de cada um dos n tr

ts carimbos emitidos no período atual tr. Onde

p tr é a duração de um período e n pa

tr é a duração do Período de Autenticação em número

de períodos.

No caso da Âncora de Confiança, o suporte a esse esquema de datação traz custos

relacionados, principalmente, à reassinatura dos Certificados para Conjuntos e armazenamento

desses certificados no RCC. A reassinatura dos certificados possui custos relacionados

principalmente ao esquema de assinatura usado e ao número de certificados emitidos

e ainda suportados. Número esse que depende da quantidade de ACTs em operação, bem

como da duração dos períodos da Âncora de Confiança. Os custos de armazenamento

desses certificados, por sua vez, podem ser representados por meio do seguinte modelo:

θÂncora (p o ) =

ar−1 n


i ACT


(

i=0 j=1

n ar

r∑

α(sl i,j

φ )) +

i=1

α(r i ) (6)

ar =


po

p ar


(7)

A função 6 reflete as informações armazenadas no RCC durante as operações da Âncora

de Confiança, desconsiderando as otimizações periódicas do RCC. Nessa função, o custo

de armazenamento após um período de operação p o é dado pelos Certificados para Conjuntos

até então publicados para as n i ACT ACTs em operação, somado ao espaço necessário

para cada uma das n ar

r solicitações recebidas no período atual ar. Onde p ar é

a duração de um período de Âncora de Confiança.

De modo a estimar os custos trazidos na prática para a ACT e Âncora de

Confiança, foram realizadas simulações das operações dessas entidades por 10 anos. Nessas

simulações foram igualmente considerados os valores da tabela 1, sendo que o número

de carimbos emitidos em cada período da ACT assume a taxa de um carimbo por segundo

durante todo o período.

Nas simulações os custos de armazenamento para a ACT chegaram a 888 MB, se

mantendo praticamente constantes devido a remoção das Provas de Associação ao fim do

Período de Autenticação dos carimbos emitidos. No caso da Âncora de Confiança, foram

necessários 24 MB para o armazenamento dos Certificados para Conjuntos emitidos ao

longo desses 10 anos. Nesse caso, não foi considerada a operação de otimização do RCC,

que removeria registros conforme a função de resumo criptográfico usada se tornasse

insegura.

68


6. Conclusões

O uso de documentos eletrônicos vem crescendo em importância nas relações

entre os cidadãos, empresas e governos, tornando a preservação de assinaturas digitais

uma questão fundamental no caso daqueles documentos que precisam ser preservados

por um longo período de tempo. Assim, várias estratégias já foram propostas, sendo a

sobreposição de carimbos do tempo a principal delas.

Neste trabalho aumentamos a eficiência e confiabilidade dessa estratégia de

preservação por meio de um novo esquema de datação, os Carimbos do Tempo Autenticados.

Tal esquema reduz drasticamente os custos na preservação e validação de assinaturas

digitais, além de oferecer maiores garantias quanto a preservação dessas assinaturas pelo

tempo necessário.

Esses benefícios, além da possibilidade de validação off-line das assinaturas, tornam

esse esquema de datação particularmente interessante para dispositivos com poucos

recursos computacionais, ou na preservação de grandes volumes de documentos. Tal esquema

pode ser usado não só na preservação de assinaturas digitais, mas igualmente em

outras áreas onde carimbos do tempo são empregados. Exemplos dessas áreas incluem a

proteção da propriedade intelectual, o comércio e votação eletrônicos.

Trabalhos futuros podem focar na análise formal dos protocolos criptográficos

envolvidos nesse esquema de datação, bem como na implementação de mecanismos de

herança que permitam migrar o conteúdo dos Repositórios de Certificados para Conjuntos

para novas Âncoras de Confiança. Outros tópicos incluem o uso dos Certificados de

Autenticidade para a otimização de assinaturas de curto prazo, bem como a integração das

operações de autenticação e renovação em outras estratégias de notarização, aumentando

sua eficiência e confiabilidade.

Referências

[1] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp

Protocol (TSP). RFC 3161 (Proposed Standard), August 2001. Updated by RFC 5816.

[2] R. Anderson. Invited lecture. In Fourth Annual Conference on Computer and Communications Security,

ACM, 1997.

[3] A. Ansper, A. Buldas, M. Roos, and J. Willemson. Efficient long-term validation of digital signatures. In

Public Key Cryptography, pages 402–415. Springer, 2001.

[4] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid. Nist sp800-57: Recommendation for key

management–part 1: General (revised). Technical report, NIST, 2007.

[5] E. Barker and A. Roginsky. Draft nist sp800-131: Recommendation for the transitioning of cryptographic

algorithms and key sizes. Technical report, NIST, jan 2010.

[6] D. Bayer, S. Haber, and W.S. Stornetta. Improving the efficiency and reliability of digital time-stamping.

Sequences II: Methods in Communication, Security, and Computer Science, pages 329–334, 1993.

[7] K. Blibech and A. Gabillon. A new timestamping scheme based on skip lists. Computational Science and

Its Applications-ICCSA 2006, pages 395–405, 2006.

[8] D. Chaum and S. Roijakkers. Unconditionally-secure digital signatures. Advances in Cryptology-

CRYPT0’90, pages 206–214, 1991.

69


[9] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. Internet X.509 Public Key Infrastructure

Certificate and Certificate Revocation List (CRL) Profile. RFC 5280 (Proposed Standard),

May 2008.

[10] R.F. Custodio, M.A.G. Vigil, J. Romani, F.C. Pereira, and J. da Silva Fraga. Optimized Certificates–A

New Proposal for Efficient Electronic Document Signature Validation. In Public Key Infrastructure:

5th European PKI Workshop: Theory and Practice, EuroPKI 2008 Trondheim, Norway, June 16-17,

2008, Proceedings, page 49. Springer-Verlag New York Inc, 2008.

[11] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); Algorithms

and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric

algorithms, Nov 2007.

[12] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); CMS

Advanced electronic Signatures (CAdES), Nov 2009.

[13] European Telecommunications Standards Institute. Electronic Signatures and Infrastructures (ESI); XML

Advanced electronic Signatures (XAdES), Jun 2009.

[14] T. Gondrom, R. Brandner, and U. Pordesch. Evidence Record Syntax (ERS). RFC 4998 (Proposed Standard),

August 2007.

[15] S. Haber and W. Stornetta. How to time-stamp a digital document. Advances in Cryptology-CRYPT0’90,

pages 437–455, 1991.

[16] M.K. Just. On the temporal authentication of digital data. PhD thesis, Carleton University, 1998.

[17] D. Lekkas and D. Gritzalis. Cumulative notarization for long-term preservation of digital signatures. Computers

& Security, 23(5):413–424, 2004.

[18] H. Massias and J.J. Quisquater. Time and cryptography. US-patent n, 5:12, 1997.

[19] R.C. Merkle. Protocols for public key cryptosystems. 1980.

[20] D. Pinkas, N. Pope, and J. Ross. Policy Requirements for Time-Stamping Authorities (TSAs). RFC 3628

(Informational), November 2003.

[21] G.J. Popek and C.S. Kline. Encryption and secure computer networks. ACM Computing Surveys (CSUR),

11(4):331–356, 1979.

[22] B. Preneel. The First 30 Years of Cryptographic Hash Functions and the NIST SHA-3 Competition. Topics

in Cryptology-CT-RSA 2010, pages 1–14, 2010.

[23] Michael Szydlo. Merkle tree traversal in log space and time. In In Eurocrypt 2004, LNCS, pages 541–554.

Springer-Verlag, 2004.

[24] M. A. G. VIGIL, N. SILVA, R. MORAES, and R. F. CUSTODIO. Infra-estrutura de chaves públicas

otimizada: Uma icp de suporte a assinaturas eficientes para documentos eletrônicos. In Simpósio

Brasileiro em Segurança da Informação e de Sistemas Computacionais, pages 129–142, 2009.

70


SCuP - Secure Cryptographic Microprocessor

Roberto Gallo 12 , Henrique Kawakami 1 ,

Ricardo Dahab 2∗

1 KRYPTUS Security Solutions Ltd., Campinas, SP, Brazil

2 Campinas State University, Campinas, SP, Brazil

{gallo,rdahab}@ic.unicamp.br, {gallo,kawakami}@kryptus.com

Abstract. In this paper we present SCuP - the Secure Cryptographic Micro-

Processor with secure code execution (encrypted, signed). SCuP is an asymmetric

multicore processor for general applications with several innovative protection

mechanisms against logical and physical attacks. Among the main processor

features are the hardware firewall (HWF) and the deep inspection/introspection

mechanism (MIP) along with the secure execution packages (PES). SCuP has

been validated in simulations and in FPGAs and its semiconductor diffusion will

be done in the next few months.

Resumo. Neste artigo apresentamos o SCuP - Processador Criptográfico com

Execução Segura de Código (cifrada, assinada). O SCuP é um processador de

múltiplos núcleos assimétrico para aplicações gerais, que apresenta diversos

mecanismos inovadores de proteção contra ataques lógicos e físicos ao processador.

Dentre as principais características do processador estão o firewall

de hardware (HWF) e o mecanismo de inspeção/introspecção profunda (MIP)

combinados com os pacotes de execução seguros (PES). O SCuP foi validado

em simulações e em FPGAs e deverá seguir para difusão semicondutora nos

próximos meses.

1. Introdução

A importância da segurança nos sistemas baseados em hardware e software é bem estabelecida

e dispensa justificativas. Entretanto, apesar de sua relevância, sistemas computacionais

seguros têm se mostrado supreendentemente difíceis de serem obtidos. Parte

desta dificuldade pode ser atribuída ao fato de que segurança mais do que uma área do

conhecimento, é uma transversal que perpassa diversas áreas, como Teoria do Números,

Codificação Segura, Criptografia, Estatística e Física dentre outras. Desta forma, até o

momento não existe uma teoria unificada para Segurança, o que explica as recorrentes

falhas reportadas em toda sorte de sistemas.

O SCuP foi desenvolvido dentro da visão mais ampla de segurança e que considera

que quaisquer componentes dos sistemas podem conter defeitos de segurança.

Nossa Contribuição Neste artigo apresentamos o SCuP - o Secure Cryptographic

Microprocessor, um processador de uso geral cuja arquitetura foi projetada para garantir

altos níveis de proteção e resiliência mesmo contra os adversários mais motivados com

um cenário de ataques ampliado. Entre as características que tornam o SCuP único estão:

i) o emprego de múltiplos núcleos com processamento assimétrico; ii) mecanismos de

71


inspeção e introspeção de software; iii) suporte a mecanismos de reparação dinâmica de

software; e iv) mecanismos de execução segura de pacotes.

Organização do Artigo Na Seção 2 fazemos uma ampla revisão de problemas e

soluções de sistemas seguros; na Seção 3 apresentamos a arquitetura do SCuP e os seus

componentes; na Seção 4 apresentamos alguns resultados de implementação; a Seção 5

conclui e apresenta algumas possibilidades de trabalhos futuros.

2. O Problema e Trabalhos Relacionados

Processadores e sistemas seguros estão relacionado com, entre outras, as áreas de: i)

arquiteturas seguras de hardware; ii) co-processadores seguros; iii) prevenção, detecção e

recuperação de violação de segurança; iv) métricas de segurança; e v) interfaces seguras.

Co-Processadores Criptográficos

Os trabalhos relacionados mais relevantes, que abrangem mais de uma área mencionada,

incluem o trabalho pioneiro do desenvolvimento do módulo criptográfico IBM4758 [4],

precursor de diversos dos mecanismos de segurança atualmente empregados em hardware

seguro, principalmente do ponto de vista de segurança física. O IBM4758 é um dispositivo

(placa) PCI, multi-chip, com funções de Hardware Security Module (HSM) e também

capaz de executar programas de usuários, previamente assinados, em seu processador com

arquitetura 80486.

Apesar de seu elevado nível de segurança física, o IBM4758 é inapropriado para

diversos cenários de uso. Neste sentido, a arquitetura AEGIS [20] representa uma evolução

importante ao propor um processador (em um único componente) capaz de realizar a

execução segura de código utilizando os conceitos de cadeia de confiança (que parte de

um processo de boot seguro) e o isolamento de processos seguros daqueles não seguros

por meio de modificações de arquitetura em um núcleo de processador MIPS . O AE-

GIS também emprega de maneira inovadora a proteção da memória RAM (off-chip) do

processador por meio da cifração e autenticação do conteúdo de memória.

O processador Cerium [2] é uma outra proposta também relevante, menos completa

do ponto de vista de arquitetura, mas que traz um benefício importante: saídas certificadas

(assinadas) da execução de aplicações. Com isso, entidades externas (clientes ou

atestadores) podem confiar nos resultados da computação através da verificação das assinaturas

produzidas. Há uma clara diferença de visão em relação aos trabalhos anteriores:

o interessado na integridade de um sistema não necessariamente é o seu proprietário, a

exemplo de aplicações de DRM (Digital Rights Management).

Execução Segura de Código

As aplicações de DRM estão sujeitas a um modelo de ameaças (threat model) particularmente

interessante: se por um lado conteúdo (aplicações, músicas, filmes) pode custar

milhões de dólares para ser produzido, o ganho do adversário individual com a pirataria

do mesmo conteúdo é ordens de grandeza menor; ou, de outra forma, a motivação de um

72


adversário para copiar alguns arquivos de música é muito limitada, em especial se o custo

do “ataque” for proporcional ao número de arquivos copiados.

Esse modelo de ameaças foi aquele utilizado na concepção da geração atual do

padrão do Trusted Platform Module (TPM) do Trusted Computing Group (TCG) [22],

a plataforma (hardware + software) padrão de mercado para computação confiável em

dispositivos como computadores pessoais e aparelhos celulares. O TPM-TCG é um periférico

soldado à placa mãe do sistema e que possui capacidades de assinatura digital,

verificação de assinatura e software measurement. Em um sistema habilitado, o TPM

pode ser utilizado para a verificação da cadeia de boot do sistema e, após inicializado, na

verificação (measurement) da integridade das aplicações em execução.

A proposta do TPM tem alguns méritos: i) tem baixo custo; ii) não requer refatoração

de código legado; e iii) vai no caminho certo ao considerar tanto integridade de binários

como de imagens em execução. Por outro lado, possui sérias limitações: i) é um dispositivo

escravo de barramento, podendo ser completamente ignorado pelo sistema, e também

não possui poder de inspeção; ii) possui arquitetura similar a de um smartcard, com barramento

LPC, resultando em baixa banda de comunicação com sistema e baixo poder

computacional; iii) pode ser subvertido por meio de modificações na BIOS do sistema (na

sessão CRTM); e iv) não considera sigilo, relegando às aplicações essa tarefa.

De forma a melhorar o perfil de segurança sem aumento considerável de custos,

Costan et al [3] propuseram e implementaram (utilizando um processador Javacard) o

Trusted Execution Module (TEM), capaz de executar código seguro no próprio módulo,

através de Secure Execution Closure Packs (SECpacks). Os SECpacks permitem que

aplicações de tamanho arbitrário, especialmente escritas, sejam fatoradas em pequenos

módulos e executadas no ambiente embarcado seguro (smartcards, processadores seguros)

ao custo de operações de E/S adicionais e da degradação de performance que acompanha

a fatoração.

O emprego de pacotes de execução segura no TEM remonta, possivelmente, ao

IBM4758, mas foi no IBM Cell [19], utilizado no Sony Playstation 3, que ela foi utilizada

de uma forma mais consistente. O Cell é um processador multi-núcleo assimétrico

especialmente voltado para o mercado de entretenimento, onde poder de processamento

e proteção de conteúdo têm prioridades altas. De especial interesse no Cell são os Synergistic

Processing Elements (SPE), responsáveis pelo processamento de alto desempenho

do processador. Cada SPE pode ser colocado em modo de execução seguro (com código e

dados assinados e cifrados), isolado dos demais núcleos, no modo secure processing vault

- com memória interna própria. Neste modo nenhum outro núcleo é capaz de inspecionar

ou alterar código ou dados em execução. Os ganhos são claros: aumento do nível de

proteção contra pirataria ao diminuir o risco de que fragilidades nos softwares executando

nos demais núcleos sejam utilizadas para atacar o SPE no modo vault.

A execução segura de pacotes pode ser vista como um tipo especial de isolamento

de threads, ou execução segura de threads, onde o número de processos executando simultaneamente

no processador é limitado ao número de núcleos; ou, de outra forma, threads

seguras não coexistem com threads normais em um mesmo núcleo.

A execução de threads seguras (ou isoladas) simultaneamente em um mesmo

núcleo foi implementada tanto na proposta do AEGIS por meio de instruções e modos

73


de execução privilegiados, como mais recentemente na arquitetura SP [9, 13]. A arquitetura

SP, no entanto é de uso mais geral e minimalista e pode ser aplicada com menor

número de intervenções em arquiteturas de processadores já existentes, como as famílias

x86 e SPARC. A Arquitetura SP utiliza alterações de instruction sets e a adição de componentes

de cifração de memória; e, utilizando o proposto Trusted Software Module, um

sistema operacional seguro minimalista, provê serviços de confidencialidade e atestação

remotos.

Arquiteturas para Execução Monitorada

Apesar de não apontado pelo trabalho de Lee [9], podemos conjecturar que, com modificações

no TSM, a arquitetura SP (e também na pilha de software do AEGIS) poderia ser utilizada

para introspecção de software entre processos. Esse uso, no entanto, parte do princípio

de que o sistema verificador (SV) não sofre das mesmas fragilidades que o sistema em

verificação (SEV), e que também não é influenciado por alguma execução faltosa. Para

diminuir riscos implícitos de segurança provenientes de problemas de implementação e

arquiteturas de solução complexas, muito se fala [18, 9] da utilização de bases minimalistas

de computação confiada onde a pilha de software (BIOS segura, S.O. seguro,

aplicações seguras...) é reduzida a alguns poucos milhares de linhas de código.

Entretanto, tanto quanto saibamos, nenhum trabalho tem se atentando ao fato de

que as arquiteturas de hardware de processadores (e sistemas) são descritas em centenas

de milhares ou mesmo milhões de linhas de código de linguagens de descrição de hardware

e, portanto, estão sujeitas a problemas de implementação tanto quanto os softwares,

na medida em que segurança não é uma consideração comum no mundo dos sintetizadores

de hardware. Desta forma, é temerário esperar que um sistema típico não possua

problemas ocultos de segurança em termos de implementação.

Trabalhos como CuPIDS [23] e CoPilot [15], por sua vez, caminham por uma linha

de pesquisa distinta: utilizam pares de sistemas, um monitor de (políticas) de segurança

e outro monitorado. O CoPilot é voltado para o monitoramento e recuperação de ataques

de rootkits. Ele é implementado por meio de uma placa PCI-mestre de barramento (sistema

monitor), conectada a um hospedeiro (sistema monitorado) e é capaz de inspecionar

todo o seu espaço de endereçamento.

O monitor não compartilha recursos com o sistema monitorado; assim, em caso de

instalação de um rootkit no sistema principal, a placa PCI é capaz de verificar que houve

modificações no espaço de endereçamento do kernel do sistema e assim corrigir o sistema

e avisar uma estação de monitoramento externa. Por possuírem arquiteturas completamente

diferentes, monitor e monitorado também minimizam a possibilidade de

compartilharem defeitos.

Já as limitações do CoPilot estão principalmente ligadas à degradação de desempenho

causada pelo processamento, pelo monitor, do espaço de endereçamento do sistema

monitorado, o que restringe a usabilidade da proposta à verificação do kernel do sistema

em RAM. O custo do hardware também é um problema.

No CuPIDS, por sua vez, a ideia de sistema independente de monitoramento é

revisitada com uma nova arquitetura de hardware e novos objetivos de monitoramento.

74


Com o uso de uma motherboard com dois processadores, seus autores dividem o sistema

em porção monitora e porção monitorada. Ao contrário do CoPilot, que tem como alvo

o próprio sistema operacional, no CuPIDS existe, para cada serviço implementado na

porção monitorada, um co-serviço de monitoramento na porção monitora (possivelmente

por meio de uma política EM-enforceable [18]). Os potenciais problemas com o CuPIDS

estão ligados à garantia da própria integridade da porção monitora. Sendo implementados

em processadores de uso geral, estão sujeitos a diversos tipos de ataque, como substituição

de binários, por exemplo.

Integridade dos Sistemas

Em aplicações onde a integridade dos serviços prestados pelo sistema (mais do que a

integridade do próprio sistema) é preocupação primordial, diferentes técnicas têm sido

utilizadas, em especial na área de sistemas de votação. Sistemas de votação eletrônica

devem atingir simultaneamente objetivos aparentemente inconciliáveis: i) um voto por

eleitor; ii) voto registrado conforme a intenção (do eleitor); iii) voto contado conforme o

registro; iv) sigilo do voto; v) verificabilidade do voto; e vi) resistência à coerção [17].

Quaisquer tentativas de se atingir estes objetivos têm implicações diretas na concepção

das máquinas de votação (digital recording electronic voting machine - DRE).

Admite-se, como regra, que os sistemas não são confiáveis e que podem ser adulterados.

Desta forma, mecanismos eficientes de verificação da integridade do sistema e

dos próprios serviços devem ser implementados e imediatamente acessíveis aos interessados.

A integração entre integridade dos sistemas e os usuários foi explorada em trabalhos

como VoteBox Nano [12], assim como em [5, 6], utilizando a noção de caminhos confiados

e classe de nível de confiança.

A confiança obtida pela verificação do sistema em produção, no entanto, sempre

está ligada (e limitada) pela confiança nas fases de desenvolvimento, ou no ciclo de vida,

do dispositivo, como apontam Mirjalili e Lenstra [10]. Neste sentido, padrões como o

FIPS 140-2 [11] e o Common Criteria [21] têm papeis relevantes. O padrão FIPS 140-2

apresenta um conjunto de requisitos e recomendações que um módulo criptográfico de uso

específico (geração, guarda e uso de chaves criptográficas) deve obedecer. Apesar de não

fixar diretamente nenhum item de arquitetura de tais módulos, o padrão é relevante por ser

completo nos diversos aspectos de segurança que um módulo deve satisfazer (proteções

lógicas, físicas, controle de acesso, sensoriamento, auto-testes, etc).

Verificação dos Sistemas e Padrões

O Common Criteria, por sua vez, é um meta-padrão, que define templates sobre os quais

perfis de segurança os (security profiles) devem ser elaborados, e que descreve as características

esperadas de um dado sistema (seguro), o qual é mais tarde certificado com base

no próprio perfil. A principal contribuição do CC é a listagem ampla de itens que devem

ser cobertos por um perfil de segurança.

No quesito verificação, de uma forma mais ampla, a nossa proposta está marginalmente

relacionada aos trabalhos de verificação formal de sistemas, onde componentes

75


(lógicos) de software e hardware são descritos formalmente e técnicas de obtenção de

provas são utilizadas para se determinar a validade das especificações. Apesar de poderosas,

no entanto, tais técnicas têm complexidade NP-difícil ou indecidível [7, 8, 16],

dificultando o seu uso na prática. Desta forma, técnicas totalmente informais ou mistas

são utilizadas na verificação das propriedades dos sistemas [1]. Neste sentido, técnicas

de verificação lógica de segurança baseadas em simulação, em especial via introspecção

de máquinas virtuais, têm se mostrado úteis, como mostram os trabalhos de Payne [14] e

Dwoskin [13].

3. Arquitetura do SCuP

A Figura 1 mostra a arquitetura do SCuP. Nela é possível identificar dois núcleos SPARC

de 32 bits, baseados no Leon 3, instanciados de maneira assimétrica, o Application Core

- AC, e o Secure Core - SC. Estes dois núcleos estão ligados aos barramentos internos

AHB (e APB) modificados. Estes barramentos implementam um firewall de hardware,

programado por SC e que limita o acesso dos mestres de barramento aos periféricos.

Os componentes periféricos encontrados no processador são divididos em dois

principais grupos: componentes sem função de segurança (caixas mais claras e que incluem,

dentre outros, USB, PCI, Controle de DDR2) e componentes com funcionalidades

seguras (como cifradores de memória externa e o TRNG (true random number generator)).

No que se segue apresentamos uma breve descrição dos componentes do SCuP e

em seguida algumas das funcionalidades de segurança permitidas pela nossa plataforma.

3.1. Componentes do Sistema

3.1.1. Os Núcleos AC e SC

A arquitetura do SCuP permite que coexistam diversos (n) Núcleos de Aplicação (AC)

com diversos (m) Núcleos de Segurança (SC). Na Figura 1, n = m = 1. O AC é

um núcleo completo para uma CPU, com unidade de ponto flutuante, cache de dados e

programa e MMU, e que serve para a execução de aplicações de usuários convencionais

como, por exemplo, executar um S.O. Linux com uma aplicação de votação. O AC é

controlado e monitorado pelo SC, com mecanismos que serão descritos mais a adiante.

O SC, por sua vez, é um núcleo minimalista e que foi modificado para ser uma das

raízes de confiança do sistema. Para minimizar possibilidades de defeitos de segurança no

próprio VHDL do processador, FPU e MMU foram eliminados, ao mesmo tempo em que

uma memória interna, de acesso exclusivo ao núcleo foi adicionada. Esta memória, chamada

de scratchpad, é essencial na segurança do sistema e foi projetada para permitir que

operações que demandam sigilo (manipulação de chaves e outros parâmetros críticos de

sistema) pudessem ser realizados com a menor possibilidade de vazamento e sem a necessidade

de memória externa. O SC tem capacidade para executar um sistema operacional

mínimo, seguindo o princípio da minimização da Trusted Computing Base (TCB).

O SC tem controle sobre todos os outros componentes do SCuP, permitindo, dentre

outros, o Mecanismo de Inspeção/Introspecção Profunda (MIP) e a Sequência de Boot

Seguro.

76


A arquitetura do SCuP mostrando os seus diversos módulos e pe-

Figura 1.

riféricos.

77


3.1.2. O Firewall de Hardware

O Firewall de Hardware (HWF) permite que o SC controle o acesso dos mestres de barramentos

internos do SCuP aos periféricos. Esta funcionalidade tem como principal objetivo

impedir que componentes (de software, de hardware) comprometidos tenham acesso

a canais de comunicação com dados em claro.

O HWF funciona por meio da programação de múltiplas regras de firewall que

contém as seguintes informações: [mestre, faixa-de-endereços, permissões]. Nesta regra,

o acesso do “mestre” à “faixa-de-endereços” está sujeita às respectivas “permissões”.

Um exemplo de uso é nos casos de protocolos de votação. Se por um lado toda

a parte gráfica e de controle de periféricos do software de votação pode ser executado no

AC, esta mesma pilha de software poderá conter defeitos que permitam que a entrada do

usuário (o voto digitado) vaze ou seja capturado por uma aplicação mal-intencionada. Em

nossa arquitetura, a captura do voto e a sua cifração podem ficar por conta do SC, que,

programando o HWF, impede o acesso pelo AC ao periférico PS/2 ao mesmo tempo que

permite o uso para si. Obviamente a aplicação precisa ser adaptada para este tipo de uso.

O HWF ainda impede que transações malignas, advindas dos periféricos-mestre

de barramento externos ao SCuP tenham a possibilidade de acessar regiões de endereçamento

não ativamente permitidas, aumentando o nível de segurança também contra ataques externos.

3.1.3. Cifrador de Memória Externa

O cifrador de memória externa (CryptoMem) permite que regiões da memória RAM externa

sejam cifrados de maneira automática com grande aceleração por hardware. Isto

permite que o processador AC/SC execute código cifrado da memória externa de maneira

transparente. As chaves do CryptoMem são diretamente controladas pelo SC, assim

como as faixas de endereçamento que devem ser protegidas. O CryptoMem emprega o

algoritmo NIST-FIPS PUB 197 - AES - com chaves de 256 bits em modo de operação

não-padrão. O CryptoMem tem performance de processamento de 128 bits/ciclo.

3.1.4. Módulo AES-256 e Módulo SHA-512 de Alto Desempenho

O módulo AES implementa o NIST FIPS PUB 197 com chaves de 256 bits nos modos

de operação ECB, CTR, CBC e GCM e desempenho de pico de processamento de 8

bits/ciclo. O módulo SHA implementa o NIST FIPS PUB 180-3, com hashes de 512 bits

e desempenho de pico ≥ 12 bits/ciclo.

Estes blocos operam como aceleradores de hardware internos ao processador e

servem aplicações executando tanto no SC como no AC de forma direta ou através da

biblioteca criptográfica da plataforma SCuP. Esta biblioteca também faz uso do acelerador

de curvas elípticas presente no processador.

78


3.1.5. Outros Componentes

O SCuP possui diversos outros componentes com funções de segurança, mas que por

questões de espaço somente mencionaremos. Um destes componentes é o TRNG do processador,

item essencial na operação da maioria dos esquemas criptográficos. O TRNG

do SCuP é não determinístico e explora características físicas das portas lógicas convencionais

do semicondutor para a geração e com alta entropia. O TRNG será tema de artigo

futuro e por enquanto representa segredo industrial.

Outro componente que merece menção é o Mailbox, utilizado para a comunicação

entre núcleos. Este componente foi especificamente projetado para permitir que informações

entre AC e SC possam ser trocadas de maneira rápida e protegida do acesso externo.

O último componente que mencionamos é o IRQMP-CPS, componente central

no MIP. O IRQMP-CPS possui modificações em relação a um gerenciador convencional

de requisições (IRQs) de forma que, quando o AC é provocado pelo SC, o primeiro

obrigatoriamente executa um trecho de código confiado determinado por SC.

3.2. Funcionalidades do SCuP

3.2.1. SBS - Sequência de Boot Seguro

A sequência de boot seguro (SBS) é fundamental para garantir que o estado da plataforma

seja conhecido (íntegro) em ambos os núcleos quando o sistema termina a inicialização.

Para tanto, utilizamos uma sequência de boot com verificação de assinaturas digitais que

vai da BIOS às aplicações de usuário. A sequência é a seguinte:

Etapa/Fase Nome Descrição

1 Load/Decode O software que carrega e decifra o software da ROM

externa, estará gravado na ROM interna, e ele utilizará

o scratchpad do SC como sua memória RAM

1.1 Auto-testes SC Realiza auto-testes de funções criptográficas e de integridade

interna

1.2 Zeração Zera todos os buffers e caches internos e a RAM

1.3 Cópia da ROM Copia o conteúdo da ROM externa para o scratchpad

1.4 Decifra Decifra o conteúdo carregado no scratchpad

1.5 Verifica Verificar a assinatura digital do conteúdo do scratchpad

1.6 Carga Limpa registradores e ajusta o PC para o início do

scratchpad

2 Execute O software da ROM externa (BIOS) está carregado no

scratchpad, e utiliza essa memória como RAM

2.1 HFW Configura o HWF (libera acessos a determinados recursos

do sistema)

2.2 SC Configura o SC

2.3 Imagem AC Obtém a imagem de boot do Linux (o qual executará

no AC). Opcionalmente (a) Verifica hardware, (b)

Continua boot pela rede, (c) Acessa a memória externa,

(d) Atualiza a ROM externa

79


2.4 Decifra Decifra a imagem de boot do Linux

2.5 Verificar Verifica a imagem de boot do Linux

2.6 Carrega Carrega a imagem de boot do Linux no endereço inicial

do AC

2.7 Libera Libera o AC (“acorda” o processador AC)

3 Boot Linux Imagem de boot do Linux carregada, recursos liberados

e AC “ acordado”

O mecanismo de boot seguro impede que ataques de substituição/alteração de

binários sejam possíveis no SCuP. Tanto quanto pudemos averiguar, o SCuP é o primeiro

processador a implementar uma sequência de boot seguro multi-core e também o

primeiro a fazer isso com serviços de assinatura digital e sigilo simultaneamente. Entretanto,

este mecanismo não é suficiente para proteger contra ataques online, onde defeitos

das aplicações são exploradas pelos adversários, como em ataques de estouro de pilha

(execução de dados).

Por este motivo, mecanismos de proteção contra ataques em tempo de execução

foram incluídos no SCuP, como o MIP.

3.2.2. MIP - Mecanismo de Introspecção/Inspeção Profunda

O objetivo do MIP é permitir que o estado do núcleo AC seja totalmente conhecido e

acessível para inspeção completa impedindo que código malicioso se aloje em qualquer

parte dos elementos de memória do núcleo. Isto é necessário pois o núcleo AC executa

uma pilha extensa de software, com elementos possivelmente não assinados digitalmente

(e não verificados pela SBS).

MIP foi inspirado no CoPilot, mas apresenta diversas modificações e vantagens.

Em primeiro lugar, o CoPilot não é capaz de ter acesso total ao estado da CPU principal do

sistema dado que seu acesso era externo, via PCI, o que também limita o seu desempenho.

O funcionamento do MIP pode ser assim sumarizado:

• Sob requisição do usuário ou de tempos em tempos, o SC inicia o ciclo de verificação;

• para tanto, o SC gera uma interrupção não mascarável de máxima prioridade no

AC (via componente IRQMP-CPS);

• o AC imediatamente começa a servir a requisição em um trecho de código fixo

em ROM que realiza verificações (V-COM). Por estar em ROM, não pode ser

modificado por adversários;

• V-ROM é utilizado então para verificar a assinatura de código adicional escrito

por SC (V-RAM) em posição pré-determinada de memória. Se a assinatura for

correta, inicia a execução deste novo trecho de código;

• V-RAM é o código que comanda a verificação do sistema seja por inspeção ou por

introspecção. No caso da introspecção, no primeiro passo, o AC empilha todos os

seus registradores e descarrega a cache (instrução “flush”) e continua executando

o “anti-malware”. No caso da inspeção, AC permanece em “stall” e SC realiza

toda as verificação;

• finalizado o trecho V-RAM, o AC retorna à execução normal.

80


Com a arquitetura do SCuP, a verificação realizada no ciclo do MIP é altamente

eficiente, uma vez que a comunicação entre o SC e o AC é realizada por meio do barramento

interno ao processador. Além disso, a nossa arquitetura também permite que o SC

mantenha serviços essenciais ao sistema enquanto o AC passa pelo MIP tarefas como, por

exemplo, manutenção de “watchdogs” ou mesmo controles demandados por periféricos

de tempo real.

Por meio do uso do HFW e do MIP simultaneamente, nossa arquitetura permite

a construção de mecanismos de recuperação dinâmica de kernel e detecção de rootkits

de alta eficiência. Para tanto, o SC protege uma região de memória onde mantém uma

cópia do kernel saudável de AC. Assim, ao executar o MIP em modo de inspeção, o SC

pode facilmente comparar cópias do kernel e restaurar imagens anteriores, uma vez que

um adversário em AC é incapaz de corromper tanto o mecanismo de verificação, como

as próprias imagens protegidas por SC. Tanto quanto saibamos, o SCuP é o primeiro

processador a dar suporte a este tipo de operação integrada.

3.2.3. Outras Funcionalidades

Além dos mecanismos SBS e MIP, o SCuP ainda incorpora o conceito de pacote de

execução segura, introduzido pelo IBM Cell e mais tarde formalizado pela proposta do

TEM. Um pacote de execução segura é um blob que contém dados e binários assinados

e possivelmente cifrados e que são entregues para um núcleo para processamento. Antes

de iniciar a execução, este núcleo verifica a assinatura sobre o pacote (e possivelmente o

decifra) antes de iniciar a sua execução, em modo exclusivo.

Apesar de baseado nestas arquiteturas, nossa proposta difere de ambas soluções:

tanto no Cell como no TEM, as unidades processantes (núcleos) funcionam como escravos

de barramento. Isto significa que pacotes de execução segura vindas do ambiente

externo não podem ser utilizadas para verificar o estado do sistema como um todo, ou

mesmo levá-lo a um estado conhecido.

No SCuP, entretanto, o SC (responsável pela execução dos pacotes seguros) é o

mestre do sistema, o que permite que tais pacotes sejam executados em um ambiente

controlado (via MIP e HMW), de fato adicionando uma camada de segurança, em vez de

ser um mecanismo acessório. O SCuP é o primeiro processador a realizar esta abordagem.

4. Implementação e Resultados

O SCuP foi implementado em VHDL utilizando a licença comercial do Gaisler Leon 3 e

simulado e sintetizado com o Quartus II Full para a plataforma alvo de desenvolvimento

Altera Stratix III EP3SL200C2 em um kit de desenvolvimento projetado por nós. O

sistema completo consumiu 69.438 ALUTs da FPGA e operou a uma frequência máxima

de 140MHz.

A Tabela 2 mostra o consumo de elementos dos principais componentes do sistema.

Nota-se que os principais consumos são dos componentes criptográficos de alto

desempenho, correspondendo por cerca de 52% da área (ALUT) do processador.

Se por um lado o impacto em elementos consumidos é alto, por outro a plataforma

se adapta bem quando mais instâncias de AC e SC são inclusas, pois os componentes

81


Componente ALUT %

AC 10,5K 15

SC 6,5K 10

AES 256 7,5K 11

SHA 512 3,5K 5

HWF 2,0K 2

MemCrypt 25,0K 36

TRNG 1K 1

Outros 13,5K 20

Total 69,5K 100

Tabela 2. Consumo de elementos

criptográficos podem ser compartilhados por todos os núcleos.

No quesito desempenho, a implementação das funcionalidades de segurança do

SCuP teve pequeno impacto na frequência máxima de operação. Sintetizando um processador

sem os componentes de segurança, obtivemos fmax de 150MHz, contra 140MHz

de nosso design, uma penalidade de apenas 6,7%.

Os testes de desempenho dos módulos AES-256 e SHA-512 a partir da biblioteca

criptográfica da plataforma foram de 380Mbps e 500Mbps, respectivamente, valores bastante

altos para a frequência de operação de 140MHz, mostrando pequeno “overhead” de

software.

5. Conclusão e Trabalhos Futuros

O SCuP traz uma arquitetura inovadora, desenvolvida levando-se em conta ataques físicos,

ataques lógicos (online e off-line) e os inexoráveis defeitos de software (e hardware). Para

tanto, além possuir tal arquitetura, no SCuP introduzimos os mecanismos de introspecção/inspeção

profunda e firewall de hardware que, em conjunto com os pacotes de execução segura, garantem

múltiplas camadas de segurança independentes no processador. O SCuP, portanto,

representa uma nova filosofia no projeto de processadores, onde um cenário de ataques

ampliado é considerado, resultando em um sistema mais robusto e mais resistente a quebras

de segurança de sub-componentes. Os resultados de implementação até o momento

apontam para a total viabilidade do processador, com degradação mínima de desempenho

(de 150 para 140MHz, -6,7%) e custos moderados em termos de área (53%). A difusão

em silício, esperada para os próximos meses, permitirá que números ajustados de desempenho

sejam obtidos e que figuras de desempenho globais sejam estabelecidas, inclusive

com o SBS, o MIP e o PES.

Os trabalhos futuros estarão centrados no desenvolvimento das bibliotecas de software

e aplicações para uso do SCuP em diversos cenários, desde votação eletrônica, até

aviônica.

Referências

[1] Gianpiero Cabodi, Sergio Nocco, and Stefano Quer. Improving SAT-based Bounded Model

Checking by Means of BDD-based Approximate Traversals. In in Design, Automation

and Test in Europe, 2003, pages 898–903, 2003.

82


[2] Benjie Chen and Robert Morris. Certifying program execution with secure processors. In

HOTOS’03: Proceedings of the 9th conference on Hot Topics in Operating Systems,

pages 23–23, Berkeley, CA, USA, 2003. USENIX Association.

[3] Victor Costan, Luis F. Sarmenta, Marten van Dijk, and Srinivas Devadas. The Trusted

Execution Module: Commodity General-Purpose Trusted Computing. In CAR-

DIS ’08: Proceedings of the 8th IFIP WG 8.8/11.2 International Conference on

Smart Card Research and Advanced Applications, pages 133–148, Berlin, Heidelberg,

2008. Springer-Verlag.

[4] Joan G. Dyer, Mark Lindemann, Ronald Perez, Reiner Sailer, Leendert van Doorn,

Sean W. Smith, and Steve Weingart. Building the IBM 4758 secure coprocessor.

Computer, 34(10):57–66, 2001.

[5] Roberto Gallo, Henrique Kawakami, and Ricardo Dahab. On device identity establishment

and verification. In Proc of EuroPKI’09 Sixth European Workshop on Public

Key Services, Applications and Infrastructures, September 2009.

[6] Roberto Gallo, Henrique Kawakami, Ricardo Dahab, Rafael Azevedo, Saulo Lima, and

Guido Araujo. A hardware trusted computing base for direct recording electronic

vote machines. Austin, Texas, USA, 2010. ACM.

[7] Warren A. Hunt. Mechanical mathematical methods for microprocessor verification. In

Rajeev Alur and Doron A. Peled, editors, Computer Aided Verification, volume 3114

of Lecture Notes in Computer Science, pages 274–276. Springer Berlin - Heidelberg,

2004.

[8] Hiroaki Iwashita, Satoshi Kowatari, Tsuneo Nakata, and Fumiyasu Hirose. Automatic

test program generation for pipelined processors. In Proceedings of the 1994 IEEE-

ACM international conference on Computer-aided design, ICCAD 94, pages 580–

583, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press.

[9] Ruby B. Lee, Peter C. S. Kwan, John P. McGregor, Jeffrey Dwoskin, and Zhenghong

Wang. Architecture for protecting critical secrets in microprocessors. SIGARCH

Comput. Archit. News, 33:2–13, May 2005.

[10] A Mirjalili, S, and Lenstra. Security Observance throughout the Life-Cycle of Embedded

Systems. In International Conference on Embedded Systems, 2008.

[11] NIST. Security requirements for cryptographic modules, Federal Information Processing

Standards Publication (FIPS PUB) 140-2, 2002.

[12] E. Oksuzoglu and D.S. Wallach. VoteBox Nano: A Smaller, Stronger FPGA-based Voting

Machine (Short Paper). usenix.org, 2009.

[13] John P., Dwoskin, and Ruby B. Lee. A framework for testing hardware-software security

architectures. Austin, Texas, USA, 2010. ACM.

[14] Bryan D. Payne, Martim Carbone, Monirul Sharif, and Wenke Lee. Lares: An architecture

for secure active monitoring using virtualization. In Proceedings of the 2008 IEEE

Symposium on Security and Privacy, pages 233–247, Washington, DC, USA, 2008.

IEEE Computer Society.

[15] Nick L. Petroni, Jr., Timothy Fraser, Jesus Molina, and William A. Arbaugh. Copilot -

a coprocessor-based kernel runtime integrity monitor. In Proceedings of the 13th

83


conference on USENIX Security Symposium - Volume 13, SSYM’04, pages 13–13,

Berkeley, CA, USA, 2004. USENIX Association.

[16] Sandip Ray and Warren A. Hunt. Deductive verification of pipelined machines using firstorder

quantification. In Rajeev Alur and Doron A. Peled, editors, Computer Aided

Verification, volume 3114 of Lecture Notes in Computer Science, pages 254–256.

Springer Berlin - Heidelberg, 2004.

[17] Naveen K Sastry. Verifying security properties in electronic voting machines. PhD thesis,

University Of California, Berkeley, 2007.

[18] F. Schneider, Greg Morrisett, and Robert Harper. A language-based approach to security.

In Informatics, pages 86–101. Springer, 2001.

[19] K. Shimizu, H. P. Hofstee, and J. S. Liberty. Cell broadband engine processor vault

security architecture. IBM J. Res. Dev., 51(5):521–528, 2007.

[20] G. Edward Suh, Charles W. O’Donnell, and Srinivas Devadas. Aegis: A single-chip

secure processor. IEEE Design and Test of Computers, 24(6):570–580, 2007.

[21] The Common Criteria Recognition Agreement. Common criteria for information technology

security evaluation v3.1 revision 3, July 2009.

[22] Trusted Computing Group. Trusted Platform Module Main Description Level 2 version

1.2 revision 116, March 2011.

[23] Paul D. Williams. CuPIDS: increasing information system security through the use of

dedicated co-processing. PhD thesis, West Lafayette, IN, USA, 2005. AAI3191586.

84


Fault Attacks against a

Cellular Automata Based Stream Cipher

José Carrijo 1 , Anderson C. A. Nascimento 1 ,

Rafael Tonicelli 1 , Vinícius de Morais Alves 1

1 Departamento de Engenharia Elétrica, Universidade de Brasília

Campus Darcy Ribeiro, 70910-900, Brasilia, DF, Brazil

carrijo@cepesc.gov.br,andclay@ene.unb.br

{tonicelli, vmalves}@redes.unb.br

Abstract. This paper presents fault attacks against a cellular automata based

stream cipher. A fault attack assumes that the adversary is able to physically

operate the cryptographic device and insert some errors into it. As a consequence,

the adversary can induce faulty results into the device and use them to

recover the stored secret key. By using this approach we provide extremely efficient

and practical cryptanalytic methods: by injecting n/2 + n 2 /32 faults we

recover the n-bit secret key from a stream cipher based on cellular automaton

rule 30. To the best of our knowledge this is the first application of fault attacks

against cellular automata based stream ciphers.

1. Introduction

1.1. Overview

Traditionally, cryptanalytic methods have been concentrated on exploiting vulnerabilities

in the algorithmic structure of the target cryptosystem. The conventional approach often

ignores the inherent physical properties of the implementation. In this context, the

fault analysis model emerged as an alternative that allowed the development of a variety

of realistic attacks against symmetric and asymmetric cryptographic protocols. The fault

analysis model relies on the principle that the adversary can physically control the cryptographic

device, and induce it to abnormally operate, making it to output faulty results.

These faulty results can later on be used by the adversary to derive secret information,

such as recovering a shared secret key. Depending on the implementation, an attacker can

perform fault injections into the device by several ways: exposing it to heat or radiation,

changing its power supply voltage, increasing its external clock, provoking temperature

variations, among other possibilities.

Fault analysis was introduced by Boneh, DeMillo, and Lipton [2], who used this

technique to attack public key cryptosystems, such as digital signature and identification

schemes. Their results stimulated a progressive research in the area, and since then other

significant results have been obtained. Remarkably, Biham and Shamir [1] used differential

fault analysis to attack block ciphers, such as DES. More recently, Hoch and Shamir

[4] developed a systematic study about the vulnerabilities of stream ciphers in the fault

analysis setting. Despite all the active research regarding the field, there are no published

results about the use of fault attacks against cellular automata based stream ciphers. One

of the goals of this paper is to fill this gap by presenting some practical fault attacks against

85


the aforementioned cryptosystem. The effectiveness of the proposed attacks demonstrates

that fault analysis represents a major threat for cellular automata based ciphers.

1.2. Cellular Automata Based Stream Ciphers

Wolfram [9, 10] was the first to notice the usefulness of cellular automata as stream ciphers

major building blocks. Wolfram pointed out that some rules used to define the

temporal evolution of one-dimensional cellular automata generated seemingly pseudorandom

behaviors. The proposed family of stream ciphers was very fast yielding efficient

implementations in hardware and software. Later analysis [5] showed that the cipher’s

parameters initially proposed by Wolfram were too optimistic, however for appropriate

key sizes all the known attacks against the cipher proposed in [9, 10] have exponential

complexity.

Later, many other ciphers based on cellular automata were proposed [3, 6, 7, 8]

but the overall goal was the same: to exploit the apparently simple rules and architecture

of cellular automata for obtaining efficient ciphers.

1.3. The Attack Model

Roughly speaking, in the fault analysis model, the adversary is focused on attacking the

physical implementation rather than the cryptographic algorithm.

We assume that the adversary has physical access to the device, but no previous

knowledge about the key. The adversary is allowed to run the device several times while

provoking faults into chosen memory areas of the same device. Specifically, we consider

that the adversary is able to apply bit flipping faults to either the RAM or the internal

registers of the device. Moreover, he/she can arbitrarily reset the cryptographic device

and later induce other randomly chosen faults into it.

We also assume that the adversary knows small parts of the plaintext (thus obtaining

also parts of the keystream). This is a widely used assumption in cryptography

(known as chosen plaintext attacks) and is quite realistic as parts of the message (such as

headers) are usually predictable by an attacker.

1.4. Rule 30 Stream Cipher

Cellular automata theory describes, among other things, how simple and well-defined

rules can lead to complex structures. It is claimed that the random properties of cellular

automata could be used to implement secure, simple, fast, and low cost cryptosystems.

In his seminal paper [9], Wolfram proposed the use of cellular automaton rule 30 as a

keystream generator for a stream cipher. The resultant encryption scheme is the so-called

Rule 30 Stream Cipher.

A cellular automaton consists of a one-dimensional circular register of n cells,

where each cell can present one of two possible states (values), 0 or 1. These cells are

updated in parallel in discrete time steps according to a next state function (or rule). Let

a t i denote the value of the i-th cell at time t. The rule 30 is given by:

a t i = a t−1

i−1 XOR ( a t−1

i

)

OR a t−1

i+1

(1)

86


2. Fault Analysis of the Rule 30 Stream Cipher

This section introduces our fault attack on the Rule 30 Stream Cipher, described earlier in

section 1.4. For sake of feasibility, the following assumptions are made:

• The adversary knows a sequence of n/2 + 1 bits extracted from the register of the

cryptographic device. I.e., he/she knows a t i, for t = 1, . . . , n/2+1. This sequence

is stored in the central column of a matrix A

• The adversary has the capability of changing the content of chosen areas of the

register, i.e., of flipping their stored value. He/she can also reset the device.

This cryptanalytic technique is divided into 3 steps (or phases). In the first step,

we determine the bits of the two columns adjacent to the central column. In the second

step, we proceed with the determination of the bits on the right side of the central column.

In step 3, we determine the bits on the left side of the central column.

As will be shown, as the attack goes on, the actions taken by the cryptanalyst will

depend on the observed configuration of the cells. The method is described below.

STEP 1: Determination of the bits of the two columns adjacent to the central column.

This step consists of provoking a fault into the register for each known pair of bits. It is

possible to determine the two pairs of bits adjacent to the central column.

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

Configuration 1.1

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

a

t−1

i−1 0 a t−1

i+1

x 0 x

)

This configuration is only possible if a t−1

i−1 = a t−1

i+1 = 1 or a t−1

i−1 = a t−1

i+1 = 0. If the

attacker flips the bit a t−1

i and then recomputes the bit a t i, there will be two possibilities:

• If a t i = 0, then a t−1

i−1 = a t−1

i+1 = 1

• If a t i = 1, then a t−1

i−1 = a t−1

i+1 = 0

Configuration 1.2

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

a

t−1

i−1 0 a t−1

i+1

x 1 x

)

This configuration is only possible if a t−1

i−1 = 0 and a t−1

i+1 = 1 or a t−1

i−1 = 1 and

a t−1

i+1 = 0. If the attacker flips the bit a t−1

i and then recomputes the bit a t i, there will be two

possibilities:

• If a t i = 1, then a t−1

i−1 = 0 and a t−1

i+1 = 1

• If a t i = 0, then a t−1

i−1 = 1 and a t−1

i+1 = 0

87


Configuration 1.3

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

a

t−1

i−1 1 a t−1

i+1

x 0 x

)

This configuration allows one to immediately determine a t−1

i−1 = 1. However, a t−1

i+1

remains undefined. If the attacker flips the bit a t−1

i and then recomputes the bit a t i, there

will be two possibilities:

• If a t i = 1, then a t−1

i−1 = 1 and a t−1

i+1 = 0

• If a t i = 0, then a t−1

i−1 = 1 and a t−1

i+1 = 1

Configuration 1.4

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

a

t−1

i−1 1 a t−1

i+1

x 1 x

)

This configuration allows one to immediately determine a t−1

i−1 = 0. However, a t−1

i+1

remains undefined. If the attacker flips the bit a t−1

i and then recomputes the bit a t i, there

will be two possibilities:

• If a t i = 1, then a t−1

i−1 = 0 and a t−1

i+1 = 1

• If a t i = 0, then a t−1

i−1 = 0 and a t−1

i+1 = 0

STEP 2: Determination of the bits on the right side of the central column.

Assume the following notation.

(

α β

x δ

)

=

(

a

t−1

i−1

x

a t−1

i

a t i

)

One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing on

equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t−1

i+1 by

applying one fault into the register.

We shall now analyze these 8 possibilities.

Configuration 2.1

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

0 0 a

t−1

i+1

x 0 x

• This configuration is only possible for a t−1

i+1 = 0.

Configuration 2.2

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

0 0 a

t−1

i+1

x 1 x

)

)

88


• This configuration is only possible for a t−1

i+1 = 1.

Configuration 2.3

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

• This configuration is not possible.

Configuration 2.4

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

If the attacker flips the bit a t−1

i

possibilities:

• If a t i = 1, then a t−1

i+1 = 1.

• If a t i = 0, then a t−1

i+1 = 0.

Configuration 2.5

(

a

t−1

i−1

a t−1

i

)

)

=

=

(

0 1 a

t−1

i+1

x 0 x

(

0 1 a

t−1

i+1

x 1 x

)

)

and then recomputes the bit a t i, there will be two

a t−1

i+1

x a t i x

)

=

(

1 0 a

t−1

i+1

x 0 x

• This configuration is only possible for a t−1

i+1 = 1.

Configuration 2.6

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

)

=

(

1 0 a

t−1

i+1

x 1 x

• This configuration is only possible for a t−1

i+1 = 0.

Configuration 2.7

(

a

t−1

i−1

a t−1

i

a t−1

i+1

x a t i x

If the attacker flips the bit a t−1

i

possibilities:

• If a t i = 1, then a t−1

i+1 = 0.

• If a t i = 0, then a t−1

i+1 = 1.

Configuration 2.8

(

a

t−1

i−1

a t−1

i

)

=

(

1 1 a

t−1

i+1

x 0 x

)

)

)

and then recomputes the bit a t i, there will be two

a t−1

i+1

x a t i x

)

=

(

1 1 a

t−1

i+1

x 1 x

)

89


• This configuration is not possible.

STEP 3: Determination of the bits on the left side of the central column.

Assume the following notation.

(

α β

δ x

)

=

(

a

t−1

i−1

a t i−1

a t−1

i

x

)

One can easily see that there are 8 different possibilities for the bits {α, β, δ}. Basing

on equation 1, an adversary in possession of the bits {α, β, δ} can determine the bit a t−1

i−2

without applying any fault into the register.

We shall now analyze these 8 possibilities.

Configuration 3.1

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 0 0

x 0 x

)

• This configuration is only possible for a t−1

i−2 = 0.

Configuration 3.2

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 0 0

x 1 x

)

• This configuration is only possible for a t−1

i−2 = 1.

Configuration 3.3

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 1 0

x 0 x

)

• This configuration is only possible for a t−1

i−2 = 1 .

Configuration 3.4

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 1 0

x 1 x

)

• This configuration is only possible for a t−1

i−2 = 0.

Configuration 3.5

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 0 1

x 0 x

)

90


• This configuration is only possible for a t−1

i−2 = 1.

Configuration 3.6

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 0 1

x 1 x

)

• This configuration is only possible for a t−1

i−2 = 0.

Configuration 3.7

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 1 1

x 0 x

)

• This configuration is only possible for a t−1

i−2 = 1.

Configuration 3.8

(

a

t−1

i−2

a t−1

i−1

a t−1

i

x a t i−1 x

)

=

(

a

t−1

i−2 1 1

x 1 x

)

• This configuration is only possible for a t−1

i−2 = 0.

3. Further Explanation on the Rule 30 Stream Cipher Fault Analysis

In this part, we explain in-depth why our fault attack on the rule 30 stream cipher works.

The main idea is simple and quite intuitive. We recall that the attacker knows a

sequence of n/2+1 cells, which are located on the central column of a matrix A. We also

recall equation 1.

a t i = a t−1

i−1 XOR ( a t−1

i

)

OR a t−1

i+1

In the first step of our attack, the cryptanalyst intends to discover the values a t−1

i−1

and a t−1

i+1, given the values that he/she knows, i.e., a t i and a t−1

i . However, he/she has two

variables and only a boolean equation (this initial configuration is displayed in figure 1).

Bits to be determined

t 1

a i 1

x

t


a 1 i


1

t1

a i

t

a i

t


1

a i


1

x

t 1

a i 1

Known cells

Figure 1. Initial configuration.

91


Our fault analysis capabilities allow the cryptanalyst to obtain another boolean

equation by flipping the bit a t−1

i and observing the new value assumed by a t i after the

fault injection. So, at the end of this action, the cryptanalyst will have a simple system of

the form:

⎧⎪ ⎨ [a t i] before

flipping = at−1 i−1 XOR ( )

b OR a t−1

i+1

⎪ ⎩ [a t i] after

flipping = at−1 i−1 XOR ( ) (2)

b OR a t−1

i+1

where [a t i] before

flipping and [at i] after

flipping denote the values observed at cell at i before and after the

fault injection, respectively. Before, the fault injection a t−1

i = b and after this, a t−1

i = b,

where b is the complementary value of b. It is easy to find the solution for this system.

The action performed is illustrated in figure 2.

Bit to be flipped

Flipped bit

t 1

a i 1

x

t


a 1 i


1


b

t

a B i F

t


1

a i


1

x

t 1

a i 1

Fault Injection

t 1

a i 1

x

t


a 1 i


1


b

t

a A i F

t


1

a i


1

x

t 1

a i 1

Observe modified

value

Figure 2. Illustration of the main idea involved in the first step of our attack.

Steps 2 and 3 are trivial, and we hardly have to perform a flip action, because,

usually, we have equation with only one variable to be determined. Figure 3 suggests

that.

Bit to be determined

t1

a i 2

x

t


a 1 i


1

t 1

a i 1

t1

a i 2

t

ai

1

tt1

a i i 1

x

t 1

a i 1

Known cells

Figure 3. Illustration of step 3 configuration.

Regarding the complexity of the attack, it is easy to obtain an estimation on the

number of faults required to break the cryptosystem. At step 1, we provoke n/2 fault

injections to determine the two pairs of bits adjacent to the central column. At step 2,

there are (1/2) × [(n/2) × (n/2)] bits, and, on average, we provoke 0.25 fault for each bit

to be determine. So, step 2 requires n 2 /32 faults. At step 3, as explained previously, no

faults need to be realized. Thus,

Number of Faults Rule30 = n2

32 + n 2

92


3.1. Fault Analysis Effect on Rule 30 Stream Cipher

One of the most known cryptanalytic techniques against the rule 30 stream cipher was

proposed by Meier and Staffelbach [5]. Their statistical technique allows one to determine

secret keys with lengths varying between 300 and 500 bits by using personal computers.

However, it is claimed that the recovery of secret keys of 1,000 bits would demand the

use of large scale parallel computers.

On the other hand, the attack based on fault analysis assumptions has proven to be

efficient and feasible for a large set of key lengths. For instance, to obtain a secret key of

256 bits, the cryptanalyst should inject 2 7 +2 11 faults and know (256/2)+1 = 129 bits of the

generated sequence. To obtain a key of 1,024 bits, 2 9 +2 15 fault injections and 512 known

bits are needed. This amount of operations can be performed by any personal computer

equipped with current technology. Besides that, the operations required to implement

the attack are simple (comparisons and fault injections) and can be performed by any

unsophisticated computational system.

4. Conclusions

Cellular automata based stream ciphers were designed to respond to the increasing need of

fast and low-cost cryptographic mechanisms. However, we have shown how devastating

fault analysis can be when applied to some of those cryptosystems.

Our fault attack against the rule 30 stream cipher needs, in order to determine a

secret key of length n, only n/2 + n 2 /32 fault injections and a sequence of n/2 + 1 bits.

It is an interesting future research direction to see how well the results introduced

here apply to other ciphers designed for low-cost, high performance cryptographic devices.

References

[1] Eli Biham, Adi Shamir. A New Cryptanalytic Attack on DES: Differential Fault Analysis.

Preprint, October 1996.

[2] Dan Boneh, Richard A. DeMillo and Richard J. Lipton. On the Importance of Checking

Cryptografic Protocols for Faults. Advances in Cryptology – EUROCRYPT 1997,

Lecture Notes in Computers Science vol.1233, Springer-Verlag, pp. 37–51, May

1997.

[3] A. Fuster-Sabater, P. Caballero-Gil and M.E. Pazo-Robles, Application of Linear Hybrid

Cellular Automata to Stream Ciphers, EUROCAST 2007, Lecture Notes in Computer

Science vol. 4739, pp. 564-571, 2007

[4] Jonathan J. Hock and Adi Shamir. Faut Analysis of Stream Ciphers. CHES 2004, Lecture

Notes in Computer Science vol. 3156, Springer-Verlag, pp. 240–253, 2004.

[5] Willi Meier and Othmar Staffelbach. Analysis of Pseudo Random Sequences Generated

by Cellular Automata. Advances in Cryptology – EUROCRYPT 1991, Lecture

Notes in Computer Science vol. 547, Springer-Verlag, pp. 186–199, 1991.

[6] S. Nandi, B.K. Par, P. Pal Chaudhuri. Theory and Application of Cellular Automata in

Cryptography, IEEE Transactions on Computers, vol 43, Issue 12, pp.1346-1357,

1994

93


[7] F. Seredynsky, P. Bouvry and A. Zomaya. Cellular Automata Computations and Secret

Key Cryptography. Parallel Computing, Vol. 30, Issues 5-6, pp. 753-766, 2004.

[8] M. Tomassini and M Perrenoud. Cryptography with Cellular Automata, Applied Soft

Computing, vol 1, Issue 2, pp. 151-160, 2001.

[9] S. Wolfram. Cryptography with Cellular Automata. Advances in Cryptology - CRYPTO

1985, Proceedings, Springer-Verlag, pp. 429–432, 1986.

[10] S. Wolfram. Random Sequence Generation by Cellular Automata. Advances in Applied

Mathematics 7, pp. 123–169, 1986.

94


Zero-knowledge Identification based on Lattices with Low

Communication Costs

Rosemberg Silva 1 , Pierre-Louis Cayrel 2 , Richard Lindner 3

1 State University of Campinas (UNICAMP)

Institute of Computing

rasilva@ic.unicamp.br – Brazil

2 Laboratoire Hubert Curien

Université de Saint-Etienne

pierre-louis.cayrel@univ-st-etienne.fr – France

3 Technische Universität Darmstadt

Fachbereich Informatik

Kryptographie und Computeralgebra

rlindner@cdc.informatik.tu-darmstadt.de – Germany

Abstract. In this paper we propose a new 5-pass zero-knowledge identification

scheme with soundness error close to 1/2. We use the hardness of the Inhomogeneous

Small Integer Solution problem as security basis. Our protocol

achieves lower communication costs compared with previous lattice-based zeroknowledge

identification schemes. Besides, our construction allows smaller

public and secret keys by applying the use of ideal lattices. We allow the prover

to possess several pairs of secret and public keys, and choose randomly which

pair is to be used in a given round of execution. We also dealt with nonces

in zero-knowledge schemes in a new way, lowering the number of values exchanged

between the prover and the verifier. Hence, our scheme has the good

features of having a zero-knowledge security proof based on a well known hard

problem of lattice theory, with worst to average-case reduction, and small size

of secret and public keys.

1. Introduction

Identification schemes are cryptographic tools applied to provide access control. A common

realization of such schemes comes in the form of protocols between two entities

called Prover and Verifier. The former is expected to establish the validity of its identity

to the latter. In order to accomplish such goal, the Prover makes used of the knowledge

of a secret key, that is connected to its identity. The application of zero-knowledge

constructions helps to ensure that no information about such key is leaked as the protocol

is performed. The only knowledge gained by the Verifier is that the claim made

by the Prover about the possession of the secret key is valid with overwhelming probability.

Lattice-based instantiations of this kind of protocol have recently been proposed:

[Lyubashevsky 2008], [Kawachi et al. 2008] and [Cayrel et al. 2010]. An interesting feature

of some lattice-based systems in Cryptography, as seen in the seminal work from

Ajtai [Ajtai 1996], is the possibility of allowing reductions from wost-cases to averagecases

of well known hard problems. In the present work we use some of these results and

propose an identification scheme that achieves better communication costs.

95


There is an standard construction of signature schemes from identification

schemes through the usage of the Fiat-Shamir heuristic, secure under the random oracle

model [Fiat and Shamir 1986]. It is of pivotal importance, however, that the communication

costs of the identification scheme be small in order to have efficient conversion.

Among the good characteristics that our system possesses we stress the resilience

to existing quantum attacks, like Shor’s [Shor 1994]. In addition to that, the relatively

small soundness error per round and the algorithm that prevents exchange of

large vectors enables to achieve small communication costs in contrast to other latticebased

solutions, such as those seen in [Lyubashevsky 2008], [Kawachi et al. 2008] and

[Cayrel et al. 2010]. This is conveyed by the Table 1, where we consider a scenario with

an overall soundness error of 2 −16 , and make the assumption that all the random choices

involve the use of seeds that are 128 bits long. For a setting applying k pairs of keys, our

scheme has soundness error 1/2 + 1/k 2 . Then, it suffices to run 17 rounds of the protocol

in order to reach such goal. The best zero-knowledge identification scheme in term of

communication cost, the CLRS scheme has soundness error of (q +1)/q, considering that

it is based on q-ary lattices over Z q . Given that we are working with q = 257, it also

requires 17 rounds in order to satisfy the requirement regarding overall soundness error.

Our proposal reaches a communication cost better than CLRS’.

Scheme

Rounds Total communication

[Kbyte]

Lyubashevsky [Lyubashevsky 2008] 11 110,00

Kawachi et al. [Kawachi et al. 2008] 27 58,67

CLRS [Cayrel et al. 2010] 17 37,50

Ours 17 23,40

Table 1. Comparison with lattice-based ID schemes.

This paper is organized as follows. The concepts necessary to the understanding

of our construction are are presented in Section 2. After that, we provide a detailed

description of the algorithms from which our scheme is composed in Section 3. Then, we

give the proofs for the zero-knowledge properties that our scheme possesses. For last, we

discuss the choice of parameters in Section 4 and future lines of investigation in Section

5.

2. Preliminaries

Notation. Along the text we use bold capital letters to denote matrices and bold small

letters to indicate vectors. Scalars, on their turn, are represented with regular characters.

Security Model. Our identification scheme employs a string commitment scheme that

possesses the properties of computationally binding and statistically hiding. We also assume

that a trusted party honestly sets up the system parameters for both the Prover and

the Verifier.

A commitment scheme is said to be statistically hiding, when no computationally

unbounded adversary can distinguish two commitment strings generated from two distinct

96


strings. It is computationally binding, if no polynomial-time adversary can imperceptibly

change the committed string after sending the corresponding commitment.

We show that our construction is resilient to concurrent attacks. Thus, we allow

the adversaries act as cheating verifiers prior to attempting impersonation attacks, with

polynomially many different instances of the prover. Such instances share the same secret

keys in each round, but use different random coins. Besides, they have their own

independent state.

Zero-Knowledge. Given a language L and one of its words x, we call zero-knowledge

proof of knowledge that x belongs L a protocol with the following properties:

• Completeness: any true theorem to be proved.

• Soundness: no false theorem can be proved.

• Zero-Knowledge: nothing but the truthfulness of the statement being proved is

revealed. According to [Goldwasser et al. 1985], there exist the following kinds

of zero-knowledge :

– Perfect: if the simulator and the real proof produce communication tapes

with exactly the same distribution.

– Statistical: if the simulator and the real proof produce communication

tapes whose statistical distributions are negligibly close.

– Computational: if no efficient algorithm can distinguish the communication

tape produced by the simulator from that corresponding to the real

protocol.

Lattices. Lattices correspond to discrete additive subgroups of R m . One can represent

them by means of a basis B composed of n ≤ m linear independent vectors in R m . Such

basis is not unique. Given two basis B 1 and B 2 for the same lattice, there is a unimodular

matrix U such that B 1 = B 2 U.

Given a basis B, the corresponding lattice is generated by all combinations of

vectors in B with integer coefficients.

There are hard problems defined over lattices that can be used as security assumptions

in the construction of cryptographic schemes. We list below the problems that are

related to the identification scheme proposed in this paper. We assume that the norm used

throughout this document is max-norm.

Definition 2.1 (Search Shortest Vector Problem, SVP). On input a lattice basis B ∈

Z m×n , the computational shortest vector problem (SVP) is defined as the task of obtaining

a non-zero lattice vector Bx satisfying ‖Bx‖ ≤ ‖By‖ for any other y ∈ Z n \ {0}.

As commonly happens in the study of computational complexity, one

can express the problem above as optimization, decision and approximation

[Micciancio and Goldwasser 2002].

Definition 2.2 (Short Integer Solution, SIS). On input a prime q, a positive real number

b, a matrix A ∈ Z n×m

q , associated with a lattice basis, the short integer solution (SIS)

problem is defined as the task of finding a non-zero vector x ∈ Z m such that Ax = 0

(mod q), with ‖x‖ ≤ b.

97


The SIS has served as security assumption in several cryptographic schemes with

worst-case connections. In [Ajtai 1996] and [Ajtai and Dwork 1996], Ajtai first showed

how to use computationally intractable worst-case lattice problems as building blocks for

cryptosystems. The parameter sizes involved, however, are not small enough to enable

practical implementations.

Working towards making lattice-based schemes practical, Micciancio showed that

it is possible to represent a basis, and thus public keys, with space that grows quasilinearly

in the lattice dimension [Micciancio 2007] through cyclic lattices. Further improvement

was obtained in conjunction with Lyubashevsky, achieving compression functions

that are both efficient and provably secure assuming the hardness of worst-case

lattice problems for ideal lattices [Lyubashevsky and Micciancio 2006].

A variety of hard problems associated with lattices has been used as security basis

in a number of cryptographic schemes. For example, Lyubashevsky’s identification

scheme is secure under active attacks, assuming the hardness of approximating SVP in all

lattices of dimension n to within a factor of Õ(n2 ). By weakening the security assumption,

on the other hand, one can achieve parameters small enough to make a practical

implementation feasible, as seen in the identification scheme proposed by Kawachi et

al. in [Kawachi et al. 2008]. In this later work, the authors suggest to use approximate

Gap-SVP or SVP within factors Õ(n). Cayrel et al. improved the results from Kawachi

in the CLRS scheme [Cayrel et al. 2010].

Ideal Lattices. There is a particular class of lattices that are closed under ring multiplications.

They correspond to the ideals of some polynomial quotient ring.

Definition 2.3 (Ideal lattices). Let f be a monic polynomial of degree n. We call L is an

ideal lattice if it corresponds to an ideal I in the ring Z[x] /〈f〉.

For lattices of rank n and entries from Z q , the storage needs for characterizing a

basis is n 2 log(q) bits. By applying ideal lattices, instead, this value can be reduced to

n log(q) bits. Besides the gain in storage, there is also a gain in performance, given that

matrix/vector multiplications can be performed in time O(n log(n)) using discrete FFTs.

Both SIS and SVP restricted to ideal lattices still keep the worst-case to averagecase

connection, provided that f is irreducible over the integers.

Definition 2.4 (Ideal-SIS). Given a monic polynomial f of degree n, the ring R f =

Z[x]/〈f〉, and m elements a 1 , . . . , a m ∈ R f /qR f , we define Ideal-SIS the problem of

finding x 1 , . . . , x m ∈ R f satisfying ∑ m

i=1 a ix i = 0 (mod q) and 0 < ‖(x 1 , . . . , x m )‖ ≤

b.

Canonical identification schemes Let the tuple (KEYGEN, P, V ) be an identification

scheme, where KEYGEN is the key-generation algorithm which on input parameters outputs

(sk, pk), P is the prover algorithm taking input sk, V is the verifier algorithm taking

inputs parameters and pk. We say that such scheme is a canonical identification scheme

if it is a public-coin 3-move protocol {commitment, challenge, answer} that enables P to

convince V about the knowledge of sk.

98


Stern’s Identification Scheme. The first code-based identification scheme was proposed

by Harari in 1989 [Harari 1988], but it was broken by Véron in 1995 [Véron 1995].

In 1990, Girault devised a three-pass scheme [Girault 1990]. Neither of those schemes

was practical, from performance perspective, though. The first practical code-based identification

scheme, from performance standpoint, was proposed by Stern [Stern 1993]. Its

security relies on the collision-resistance property of a hash function h and the hardness

of the syndrome decoding problem. The entity to be authenticated possesses a pair of

keys (i, s) related by i = H T s, where H is a public parity check matrix of a given code, s

is a private binary vector of Hamming weight p, and i is its public syndrome. It engages

in a zero-knowledge protocol with a verifier, aiming to prove the knowledge of the secret

key, without revealing its value. In the same paper Stern proposed some variations of the

protocol. The most efficient in terms of communication costs had soundness error of 2/3.

This implies that, in order to reach a confidence level L on the authenticity of the prover,

the protocol has to be repeated a number r of rounds, in order to satisfy 1 − (2/3) r ≥ L.

Gaborit and Girault’s Identification Scheme Another scheme suggested by Gaborit

and Girault requires smaller storage for public data [Gaborit and Girault 2007]. Given

that the schemes we have seen are dealing with codes, this usually implies that a generator

matrix or a parity check matrix is needed to fully characterize them. The idea applied by

Gaborit and Girault was to use double-circulant matrices for a compact representation.

In our work, we point out that a combination of these two approaches (and the

one from Aguilar et al. [Aguilar et al. 2011]) can be used in the lattice context, namely

ideal lattices (which allow a very compact representation, as efficient as double-circulant

matrices) for an identification scheme structure with soundness error of 1/2. With this, we

manage to have the lowest communication costs and lowest public data storage needs.

3. Identification Scheme

Our scheme is comprised of two algorithms: key generation, and identification protocol.

The first picks uniformly at random k binary vectors with length m, Hamming weight

p and disjoint supports. The corresponding public keys are obtained by multiplication

of the private key by a uniformly chosen matrix A ∈ Z n×m

q . Given the small norm

of the private keys, it is still computationally intractable to derive them from the public

data for a suitable choice of parameters with algorithms known to this date. Such task

corresponds to the inhomogeneous SIS problem. In addition to that, several valid private

keys correspond to a given public key. This fact will be used later on to establish the

concurrent security of our scheme.

KEYGEN:

A ←− $ Z n×m

q

Compute x = {x 1 , . . . , x k } and y = {y 1 , . . . , y k } where

$

x i ←− {0, 1} m , with Hamming weight p and 1 ≤ i ≤ k

y i ←− Ax i mod q with 1 ≤ i ≤ k

COM ←− $ F, suitable family of commitment functions

Output (sk, pk) = (x, (y, A, COM)), where the private key is sk, and the public key is pk.

Figure 1. Key generation algorithm, parameters n, m, q are public.

The second algorithm corresponds to the identification protocol. To a given user

we have associated k distinct pairs of keys. In a given round of execution, the Verifier

99


Prover P(sk, pk)

(sk, pk) = (x, (y, A, COM)) ←− KEYGEN

Verifier V(pk)

u ∗ $

←− Z m q , σ ←− $ S m

u ←− σ −1 (u ∗ )

$

r 3 ←− {0, 1} m

r 1 ←− σ(r 3 )

r 2 ←− u ∗ &r 3

c 1 ←− COM(σ ‖ Au; r 1 )

c 2 ←− COM(u ∗ ; r 2 )

c 3 ←− COM(σ(x s + x t + u) mod q; r 3 )

If b = 0:

c 1 , c 2

−−−−−−−−−−−−→

s, t

$

←−−−−−−−−−−−− s, t ←− {1, . . . , k}

c 3

−−−−−−−−−−−−→

Challenge b

←−−−−−−−−−−−− b ←− $ {0, 1}

σ, u + x s + x t mod q, r 3

−−−−−−−−−−−−→

Check

r 1 ←− σ(r 3 )

c 1

? = COM(σ ‖ A(u + xs + x t ) − y s − y t ; r 1 )

c 3

? = COM(σ(xs + x t + u) mod q; r 3 )

Else:

u ∗ , σ(x s + x t ), r 3

−−−−−−−−−−−−→

Check

r 2 ←− u ∗ &r 3

c 2

? = COM(u

∗ ; r2 )

c 3

? = COM(σ(xs + x t ) + u ∗ mod q); r 3 )

σ(x s + x t ) is binary with Hamming weight 2p

Figure 2. Identification protocol

picks two pairs of keys that the Prover is supposed to use for the interactive proof. When

performing operations over the private keys, the Prover uses blinding factors in the form

of permutations and vector sums with modular reduction. Both the permutation and the

vector to be added to the private keys are uniformly randomly chosen. Hence, observing

the outcome does not reveal any information about the private key value, given that its statistical

distribution is uniform. This is applied in the demonstration of the zero-knowledge

property of our scheme.

In order to help in the reduction of communication costs, the nonces that are used

in conjunction with the COM functions can be generated in such a way that only one of

the three values r i is chosen uniformly at random. We can chose r 3 because c 3 is the

common commitment that is checked for both possible values for the challenge b. The

other two nonces may be obtained by performing operations involving the first one, either

by applying a random permutation (σ) or by performing the bitwise logical AND with the

appropriate number of bits of the permutation of a randomly chosen vector (u). When

replying to the challenges, the Prover would give to the Verifier all the seeds needed

to reconstruct the nonces r i . The Prover also sends the seeds for computing σ and u ∗ ,

depending on the challenge received from the Verifier, instead of sending matrices and

vectors that define them. We are making the assumption that the utility function to derive

them from the seeds are publicly known.

Regarding the computation of the blinding vector u, we first randomly choose its

image u ∗ . Then, using the seed of the permutation σ, we obtain u ←− σ −1 (u ∗ ). This

choice enables to, instead of replying the challenge b = 1 with a vector in Z m q , send

only a seed to reconstruct the value of u ∗ by the Verifier. This is the point where the

improvement in terms of communication costs regarding CLRS becomes more evident.

For instantiating the commitment scheme COM, we recommend Kawachi’s

[Kawachi et al. 2008], whose security is based on SIS. As seen with CLRS and SWI-

100


FFT, the application of ideal lattices can bring improvement in performance and storage

needs, without sacrificing security.

3.1. Security

We provide below proofs for the completeness, soundness and zero-knowledge properties

of the identification scheme described in Figure 2. We use as assumptions the fact that

the string commitment scheme COM is a statistically hiding and computationally binding

commitment scheme, and also that the inhomogeneous SIS problem is hard.

3.1.1. Completeness

Given that an honest prover has knowledge of the private keys x i , the blending mask u

and the permutation σ, he will always be able to derive the commitments c 1 , c 2 and c 3 ,

and reveal to the verifier the information necessary to check that they are correct. He can

also show that the private keys in his possession has the appropriate Hamming weights.

So, the verifier will always accept the honest prover’s identity in any given round. This

implies perfect completeness.

3.1.2. Zero-Knowledge

We give a demonstration of the zero-knowledge property for the identification protocol

shown in Figure 2. Here, we require the commitment function COM to be statistically

hiding, i.e., COM(x; r) is indistinguishable from uniform for a uniform r ∈ {0, 1} m .

Theorem 3.1. Let q be prime. The protocol described in Figure 2 is a statistically zeroknowledge

proof of knowledge that the prover knows a set of k secret binary vectors x i

of Hamming weight p that satisfy Ax i = y i mod q, for i ∈ {1, . . . , k}, if the employed

commitment scheme COM is statistically-hiding.

Proof. To prove the zero-knowledge property of our protocol, we construct a simulator

S that, given oracle access to a verifier V (not necessarily honest), produces a communication

tape that is statistically indistinguishable from a tape generated by the interaction

between an honest prover P and the given verifier V . The construction of such simulated

tape is described below. The simulator prepares to answer the second challenge b

by guessing its value ˜b picked uniformly at random from {0, 1}, and produces the corresponding

commitments c 1 and c 2 . It accesses the verifier, as an oracle, passing the

commitments c 1 and c 2 , obtaining as response the first challenge {s, t}. Then, it computes

commitment c 3 and passes it to the verifier, obtaining the final challenge b. If b and

˜b match, the simulator records the interaction in the communication tape. Otherwise, it

repeats the process. The number of rounds recorded r corresponds to what would be expected

from a real pair (P, V ) in order to reach a specified value for the overall soundness

error L.

The computations of each commitment are executed as follows.

If ˜b = 0, the simulator selects u, σ and the nonces {r 1 , r 2 , r 3 } as per protocol, computes

the commitments {c 1 , c 2 } and passes them to the verifier V , which responds with a

challenge {s, t}. The simulator solves the equations Ax t = y t (mod q) and Ax s = y s

101


(mod q) for x t and x s , without any restriction regarding the norm of the solution. Such

step is not computationally hard, and can be done in polynomial time. With these pseudo

secret keys x t and x s , the simulator computes c 3 according to the protocol and sends it

to the verifier. The deviation in c 3 is not recognized because COM is statistically hiding.

Upon receipt of c 3 the verifier responds with the final challenge b. If it matches the

value to which the simulator had prepared to answer, namely ˜b, then it reveals the values

{σ, u + x s + x t mod q, r 1 , r 3 } to the verifier. The whole set of data exchanged between

the simulator and the verifier is recorded. If there is not a match between b and ˜b, however,

the simulator does not record anything and prepares for a new round by picking another ˜b

uniformly at random and restarts the process.

If ˜b = 1, the simulator needs to play against the second verification branch. It

selects u, σ and the nonces {r 1 , r 2 , r 3 } according to the protocol, uniformly at random.

It computes the commitments {c 1 , c 2 }, sends them to the verifier, obtaining the answer t

as result. Then, the simulator picks x t and x t uniformly at random as a binary vectors

of dimension m, Hamming weight p and disjoint supports, without having to satisfy the

restrictions Ax s = y s mod q and Ax t = y t mod q, given that this will not be used

to check the validity of the commitments, in case the guessed challenge is correct. It

suffices that c 2 and c 3 can be reproduced by the verifier, and that the surrogate private

keys x t and x t have Hamming weight p. The simulator computes commitment c 3 , sends

it to the verifier, and gets the final challenge as response. Again, such deviation is hidden

by COM. In case the final challenge matches the guessed value, the whole interaction of

this round is recorded. Otherwise, the simulator picks another ˜b and restarts the process.

As a result, after 2r rounds in average, the simulator produces a communication tape

statistically indistinguishable from a real one, provided that COM is statistically hiding.

3.1.3. Soundness

Theorem 3.2. If after r rounds of protocol execution a cheating prover is accepted with

probability at least (1/2+1/k 2 ) r +ɛ, for any ɛ > 0, either there is a knowledge extractor,

which is a polynomial time probabilistic Turing machine that computes with overwhelming

probability the sum of two private keys x i and x j , with i, j ∈ {1, . . . , k}, which are

solutions to instances of the inhomogeneous SIS, or the binding property of the commitment

scheme COM is broken.

Proof. We follow the same strategy as Véron [Véron 1996] for reasoning about trees

that model the probability space corresponding to the execution of the protocol. Let us

suppose that a cheating prover can be accepted with such probability as (1/2+1/k 2 ) r +ɛ,

or higher. Then, by rewinding this prover a number of times given by 1/ɛ, we can find

with overwhelming probability a node with two sons in the execution tree associated with

the protocol between the cheating prover and the verifier, corresponding to the reception

of the two possible values for the challenge b. This means that such cheating prover will

be able to answer all challenges for a fixed set of commitments c 1 , c 2 , c 3 .

There are two possibilities for him to accomplish this. The first one is to have the

arguments from which the commitments assuming different values for the two challenges,

102


ut with similar images through the application of the function COM. This implies a

violation of the binding property of the commitment scheme, given that a collision was

found.

The second possibility is that the arguments to the function COM match. Let us

call σ 0 and u 0 + x s 0 + x t 0 the values revealed by the cheating prover upon receipt of

the challenge b = 0. Let us call σ(u 1 ) and σ 1 (x s 1 + x t 1 ) the answer to the challenge

b = 1. Then, we can obtain the sum of the private key x s + x t as σ0 −1 (σ 1 (x t 1 + x t 1 )).

This also means that we solved an arbitrary inhomogeneous SIS instance in probabilistic

polynomial time, violating our assumption that such problem is hard.

The ability to find the sum of two arbitrary private keys also implies the ability

to obtain each of the individual keys corresponding to such sum. In order to do that, we

can use the fact that private keys are binary vectors with constant Hamming weight p.

Then, using the pigeon hole principle, after finding k pair sums, we will have necessarily

a non-empty intersection with the support set of the next pair sum. Such intersection

corresponds to the support set of a single key. Given that the key is binary, it can be

uniquely determined from its support set. Then, applying an XOR operation between

each partially colliding sum and the recently computed key, we can retrieve the other two

remaining private keys. This whole process can be executed over polynomially many key

sums, so that all the individual private keys can be recovered.

In the security proofs above, we make the assumption that the distributions of r 1 ,

r 2 and r 3 are uniform, provided that r 3 is randomly chosen from {0, 1} n , and that the

other two nonces are computed as r 1 ←− σ(r 3 ) and r 2 ←− σ(u) & r 3 . Besides, given

that COM is statistically-hiding, these choices can not be distinguished from what would

have been obtained, had r 1 and r 2 been directly picked at random from {0, 1} n .

3.2. Security and Performance Considerations

The application of ideal lattices in this identification scheme can lead to improved and

reduced memory footprint for public data. The usual restrictions regarding the choice of

irreducible polynomials in the characterization of the ideal lattice, as well as its expansion

factor must be observed, as discussed in [Lyubashevsky and Micciancio 2006]. This helps

to ensure that finding short vectors in this kind of lattice remains hard to achieve.

Our scheme is also secure against concurrent attacks. This is a consequence of

the fact that a public key corresponds to multiple secret keys, when the parameters are

chosen in such a way that the pre-image set given by the private keys is much larger than

the image set to which the public keys belong. The keys are related via mapping through

the matrix A.

3.3. Communication Costs

This identification scheme can benefit from the use of ideal lattices, by performing faster

matrix vector multiplications with FFTs, similarly to what was done with SWIFFT hash

function [Lyubashevsky et al. 2008]. The associated polynomial must be irreducible and

with small expansion factor, as suggested in [Lyubashevsky and Micciancio 2006], in order

to avoid known attacks.

103


Another efficient identification scheme, named CLRS, based on SIS was recently

proposed by Cayrel et al.[Cayrel et al. 2010]. It possesses a soundness error of (q +1)/2q

per round, which is slightly higher than ours, namely 1/2. Such small difference plays

an important role in terms of performance as depicted in Table 1. We provide below a

comparison in terms of communication costs per round.

Our identification scheme exhibits the following message exchanges between the

prover P and the verifier V . We are assuming that the seeds used to generate random elements

in the protocol are 128 bits wide, and that the commitment function COMprovides

results that are 256 bits wide.

• Commitments: 768 bits, corresponding to three commitment vectors.

• First challenge: 2 log 2 k bits

• Second challenge: 1 bit

• Answer to the second challenge: (m/2) log 2 q + m/2 + 256, which is an average

between

– case challenge is 0:

∗ one permutation seed: 128 bits

∗ one vector in Z m q : m log 2 q bits

∗ one seed for the nonce r 3 : 128 bits

– case challenge is 1:

∗ one seed for reconstructing the vector u ∗ ∈ Z m q : 128 bits

∗ one vector in {0, 1} m : m bits

∗ one seed for the nonce r 3 : 128 bits

Thus, the total communication costs in bits per round of the protocol can be expressed

as

m

2 log 2 q + 2 log 2 k + m 2 + 1025.

Making the substitution of the parameters used in a concrete implementation, we

have the 11275 bits per round. The overall cost for a scenario demanding soundness error

of 2 −16 is listed in Table 1. From there, one can see that our scheme improves the state of

art (CLRS) in approximately 38%.

4. Attacks on the security assumptions

An attacker might try to break our scheme either by finding collisions in the COM function

at will or by computing solutions to the SIS instances corresponding to the scheme. Given

that the COM function adopted is also based on SIS [Kawachi et al. 2008], this implies the

ability of successfully finding solutions for SIS defined over Z q , with vectors of dimension

m and approximation factor √ m. Breaking our instances of inhomogeneous SIS, implies

the capacity to find vectors with max-norm 1 in arbitrarily chosen lattices. Neither of these

attacks can be efficiently implemented with tools and techniques currently available. This

does not change with the application of ideal lattices either.

In similarity with CLRS, we choose the parameters such that with overwhelming

probability that there are other solutions to Ax = y mod q besides the private key

possessed by the Prover. This fact is of great importance for obtaining security against

concurrent attacks. In order to reach this goal, q and m are chosen in such a way that

the cardinality of set of the private keys is much bigger than the cardinality of set of the

104


public keys. This ensures that the system has the property of witness indistinguishability,

which is kept under parallel composition.

As an instantiation with 100 bits of security, we suggest the parameters listed in

Table 2, which are comparable to those used by the SWIFFT hash function and the CLRS

identification scheme. The best combinatorial attack for finding short lattice vectors to

this date, devised by Wagner [Wagner 2002], has a computational complexity above 2 100

for such set of parameters. In addition to that, our private keys have norm below of what

the best lattice reduction algorithms can obtain.

We chose the parameter k as 24 so that the soundness error per round be approximately

the same as that of CLRS. Naturally, the Verifier has to load the set of public

keys before the execution of the protocol from the trusted party that generates the keys.

This represents an extra cost when compared to CLRS, but such operation can be executed

at setup time. We are primarily concerned with the payload exchanged between the

Prover and the Verifier. This can help in preserving bandwidth and battery time, which is

important for constrained devices.

k n m q COM Length (bits)

24 64 2048 257 256

Table 2. Parameters for Lattice Instantiation

5. Conclusion and Further Work

We have shown in this paper a construction of a lattice-based identification scheme with

worst-case connections, taking as starting point a code-based scheme. Its small soundness

error results in lower communication costs than those from other lattice-based constructions

over the I-SIS or SIS problems. Further improvements in computational costs can be

obtained with the application of ideal lattices, without weakening the security properties.

As future work, we suggest an extension of this approach of replacing security

assumptions used by cryptographic schemes to other hard problems in lattices, such as

LWE (learning with errors) which has a formulation very close to that of error-correcting

codes.

References

Aguilar, C., Gaborit, P., and Shreck, J. (2011). A new zero-knowledge code-based identification

and signature scheme with reduced communications. preprint.

Ajtai, M. (1996). Generating hard instances of lattice problems. Electronic Colloquium

on Computational Complexity (ECCC), 3(7).

Ajtai, M. and Dwork, C. (1996). A public-key cryptosystem with worst-case/average-case

equivalence. Electronic Colloquium on Computational Complexity (ECCC), 3(65).

Cayrel, P.-L., Lindner, R., Rückert, M., and Silva, R. (2010). Improved zero-knowledge

identification with lattices. In Provable Security, volume 6402 of Lecture Notes in

Computer Science, pages 1–17. Springer.

105


Fiat, A. and Shamir, A. (1986). How to prove yourself: Practical solutions to identification

and signature problems. In Odlyzko, A. M., editor, CRYPTO, volume 263 of Lecture

Notes in Computer Science, pages 186–194. Springer.

Gaborit, P. and Girault, M. (2007). Lightweight code-based identification and signature.

IEEE Transactions on Information Theory (ISIT), pages 186–194.

Girault, M. (1990). A (non-practical) three-pass identification protocol using coding theory.

In Seberry, J. and Pieprzyk, J., editors, AUSCRYPT, volume 453 of Lecture Notes

in Computer Science, pages 265–272. Springer.

Goldwasser, S., Micali, S., and Rackoff, C. (1985). The knowledge complexity of interactive

proof-systems. In Proceedings of the seventeenth annual ACM symposium on

Theory of computing, page 304. ACM.

Harari, S. (1988). A new authentication algorithm. In Cohen, G. D. and Wolfmann, J.,

editors, Coding Theory and Applications, volume 388 of Lecture Notes in Computer

Science, pages 91–105. Springer.

Kawachi, A., Tanaka, K., and Xagawa, K. (2008). Concurrently secure identification

schemes based on the worst-case hardness of lattice problems. In ASIACRYPT ’08:

Proceedings of the 14th International Conference on the Theory and Application of

Cryptology and Information Security, pages 372–389, Berlin, Heidelberg. Springer-

Verlag.

Lyubashevsky, V. (2008). Lattice-based identification schemes secure under active attacks.

In Cramer, R., editor, Public Key Cryptography, volume 4939 of Lecture Notes

in Computer Science, pages 162–179. Springer.

Lyubashevsky, V. and Micciancio, D. (2006). Generalized compact knapsacks are collision

resistant. In Bugliesi, M., Preneel, B., Sassone, V., and Wegener, I., editors, ICALP

(2), volume 4052 of Lecture Notes in Computer Science, pages 144–155. Springer.

Lyubashevsky, V., Micciancio, D., Peikert, C., and Rosen, A. (2008). Swifft: A modest

proposal for fft hashing. In Nyberg, K., editor, FSE, volume 5086 of Lecture Notes in

Computer Science, pages 54–72. Springer.

Micciancio, D. (2007). Generalized compact knapsacks, cyclic lattices, and efficient oneway

functions. In Computational Complexity. Springer.

Micciancio, D. and Goldwasser, S. (2002). Complexity of Lattice Problems: a cryptographic

perspective, volume 671 of The Kluwer International Series in Engineering

and Computer Science. Kluwer Academic Publishers, Boston, Massachusetts.

Shor, P. W. (1994). Polynominal time algorithms for discrete logarithms and factoring on

a quantum computer. In Adleman, L. M. and Huang, M.-D. A., editors, ANTS, volume

877 of Lecture Notes in Computer Science, page 289. Springer.

Stern, J. (1993). A new identification scheme based on syndrome decoding. In Stinson,

D. R., editor, CRYPTO, volume 773 of Lecture Notes in Computer Science, pages 13–

21. Springer.

Véron, P. (1995). Cryptanalysis of harari’s identification scheme. In Boyd, C., editor, IMA

Conf., volume 1025 of Lecture Notes in Computer Science, pages 264–269. Springer.

106


Véron, P. (1996). Improved identification schemes based on error-correcting codes. Appl.

Algebra Eng. Commun. Comput., 8(1):57–69.

Wagner, D. (2002). A generalized birthday problem. In Yung, M., editor, CRYPTO,

volume 2442 of Lecture Notes in Computer Science, pages 288–303. Springer.

107


Obtaining Efficient Fully Simulatable Oblivious Transfer from

General Assumptions

Bernardo M. David 1 , Anderson C. A. Nascimento 1 , Rafael Tonicelli 1

1 Department of Electrical Engineering, University of Brasilia.

Campus Universitario Darcy Ribeiro,Brasilia, CEP: 70910-900, Brazil

bernardo.david@redes.unb.br, andclay@ene.unb.br, tonicelli@redes.unb.br

Abstract. We introduce a general construction of fully simulatable oblivious

transfer based on lossy encryption. Furthermore, we extend the common definition

of lossy encryption by introducing the notion of computationally lossy

encryption. If the cryptosystem used is computationally lossy, our general construction

yields oblivious transfer protocols with computational security for both

parties. Otherwise, when regular statistically lossy cryptosystems are employed

in this construction, it yields oblivious transfer protocols with statistical security

for the sender. The construction introduced in this paper is realizable from rerandomizable,

homomorphic and lossy cryptosystems in general. Thus, it yields

specific constructions based on different assumptions, such as DDH, LWE and

McEliece. Moreover, it proves the equivalence of fully simulatable oblivious

transfer and lossy encryption.

1. Introduction

Oblivious transfer (OT), a cryptographic primitive introduced by Rabin [Rabin 1981], is

of great importance in the design of secure two-party and multiparty computation protocols.There

exist many variants of OT, each one suitable for a given kind of application. In

the present work, we concentrate ourselves on a variant called one-out-of-two oblivious

transfer, denoted by ( 2

1)

-OT. In this variant, a sender (Alice) inputs two bits b0 , b 1 and

a receiver (Bob) inputs a choice bit σ. At the end of the protocol, Alice receives nothing

and Bob receives the bit b σ . Loosely speaking, an OT protocol is said to be private

if the sender learns no information on the receiver’s choice σ, while the receiver gets

information concerning at most one of the sender’s inputs.

It has been proven that oblivious transfer enjoys a property called completeness,

meaning that any function can be securely computed if the parties are given black-box

access to OT [Kilian 1988]. Since OT serves as a building block for a wide variety of

secure protocols, it is desirable to have OT protocols that achieve a strong notion of security

against an unrestricted adversarial model. Regarding the adopted notion of security,

it is of particular interest to design OT protocols that are fully-simulatable, that is, secure

in the real/ideal model simulation paradigm. It is a well-known fact that OT protocols

proven secure in the simulation-based paradigm are secure under sequential composition

and, consequently, can truly be used as building blocks in more complex protocols. Regarding

the adopted adversarial model, it is desirable for an OT protocol to be resistant

against a malicious adversary. In contrast to a semi-honest adversary (who follows the

protocol, but may try to acquire more information than it is allowed to know), a malicious

108


adversary may arbitrarily deviate from the protocol specifications and, thus, represents a

more powerful adversarial model.

In spite of being a fundamental cornerstone in two- and multi-party computation,

there are only a few results of efficient OT constructions that are secure against malicious

adversaries under the real/ideal model simulation paradigm without random oracles

[Lindell 2008, Green and Hohenberger 2007, Camenisch et al. 2007]. In [Camenisch et al. 2007]

the authors introduce constructions based on q-power DDH and q-strong Diffie-Hellman,

which are strong and relatively non-standard assumptions. In [Green and Hohenberger 2007],

a construction based on the Decisional Bilinear Diffie-Hellman assumption is introduced.

The first construction based on standard assumptions is given in [Lindell 2008], which

introduces protocols based on the DDH assumptions, smooth projective hashing and general

homomorphic cryptosystems (which is an assumption much stronger than lossy encryption,

being realizable under much more limited number of underlying computational

assumptions).

1.1. Contributions

In this paper, we present the following significant contributions:

• An efficient fully-simulatable oblivious transfer protocol based on a general assumption:

Lossy Encryption [Hemenway et al. 2009, Bellare et al. 2009]. In this

construction we utilize techniques from the DDH based efficient fully simulatable

protocol presented in [Lindell 2008]. It is realizable from a broad number of

general assumptions (such as smooth projective hashing and re-randomization),

computational assumptions (such as DDH, LWE) and also the McEliece assumptions

under the extra assumption of the existence of perfectly binding and perfectly

hiding commitments.

• Our construction proves the equivalence between fully simulatable oblivious transfer

and several flavors of lossy encryption, since the converse is shown in [Hemenway et al. 2009].

• We introduce computationally lossy encryption, which is realizable under a broader

number of assumptions than statistically lossy encryption, and show that the proposed

general construction achieves computational security for both parties in the

case that such a cryptosystem is employed.

• We unify all current constructions of efficient fully simulatable oblivious transfer

in the plain model, since lossy encryption (computational or statistical) is realizable

under all of the assumptions previously used to construct fully simulatable

oblivious transfer in the plain model, such as: smooth projective hashing rerandomizable

cryptosystems, homomorphic cryptosystems, DDH, q-power DDH,

q-strong Diffie-Hellman and Bilinear Diffie-Hellman.

In summary, the main contribution of this paper is to provide a general construction

for fully-simulatable oblivious transfer based on the sole assumption of lossy encryption

and a property enjoyed by many constructions of such cryptosystems. This construction

is realizable under several well known computation assumptions, including factorization,

discrete logarithm, lattice and coding theory problems. Hence, it unifies all current

constructions of efficient fully simulatable oblivious transfer in the plain model.

109


2. Preliminaries

Hereupon, we will denote by x ∈ R D an uniformly random choice of element x over its

domain D; by ⊕ a bit-wise exclusive OR of strings; and by a | b the concatenation of

string a with string b. All logarithms are to the base 2. For a PPT machine A, we use

a $ ← A to denote running the machine A and obtaining an output, where a is distributed

according to the internal randomness of A.

If X and Y are families of distributions indexed by a security parameter λ, we

use X ≈ s Y to mean the distributions X and Y are statistically close, i.e., for all polynomials

p and sufficiently large λ, we have ∑ x

|P r[X = x] − P r[Y = x]| < 1. Two

sequences X n , n ∈ N and Y n , n ∈ N of random variables are said to be computationally

indistinguishable, denoted by X = c Y , if for every non-uniform probabilistic polynomialtime

distinguisher D there exists a negligible function ɛ(·) such that for every n ∈ N,

| P r[D(X n ) = 1] − P r[D(Y n ) = 1] |< ɛ(n).

2.1. Real/Ideal Model Simulation Paradigm

The real/ideal model paradigm has been extensively used to analyse the security of protocols

under sequential composition. In this model, security is analysed by comparing real

protocol execution with an ideal execution. In the ideal execution, the parties send their

private inputs to a trusted party that computes the desired functionality through confidential

and authenticated channels. After receiving the inputs, the trusted party computes the

function and returns the output assigned to each party. In the real execution, the parties

interact directly through the protocol. Intuitively, if all attacks feasible in the real model

are also feasible in the ideal model, the protocol is considered secure.

Ideal Model Execution. An ideal ( 2

1)

-OT functionality is formally defined as function

f with two inputs and one output. The sender Alice inputs two bits (b 0 , b 1 ), while the

receiver Bob inputs a bit σ. After the protocol is run, Alice receives no output (denoted by

the empty string λ), and Bob receives b σ . This is denoted as: f : {0, 1} 2 ×{0, 1} → {0, 1},

such that f((b 0 , b 1 ), σ) = (λ, m σ ).

Considering two two parties P a (Alice) and P b (Bob) that have access to a trusted

third party T , the ideal oblivious transfer functionality is described bellow.

Ideal OT Execution

Input generation. Party P a is activating upon receiving a pair (b 0 , b 1 ) ∈ {0, 1} 2

and party P b is activated upon receiving a bit σ.

Transmission of inputs to T . An honest participant sends its unaltered output to

the trusted party T . A malicious participant may abort (sending ⊥ to T ) or send any other

input to T .

Output computation by T . If the functionality T receives ⊥ from any of the

parties, then it sends ⊥ to both parties and halts. Else, upon receiving (b ′ 0, b ′ 1) from P a

and σ ′ from P b , T sends b ′ σ ′ to party P b and halts.

Outputs. An honest party always outputs the message as received from T (⊥ or

nothing in the case of P a , and ⊥ or b ′ σ ′ in the case of P b. A corrupted party can output an

arbitrary PPT function of its initial input and the message obtained from the trusted party.

110


Let f an ideal oblivious transfer functionality and let B = (B 1 , B 2 ) denote

an admissible pair (i.e. at least one of the parties is honest) of non-uniform probabilistic

expected polynomial-time machines (representing parties in the ideal model).

The joint execution of f under B in the ideal model on inputs ((b 0 , b 1 ), σ), denoted by

IDEAL f,B ((b 0 , b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained

by B 1 and B 2 after the ideal execution.

Real Model Execution. for this execution, no trusted party is available and the parties

interact directly. A corrupted party may adopt any arbitrary strategy implementable by

non-uniform PPT machines. Let π denote a two-party protocol and let A = (A 1 , A 2 )

denote a pair of non-uniform PPT machines (representing parties in the real model).

The joint execution of π under A in the real model on inputs ((b 0 , b 1 ), σ), denoted by

REAL π,A ((b 0 , b 1 ), σ), is defined as the resulting output pair and protocol transcript obtained

by A 1 and A 2 after the protocol execution.

Adversarial Model. In this paper, we consider the malicious adversarial model, where

a dishonest party may arbitrarily disrupt the protocol execution (for instance, a malicious

party is allowed to deviate from the protocol). Additionally, we assume the static corruption

model, where parties have fixed a behavior throughout protocol execution.

Enlightened by the previous definitions, we can now formalize the notion of securely

implementing an OT protocol in the simulation-based paradigm.

Definition 1. Consider an ideal OT functionality f and a two-party protocol π in the real

model. The protocol π is said to securely implement an OT protocol if for every pair of

admissible non-uniform PPT machines A = (A 1 , A 2 ) for the real model, there exists

a pair of admissible non-uniform probabilistic expected polynomial-time machines B =

(B 1 , B 2 ) for the ideal model, such that for every b 0 , b 1 ∈ {0, 1} and every σ ∈ {0, 1},

{

}

IDEAL f,B (n, (b 0 , b 1 ), σ) ≡ c REAL π,A (n, (b 0 , b 1 ), σ)

In order to achieve constant-round protocols it is necessary to allow the ideal adversary

and simulators to run in expected polynomial time [Barak and Lindell 2004].

3. Lossy Encryption

Lossy encryption [Hemenway et al. 2009, Bellare et al. 2009] expands on the definition

of Dual Mode Encryption [Peikert et al. 2008], a type of cryptosystem with two types of

public keys, which specify two modes of operation: a messy mode and a decryption mode.

In the decryption mode, the cryptosystem behaves normally and it is possible to decrypt a

message encrypted with a given public key using the corresponding secret key. However,

in the messy mode, the encrypted information is statistically lost.

A lossy cryptosystem is defined as a type of cryptosystem with two types of public

keys, injective and lossy keys, which specify different results of encryption. If injective

keys are used, the cryptosystem behaves regularly (correctly decrypting ciphertexts with

the right secret key) while in the lossy mode, the ciphertexts generated by the encryption

algorithm are independent from the plaintext messages,causing information to be statistically

lost. It is also required that lossy keys are indistinguishable from injective keys by

efficient adversaries.

111


It has been shown that it is possible to obtain lossy cryptosystems from oblivious

transfer, re-randomization and smooth projective hashing [Hemenway et al. 2009]. Thus,

our construction of fully simulatable oblivious transfer based on lossy encryption proves

that oblivious transfer and lossy encryption are equivalent.

We now present a formal definition of Lossy Encryption similar to the definition

given in [Hemenway et al. 2009]:

Definition 2. A lossy public-key encryption scheme is a tuple (G, E, D) of efficient algorithms

such that

• G(1 λ , inj) outputs keys (pk inj , sk inj ), keys generated by G(1 λ , inj) are called injective

keys.

• G(1 λ , lossy) outputs keys (pk lossy , sk lossy ), keys generated by G(1 λ , lossy) are called

lossy keys.

E(pk, m) is an encryption algorithm that takes as input a public key and a plain-text

message, outputting a ciphertext.

D(sk, c) is a decryption algorithm that takes as input a secret key and ciphertext, outputting

a plain-text message.

Additionally, the algorithms must satisfy the following properties:

• Correctness on injective keys. For all plaintexts x ∈ X,

[

]

P r (pk inj , sk inj ) ← $ G(1 λ , inj); r ← $ coins(E) : D(sk inj , E(pk inj , x, r)) = x = 1

• Indistinguishability of keys. In lossy mode, public keys are computationally indistinguishable

from those in the injective mode given no previous information.

Specifically, if proj : (pk, sk) → pk is the projection map, then

{

proj(G(1 λ , inj)) } c


{

proj(G(1 λ , lossy)) }

• Lossiness of lossy keys. If (pk lossy , sk lossy ) ← $ G(1 λ , lossy) , then for all x 0 , x 1 ∈

X, the statistical distance between the distributions E(pk lossy , x 0 , R) and E(pk lossy , x 1 , R)

is negligible in λ.

• Openability. If(pk lossy , sk lossy $

) ← G(1 λ $

, lossy), and r ← coins(E) , then for

all x 0 , x 1 ∈ X with overwhelming probability, there exists r ′ ∈ coins(E) such

that E(pk lossy , x 0 , r) = E(pk lossy , x 1 , r ′ ). In other words, there is an (unbounded)

algorithm opener that can open a lossy ciphertext to any arbitrary plaintext with

all but negligible probability.

Additionally, we require that there exists an efficient algorithm that distinguishes

between lossy and injective public keys given the corresponding secret key. Such algorithm

is formally denoted as:

• KD(sk, pk) is a PPT algorithm that receives as input a key pair (sk, pk) and outputs

0 if the public key is lossy. Otherwise, it outputs 1.

This property is valid for many flavors of lossy encryption such as the general constructions

based on re-randomization and smooth projective hashing [Hemenway et al. 2009].

112


However, for the sake of brevity, we will give formal proof only for the re-randomization

based construction, which is realized by many underlying computational assumptions.

The algorithm for the smooth projective hashing based construction follows trivially from

the fact that the key generation algorithm outputs an empty secret key if a lossy public

key is generated.

3.1. Computationally Lossy Encryption

In the present work, we also consider a variation of common statistically lossy encryption

which we call computationally lossy encryption. In a computationally lossy cryptosystem,

the distribution of ciphertexts generated under a lossy key is computationally

indistiguishable from the uniform distribution of ciphertexts (i.e. information is lost only

computationally). Such cryptosystems preserve all properties of statistically lossy cryptosystems

but the lossiness of key, which in this case is computational:

• Lossiness of lossy keys. If (pk lossy , sk lossy ) $ ← G(1 λ , lossy) , then for all x 0 , x 1 ∈

X, the distributions E(pk lossy , x 0 , R) and E(pk lossy , x 1 , R) are computationally indistinguishable

in λ.

Computationally lossy encryption is interesting since it yields an OT protocol with

computational security for both parties, a fact that has been previously observed only in

[Dowsley et al. 2008], which is not secure under sequential composition. Furthermore,

such a construction may be realized under a broader number of assumptions than statistically

lossy encryption allows. For example, it can be trivially obtained under the McEliece

assumptions using the techniques in [Dowsley et al. 2008] and [Hemenway et al. 2009].

Perhaps the re-randomization techniques in [David et al. 2010] can also be applied to obtain

a similar primitive.

3.2. A construction based on Re-Randomization

We now recall a construction of a IND-CPA secure statistically (resp. computationally)

lossy cryptosystem from a statistically (resp. computationally) re-randomizable cryptosystem

which is given and proven in [Hemenway et al. 2009]. Furthermore, we show

that it is possible to construct a public key distinguishing algorithm for this construction.

A cryptosystem is called statistically (resp. computationally) re-randomizable if,

given a ciphertext c and a public key, it is possible to re-randomize c obtaining a new valid

chipertext c ′ which encrypts the same plain-text message while being statistically (resp.

computationally) indistinguishable from the original c. Although different definitions of

re-randomizable cryptosystems exist, we consider a definition similar to the one given in

[Hemenway et al. 2009].

Notice that it is possible to obtain re-randomizable cryptosystems from homomorphic

cryptosystems, DDH, q-power DDH, q-strong Diffie-Hellman and Bilinear Diffie-

Hellman. Hence, our construction unifies all previous constructions of fully simulatable

oblivious transfer, which are based on these assumptions and also on smooth projective

hashing (that also yields lossy encryption).

Definition 3. Let (Gen, Enc, Dec, ReRand) be a statistically (resp. computationally) rerandomizable

IND-CPA secure public-key cryptosystem, we create statistically (resp. computational)

(G inj , G lossy , E, D) as follows:

113


• Key Generation: G(1 λ , inj) generates a pair (pk, sk) ← Gen(1 λ ). Then G(1 λ , inj)

generates K 0 = Enc(pk, 0), K 1 = Enc(pk, 1). G(1 λ , inj) returns (pk, sk) =

((pk, K 0 , K 1 ), sk).

G(1 λ , lossy) runs Gen(1 λ ), generating a pair (pk, sk). Then, it generates K 0 =

Enc(pk, 0), K 1 = Enc(pk, 0). G(1 λ , lossy) returns (pk, sk) = ((pk, K 0 , K 1 ), sk).

• Encryption: E(pk, b) = ReRand(pk, K b ) for b ∈ {0, 1}

• Decryption: D(sk, c), simply outputs Dec(sk, c).

An algorithm that distinguishes lossy public keys from injective public keys given

the corresponding secret key can be constructed as follows:

• KD(sk, pk): First computes test ciphertext c = E(pk, 1). Then output whatever

D(sk, c) outputs.

It is clear that, if the public key pk is injective, this algorithm will output 1, which

is the information encrypted into the ciphertext. Otherwise, if the public key is lossy, this

algorithm will output 0, since the ciphertext generated by E is always an encryption of 0

if the public key pk is lossy. Thus, the proposed algorithm KD successfully distinguishes

lossy and injective public keys given the corresponding secret key.

4. The Protocol

The protocol introduced in this section was inspired by the fully simulatable protocol

for Oblivious Transfer under the DDH assumptions presented in [Lindell 2008]. In this

protocol, the sender (Alice) inputs a pair of bits b 0 , b 1 and the receiver (Bob) inputs a

choice bit σ, Bob receives the bit b σ and Alice receives nothing (⊥). In the end of the

protocol Bob must not have learnt anything about the other bit b 1−σ and Alice must not

have learnt anything about Bob’s choice bit σ.

Apart from the IND-CPA secure lossy cryptosystem (Gen, Enc, Dec), we also assume

the existence of a perfectly hiding commitment scheme Com h and a perfectly binding

commitment scheme Com b . Notice that such commitments can be obtained from the

DDH assumptions (and its variations). Moreover, the smooth projective hashing and homomorphic

encryption based constructions also rely on such commitment schemes. Thus,

our construction unifies the previous fully simulatable oblivious transfer protocols based

on such assumptions.

The protocol is secure against static malicious adversaries, in other words, the parties

may deviate from the protocol but must have their behavior fixed before the execution

begins, behaving maliciously or honestly during the whole execution.

1. For i = 1, . . . , l, the receiver Bob chooses a random bit σ i ∈ R {0, 1} and runs

G(1 n , inj), obtaining l injective key pairs (pk inj

i , sk inj

i ). It also runs G(1 n , lossy),

obtaining l lossy key pairs (pk lossy

i , sk lossy

i ).For each bit σ i , Bob generates a pair

of public keys (γ σ i

i , γ 1−σ i

i ) such that γ σ i

i = pk inj

i and γ 1−σ i

i = pk lossy

i . Bob sends

all of the pairs 〈(γ1, 0 γ1), 1 . . . , (γl 0, γ1 l )〉 to Alice.

2. Coin tossing:

(a) Alice chooses a random s ∈ R {0, 1} l and sends Com h (s) to Bob.

(b) Bob chooses a random s ′ ∈ R {0, 1} l and sends Com b (s ′ ) to Bob.

(c) Alice and Bob send decommitments to Com h (s) and Com b (s ′ ) respectively,

and set r = s ⊕ s ′ . Denote r = r 1 , . . . , r l .

114


3. For every i for which r i = 1, Bob sends (sk inj

i , sk lossy

i ) to Alice. In addition, for

every j for which r j = 0, Bob sends a ”reordering” of γj 0 and γj 1 such that, in the

resulting tuples (γj 0 , γj 1 ), γj

σ is an injective public key and γ 1−σ

j is a lossy public

key. This reordering is a bit such that if it equals 0 then the tuples are left as is,

and if it equals 1 then γj 0 and γj 1 are interchanged.

4. Alice checks that, for every i for which r i = 1 it received a valid secret key pair

(sk inj

i , sk lossy

i ), such that exactly one of the corresponding public keys is injective

and exactly one is lossy. Furthermore, it checks that exactly one of the public keys

(γi 0 , γi 1 ) received is injective and exactly one of the public keys is lossy by running

KD(sk inj

i , γi 0 ) and KD(sk inj

i , γi 1 ). If any of the checks fail, Alcie halts and outputs

⊥. Otherwise it proceeds to the next step.

5. For each j for which r j = 0 denote each (γ 0 j , γ 1 j ) as (Υ 0 n, Υ 1 n) for n = 1, . . . , l ′ ,

where l ′ is the total number of j for which r j = 0. Employing a reduction given in

[Damgård et al. 1999], Alice chooses n random bits b 0,1 , . . . , b 0,n and n random

bits b 1,1 , . . . , b 1,n such that b 0 = b 0,1 ⊕ . . . ⊕ b 0,n and b 1 = b 1,1 ⊕ . . . ⊕ b 1,n .

For each pair of bits b 0,n , b 1,n and each (Υ 0 n, Υ 1 n) Alice computes a random bit

µ n ∈ R {0, 1} and the encryption of b •,n ⊕ µ n for each bit in the pair, obtaining

ˆb0,n = E(Υ 0 n, b 0,n ⊕ µ n ) and ˆb 1,n = E(Υ 1 n, b 1,n ⊕ µ n ). Alice sends the bits µ n and

the pairs (ˆb 0 n, ˆb 1 n) to Bob.

6. For each pair of bit ˆb σ,n and bit µ n Bob computes b σ,n = D(sk inj

n , ˆb σ,n ) ⊕ µ n .

Finally, bob computes b σ = b σ,1 ⊕ . . . ⊕ b σ,n , obtaining b σ .

Correctness: Before proceeding to the proof of security, we show that the protocol

above is correct, in the sense that, if both Alice and bob are honest, the correct

output is obtained. First, observe that in the reordered pairs obtained after the coin tossing,

Υ σ n is an injective key, enabling an honest Bob to extract a bit encrypted with it

are lossy, which makes it im-

Also, since

ˆbσ,n = E(Υ σ n, b σ,n ⊕ µ n ) for a random value of µ n , Bob is not able to obtain the original

value of b σ,n without first obtaining the corresponding µ n .

(i.e., b = D(skn

inj , E(Υ σ n, b))). However, the keys Υ 1−σ

n

possible for Bob to obtain the value of a bit encrypted with those keys.

Given that Alice and Bob are honest, it is possible for Bob to obtain the bit b σ

since, based on the facts stated above, it is possible to obtain the value of each bit b σ,n

computing b σ,n = D(skn

inj , ˆb σ,n )⊕µ n after receiving the correct values of µ n and ˆb σ,n from

Alice. In order to obtain the original bit b σ , Bob employs the reduction given and proven

in [Damgård et al. 1999] computing b σ = ⊕ n i=1b σ,i , correctly yielding: b σ = (b σ,1 ⊕ µ 1 ) ⊕

. . . ⊕ (b σ,n ⊕ µ n ).

Notice that, if statistically lossy encryption is employed, the resulting protocol

offers statistical security for the sender, since the ciphertexts ˆb 1−σ,n statistically loose

information about the bits corresponding to ˆb 1−σ . On the other hand, if computationally

lossy encryption is employed, the resulting protocol offers computational security for

the sender, since the ciphertexts ˆb 1−σ,n computationally loose information about the bits

corresponding to ˆb 1−σ . The security for the receiver is computational in both cases, since

it relies on the computational indistinguishability of lossy and injective keys.

115


4.1. Simulator for the case Alice (sender) is corrupted

In order to prove the security of the proposed protocol we adapt the simulators given in

[Lindell 2008] for the case where the sender is corrupted and the case the receiver is corrupted.

Notice that the resulting simulators have the same running time of the simulators

in [Lindell 2008], since the steps involved are essentially the same. Let A 1 be a nonuniform

probabilistic polynomial-time real adversary that controls Alice. We construct a

non-uniform probabilistic expected polynomial-time ideal-model adversary/simulator S 1 .

S 1 uses rewinding in order to ensure that all of the ”checked” public key pairs are valid

(i.e.,exactly one of them is lossy), whereas both keys contained in the ”unchecked” public

key pairs are injective. This enables it to obtain both messages input by A 1 into the

protocol. S 1 then sends these inputs to the trusted party, and the honest party Bob in the

ideal model will receive the same message that it would have received in a real execution

with A 1 (or more accurately, a message that is computationally indistinguishable from

that message).

We now describe S 1 formally. Upon input 1 n and (b 0 , b 1 ), the machine S 1 invokes

A 1 upon the same input and works as follows:

1. S 1 chooses a random r ∈ R 0, 1 l and generates public key pairs (γ1, 0 γ1), 1 . . . , (γl 0, γ1 l )

with the following property:

(a) For every i for which r i = 1, S 1 constructs (γi 0 and γi 1 ) like an honest Bob.

It runs G(1 n , inj), obtaining l injective key pairs (pk inj

i , sk inj

i ). It also runs

G(1 n , lossy), obtaining l lossy key pairs (pk lossy

i , sk lossy

i ). S 1 generates a

pair of public key (γ σ i

i , γ 1−σ i

i ) such that γ σ i

i = pk inj

i and γ 1−σ i

i = pk lossy

i ,

for random bits σ i ∈ R {0, 1}.

(b) For every j for which r j = 0, S 1 constructs (γj 0 , γj 1 ) such that both γj 0 and

γj 1 are injective keys.

S 1 hands the public key pairs to A 1 .

2. Simulation of the coin tossing: S 1 simulates the coin tossing so that the result is

r, as follows:

(a) S 1 receives a commitment c h from A 1 .

(b) S 1 chooses a random s ′ ∈ R {0, 1} l and hands c b = Com h (s ′ ) to A 1 .

(c) If A 1 does not send a valid decommitment to c h , then S 1 simulates Bob

aborting and sends ⊥ to the trusted party. Then S 1 outputs whatever A 1

outputs and halts. Otherwise, let s be the decommitted value. S 1 proceeds

as follows:

i. S 1 sets s ′ = r ⊕ s, rewinds A 1 , and hands it Com b (s ′ ).

ii. If A 1 decommits to s, then S 1 proceeds to the next step. If A 1

decommits to a value ˜s ≠ s, then S 1 outputs fail. Otherwise, if it

does not decommit to any value, S 1 returns to the previous step and

tries again until A 1 does decommit to s. (We stress that in every

attempt, S 1 hands A 1 a commitment to the same value s ′ . However,

the randomness used to generate the commitment Com b (s ′ ) is

independent each time.) 1

1 Similarly to the DDH based protocol of [Lindell 2008], this strategy by S 1 does not actually guarantees

that it runs in expected polynomial-time. Fortunately this issue is solved in [Lindell 2008] and we refer the

reader to that work for detailed information.

116


3. Upon receiving a valid decommitment to s from A 1 , simulator S 1 decommits to

A 1 , revealing s ′ . (Note that r = s ⊕ s ′ .)

4. For every i for which r i = 1, simulator S 1 hands A 1 the secret key pairs (sk inj

i

, sk lossy

i )

correspondent to the public keys (γ 0 i , γ 1 i ). In addition, S 1 hands A 1 a random reordering

of the pairs (γ 0 j , γ 1 j ) for every j for which r j = 0.

5. If A 1 does not reply with a valid message, then S 1 sends ⊥ to the trusted party,

outputs whatever A 1 outputs and halts. Otherwise, it receives the bits µ n and a

series of pairs (ˆb 0 n, ˆb 1 n). S 1 then follows the instructions of Bob for obtaining both

b 0 and b 1 . Unlike an honest Bob, it decrypts both ˆb 0 n and ˆb 1 n with the injective secret

keys corresponding to (Υ 0 n, Υ 1 n), obtaining a series of pairs (b 0,n , b 1,n ). It then

computes b 0 = (b 0,1 ⊕µ 1 )⊕. . .⊕(b 0,n ⊕µ n ) and b 1 = (b 1,1 ⊕µ 1 )⊕. . .⊕(b 1,n ⊕µ n ).

S 1 sends the pair (b 0 , b 1 ) to the trusted party as the first party’s input, outputs

whatever A 1 outputs and halts.

Theorem 4. The joint output distribution of S 1 and an honest Bob in an ideal execution is

computationally indistinguishable from the output distribution of A 1 and an honest Bob

in a real execution.

Proof. In order to prove this theorem we adapt the proof given in [Lindell 2008]. Notice

that the view of A 1 in the simulation with S 1 is indistinguishable from its view in a real

execution. The sole difference in this view is due to the fact that the public keys γ 0 j and

γ 1 j for which r j = 0 are both injective public keys.

The only other difference would be in the coin tossing phase (and the rewinding).

However, since the commitment sent by A 1 is binding and since Bob generates its commitment

after receiving A 1 ’s commitment, it is clear that the result of the coin tossing in

a real execution and in the simulation with S 1 are statistically close to uniform (where the

only difference is due to the negligible probability that A 1 will break the computational

binding property of the commitment scheme.) In the simulation by S 1 , the outcome is

always uniformly distributed, assuming that S 1 does not output fail. Since S 1 outputs fail

when A 1 breaks the computational binding of the commitment scheme, this occurs with at

most negligible probability (a rigorous analysis is given in [Goldreich and Kahan 1996]).

Thus, the joint distribution of the coin tossing results in a real execution and in the simulation

with S 1 are statistically close.

Therefore, the only remaining difference lies in the generation of public keys γ 0 j

and γ 1 j . Indistinguishability follows intuitively from the definition of lossy encryption

(i.e. lossy public keys are computationally indistinguishable from injective public keys).

This is formally proven by constructing a machine D that distinguishes many injective

keys from many lossy keys, which implies in breaking the lossy key indistinguishability

property of the lossy cryptosystem. D receives a set of public keys and runs in exactly

the same way as S 1 but constructs the γ 0 j and γ 1 j public keys (for which r j = 0) in such a

way that one is injective and the other is from its input, in random order. Furthermore, it

provides the reordering so that all of the injective keys it generates are associated with σ

and all of the ones it receives externally are associated with 1 − σ (we assume that D is

given the input σ of Bob). Note that, if D receives a set of injective keys, then the view

of A 1 is exactly the same as in the simulation with S 1 (because all the keys are injective).

Otherwise, if D receives a set of lossy keys, then the view of A 1 is exactly the same as

in a real execution (because only the keys associated with σ are injective). This shows

117


that the output of A 1 in a real execution and the output of S 1 in an ideal execution are

indistinguishable (recall that S 1 outputs whatever A 1 outputs).

However,it is necessary to show this for the joint distribution of the output of A 1

(or S 1 ) and an honest Bob. First, recall that Bob receives m σ as output, where σ is the

honest Bob’s input. Next, assume that there exists a polynomial-time distinguisher D ′

that distinguishes between the real and ideal distributions with non-negligible probability.

To complete this proof we construct another distinguisher D that distinguishes injective

keys from lossy keys. D receives Bob’s input σ and a set of keys that are either injective

or lossy. D then works exactly as above (i.e., constructing the public keys γj 0 and γj 1 so

that in the reordering step, all the γj

σ keys are those it generated itself and all the γ 1−σ

j

tuples are those it received as input). D is able to decrypt each ˆb σ,n and obtain m σ , since

it generated all of the γj σ keys. Machine D then does this, and runs D ′ on the output of A 1

and the message m σ (which is the output that an honest Bob would receive). Finally, D

outputs whatever D ′ does. If D receives lossy keys, then the output distribution generated

is exactly the same of a real execution between A 1 and Bob. On the contrary, if it receives

injective keys, the output distribution is exactly the same of an ideal execution with S 1 .

(Notice that the distribution over the γ public keys generated by D with knowledge of σ is

identical to the distribution generated by S 1 without knowledge of σ. The reason for this

is that when all the keys are injective, their ordering makes no difference.) We conclude

that D distinguishes lossy and injective public keys with non-negligible probability, in

contradiction to the definition of lossy encryption. Thus, the REAL and IDEAL output

distributions are computationally indistinguishable.

The last step is to prove that S 1 runs in expected polynomial-time. However, as in

the protocols given in [Lindell 2008] this is not true. Fortunately, this can be fixed by a direct

application of the techniques proposed in [Lindell 2008] and [Goldreich and Kahan 1996],

and we refer the reader to these works for a detailed analysis. It is shown that these

techniques yield a simulator that is guaranteed to run in expected polynomial time. Furthermore,

the output of the simulator is only negligibly far from the original (simplified)

strategy described in this work. Thus, after applying these techniques, our simulator runs

in expected polynomial time, with the result being that the output in a simulation is only

negligibly different from the output in a real execution.

4.2. Simulator for the case Bob (receiver) is corrupted

Once again we base our simulator and proof on the techniques proposed in [Lindell 2008].

Let A 2 be any non-uniform probabilistic polynomial-time adversary controlling Bob, we

construct a non-uniform probabilistic expected polynomial-time simulator S 2 . The simulator

S 2 extracts the bit σ used by A 2 by rewinding it and obtaining the reordering of

public keys that it had previously opened. Formally, upon input 1 n and σ, the simulator

S 2 invokes A 2 upon the same input and works as follows:

1. S 2 receives a series of public key pairs (γ 0 1, γ 1 1), . . . , (γ 0 l , γ1 l ) from A 2.

2. S 2 hands A 2 a commitment c h = Com h (s) to a random s ∈ R {0, 1} l , receives

back c b , decommits to c h and receives A 2 ’s decommitment to c b . S 2 then receives

all of the sk i keys from A 2 , for i where r i = 1, and the reorderings for j where

r j = 0. If the pairs (γ 0 i , γ 1 i ) sent by A 2 are not valid (as checked by Alice in the

118


protocol) or A 2 did not send valid decommitments, S 2 sends ⊥ to the trusted party,

outputs whatever A 2 outputs, and halts. Otherwise, it continues to the next step.

3. S 2 rewinds A 2 back to the beginning of the coin-tossing, hands A 2 a commitment

˜c h = Com h (˜s) to a fresh random ˜s ∈ R {0, 1} l , receives back some ˜c b , decommits

to ˜c h and receives A 2 ’s decommitment to ˜c b . In addition, S 2 receives the

(sk inj

i , sk lossy

i ) secret key pairs and reorderings. If any of the pairs (γi 0 , γi 1 ) are

not valid, S 2 repeats this step using fresh randomness each time, until all pairs are

valid.

4. Following this, S 2 rewinds A 2 to the beginning and resends the exact messages of

the first coin tossing (resulting in exactly the same transcript as before).

5. Denote by r the result of the first coin tossing (Step 2 above), and ˜r the result of

the second coin tossing (Step 3 above). If r = ˜r then S 2 outputs fail and halts.

Otherwise, S 2 searches for a value t such that r t = 0 and ˜r t = 1. (Note that by the

definition of the simulation, exactly one of γt 0 and γt 1 is injective. Otherwise, the

values would not be considered valid.) If no such t exists (i.e., for every t such that

r t ≠ ˜r t it holds that r t = 1 and ˜r t = 0),then S 2 begins the simulation from scratch

with the exception that it must find r and ˜r for which all values are valid (i.e., if

for r the values sent by A 2 are not valid it does not terminate the simulation but

rather rewinds until it finds an r for which the responses of A 2 are all valid).

If S 2 does not start again, we have that it has sk t and can determine which of (γt

0

and γt 1 is injective. Furthermore, since ˜r t = 1, the reordering that S 2 receives from

A 2 after the coin tossing indicates whether the public key pair is associated with 0

(if γt 0 is injective) or 1 (if γt 1 is injective) . S 2 sets σ = 0 if after the reordering γt

0

is injective, and sets σ = 1 if after the reordering γt 1 is injective. (Note that exactly

one of the keys is injective because this is checked in the second coin tossing.)

6. S 2 sends σ to the trusted party and receives back a bit b = b ′ σ. Simulator S 2 then

computes the last message from Alice to Bob honestly, setting b σ = b, b 1−σ ∈ R

{0, 1} and running the instruction used by an honest Alice to compute the last

message. S 2 hands A 2 these messages and outputs whatever A 2 outputs and halts.

Theorem 5. The output distribution of A 2 in a real execution with an honest Alice (with

input (m 0 , m 1 )) is computationally indistinguishable from the output distribution of S 2 in

an ideal execution with an honest Alice (with the same input (m 0 , m 1 ))

Proof. First, notice that S 2 outputs fail with probability at most 2 1−l even if r = ˜r in

later rewindings, which may occur if S 2 has to start again from scratch. A detailed analysis

of this probability is given in [Lindell 2008]. Given this fact, we proceed to show

indistinguishability of the ideal and real executions adapting the proof of [Lindell 2008].

Notice that, if S 2 does not output fail, A 2 views a final transcript consisting of the

first coin tossing (that is distributed exactly as in a real execution) and the last message

from S 2 to A 2 . This message is not honestly generated, since c σ is indeed an encryption

of m σ , but c 1−σ is actually an encryption of an arbitrary value (which is not necessarily of

m 1−σ ). However, it follows from the definition of lossy encryption (specifically from the

lossiness property) that, for any lossy public key γ 1−σ

j , the value encrypted in ˆb 1−σ,n is at

least computationally indistinguishable from a random value in the lossy cryptosystem’s

plaintext space. This implies that the distribution of values ˆb 1−σ,n generated under a lossy

key from a random plaintext value is computationally indistinguishable from the distribution

of values ˆb 1−σ,n generated from the values m 1−σ . Thus, A 2 ’s view in the execution

119


with S 2 is at least computationally indistinguishable from its view in a real execution with

Alice (the only difference being if S 2 outputs fail).

Note that, if statistically lossy encryption is used, the values ˆb 1−σ,n are uniformly

distributed. Thus, A 2 ’s view in the execution with S 2 is statistically close to its view in a

real execution with Alice (the only difference being if S 2 outputs fail).

It remains to prove that S 2 runs in expected polynomial-time, a fact that follows

directly from the analysis in [Lindell 2008].

5. Conclusion

In this paper we propose a general construction of efficient fully simulatable oblivious

transfer based on lossy encryption. Our construction can be realized from a multitude of

underlying primitives and computational assumptions such as smooth projective hashing,

re-randomization, factorization, discrete logarithm and coding theory problems. Additionally,

the proposed protocol essentially unifies known efficient fully simulatable OT

protocols in the plain model. Furthermore, this protocol completes the proof that several

flavors of lossy encryption are equivalent to fully simulatable oblivious transfer, since the

converse is proved in [Lindell 2008] for smooth projective hashing and re-randomization

based constructions.

In order to obtain our results we introduce the primitive of computationally lossy

encryption, which may be of independent interest to other applications. In this case,

it can be used to obtain a construction of efficient fully simulatable OT based on the

McEliece assumptions, which can be shown to realize computationally lossy encryption

using the techniques of [Dowsley et al. 2008]. However, this construction would still

be based on the assumption that a perfectly hiding commitment scheme and a perfectly

binding commitment scheme exist.

Apart from unveiling new theoretical relations between cryptographic primitives,

our contributions also provide a general framework for constructing efficient fully simulatable

oblivious transfer protocols, which are a central building block in two- and multiparty

computation. However, we have not yet achieved security in the universal composability

framework. As a future work we suggest the creation a of a general unifying

framework for universally composable oblivious transfer realizable under the same underlying

computational assumptions as our fully simulatable construction. Moreover, we

point out further investigation of applications for computationally lossy encryption.

References

Barak, B. and Lindell, Y. (2004). Strict polynomial-time in simulation and extraction.

SIAM J. Comput., 33(4):738–818.

Bellare, M., Hofheinz, D., and Yilek, S. (2009). Possibility and impossibility results for

encryption and commitment secure under selective opening. In Proceedings of the

28th Annual International Conference on Advances in Cryptology: the Theory and

Applications of Cryptographic Techniques, EUROCRYPT ’09, pages 1–35, Berlin,

Heidelberg. Springer-Verlag.

120


Camenisch, J., Neven, G., and Shelat, A. (2007). Simulatable adaptive oblivious transfer.

In Naor, M., editor, EUROCRYPT, volume 4515 of Lecture Notes in Computer Science,

pages 573–590. Springer.

Damgård, I., Kilian, J., and Salvail, L. (1999). On the (im)possibility of basing oblivious

transfer and bit commitment on weakened security assumptions. In EUROCRYPT’99:

Proceedings of the 17th international conference on Theory and application of cryptographic

techniques, pages 56–73, Berlin, Heidelberg. Springer-Verlag.

David, B. M., Nascimento, A. C. A., and Nogueira, R. B. (2010). Oblivious transfer based

on the mceliece assumptions with unconditional security for the sender. In X Simposio

Brasileiro de Segurança da Informação e de Sistemas Computacionais.

Dowsley, R., van de Graaf, J., Müller-Quade, J., and Nascimento, A. C. A. (2008). Oblivious

transfer based on the mceliece assumptions. In Safavi-Naini, R., editor, ICITS,

volume 5155 of Lecture Notes in Computer Science, pages 107–117. Springer.

Goldreich, O. and Kahan, A. (1996). How to construct constant-round zero-knowledge

proof systems for np. Journal of Cryptology, 9:167–189. 10.1007/BF00208001.

Green, M. and Hohenberger, S. (2007). Blind identity-based encryption and simulatable

oblivious transfer. In Kurosawa, K., editor, ASIACRYPT, volume 4833 of Lecture Notes

in Computer Science, pages 265–282. Springer.

Hemenway, B., Libert, B., Ostrovsky, R., and Vergnaud, D. (2009). Lossy encryption:

Constructions from general assumptions and efficient selective opening chosen ciphertext

security. Cryptology ePrint Archive, Report 2009/088. http://eprint.

iacr.org/.

Kilian, J. (1988). Founding crytpography on oblivious transfer. In STOC ’88: Proceedings

of the twentieth annual ACM symposium on Theory of computing, pages 20–31, New

York, NY, USA. ACM.

Lindell, A. Y. (2008). Efficient fully-simulatable oblivious transfer. In Proceedings of

the 2008 The Cryptopgraphers’ Track at the RSA conference on Topics in cryptology,

CT-RSA’08, pages 52–70, Berlin, Heidelberg. Springer-Verlag.

Peikert, C., Vaikuntanathan, V., and Waters, B. (2008). A framework for efficient and

composable oblivious transfer. In Wagner, D., editor, Advances in Cryptology –

CRYPTO 2008, volume 5157 of Lecture Notes in Computer Science, pages 554–571.

Springer Berlin / Heidelberg.

Rabin, M. O. (1981). How to exchange secrets by oblivious transfer. Technical Memo

TR-81, Aiken Computation Laboratory, Harvard University.

121


Syndrome-Fortuna: A viable approach for Linux random

number generation

Sérgio Vale Aguiar Campos 1 , Jeroen van de Graaf 1 , Daniel Rezende Silveira 1

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais (UFMG)

Belo Horizonte (MG) – Brazil

Abstract. This work presents a random number generator based on the intractability

of an NP-Complete problem from the area of error-correcting codes.

It uses a non-heuristic approach for entropy collection, taken from the Fortuna

design philosophy. We implemented the new generator inside the Linux kernel,

providing an alternative system interface for secure random number generation.

1. Introduction

Random number generators are the basis of several cryptographic systems. Its output must

be unpredictable by potential adversaries and should be produced fast and efficiently. The

most common way to achieve this is by using algorithms to mix and expand the outcome

of entropy sources. These algorithms are called pseudo-random number generators

(PRNGs). The quality of these generators and their applicability to protocols and security

applications have been widely studied in recent years.

In this work we present a PRNG based on the Fortuna architecture, proposed by

[Ferguson and Schneier, 2003]. Fortuna presents a new scheme for system events collection,

that does not use any heuristics, avoiding entropy estimation problems. Its mixing

function is the AES algorithm, considered strong and efficient.

The PRNG we propose, called Syndrome-Fortuna, changes the mixing function of

Fortuna, using the syndrome decoding algorithm proposed by [Fischer and Stern, 1996].

We consider this an improvement, since the syndrome problem is known to be NP-

Complete, and has a formal proof of its strength.

We implemented Syndrome-Fortuna inside the Linux kernel version 2.6.30, providing

an user interface for random numbers besides /dev/urandom. As we expected,

our generator is slower than the original Linux random number generator (LRNG). But it

does not use any entropy estimation heuristics and applies a strong and formally proved

algorithm as its core function.

1.1. Randomness concept

Random number generators emerged, initialy, for use in simulations and numerical analysis.

These applications require efficiency and, especially, uniformity. The cryptography

evolution brought a new requirement on PRNGs. Secure applications needed secret keys,

generated randomly, to allow users to communicate safely. Since then, unpredictability

has become a fundamental requirement for pseudorandom number generators.

The only way to ensure that a generator seed is non-deterministic is by using real

sources of randomness. External sources of randomness collect data from presumably

unpredictable events, such as variations in pressure and temperature, ambient noise, or

122


timing of mouse movements and keystrokes. The concept of unpredictability is related

to human inability to predict certain complex phenomena, given its chaotic or quantum

essence.

Before using the collected randomness, however, it is necessary to estimate it. The

goal is to prevent that the internal state of the generator is updated with values potentially

easy to discover. In 1996 a flaw in the random number generator of Netscape browser

allowed that keys used in SSL connections were discovered in about one minute. The

problem, revealed in the work of [Goldberg and Wagner, 1996], was the use of system

time and the process id as sources of randomness. Even when the browser used session

keys of 128 bits, considered safe, they possessed no more than 47 bits of randomness,

very little to prevent that opponents using brute force could find the key value.

Entropy estimation is one critical point of random number generators design, because

their security level is directly related to estimates precision. As we shall see, the

approach of entropy collection proposed by [Ferguson and Schneier, 2003] and adapted

in this work minimizes the problem of possible inaccuracy in the estimation of entropy.

2. Construction of a cryptographically secure random number generator

2.1. One-way functions

Intuitively, a function f is one-way if it is easy to compute but difficult to invert. In other

words, given x, the value f(x) can be computed in polynomial time. But any feasible

algorithm that receives f(x) can generate an output y such that f(y) = f(x) with only

negligible probability.

The existence of one-way functions is not proved. It is known that if P = NP

they certainly do not exist. But it is unclear whether they exist if P ≠ NP . However,

there are several functions that are believed to be unidirectional in practice. One of them

is the SHA-1 hash function, used inside the Linux random number generator. There are

also functions that are conjectured to be unidirectional. Some examples are the subsets

sum problem and the discrete logarithm calculation. These functions belong to the class

NP, and supposing P ≠ NP , and are unidirectional under some intractability assumption.

The main difference between the two types of one-way functions, besides the theoretical

basis, is the computational cost. Functions based on intractable mathematical

problems require, in general, a larger amount of calculations per bit generated. As shown

in [Impagliazzo et al., 1989], cryptographically secure pseudorandom number generators

exists if, and only if, one-way functions exists.

In the generator presented in this paper we use the algorithm proposed by

[Fischer and Stern, 1996] as our one-way function. It is based on the syndrome decoding

problem, a NP-complete problem from the area of error-correcting codes.

2.2. Syndrome decoding problem

In coding theory, coding is used to transmit messages through noisy communication channels,

which can produce errors. Decoding is the process of translating (possibly corrupted)

messages into words belonging to a particular code. A binary linear code is an errorcorrecting

code that uses the symbols 0 and 1, in which each word can be represented as a

linear combination of others, and each word has a weight, ie, a number of 1 bits, defined.

123


A binary linear code (n, k, d) is a subspace of {0, 1} n with 2 k elements in which

every word has weight less than or equal to d. The information rate of the code is k/n

and it can correct up to ⌊ d−1 ⌋ errors. Every code can be defined by a parity matrix of

2

size n × (n − k) which multiplied (mod 2) by a vector of the code x = ( )

x 1 , x 2 , . . . , x n

results in an all zero vector s = ( 0, 0, . . . , 0 ) of size (n−k), called syndrome. Conversely,

when the word multiplied by the parity matrix does not belong to the code, the value of

the syndrome is nonzero.

A randomly filled parity matrix defines a random binary linear code. For this code,

there is no efficient algorithm known that can find the closest word to a vector, given a

nonzero syndrome. Another difficult problem, known as syndrome decoding, is to find a

word of certain weight from its syndrome.

The latter problem is NP-Hard and can be described as follows: let a binary matrix

A = {a ij } of size n × (n − k), a non-zero syndrome vector s and a positive integer w.

Find a binary vector x with weight |x| ≤ w, such that:



a 1,1 a 1,2 · · · a 1,n−k

( ) a 2,1 a 2,2 · · · a 2,n−k

x1 , x 2 , . . . , x n · ⎜


.

. . .


. . ⎠ = ( )

s 1 , s 2 , . . . , s n−k

a n,1 a n,2 · · · a n,n−k

(mod 2)

The case in which we seek the vector x with weight |x| = w is NP-complete

[Berlekamp et al., 1978].

The fact that a problem is NP-Complete guarantees that there is no polynomial

time algorithm for solving the worst case, under the assumption that P ≠ NP . Many

problems, however, can be solved efficiently in the average case, requiring a more detailed

study of each instance of the problem.

2.2.1. Gilbert-Warshamov Bound

To evaluate the hardness of a specific instance of the syndrome decoding problem we

will use a concept extensively studied and reviewed by [Chabaud, 1994], under which the

most difficult instances of the problem of syndrome decoding for random codes are those

with weights in the vicinity of the Gilbert-Warshamov bound of the code.

The Gilbert-Warshamov bound λ of a code (n, k, d) is defined through the relation

1 − k/n = H 2 (λ) where H 2 (x) = −x log 2 x − (1 − x) log 2 (1 − x) is the binary entropy

function.

According to the analysis of [Fischer and Stern, 1996], there is, on average, a vector

for each syndrome when the weight is around the Gilbert-Warshamov bound of the

code. That is, the difficulty of finding a word is a function of the weight increasing until

the Gilbert-Warshamov bound, and decreasing thereafter. Thus, it is possible to define

a hard instance of the syndrome decoding problem when the weight is near the Gilbert-

Warshamov bound.

124


Figure 1. Gilbert-Warshamov bound, defined by the binary entropy function.

2.2.2. Formal definitions

Definition A function f : {0, 1} ∗ → {0, 1} ∗ is considered strongly unidirectional if the

following conditions apply:

• Easy to compute: there is a deterministic polynomial-time algorithm A such that

for every input x, an output A(x) = f(x) is computed.

• Hard to invert: for all probabilistic polynomial-time algorithm A ′ and every positive

polynomial p(n) large enough,

P r(A ′ (f(X n )) ∈ f −1 (f(X n ))) < 1

p(n)

where x n is random and uniformly distributed over {0, 1} n

Let us consider a collection of functions related to the problem of decoding the

syndrome.

Definition Let ρ be in ]0, 1[ and δ be in ]0, 1/2[. A collection SD(ρ, δ) is a set o functions

f n such that:

D n = {(M, x), M ∈ ⌊ρn⌋ × n, x ∈ {0, 1} n /|x| = δn}

f n : D n → {0, 1} ⌊ρn⌋·(n+1)

(M, x) → (M, M · x)

According to [Fischer and Stern, 1996], instances of the problem with weight δn

very small or close to n/2 are not difficult. The instances of the collection SD with the

weight δ near the Gilbert-Warshamov bound are believed to be unidirectional, although

there is no proof in this sense. Thus we have the following assumption of intractability:

Intractability assumption Let ρ be in ]0, 1[. Then, for all δ in ]0, 1/2[, such that H 2 (δ) <

ρ, the collection SD(ρ, δ) is strongly unidirectional.

125


Note that if H 2 (λ) = ρ and δ < λ , the intractability of SD(ρ, δ) is a special case

2

of decoding beyond half the minimum distance. Thus, the assumption becomes stronger

than the usual assumptions for the decoding problem [Goldreich et al., 1993].

Cryptographic applications based on the complexity of known problems have been

extensively studied and implemented in the last decades. Intractability assumptions are a

natural step in building such applications. At the current state of knowledge in complexity

theory, one cannot hope to build such algorithms without any intractability assumptions

[Goldreich, 2001, p. 19].

3. Syndrome-Fortuna

The purpose of this work is to develop a random number generator and implement it

inside the Linux kernel. The generator has its own scheme for entropy collection and the

generating function is based on the intractability of the syndrome decoding problem. We

will show that the proposed generator applies good grounds of security and is based on

sound mathematical principles.

The generator was designed with independent functions of entropy collection and

random values generation. Each one will be addressed separetely.

3.1. Fortuna: Entropy collection

[Ferguson and Schneier, 2003] proposed a cryptographically secure random number generator

called Fortuna. The main contribution of Fortuna is the events collection system.

It eliminated the need of entropy estimators, used until then in most of the generators we

are aware of. Entropy estimation is commonly used to ensure that the generator state – or

seed – is catastrophically updated, i.e., with sufficient amount of randomness. This should

prevent potential adversaries who, for some reason, already know the seed, to iterate over

all the possible new states and maintain control over the generator. If the possible new

states are too many, it will not be feasible to try all of them.

3.1.1. Entropy accumulator

The Fortuna entropy accumulator captures data from various sources of entropy and uses

them to update the seed of the generator. Its architecture, as we shall see, keeps the system

secure even if an adversary controls some of the sources.

The captured random events must be uniform and cyclically distributed across n

pools of the generator, as shown in figure 2. This distribution will ensure an even spread

of entropy among pools, which will allow seed updates with successively larger amounts

of randomness.

Each pool can receive, in theory, unlimited random data. To implement this the

data is compressed incrementally, using the SHA 256 hash function, thus maintaining

pools with constant size of 256 bits.

The generator state will be updated when the P 0 pool accumulate sufficient random

data. A variable counter keeps track of how often the seed has been updated. This

counter determines which pools will be used in the next update. A pool P i will be used if,

and only if, 2 i divides counter.

126


Figure 2. Entropy allocation among n pools. Data is compressed using the SHA

256 hash function.

Counter Used pools

1 P0

2 P0, P1

3 P0

4 P0, P1, P2

5 P0

6 P0, P1

7 P0

8 P0, P1, P2, P3

Table 1. Used pools in the 8 first updates of Fortuna generator

Table 1 shows the update strategy of the generator. As we can see, the higher the

number of the pool, less it is used in the update of the generator and, therefore, the greater

the amount of accumulated entropy. This allows the generator to adapt automatically to

attacks. If the opponents have little control over the sources of randomness, they can not

even predict the state of the pool P 0 , and the generator will recover from a compromised

state quickly, at the next reseed.

However, the opponent may control multiple sources of entropy. In this case he

probably knows a lot about the pool P 0 and could reconstruct the state of the generator

using the previous state and the outputs produced. But when P 1 is used in a reseed, it contains

twice the amount of randomness of P 0 . When P 2 is used, it will contain four times

the amount of randomness of P 0 , and so on. While there are some truly unpredictable

sources, eventually one pool will collect enough randomness to defeat the opponents, regardless

of how many fake events they can generate or how many events they know the

system would recover. The speed of recovery will be proportional to the level of opponents

control over the sources.

3.1.2. Initial estimate

The proposed scheme avoids the entropy estimate, as used in Linux. However it is still

necessary to make an initial entropy estimate in order to determine the minimum number

of events necessary to perform a catastrophic reseed. This estimate is calculated for the

127


pool P 0 and determines when the generator state is updated.

To elaborate such, one should observe some aspects of the system as: the desired

security level; the amount of space occupied by the events and the amount of entropy

present in each event.

[Ferguson and Schneier, 2003] suggest a minimum of 512 bits for P 0 , for a level of

128-bit security. The initial entropy estimation plays an important role on system security,

but is mitigated by the fact that if the chosen value is too low, there will always be reseeds

with higher amounts of entropy. If the chosen value is too high, a possible recovery from

a compromise may take longer, but will inevitably occur.

3.2. Syndrome: Generating function

3.2.1. Construction of the generating function

We built a PRNG based on a hard instance of the syndrome decoding problem using

the SD collection of functions (ρ, δ) defined in section 2.2. Initially, we show that the

functions fn

ρ,δ from the collection SD(ρ, δ) expand its inputs, ie, they have image sets

greater than the respective domain sets.

The domain Dn

ρ,δ from fn

ρ,δ consists of a matrix M of size ⌊ρn⌋ × n and of vector

x of size n and weight δn. So the size of the domain set is 2 ⌊ρn⌋·n · ( n

δn)

. Yet, the image

set is formed by the same matrix M of size ⌊ρn⌋ × n and a vector y = M · x of size ⌊ρn⌋.

Thus, its size is 2 ⌊ρn⌋·n · 2 ⌊ρn⌋ .

So, for the image set to be larger than the domain set, we need 2 ⌊ρn⌋ > ( n

δn)

. This

condition is satisfied when H 2 (δ) < ρ according to the Gilbert-Warshamov bound defined

in section 2.2.1. That is, for a sufficiently large n and suitable δ and ρ, fn

ρ,δ expands its

entry into a linear amount of bits.

Given an instance with fixed parameters ρ and δ from SD(ρ, δ) collection, we can

construct an iterative generating function G ρ,δ from the one-way function fn

ρ,δ . For this,

we use an algorithm ( A that returns a vector x of size n and weight δn from a random

vector with log n

2 δn)

bits. This algorithm is described in section 3.2.2. The generator Gρ,δ

is described in pseudocode in algorithm 1. Figure 3 illustrates its operation.

Algorithm 1 syndrome – Iterative generating function based on the syndrome decoding

problem.

Input: (M, x) ∈ Dn

ρ,δ

Output: Print bit sequence

1: y ← M · x

(

2: Split y into two vectors y 1 e y 2 . The firs with ⌊log n

2 δn)

⌋ bits and the second with the

remaining bits.

3: print y 2

4: x ← A(y 1 )

5: Go to: 1

128


Figure 3. Syndrome generating function.

3.2.2. Generating words with given weight

As noted, the generator requires ( an algorithm to produce vectors with fixed weight. From

each entry of size ⌊log n

)

2 δn ⌋, this algorithm must output a different vector x ∈ {0, 1}

n

with weight |x| = δn. To build it, we use the lexicographic enumeration function shown

by [Fischer and Stern, 1996].

To explain the working of the lexicographic enumeration, we will use Pascal’s

Triangle. It is formed by the binomial coefficients ( n

k)

where n represents the row and k

the column. The construction follows the Pascal’s rule, which states:

( ) n − 1

+

k − 1

( ) ( n − 1 n

= for 1 ≤ k ≤ n

k k)

Each triangle component t(n, k) = ( n

k)

represents the number of existing words

with size n and weight k. Here t(n, k) equals the sum of two components immediately

above t(n − 1, k) and t(n − 1, k − 1). These components represent, respectively, the

number of words of size n starting with a 0-bit and starting with a 1-bit.

This way, we can generate the output word from an index i by making an upward

path in Pascal’s Triangle. We start from the component t(n, k) towards the top. When

the index i is less than or equal to the up-left component t(n − 1, k), we generate a 0-bit

and move to this component. When the index is higher, we generate a 1-bit and walk to

the up-right component t(n − 1, k − 1), decrementing the index at t(n − 1, k − 1). The

complete algorithm is described in pseudocode at the end of this section.

As an example, see Figure 4. We ilustrate a walk to generate a word of size n = 4

and weight k = 2, index i = 2.

The path begins at the component t(4, 2) = ( 4

2)

= 6. As i = 2 ≤ t(3, 2) = 3, the

algorithm generates a 0-bit and walks to the component t(3, 2). Now, i = 2 > t(2, 2) = 1,

so the algorithm generates a 1 bit, updates the index i ← i − t(2, 2) and the path goes to

the component t(2, 1). And so it goes until you reach the top of the triangle, forming the

word (0, 1, 0, 1).

129


Figure 4. Walk in Pascal’s Triangle to generate word of index i = 2 within a set of

words of size 4 and weight 2

3.3. Combining Syndrome and Fortuna

The generating function constructed in 3.2.1 is based on the difficulty of finding a vector

x with weight w from its syndrome, given a random matrix M. Thus, the only part of

the function that actually makes up the internal state E, which must be kept secret, is the

vector x. We will use, then, the entropy collection scheme to update the internal state. It

should occur whenever the minimum amount of entropy is available in the P 0 pool. This

way we ensure that the generating function receives the operating system randomness

over time.

At each request for random numbers, a check is made whether there is enough

entropy to update the internal state. This check is conditional on the minimum entropy in

the pool P 0 , as stipulated on the initial estimate. A minimum time lapse between reseeds

is also respected. [Ferguson and Schneier, 2003] suggested 100ms to prevent an adversary

to make numerous requests and flush out the entropy of the pools. Figure 5 illustrates the

complete workings of the generator.

The Syndrome-Fortuna update strategy preserves the one-way function direct

cryptanalysis resistance. Only the seed, the vector x, is updated from time to time. Regardless

of this update, any adversary that can reconstruct the internal state through the

output vector y and the matrix M has managed to solve a problem currently considered

computationally intractable.

Forward security is guaranteed by the feedback operation in which part of the

result vector y is used to choose the new vector x. An adversary can, at time t, know the

state of the generator E t = (x t , M, P t ), where M is the matrix, x t is the vector x at time

t and P t represents all the Fortuna Pools at time t. In this case, the opponent can simply

find the last index value used in the lexicographic enumeration function A −1 (x t ) = y1 t−1 .

This value is part of the vector y t−1 , as can be seen in figure 5. From there, to find the

value x t−1 , or the last output value y2 t−1 requires inverting the generating function.

The recovery to a safe state after a compromise – backward security – is guaranteed

by the eventual update of vector x by the entropy collection system. An adversary

who controls the state of the generator E t = (x t , M, P t ) could possibly keep it until time

t + k, when the accumulated entropy is sufficient for a catastrophic reseed. At this point

the value of the vector x is changed by the hash function of Fortuna pools, as seen in

figure 5. As long as the opponent has not enough knowledge about the entropy added to

130


Figure 5. Syndrome-Fortuna operation. At each request is checked whether the

pool P 0 has the minimum entropy and the time between reseeds is over 100ms.

If so the algorithm performs a reseed, incrementing a counter c and choosing

among the pools p i that satisfies 2 i divides c. A SHA 256 is performed accross

the chosen pools and the result is used to index a word of size n and weight w.

Then, the generating function performs the multiplication between the chosen

vector and the matrix M producing the syndrome vector y. Part of this vector is

sent to the output and part is used as feedback, enabling the iterative generation

of random data .

the pools, the new state E t+k+1 should be out of his control.

Ideally a system recovery should require 128 entropy bits

[Ferguson and Schneier, 2003]. In the Fortuna entropy collection system this amount is

multiplied by the number of pools, since the entropy is distributed. Thus, this amount

rises to 128 ∗ n, where n is the number of pools. This value can be relatively high

compared to the ideal; however, this is a constant factor, and ensures that the system will

recover, at a future time.

In the above compromise case, considering the entropy input rate ω, the generator

recovery time would be at most k = (128 ∗ n)/ω. Adversaries could try to deplete the

system entropy while it is accumulated. They would need to promote frequent reseeds,

emptying the pools before they contain enough entropy to defeat them. This could be

done injecting false events on the pools through malicious drivers to keep the pool P 0

filled, allowing the real entropy flush. This attack is unlikely, given that the opponent

would have to promote 2 n reseeds before the system collects 128 ∗ n real entropy bits.

However, to avoid any attempt a minimum time between state updates is used to prevent

very frequent reseeds and the system entropy exhaustion.

131


3.4. Starting the generator

The initialization is a critical step for any random number generator that manages its

own entropy. The problems related to lack of randomness at initialization time must be

addressed according to each scenario. Therefore, it is beyond the scope of this paper to

define specific strategies.

However, it should be noted that the implemented entropy accumulator allows the

use of any source of randomness. Even a source of low quality, which can enter foreseeable

data in the pools, has not the capacity to lower the system entropy. Other strategies,

including the one used by the Linux kernel, estimate the collected amount of entropy.

These approaches do not allow questionable sources to be used, since a miscalculation

could lead to a security breach.

One good strategy to mitigate the problem of lack of entropy during boot is to

simulate continuity between reboots. For the Syndrome-Fortuna generator a seed-file was

implemented the same way as in Linux. The system writes a file with random data to disk

during shutdown and startup. At the startup, the seed is read, fed to the generator and the

output is written on disk before any request for random numbers. This prevents repeated

states when sudden hangs occur. At startup, this seed-file is used to refresh the pools.

4. Implementation, analysis and results

4.1. Testing methodology

One way to evaluate a random number generator quality is assessing its output’s statistical

behavior. This analysis does not guarantee, in any way, the security of a cryptographic

generator. However, it can reveal flaws on its design or implementation.

There are several libraries for statistical tests accepted by the scientific community.

We used the libraries SmallCrush and Crush from TestU01 library, developed by

[L’Ecuyer and Simard, 2007]. The first one implements a set consisting of 10 tests and

is recommended for a generator’s initial assessment. The second library applies 32 tests

with several configurations, evaluating a total of 2 35 random bits.

To evaluate the generator performance, we compared it with the Blum-Blum-Shub

generator, which has a simple construction, based on the integer factoring difficulty. We

also compared to the Linux kernel 2.6.30 generator (LRNG). TestU01 library was used to

measure the generators performance.

4.2. Statistical Results

The statistical tests results are presented in the shape of p-values, which indicate the likelihood

of a sample Y present the sampled value y, considering true the null hypothesis

H 0 :

p = P (Y ≥ y|H 0 )

To illustrate this statistical approach, we evaluate a sample Y of 100 coin flips in which 80

times was randomly selected “heads” and 20 times “tails”. In this case, the null hypothesis

is the coin fairness and therefore Y is a cumulative binomial distribution. Thus, we have

p = P (Y ≥ 80) = 5.6 ∗ 10 −10 . The observed sample could occur with a fair coin

with only 5.6 ∗ 10 −10 probability. This is not to tacitly reject the null hypothesis, but

132


according to a defined demand level, we can consider the sample clearly failed the applied

test. [L’Ecuyer and Simard, 2007] arbitrate as clear failures the p-values outside the range

[10 −10 , 1 − 10 −10 ].

All generators tested: BBS, Syndrome-Fortuna and LRNG passed the statistical

test libraries. All p-values were in the range [10 −3 , 1 − 10 −3 ], forbidding us to reject

the null hypothesis. This means that, statistically, the generated values cannot be distinguished

from truly random values.

4.3. Performance analysis

The Syndrome-Fortuna generator was evaluated through performance tests and compared

to the BBS and LRNG generators. We used a computer with an Intel Pentium Dual Core

T3400 2.16GHz with 2GB of RAM. We used loads of 100 bytes, 1 kB, 10kB, 100kB and

100kB intervals until complete 1MB of random data. Each generator had the generating

time clocked 3 times for each load.

Syndrome-Fortuna and LRNG were assessed while compiled into the kernel. The

BBS algorithm was used only as a benchmark for performance and was not implemented

within the kernel, being assessed with TestU01 library.

To evaluate the performance diferences between generators built inside and outside

the kernel, we did tests with an implementation of Syndrome-Fortuna compiled in

user-space. The results were statistically indistinguishable from the results when the algorithm

was implemented inside the kernel. This does not necessarily imply that the same

would happen to the BBS algorithm, the only algorithm not implemented inside the kernel.

But for the purposes of this paper, we consider it satisfactory for the comparision

of the BBS, compiled in user space, with Syndrome-Fortuna and LRNG, built inside the

kernel.

The average speed of each generator, with the respective deviation, are shown in

table 2. The generators behavior for the different loads are summarized in figure 6.

Generator Speed (em kB/s)

LRNG 2664,0 ± 818,9

Syndrome-Fortuna 197,1 ± 58,2

BBS 31,4 ± 6,4

Table 2. Generators LRNG, Syndrome-Fortuna and BBS performance measurement.

As expected, Syndrome-Fortuna underperforms the current Linux generator,

which is highly optimized for performance and does not have formal security proof.

When compared with the BBS generator, which has similar formal security features, the

Syndrome-Fortuna performance is 6.3 times higher.

5. Concluding remarks

During this research we studied several types of random number generators, statistical

and cryptographic. We conducted a detailed investigation of the Linux kernel generator,

and proposed and implemented a new generator based on two existing approaches.

133


Figure 6. Performance of random generators: Linux (LRNG) Syndrome-Fortuna

and Blum-Blum-Shub (BBS).

5.1. Conclusions from our research

Random number generators are an important part of the complex set of protocols and applications

responsible for ensuring information security. In a scenario of rapid change,

when the computing reach unexplored places, and new users, the framework for cryptographic

applications must adapt to provide the desired security.

For random number generators, this means adapting to new sources of entropy,

new forms of operation. It is not difficult to imagine scenarios where a keyboard, mouse

and hard drive are less present, imposing restrictions on the randomness of the systems.

The strategy we implemented for entropy collection is in line with this need. It does

not require estimations and can use any entropy sources, even the ones with questionable

randomnness.

Conversely, as noted in its operation, the Linux random number generator faces a

difficulty to adapt to new entropy sources. All of them must pass through a heuristic that,

if inaccurate, can lead to a generator low entropy state. In a running Linux Ubuntu 9.10,

we observed the entropy collection only from the keyboard, mouse and hard drive, while

a series of possibly good entropy sources were available, such as wireless network cards,

software interrupts, etc.

As for the random values generation, per se, the implementation applies solid

mathematical principles derived from the theory of error-correcting codes, and predicting

them can be considered as difficult as the syndrome decoding problem, which is NPcomplete.

134


The proposed algorithm can be considered for use in various scenarios, especially

on diskless servers, or in cloud-computing scenarios, where the usual randomness sources

are not present. We believe that the generator implements a satisfying trade-off, providing

bits with good statistical properties, solid security and reasonable speeds

5.2. Future work

We believe that the Syndrome-Fortuna time and memory performance can be improved

considerably by changing the generating function “A”, shown in figure 5. We note that

much of the processing and, clearly, most of the memory costs are related to the problem

of obtaining the vector x of size n and weight w from a random index i. The approach

used in the work of Augot et al. [Augot et al., 2005] could reduce drastically these costs.

Generator specific parameters should be studied and modified to allow this use.

As shown, the entropy collection strategy allows the use of new randomness

sources, independent of detailed entropy studies. A natural extension of this work is

to identify these sources and promote their interconnection with the Linux kernel entropy

collection system.

References

Augot, D., Finiasz, M., and Sendrier, N. (2005). A family of fast syndrome based cryptographic

hash functions. In Dawson, E. and Vaudenay, S., editors, Mycrypt 2005, volume 3715, pages

64–83. Springer.

Berlekamp, E., McEliece, R., and Van Tilborg, H. (1978). On the inherent intractability of certain

coding problems (corresp.). IEEE Transactions on Information Theory, 24(3):384–386.

Chabaud, F. (1994). On the security of some cryptosystems based on error-correcting codes. In

EUROCRYPT, pages 131–139.

Ferguson, N. and Schneier, B. (2003). Practical Cryptography. Wiley & Sons.

Fischer, J.-B. and Stern, J. (1996). An efficient pseudo-random generator provably as secure as

syndrome decoding. In EUROCRYPT, pages 245–255.

Goldberg, I. and Wagner, D. (1996). Randomness and the Netscape browser. Dr. Dobb’s Journal

of Software Tools, 21(1):66, 68–70.

Goldreich, O. (2001). Foundations of Cryptography. Volume I: Basic Tools. Cambridge University

Press, Cambridge, England.

Goldreich, O., Krawczyk, H., and Michael, L. (1993). On the existence of pseudorandom generators.

SIAM J. Computing, 22(6):1163–1175.

Impagliazzo, R., Levin, L., and Luby, M. (1989). Pseudorandom generation from one-way functions.

In Proc. 21st Ann. ACM Symp. on Theory of Computing, pages 12–24.

L’Ecuyer, P. and Simard, R. (2007). Testu01: A c library for empirical testing of random number

generators. ACM Transactions on Mathematical Software, 33(4).

135


SpSb: um ambiente seguro para o estudo de spambots

Gabriel C. Silva 1 , Alison C. Arantes 2 ,

Klaus Steding-Jessen 3 , Cristine Hoepers 3 , Marcelo H.P. Chaves 3 ,

Wagner Meira Jr. 1 , Dorgival Guedes 1

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais

2 CSIRT/POP-MG – Equipe de resposta a incidentes de segurança do POP-MG

3 CERT.br – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança

NIC.br – Núcleo de Informação e Coordenação do Ponto Br

gabrielc@dcc.ufmg.br, alison@csirt.pop-mg.rnp.br

{jessen,cristine,mhp}@cert.br, {meira,dorgival}@dcc.ufmg.br

Resumo. Botnets são consideradas a origem de grande parte do spam observado

atualmente. Entretanto, a informação que se tem sobre esses sistemas costuma

ser apócrifa ou deriva de esforços de engenharia reversa pontuais. Para

se entender melhor o comportamento desses sistemas é necessário um ambiente

de monitoração que dê ao bot a impressão de estar executando com liberdade

na Internet, porém sem permitir que suas atividades causem dano à rede. Este

artigo curto descreve uma implementação de tal sistema atualmente em curso.

1. Introdução

No cenário atual de combate ao spam na Internet, botnets ocupam uma posição particularmente

importante, por sua capacidade de disseminação de mensagens a partir de um

grande número de máquinas comprometidas (bots) [Xie et al. 2008]. Um dos grandes

desafios para a comunidade de segurança que combate spam é entender como essas redes

operam, a fim de criar mecanismos de detecção e bloqueio dessas fontes de spam

(denominadas spambots, nesse caso).

Na prática, a informação sobre o comportamento de botnets tende a ser apócrifa,

sem validação científica, ou de validade limitada pela volatilidade da área. Dessa forma,

é essencial que se tenha uma forma flexível de acompanhar o comportamento de novos

bots à medida que eles surgem. Esse acompanhamento envolve tanto a coleta de binários

de versões ativas de malware para análise, quanto o acompanhamento de sua execução.

O grande problema de se analisar o comportamento de um bot é que esse comportamento

só pode ser observado em sua totalidade se lhe é garantido acesso à Internet.

Como esses programas operam seguindo os comandos de um elemento central, denominado

Comando-e-Controle (C&C), um bot só passa a atuar no envio de spam, por exemplo,

após se conectar ao seu C&C e obter instruções sobre o conteúdo das mensagens e

os destinatários. Entretanto, se o malware tem acesso à Internet, se torna difícil evitar que

cause dano (por exemplo, enviando spam). Por esse motivo, serviços de análise de comportamento

de binários, como o Anubis 1 , se limitam a executar os binários sob suspeita

sem permitir o seu acesso à rede, registrando apenas o seu comportamento na máquina

local. Apesar de auxiliar na identificação do binário, essas informações não contribuem

para o entendimento de seu comportamento na rede.

1 http://anubis.iseclab.org/?action=sample_reports

136


O objetivo deste artigo é propor um ambiente seguro para o estudo de spambots

que seja ser capaz de registrar o comportamento de todo o ciclo de vida de um spambot

analisando seu tráfego de rede, sem permitir que ataques reais ocorram. Neste ambiente,

qualquer bot sob análise deve ser capaz de trocar informações com seu C&C sem efetivamente

conseguir enviar o spam. Pelas suas características, esse ambiente se encaixa na

definição de um sandbox, daí o nome escolhido para o sistema, SpSb (Spam Sandbox).

2. Arquitetura proposta

Para garantir um ambiente seguro para análise de malware, pretendemos utilizar a infraestrutura

de rede ilustrada na figura 1. A arquitetura inclui um sistema de captura de

amostras de binários de possíveis spambots e o sandbox propriamente dito. Nesta seção

discutimos os princípios de operação previstos para cada elemento do sistema. A seção

seguinte discute detalhes de implementação relacionados.

Figura 1. Arquitetura proposta

O sistema de captura inclui um honeypot especializado na coleta de malware e

um serviço de avaliação, filtragem e armazenamento de amostras. O primeiro desafio

do sistema é identificar as amostras de interesse. Para isso, cada amostra é comparada a

outras já avaliadas e uma consulta é feita a serviços de análise externos. Apesar desses

serviços não serem suficientes para determinar todo o comportamento de uma amostra,

eles fornecem informações úteis, como a identificação de amostras claramente sem interesse

nesse caso, como vírus e ou variações de outros bots já coletados. A transferência

de uma amostra selecionada para o sandbox deve ser feita de forma bastante controlada,

para evitar que a amostra contamine algum elemento de forma inesperada e para garantir

que o mecanismo de transferência não possa vir a ser explorado por um malware durante

sua execução no ambiente.

A máquina alvo que será infectada pode ser uma máquina real, ou uma máquina

virtual executando em um dos ambientes de virtualização hoje disponíveis. A opção entre

as duas opções representa um compromisso entre a flexibilidade de operação, a segurança

do sistema e a gama de malware que poderão ser avaliados. O uso de máquinas virtuais

simplifica a gerência e configuração do sistema, tornando simples recuperar uma

visão de uma máquina em um determinado ponto de sua configuração, antes ou após a

contaminação pelo bot. Entretanto, o gerente de máquinas virtuais está sujeito a ataques a

partir da máquina virtual (ao menos potencialmente) e diversos tipos de software malicioso

hoje incluem algum tipo de mecanismo para detectar sua instalação em uma máquina

virtual [Miwa et al. 2007].

137


A tarefa de controlar a visão do bot para a Internet é dividida entre o controlador

de acesso e o emulador de serviços. O primeiro é responsável por interceptar cada pacote

gerado pela máquina infectada e decidir sua destinação, que deve se encaixar em uma das

opções a seguir: (i) processar o pacote localmente, (ii) permitir que o pacote siga seu caminho

para a Internet, (iii) redirecionar o pacote para um emulador de serviços, ou (iv)

descartar o pacote. Pacotes como consultas DNS devem ser tratadas diretamente pelo

controlador, A interceptação desse protocolo tem dois objetivos: observando o padrão

de consultas DNS de um bot é possível, em muitos casos, inferir a natureza do seu

C&C [Choi et al. 2009]; além disso, caso algum tráfego seja identificado com um ataque

iniciado pelo bot (como o envio de spam), o servidor de DNS do controlador de acesso

tem a informação necessária para redirecionar o tráfego para o emulador de serviços. Isso

pode ser feito pela re-escrita dos endereços de resposta, ou pela observação do endereço

de resposta e pela inserção de regras de roteamento que interceptem o tráfego para aqueles

endereços e os redirecionem para o emulador.

Pacotes identificados como associados ao fluxo de controle do bot, direcionados

principalmente ao seu Comando-e-Controle, devem ser encaminhados normalmente pela

Internet. Essa identificação pode ser feita através dos padrões de DNS, como mencionado,

pelo tipo de protocolo utilizado (p.ex., IRC) e pelo momento da conexão. Para evitar problemas

devido a ataques que porventura possam ser encapsulados em consultas aparentemente

inócuas, um controle rigoroso de taxa de comunicação deve ser implementado.

Tráfego redirecionado para o emulador de serviços inclui todo tipo de protocolo que seja

classificado com parte de um ataque. Entre esses protocolos destacam-se ataques a outras

máquinas com o objetivo de propagar o malware e tentativas de distribuição de spam.

Como mencionado anteriormente, o emulador de serviços deve manter uma comunicação

constante com o controlador de acesso, pois ele deve ser informado sobre como responder

a cada requisição redirecionada (por exemplo, uma conexão SMTP redirecionada deve ser

respondida com o nome do servidor alvo pretendido, bem como seu endereço IP). Essa

informação deve ser repassada pelo controlador de acesso. As mensagens de spam coletadas

são armazenadas e processadas para extrair informações que permitam classificá-las.

Um objetivo importante do Spam Sandbox é automatizar as decisões sobre que

tráfego do bot pode acessar a Internet e que tráfego deve ser direcionado para o emulador.

Por exemplo, uma sequência desse tipo poderia ser vista da seguinte forma a partir do

controlador de acesso: uma consulta DNS é seguida por uma conexão ao porto 6667

(IRC) do endereço IP fornecido pela resposta DNS — o controlador permite a conexão e

a troca de tráfego com o destino, por se tratar de uma conexão ao C&C; uma nova consulta

DNS é seguida por uma conexão ao porto 25 (SMTP) do novo endereço — nesse caso,

o controlador notifica o emulador sobre o nome e o IP que o bot tenta conectar e passa a

redirecionar o tráfego para aquele IP para o emulador, que passa a executar o código do

emulador de um servidor de correio, armazenando a mensagem de spam que o bot acha

que foi entregue.

3. Aspectos de implementação

O sistema está sendo implementado utilizando módulos disponíveis na comunidade de

sofwtare livre e aberto, bem com módulos especialmente desenvolvidos para esse fim. O

138


sistema de coleta de amostras de malware utiliza o honeypot Dionaea 2 . As amostras coletadas

são enviadas para análise pelo serviços Anubis 3 e Norman Sandbox 4 . No momento,

a análise da informação obtida dessas fontes é manual. No futuro, o processamento será

automatizado com extratores automáticos, para simplificar a coleta de amostras.

Nossa primeira opção para a máquina infectada é a utilização de uma máquina

virtual executando no ambiente Virtual Box. O ambiente é configurado de forma a remover

elementos de configuração da máquina virtual que são usualmente utilizados por

bots para determinar se o ambiente é uma máquina virtual. Dessa forma, podemos nos

beneficiar dos recursos de manipulação de imagens e armazenamento de snapshots para

retornar o sistema a uma configuração pré-determinada. A inserção de malware é feita

atualmente através de um dispositivo USB; estamos estudando o ambiente virtualizado

para poder configurar a amostra diretamente na imagem da máquina virtual.

O controlador de acesso é implementado com uma máquina FreeBSD, utilizando

o sistema de filtragem de pacotes nativo daquele sistema, o PF (BSD Packet Filter). As

interfaces da máquina são conectadas através de uma switch virtual transparente configurada

pelo sistema operacional. O processo de captura e re-escrita de pacotes é feito com

regras PF, com um tratamento especial dos pacotes de retorno do emulador de serviços

para garantir o roteamento correto de pacotes com endereços forjados. O software de controle

do PF está sendo desenvolvido para interceptar os pacotes recebidos, tomar decisões

sobre os próximos passos, inserir novas regras para determinar como as novas conexões

serão tratadas e notificar o emulador a respeito dos serviços que ele deve emular.

O emulador de serviços contém um segundo servidor Dionaeae um honeypot especialmente

desenvolvido para a coleta de spam [Steding-Jessen et al. 2008]. Ambos os servidores

estão sendo configurados para se adequarem ao ambiente emulado. Em particular,

eles devem receber comandos do controlador de acesso para saberem quais endereços IPs

devem ser emulados e qual o nome o servidor deve ser usado em cada caso. O coletor de

spam é basicamente o mesmo desenvolvido originalmente para aquele honeypot. Outros

serviços podem ser incluídos posteriormente.

Técnicas de análise do spam coletado estão sendo desenvolvidas para identificar

os padrões de tráfego das botnets e os padrões de máquinas alvo que seriam atacadas

pelo bot caso ele operasse na Internet. Essas técnicas são desenvolvidas em conjunto com

outros trabalhos de análise de spam atualmente em atividade no grupo do DCC/UFMG

em conjunto com o CERT.br e o CSIRT/POP-MG [Guerra et al. 2010].

4. Trabalhos relacionados

Muitos trabalhos se orientam por princípios gerais universalmente reconhecidos a respeito

de botnets, sem entretanto oferecer uma confirmação científica para esses princípios.

Por exemplo, ao assumir que todas as conexões que chegam a um servidor de correio

eletrônico tentando entregar mensagens de spam se originam de botnets, Xie et al. identificam

tais redes com base nos endereços de origem das conexões contendo spam, sem uma

confirmação direta de sua natureza [Xie et al. 2008]. Outro trabalho que se orienta por

esses princípios gerais é o da ferramenta de detecção BotGad [Choi et al. 2009]. Nesse

2 http://dionaea.carnivore.it/

3 http://anubis.iseclab.org/

4 http://www.norman.com/security_center/security_tools/

139


caso, um grupo de máquinas com certos comportamentos comuns na rede (p.ex., consultas

DNS semelhantes) é identificado como uma botnet.

Os trabalhos mais próximos desta proposta são Botlab [John et al. 2009] e Mimetic

Internet [Miwa et al. 2007]. Botlab propõe uma arquitetura de análise segura, mas

depende diretamente da intervenção de um operador, que deve decidir como reagir a cada

ação do bot sendo observado. Já Mimetic Internet propõe um arcabouço isolado que tenta

reproduzir a Internet, com servidores que simulam sites populares, por exemplo, mas que

não permite nenhum acesso à Internet real. Nesse caso, um spambot não seria capaz de

contactar o restante da sua rede, o que limitaria sua ação.

5. Conclusão e trabalhos futuros

Observar o comportamento de uma botnet em uma campanha de spam a partir de um

de seus componentes pode gerar um grande volume de informações sobre esses sistemas

e formas de evitar sua ação. Entretanto, realizar esse estudo exige que se permita que

um spambot acesse a Internet para estabelecer contato com seu comando-e-controle e se

convencer de que está executando livremente, ao mesmo tempo que se evite que o mesmo

cause danos reais à rede (p.ex., pelo envio de spam).

A arquitetura descrita neste artigo visa oferecer condições para que essa análise

seja possível, de forma bastante automatizada. A combinação de um filtro de pacotes

altamente flexível, com capacidade de redirecionamento e re-escrita de pacotes, e um

conjunto de emuladores de serviços operando de forma integrada a esse filtro pode permitir

que pacotes/fluxos identificados como de controle possam ter permissão para acessar a

Internet, enquanto comportamentos daninhos, como o envio de spam, podem ser direcionados

para servidores apropriados.

A implementação desse sistema se encontra em curso. Apesar de já concebermos

uma solução completa, há ainda muito espaço para pesquisa no desenvolvimento de

métodos para identificação de padrões de controle e de ataques e para o aumento do grau

de automatização dos mecanismos de redirecionamento e emulação de serviços.

Referências

Choi, H., Lee, H., and Kim, H. (2009). Botgad: detecting botnets by capturing group activities

in network traffic. In Proceedings of the Fourth International ICST COMSWARE,

pages 1–8, New York, EUA. ACM.

Guerra, P. H. C. et al. (2010). Exploring the spam arms race to characterize spam evolution.

In Proceedings of the 7th CEAS, Redmond, WA.

John, J. P. et al. (2009). Studying spamming botnets using botlab. In Proceedings of the

6th USENIX NSDI, pages 291–306.

Miwa, S. et al. (2007). Design and implementation of an isolated sandbox with mimetic

internet used to analyze malwares. In Proceedings of the USENIX DETER Workshop

on Cyber Security Experimentation and Test, pages 1–9.

Steding-Jessen, K. et al. (2008). Using low-interaction honeypots to study the abuse of

open proxies to send spam. Infocomp (UFLA), 7:44–52.

Xie, Y. et al. (2008). Spamming botnets: signatures and characteristics. SIGCOMM CCR,

38(4):171–182.

140


Fatores que afetam o comportamento de spammers na rede

Gabriel C. Silva 1 , Klaus Steding-Jessen 2 , Cristine Hoepers 2 ,

Marcelo H.P. Chaves 2 , Wagner Meira Jr. 1 , Dorgival Guedes 1

1 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais

2 CERT.br – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança

NIC.br – Núcleo de Informação e Coordenação do Ponto Br

{gabrielc,meira,dorgival}@dcc.ufmg.br

{jessen,cristine,mhp}@cert.br

Resumo. O propósito deste trabalho é entender melhor o comportamento de

spammers (responsáveis pelo envio de mensagens de spam) na rede, e assim

trazer mais informações para o combate a eles. Para isso utilizamos um sistema

de honeypots virtualizados especialmente desenvolvidos para a coleta de

spam que possibilita avaliar a influência de diversos fatores no comportamento

dos transmissores. Os resultados mostram que as variações na configuração

dos cenários pode afetar drasticamente o volume de spam coletado, bem como

suas características internas. Em particular, o trabalho identificou dois tipos

bastante diversos de transmissores: spammers em larga escala, que usam poucas

máquinas com muitos recursos, e botnets, que enviam cada uma um número

limitado de mensagens.

1. Introdução

O correio eletrônico, apesar de ser um dos mais antigos serviços da Internet, continua

sendo um dos mais populares. Segundo um estudo do grupo Radicati, em maio de 2009,

havia mais de 1,9 bilhões de usuários de e-mail em todo o mundo, trocando 294 bilhões

de mensagens por dia (em média, são mais de 2.8 milhões de novos e-mails que trafegam

na rede por segundo) [Radicati 2009]. São dados impressionantes para um serviço tão

antigo para os padrões da Internet.

Muitos consideram que o sucesso da popularização do e-mail se deve a sua facilidade

de uso e simplicidade de projeto. Porém, devido às deficiências de segurança de seu

protocolo e ao seu baixo custo de operação, o e-mail é alvo constante de abusos como o

spam: mensagens eletrônicas não solicitadas, normalmente enviadas em larga escala com

objetivos que variam desde marketing simples até fraude ideológica e/ou bancária.

Com objetivo de conter esse problema foram desenvolvidas tecnologias avançadas

para a criação de filtros de detecção do spam. Entretanto, dada a constante evolução das

técnicas de evasão e ofuscação, muitos desses filtros dependem de constantes e custosas

manutenções, atualizações e refinamentos para que se mantenham eficazes. Tentar solucionar

este problema com filtros mais restritivos nem sempre é uma saída, pois há o risco

de gerar excesso de falsos positivos tornando a ferramenta inútil, ou pior, causando um

problema ainda maior ao criar aversão no usuário, que pode preferir até ficar desprotegido.

Uma forma mais recente e diferenciada de abordar o problema do spam é estudá-lo

de uma nova óptica: entender o comportamento dos spammers (responsáveis pelo envio

do spam) [Giles 2010] dentro da rede. Nessa abordagem procura-se não apenas analisar os

141


padrões encontrados dentro das mensagens enviadas ou os métodos de evasão de detecção

utilizados pelos autores, mas também caracterizar os fatores ou a forma como o spammer

se comporta em diferentes âmbitos e cenários. Esse enfoque é de particular interesse para

a comunidade de segurança, já que pode gerar informações que permitam identificar e

bloquear tais abusos antes que consumam recursos de rede e dos servidores alvo.

É indispensável entender o que leva o spammer a dar esse tipo de preferencia, ao

dar escolher a máquinas na rede com determinadas características, e ainda entender quais

tipos de ataques são mais comuns para a disseminação do spam. Esse tipo de informação

comportamental pode levar a novos tipos de defesas precoces contra o spam, ainda antes

do envio na rede, e pode ainda abrir caminho a novos tipos de pesquisas na área. Apenas

a análise do conteúdo de spam não gera evidências para obter essas informações; é

necessário analisar o abuso em si e não apenas isso, mas também verificar como o comportamento

do spammer muda se o alvo do abuso tem diferentes características.

Para realizar esse estudo é necessário criar diferentes cenários para o ataque dos

spammers para possibilitar a análise de quanto as métricas consideradas são influenciadas

pela mudança dos fatores. A dificuldade de analisar a origem e o caminho das mensagens

na rede, ainda é uma das principais barreiras na caracterização do comportamento

dos spammers. O objetivo deste trabalho é fazer uma caracterização do comportamento

dos spammers ao serem confrontados com diversos cenários de ataque. Para isso quantificamos

a influência de diversos fatores (como restrições de banda, vulnerabilidades

disponíveis para ataque, etc) em métricas (quantidade de spam enviado, código de área

dos endereços utilizados, tipos de ataque aplicados) que, em conjunto, são capazes de

caracterizar o comportamento em estudo.

Para atingir esse objetivo foi projetado e implementado uma coleta de dados especial

capaz de captar spam em diferentes cenários e assim possibilitar a analise da influência

de diferentes combinações de fatores nas métricas de interesse. Para realizar esse

processo de coleta, foram utilizados coletores de spam desenvolvidos pela equipe de do

Cert.br (Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no Brasil).

O restante deste trabalho está organizado da seguinte forma: a seção 2 desenvolve

a metodologia de pesquisa adotado na coleta e na análise dos dados; a seção 3 mostra e

discute os resultados obtidos na pesquisa; a seção 4 apresenta os trabalhos relacionados ao

estudo; finalmente, a seção 5 apresenta algumas conclusões e discute os trabalhos futuros.

2. Metodologia

Durante a realização de vários dos trabalhos anteriores do nosso grupo de pesquisa utilizando

um honeypot coletor de spam, observou-se indícios de que vários dos fatores

no processo de coleta de dados influenciavam consideravelmente na quantidade e nas

características do spam coletado. Essa influência, portanto, evidenciava uma aparente

correlação do comportamento dos spammers e as propriedades do alvo atacado (no caso,

as propriedades configuradas na interface exposta pelo honeypot). A concepção e consequente

arquitetura metodológica deste estudo nasceu exatamente da ideia de verificar e

quantificar essa correlação.

Dentre os indícios de correlação mais forte entre o comportamento dos spammers

e as características do alvo, foram selecionados os fatores que seriam avaliados no estudo,

utilizando o princípio do experimento fatorial.

142


2.1. O coletor de spam utilizado e as possibilidades de configuração disponíveis

O coletor de spam utilizado é uma evolução do sistema desenvolvido

por [Steding-Jessen et al. 2008], com diversas melhorias em termos de desempenho

e organização de dados, mas com funcionalidades semelhantes. Considerando-se seu

modo de operação, há pelo menos quatro dimensões de configuração que são importantes

para o desenvolvimento deste trabalho. Um esquema simplificado do funcionamento

do coletor de spam é apresentado na figura 1 e os detalhes de operação relevantes são

discutidos a seguir.

Figura 1. Esquema simplificado do funcionamento do coletor (honeypot).

Tratamento de mensagens de teste. Como mencionado anteriormente, um dos

objetivos deste trabalho é coletar spam sem permitir que ele se propague pela rede. A

única situação em que uma mensagem pode ser enviada pelo coletor é no caso de mensagens

que sejam identificadas como mensagens de teste geradas pelo atacante. Ao longo

do desenvolvimento do honeypot de coleta de spam, os autores identificaram padrões

claramente usados pelos spammers para registrar a operação da máquina sendo atacada.

Tais mensagens parecer ter como objetivo testar o funcionamento da máquina atacada. O

spampot pode encaminhar essas mensagens ou não, dependendo da sua configuração.

Protocolos emulados. O coletor aceita conexões na porta 25/tcp, tradicionalmente

associada ao protocolo SMTP, e outras que costumam ser usadas como portas

alternativas, como a porta 587/tcp. Para qualquer conexão observada nessas portas, o

coletor se comporta como um servidor SMTP padrão (mail relay), passando pelas etapas

de inicialização da conexão SMTP corretamente. Quando o transmissor que iniciou

a conexão inicial os comandos do protocolo para envio de uma mensagem a um destinatário

(ou grupo deles), o coletor aceita a mensagem, armazena-a localmente e responde

com o código de sucesso para a operação, indicando que a mensagem seria corretamente

encaminhada. O spampot também implementa emuladores para os protocolos SOCKS4,

SOCKS4a, SOCK5 e HTTP, associados a todas as portas comumente usadas por esses

protocolos que emulam o comportamento de proxy aberto associado a esses protocolos.

Quando uma conexão é estabelecida para uma dessas portas, se o comando seguinte é um

pedido de conexão (proxy) para o porto 25 de outra máquina, o spampot passa a simular o

servidor de correio naquela conexão, como no caso do open relay local, mas respondendo

como o servidor que seria o alvo.

Utilização (ou não) de listas de bloqueio. No contexto mundial do combate à

disseminação de spam, as listas de bloqueio são consideradas um elemento importante,

especialmente do ponto de vista dos administradores de grandes servidores de correio

eletrônico. Há muita controvérsia, entretanto, sobre a efetividade dessas listas ao longo

143


do tempo. Para fornecer mais informações a esse respeito, o spampot mantém um acompanhamento

da efetividade da lista Spamhaus Zen 1 , uma das listas consideradas mais

eficazes na identificação de máquinas que enviam spam. Para cada conexão recebida, o

coletor verifica o status daquele endereço IP na lista e armazena o resultado.

Conexões concorrentes. Além das opções anteriores, o coletor pode ser configurado

para limitar on número de conexões concorrentes permitidas, bem como restringir

o número de conexões simultâneas de uma mesma origem. Esse mecanismo pode

ser usado para evitar que transmissores de maior capacidade “monopolizem” o spampot,

abrindo diversas conexões ao mesmo tempo e se valendo do princípio de controle de congestionamento

do protocolo TCP para garantir uma fração maior da banda de acesso ao

computador atacado.

2.2. Opções de configuração utilizados no experimento

Para avaliar o comportamento dos spammers, consideramos então as quatro dimensões

de configuração disponíveis: (i) o repasse de mensagens de teste, (ii) o tipo de protocolo

vulnerável, (iii) a de rejeição de endereços encontrados em listas negras e (iv) restrições

ao número de conexões aceitas concorrentemente. Com a combinação desses fatores,

cada um com dois níveis, temos 16 cenários diferentes que devem ser considerados no

experimento fatorial.

No restante deste trabalho, em diversos momentos é importante nos referirmos

ao cenário de coleta considerado. Cada cenário foi identificado como uma sequência de

quatro bits, um para cada dimensão na ordem apresentada, indicando quais variáveis de

configuração estava ativas em cada caso. Nos resultados a seguir, essa notação é usada

em alguns casos por limitações de espaço. Outra forma também adotada, ainda compacta

mas de mais fácil interpretação, consiste em utilizar as abreviaturas TMSG, SMTP, DNBL

e CLIM para identificar, respectivamente, as opções de (i) permitir o encaminhamento de

mensagens, (ii) limitar o abuso ao protocolo SMTP, (iii) negar conexão a máquinas que

figurem em listas de bloqueio da SpamHaus e (iv) limitar o número de conexões concorrentes.

Para facilitar a interpretação, essas abreviaturas são concatenadas para gerar

uma sequência posicional. Assim sendo, TMSG.SMTP.DNBL.CLIM representa todas a

configuração em que as mensagens de teste são repassadas, apenas o protocolo SMTP

está disponível, a lista de bloqueio da Spamhaus é utilizada e há limites para conexões

simulâneas. Os casos em que aquelas configurações particulares não ativadas são representadas

pela sequência “‘----”, que indica, dependendo da posição, que (i) o repasse

de mensagens de teste não é permitido, ou (ii) os protocolos de proxy (HTTP, SOCKS)

também são emulados, ou (iii) não há rejeição de conexões por listas de bloqueio, ou (iv)

não á restrições ao número de conexões concorrentes. Nas discussões a seguir, além dessas

convenções a seguir, adotamos o uso do asterisco (*) para indicar quando desejamos

agrupar cenários independentemente de alguma variável (p.ex.,----.SMTP.*.* representa

todas as configurações que não encaminham mensagens de teste e emulam apenas

mail relay).

2.3. Arquitetura de coleta

Para cada um dos 16 cenários um coletor deve ser instanciado. Como o coletor não exige

uma máquina com muitos recursos, a solução adotada foi uma solução de virtualização

1 http://www.spamhaus.org/zen/

144


de máquinas para implementar os 16 cenários como 16 máquinas virtuais executando

em uma mesma máquina física. O uso de virtualização garante o isolamento entre os

recursos de hardware de cada máquina, evitando efeitos inesperados por interferência

entre coletores, e permite um melhor aproveitamento dos recursos computacionais do

laboratório.

Como plataforma de virtualização utilizamos o VirtualBox versão 3.2.12, uma

plataforma de código aberto, executada em um sistema Linux com kernel 2.6 (Debian

GNULinux 5.0). Cada máquina virtual tem um endereço IP único, mas o acesso de rede

externo é feito compartilhando uma única interface de rede real através de um comutador

virtual (a linux bridge) que conecta as interfaces virtuais de cada coletor. O canal

de acesso foi fornecido pelo POP-MG (Ponto de Presença da RNP em Minas Gerais, na

UFMG) com uma banda de 100 Mbps, muito superior à demanda agregada dos 16 coletores

(configurados cada um com um limite de 1 Mbps). Quando a opção CLIM foi

habilitada, o número de conexões simultâneas ao coletor em questão foi limitado a 250 e

as conexões concorrentes de um mesmo endereço de origem foram limitadas a três.

Ao entrar em operação, cada coletor se torna visível para máquinas que façam varreduras

de portas pelo espaço de endereços IP. Em geral, cada coletor leva algumas horas

para ser identificado pelo primeiro processo de varredura e em alguns dias o volume de

acessos atinge níveis mais altos, apesar do tráfego diário continuar a variar razoavelmente

ao longo dos dias. Toda a análise realizada neste trabalho considera dados coletados depois

que todos os coletores já estavam ativos por mais de um mês, o que garante que todos

já tinham se tornado bastante visíveis na rede, ainda mais considerando-se que utilizavam

endereços IP adjacentes — se um dos coletores foi acessado por uma varredura, muito

provavelmente todos os demais o seriam no mesmo processo.

3. Resultados

A arquitetura de coleta foi colocada em operação em um servidor de grande porte do

projeto, instalado nas dependências do POP-MG. Os 16 cenários de coleta foram configurados

como máquinas virtuais e colocadas em operação simultaneamente. A coleta foi

iniciada em 22/12/2010 e durou até 22/07/2011. Para evitar efeitos indesejados para a

análise, todos os dias durante o período de coleta em que um ou mais coletores não estava

em operação foram retirados do conjunto de análise. Nesse processo, 97 dias foram expurgados

da coleta (houve um grande número de falhas de energia devido ao período de

chuvas). O conjunto final considerado seguro para análise é composto por 116 dias naquele

período de coleta. A tabela 1 indica alguns dos grandes números relativos à coleta.

Período: 22/12/2010 a 22/07/2011 (213 dias)

Dias considerados: 116

Tráfego total (GB): 3.495

Mensagens coletadas: 182.564.598

Conexões registradas: 453.033

Tabela 1. Dados gerais sobre a coleta utilizada

O experimento fatorial nos permite identificar os grandes fatores de impacto na

coleta. Por limitações de espaço não apresentamos aqui os resultados da análise segundo

145


o princípio do fatorial 2 k r, mas os resultados dessa análise se refletem nos resultados

da discussão apresentada a seguir. Nesta seção avaliamos os dados agregados por coletor,

rankings associados às diversas métricas e dados de distribuição para oferecer uma

discussão mais detalhada para os impactos de cada fator de configuração, que poderiam

também ser apresentados (de forma mais resumida) através dos resultados do fatorial.

A tabela 2 apresenta os valores agregados das métricas consideradas durante esta

análise. A ordem dos cenários na tabela foi escolhida para facilitar a discussão.

Duas primeiras características dos dados são claramente visíveis com relação ao

ao volume de tráfego coletado: o impacto da restrição da coleta ao comportamento de

open mail relay apenas (SMTP) e da restrição ao número de conexões concorrentes.

Bits Abreviaturas Volume (GB) Mensagens Conexões IPs

0000 ----.----.----.---- 734,34 19.451.340 13.031 2.498

0001 ----.----.----.CLIM 281,46 10.396.105 10.290 2.051

0010 ----.----.DNBL.---- 562,36 16.087.849 9.513 688

0011 ----.----.DNBL.CLIM 324,25 24.563.202 14.766 828

1010 TMSG.----.DNBL.---- 503,23 17.127.447 10.059 734

1011 TMSG.----.DNBL.CLIM 223,27 13.324.938 6.372 838

1000 TMSG.----.----.---- 450,45 17.981.985 64.582 26.421

1001 TMSG.----.----.CLIM 217,48 17.246.326 71.329 32.710

1100 TMSG.SMTP.----.---- 101,76 28.437.165 125.486 73.332

1101 TMSG.SMTP.----.CLIM 86,36 17.785.180 122.243 64.514

1110 TMSG.SMTP.DNBL.---- 3,36 53.248 1.965 439

1111 TMSG.SMTP.DNBL.CLIM 6,51 108.705 2.850 505

0100 ----.SMTP.----.---- 0 (655 KB) 474 264 199

0101 ----.SMTP.----.CLIM 0 (573 KB) 480 251 198

0110 ----.SMTP.DNBL.---- 0 (82 KB) 76 16 11

0111 ----.SMTP.DNBL.CLIM 0 (82 KB) 78 16 11

Tabela 2. Resultados agregados para métricas cumulativas

Mensagens de teste e open mail relays

O impacto da restrição SMTP é extremamente significativo. Podemos ver pela tabela 2

que o volume coletado nos cenários apenas com mail relay é ordens de grandeza inferior

aos demais, em particular nos casos onde o encaminhamento de mensagens de teste não

é permitido (cenários ----.SMTP.*.*). Por inspeção direta das mensagens coletadas,

verificamos que todas (salvo alguma exceções isoladas) são mensagens de teste, o que sugere

fortemente que spammers só abusam open mail relays se conseguem enviar primeiro

uma mensagem de teste.

Além disso, verificamos ainda que se habilitamos a rejeição de conexões a partir

de máquinas cujos endereços aparecem em listas negras, o resultado é ainda pior. Aparentemente,

a grande maioria das máquinas de spammers que se valem desse recurso já

foram incluídas em listas negras. Isso faz sentido: se considerarmos que o coletor de

146


spam aparece se faz passar por uma máquina de usuário infectada, é do interesse do transmissor

que já foi incluído em uma lista negra se esconder atrás de outro mail relay para

ocultar sua identidade, especialmente se aquele relay já demonstrou sua capacidade de

enviar uma mensagem (de teste) com sucesso.

É interessante observar o número de endereços IP distintos observados tentando

enviar mensagens em cada um daquele cenários: apenas 11 máquinas tentaram enviar

mensagens nos cenários ----.STMP.DNBL.*, mas esse número já sobe para pelo menos

439 nos cenários TMSG.STMP.DNBL.*. Como em um primeiro momento basicamente

os mesmos 11 transmissores enviaram mensagens em todos esses casos, o encaminhamento

bem sucedido das mensagens de teste daqueles onze foi suficiente para aumentar

em quase 400 vezes o número de máquinas que tentaram enviar mensagens usando

aqueles coletores. Nos cenários *.STMP.----.* (sem rejeição baseada em listas negras),

o encaminhamento de mensagens de teste fez com que o número de máquinas diferentes

passasse de 198 para 64.514 no pior caso, um aumento de mais de 325 vezes. Esse

comportamento sugere claramente que mensagens de teste estão associadas à atuação de

botnets: depois que uma mensagem de teste é entregue com sucesso, a identificação da

máquina supostamente vulnerável é distribuído entre vários computadores da rede, que

passaram todos a se aproveitar da máquina disponível.

O impacto da limitação de conexões concorrentes

O segundo fator identificado pelo experimento fatorial como responsável por variações

no volume de mensagens foi a limitação no número de conexões simultâneas permitidas.

Esse impacto pode ser observado ao compararmos os pares de cenários que diferem apenas

pelo fator CLIM: aqueles que têm a limitação recebem um volume menor de tráfego

que aqueles que não têm a limitação. Isso é um primeiro indício de que há máquinas

de spammers que utilizam muitas conexões em paralelo para aumentar sua taxa de transmissão

(como TCP tem um sistema de controle de congestionamento que visa distribuir a

banda entre fluxos, um transmissor com mais conexões teria uma fração maior da banda

disponível). Em situações sem limitadores, esses transmissores podem eclipsar outras

fontes de spam e aumentar seu aproveitamento da máquina abusada.

Configurações antagônicas com efeitos semelhantes

Se observarmos os diversos valores exibidos na tabela 2, notaremos que não há um padrão

comum às métricas (exceto entre conexões e número de endereços IP de origem distintos).

O volume de tráfego observado por cada cenário não apresenta grupos notáveis,

apesar de alguns pontos merecerem uma discussão posteriormente. Já no número de mensagens,

temos dois cenários, TMSG.SMTP.----.---- e ----.----.DNBL.CLIM,

com configurações opostas, que recebem o maior número de mensagens; depois, um

grupo com configurações variadas com valores semelhantes e dois cenários com resultados

ligeiramente inferiores. Claramente, há uma grande variação entre os tipos de mensagens,

pois o primeiro e o segundo cenários com mais mensagens são apenas o nono e o

quinto, respectivamente, em volume de tráfego. Além disso, os três cenários com maior

número de conexões são nono, décimo e oitavo, respectivamente, em número de mensa-

147


gens. Já os três cenários com o maior volume de tráfego observado são apenas o sexto,

nono e oitavo em termos de número de conexões e endereços IP distintos observados.

Em relação ao cenário ----.----.----.----, certamente as condições de

emular proxies e mail relay, não rejeitar conexões e não limitar o número de conexões

são todas conceitualmente benéficas para um maior volume de coleta. Entretanto, em

um primeiro momento, esperava-se que a configuração com ainda mais flexibilidade

(TMSG.----.----.----, que repassa mensagens de teste) recebesse o maior volume

de tráfego. Entretanto, como vimos, o repasse das mensagens de teste causa o aumento

do abuso da máquina por botnets com mensagens menores. Esse abuso gera mais conexões

de curta duração para aquele cenário, que podem limitar a banda disponível para

os grandes transmissores.

Já o cenário ----.----.DNBL.CLIM, por não repassar mensagens de teste,

seria a princípio um alvo maior para os mesmos transmissores de maior volume e mensagens

maiores, pelo que se esperava um menor número de mensagens nesse caso (certamente,

menos que segundo lugar nessa métrica). Nesse caso, uma análise dos endereços

encontrados entre os maiores transmissores naquele caso indica um conjunto grande de

máquinas de uma mesma faixa de endereços (184.95.36/23), com um volume de tráfego

significativo, mas com mensagens bem menores que as dos transmissores que aparecem

nos primeiros lugares. O endereço que envia o maior volume (terceiro em número de mensagens)

tem uma média de 55 KB por mensagem e outros três encontrados entre os cinco

primeiros nas duas listas têm médias acima de 20 KB por mensagem. Já as máquinas

daquela faixa de endereços enviam mensagens de 3,5 KB em média (daí, uma contagem

maior de mensagens sem um volume tão significativo. Aparentemente, essas máquinas

pertencem a um mesmo spammer e tiveram seu acesso facilitado naquele cenário exatamente

pelas condições mais restritivas para os transmissores mais pesados.

O abuso a proxies está associado a spammers com mais recursos

Nas estatísticas de trabalhos anteriores do grupo Spammining, coletores semelhantes aos

utilizados neste trabalho, quando emulando tanto proxies quanto mail relays, observam

que os primeiros são responsáveis por mais de 90 % do volume e do número de mensagens

[Steding-Jessen et al. 2008]. Estatísticas de análise das coletas realizadas pelo

Cert.br indicam que atualmente certa de 8 % das mensagens seja enviadas por STMP 2

Entretanto, vemos que quando o coletor oferece apenas a emulação de mail relay, o

volume de tráfego coletado equivale a 23 % do tráfego coletado por uma configuração

equivalente que também emule proxies abertos (TMSG.SMTP.----.----: 101 GB;

TMSG.----.----.----: 450 GB). Isso, somado aos fatos de haver proporcionalmente

muito menos endereços IP nos cenários que emulam proxies, e desses cenários

serem responsáveis pelos maiores volumes de tráfego, sugere que os transmissores que

atacam essas máquinas enviam um volume elevado de mensagens. Além disso, o fato da

restrição do número de conexões concorrentes causar uma redução no volume de tráfego

para cenários semelhantes também sugere que os abusos a proxies podem ser levados a

cabo por máquinas que abrem um grande número de conexões paralelas, para aumentar

sua taxa para o destino e assim ganhar um vantagem sobre outros spammers.

2 http://kolos.cert.br, acesso restrito.

148


Para melhor entendermos o comportamento desses transmissores com mais recursos,

observamos os endereços IPs identificados com maiores transmissores em cada

cenário, tanto em volume de tráfego quanto em número de mensagens. Por limitações de

espaço, apenas reportamos os resultados aqui; uma descrição detalhada desses resultados

pode ser encontrada em [Silva 2011]. Nossa análise dos dados revela que:

• os oito endereços com mais mensagens também tiveram maior volume de tráfego;

• esses oito endereços foram responsáveis por 64 % do tráfego, mas apenas 34 %

das mensagens, o que sugere que enviam mensagens maiores;

• nenhum desses endereços aparecem nos cenários que só emulavam mail relays;

• nos cenários com proxies, dos 15 primeiros endereços do ranking geral, 14 deles

aparecem no topo em cada cenário que não usa listas negras;

• nos cenários com proxies que usam listas negras, encontra-se ainda oito dos quinze

endereços identificados com maiores transmissores;

• as distribuições de volume de tráfego parecem ser mais desiguais nos casos com

proxies: a razão de volume entre o primeiro e o décimo-quinto endereços do ranking

é superior a 24 em todos esses casos, chegando a mais de 1000 em um cenário

(nos cenários com mail relay apenas, essa razão não ultrapassa 5,2;

• os cenários que utilizam listas negras e que limitam conexões concorrentes tendem

a ter mais endereços entre os maiores que não aparecem na lista geral.

Todos esses resultados apontam para o fato do abuso a proxies ser coordenado

a partir de poucas máquinas, com boa conectividade e que utilizam múltiplas conexões

simultânas para se aproveitar ao máximo das máquinas vulneráveis que atacam. Além

disso, as mensagens enviadas nesse tipo de ataque tendem a ser maiores que as enviadas

utilizando-se botnets e open mail relays, em geral.

Tamanhos de mensagens

Considerando a adição da informação de tamanho médio de mensagens utilizada

na análise anterior, a tabela 3 apresenta um conjunto de métricas derivadas das

métricas acumuladas descritas anteriormente. Novamente, podemos ignorar o grupo

----.SMTP.*.*, cujo comportamento restrito já foi discutido anteriormente.

Um comportamento que chama a atenção é aquele relacionado aos tamanhos

das mensagens. Ignorando o grupo ----.SMTP.*.*, temos três categorias: em dois

cenários, o tamanho médio das mensagens fica acima de 62 KB; outros cinco recebem

na ordem de poucas dezenas de KB por mensagem e dois recebem até 5 KB por mensagem.

Esse último grupo é composto pelos cenários TMSG.SMTP.*.*, o que nos permite

afirmar que botnets observadas enviam mensagens pequenas, com algumas conexões entregando

centenas de mensagens de cada vez.

Escolhemos um cenário em cada grupo para uma análise por amostragem das

mensagens: ----.----.----.----, que tem o maior volume de tráfego total, mas

apenas o terceiro número de mensagens, com a média de quase 40 KB por mensagem;

TMSG.SMTP.----.----, que tem o maior número de mensagens, mas é apenas o

nono em volume de tráfego, com média de pouco menos de 4 KB por mensagem; e

TMSG.SMTP.DNBL.CLIM, que tem volume e número de mensagens relativamente baixos,

mas tem média de mais de 60 KB por mensagem.

149


Bits Abreviaturas msgs/con MB/con KB/msg conex/IP

0010 ----.----.DNBL.---- 1.691,1 60,5 36,7 13,8

0000 ----.----.----.---- 1.492,7 57,7 39,6 5,2

1010 TMSG.----.DNBL.---- 1.702,7 51,2 30,8 13,7

1011 TMSG.----.DNBL.CLIM 2.091,2 35,9 17,6 7,6

0001 ----.----.----.CLIM 1.010,3 28,0 28,4 5,0

0011 ----.----.DNBL.CLIM 1.663,5 22,5 13,8 17,8

1000 TMSG.----.----.---- 278,4 7,1 26,3 2,4

1001 TMSG.----.----.CLIM 241,8 3,1 13,2 2,2

1111 TMSG.SMTP.DNBL.CLIM 38,1 2,3 62,8 5,6

1110 TMSG.SMTP.DNBL.---- 27,1 1,8 66,1 4,5

1100 TMSG.SMTP.----.---- 226,6 0,8 3,8 1,7

1101 TMSG.SMTP.----.CLIM 145,5 0,7 5,1 1,9

Tabela 3. Resultados agregados para métricas relativas

As mensagens observadas no cenário TMSG.SMTP.----.----, associado a

botnets em geral, são mensagens de spam curtas, contendo apenas texto em HTML e,

frequentemente, links que parecem apontar para sites de propaganda e venda.

As mensagens no cenário ----.----.----.---- se dividem em geral em

dois grupos, um de mensagens de spam de aproximadamente 4 KB, frequentemente com

conteúdo em HTML e alguns links que levam a sites de anúncio/venda de produtos após

alguns redirecionamentos, e outro de mensagens maiores, por volta de 65 KB, formadas

por documentos codificados em mime, usualmente PDF. Um teste simples com diversos

cenários nessa categoria sugere que as variações na média de volume por mensagem se

deve a uma combinação de quantidades diferentes de mensagens desses dois tipos.

Já as mensagens encontradas no cenário TMSG.SMTP.DNBL.CLIM compunham

um conjunto menor (provavelmente devido ao comportamento mais restritivo do cenário).

Nesse caso encontramos uma combinação de mensagens codificadas em mime, sendo um

conjunto com aproximadamente 10 KB por mensagem e frequentemente contendo mime

mal formado, e outro com documentos PDF de por volta de 200 KB. Aparentemente, o

material coletado nesse cenário (e no TMSG.SMTP.DNBL.----) representam um outro

comportamento diferente do dominante que havia sido identificado antes para botnets.

Devido ao volume relativamente reduzido, uma análise mais longa pode ser necessária

para determinar se esse comportamento realmente se destaca, ou se ele foi apenas devido

a um conjunto de dados reduzido.

Relações entre volume e tamanho de mensagens

A discussão anterior sobre volumes de tráfego e número de mensagens sugere que os

comportamentos das máquinas podem se distribuir por um espaço amplo. Uma análise

das distribuições de número de mensagens enviadas por cada endereço de origem e de

volume de tráfego gerado mostram realmente distribuições bastante desbalanceadas.

A diferença entre as máquinas de alta capacidade que abusam proxies e enviam

muitas mensagens, e as máquinas de botnets, que enviam cada uma poucas mensagens, e

150


normalmente menores, pode ser visualizada ao representarmos cada transmissor em um

gráfico de número de mensagens por volume de tráfego transmitido (um scatter plot). A

figura 2 mostra esse resultado para os mesmos cenários considerados anteriormente.

Figura 2. Relação entre volume de tráfego e número de mensagens

Na figura, fica claro o comportamento bastante regular das máquinas que abusam

os cenários que só emulam open relay (1100 e 1111), com uma tendência que sugere

que a grande maioria dos transmissores naqueles cenários enviam mensagens de mesmo

tamanho. Já nos cenários que emulam proxies, como o 0000, alguns transmissores se

destacam com volumes de mensagens e tráfego muito superiores aos demais. Já que esses

transmissores enviam muito mais que os demais e estão presentes em diversos cenários, o

gráfico para o padrão geral é semelhante. Nele pode-se inclusive perceber que a inclinação

da reta gerada pelos computadores que transmitem menos mensagens (botnets) é bem

menor, confirmando que os transmissores de maior capacidade enviam mensagens bem

maiores, em geral.

Se gerarmos os mesmos gráficos retirando os transmissores mais pesados de cada

cenário (figura 3), o comportamento regular dos transmissores de menor capacidade se

torna mais claro, tanto no agregado, quanto no cenário 1111. O cenário 1100 já tinha

um padrão bastante regular, sendo pouco afetado. Já o cenário 0000, por não repassar as

mensagens de teste e por isso não ser visível para botnets que abusam mail relays, tem

um padrão mais disperso, mas ainda assim pode-se perceber uma regularidade maior nos

151


Figura 3. Relação entre volume de tráfego e número de mensagens

tamanhos das mensagens (relação volume por número de mensagens).

4. Trabalhos Relacionados

O uso de honeypots se estabeleceu como um método eficaz para estudo e prevenção

em ataques em rede [Provos and Holz 2007]. Honeypots podem ter as mais variadas

aplicações, como base de estudo para botnets [John et al. 2009], método de defesa para

ataques de negação de serviço [Sardana and Joshi 2009], entre outros.

A base da arquitetura de coleta deste estudo é um honeypot virtual. O conceito

de um framework para coleta de spam como o descrito tem origem no agrupamento de

diversos conceitos, metodologias que foram sendo aperfeiçoadas na literatura e no desenvolvimento

interno ao próprio grupo de pesquisa 3 . A decisão de analisar os spammers

de forma mais direta tem inspiração no trabalho [Pathak et al. 2008], que utiliza o tipo

de honeypot descrito em [Provos 2004]. O coletor usado na pesquisa é uma atualização

do projeto apresentado em [Steding-Jessen et al. 2008], mantido pelo Cert.br, com várias

3 O projeto Spammining, parceria entre o CERT.br e o Departamento de Ciência da Computação da

UFMG.

152


aperfeiçoamentos na técnica e atualizações da estrutura.

Trabalhos focados em entender a formação e a origem d spam [Shue et al. 2009]

mostram que apesar de novas técnicas como o uso de botnets para o envio de spam,

o abuso de open relays na disseminação do spam é muito expressivo. Nossos resultados

mostram que os dois princípios parecem estar relacionados ao invés de serem mutuamente

exclusivos. É interessante verificar se o tráfego diário gerado por cada open

relay na Internet continua significativo mesmo com diversas restrições de rede. Diversos

estudos foram feitos utilizando diretamente ou indiretamente os conceitos por trás do

abuso de open relays [Pathak et al. 2008, Kreibich et al. 2008, Steding-Jessen et al. 2008,

Li and Hsieh 2006].

O experimento fatorial é uma ferramenta metodológica largamente empregada

na literatura em trabalhos de caracterização dada sua abordagem e confiabilidade estatística,

como pode ser observado em diversos trabalhos [Mycroft and Sharp 2001,

Guerrero and Labrador 2010]. A aplicação desse método experimental permite determinar

a influência que fatores pré-determinados têm no objeto em estudo, no caso, o comportamento

dos spammers. Uma boa introdução sobre o tema é o livro de Jain [Jain 2008].

5. Conclusão e Trabalhos Futuros

Neste trabalho aplicamos a metodologia do experimento fatorial para analisar e comparar

as influências que diversos fatores ligados à interface exposta por alvos dos spammers têm

em seus comportamentos. Os diversos cenários contemplados por essa análise demonstraram,

através das métricas coletadas, que existe não apenas uma correlação forte entre os

fatores e as preferências dos spammers individualmente, mas que ocorre também seleção

de todo o espectro de abuso que poderia ser coletado. O formato experimental aplicado

neste estudo apesar de ser muito utilizado nas mais diversas áreas do conhecimento, observamos

poucos estudos com esse foco no problema de caracterização e compreensão

das técnicas do envio de spam.

As análises apresentadas nos permitem afirmar que realmente o comportamento

exibido pelo coletor de spam afeta significativamente o tipo de mensagens e os padrões de

tráfego que ele recebe. Em particular, a capacidade de encaminhar mensagens de teste só

tem impacto para spammers que abusam open mail relays e o padrão de endereços observado,

muito maior que o conjunto que realmente enviou mensagens de teste, sugere um

esquema de disseminação de informação de botnets. Em particular, esse esquema é mais

utilizado por máquinas que se encontram em listas negras, o que sugere que é utilizado

exatamente como um subterfúgio para escapar desse tipo de mecanismo As mensagens

enviadas por estas tendem a ser menores em geral. Já os proxies abertos tendem a se tornar

alvos de máquinas de alta capacidade que enviam um grande volume de mensagens,

frequentemente usando diversas conexões concorrentes, o que tende a excluir tráfego de

outras fontes. Em dois cenários foram observado tráfego com padrão de botnet, mas com

mensagens muito maiores que as observadas nos outros casos. Como o volume nesse

cenário foi reduzido, uma coleta mais longa seria necessária para determinar se isso representa

um outro padrão comum, ou apenas um evento isolado.

Referências

Giles, J. (2010). To beat spam, first get inside its head. New Scientist, 205:20–20.

153


Guerrero, C. D. and Labrador, M. A. (2010). On the applicability of available bandwidth

estimation techniques and tools. Comput. Commun., 33:11–22.

Jain, R. (2008). The Art Of Computer Systems Performance Analysis:Techniques for

Experimental Design, Measurement, Simulation, and Modeling. Wiley India Pvt. Ltd.

John, J. P., Moshchuk, A., Gribble, S. D., and Krishnamurthy, A. (2009). Studying spamming

botnets using botlab. In NSDI’09: Proceedings of the 6th USENIX symposium on

Networked systems design and implementation, pages 291–306, Berkeley, CA, USA.

USENIX Association.

Kreibich, C., Kanich, C., Levchenko, K., Enright, B., Voelker, G. M., Paxson, V., and

Savage, S. (2008). On the spam campaign trail. In LEET’08: Proceedings of the 1st

Usenix Workshop on Large-Scale Exploits and Emergent Threats, pages 1–9, Berkeley,

CA, USA. USENIX Association.

Li, F. and Hsieh, M.-H. (2006). An empirical study of clustering behavior of spammers

and group-based anti-spam strategies. Proceedings of the Third Conference on Email

and Anti-Spam (CEAS). Mountain View, CA.

Mycroft, A. and Sharp, R. (2001). Hardware/software co-design using functional languages.

In Margaria, T. and Yi, W., editors, Tools and Algorithms for the Construction

and Analysis of Systems, volume 2031 of Lecture Notes in Computer Science, pages

236–251. Springer Berlin Heidelberg.

Pathak, A., Hu, Y. C., and Mao, Z. M. (2008). Peeking into spammer behavior from

a unique vantage point. In LEET’08: Proceedings of the 1st Usenix Workshop on

Large-Scale Exploits and Emergent Threats, pages 1–9, Berkeley, CA, USA. USENIX

Association.

Provos, N. (2004). A virtual honeypot framework. In Proceedings of the 13th conference

on USENIX Security Symposium - Volume 13, SSYM’04, pages 1–1, Berkeley, CA,

USA. USENIX Association.

Provos, N. and Holz, T. (2007). Virtual Honeypots: From Botnet Tracking to Intrusion

Detection. Addison-Wesley Professional.

Radicati, S. (2009). Email statistics report, 2009-2013. Relatório anual, The Radicati

Group, Inc. http://www.radicati.com/.

Sardana, A. and Joshi, R. (2009). An auto-responsive honeypot architecture for dynamic

resource allocation and qos adaptation in ddos attacked networks. Comput. Commun.,

32:1384–1399.

Shue, C. A., Gupta, M., Lubia, J. J., Kong, C. H., , and Yuksel, A. (2009). Spamology: A

study of spam origins. In Conference on Email and Anti Spam (CEAS).

Silva, G. C. (2011). Análise de fatores que afetam o comportamento de spammers na

rede. Dissertação de mestrado, Universidade Federal de Minas Gerais.

Steding-Jessen, K., Vijaykumar, N. L., and Montes, A. (2008). Using low-interaction

honeypots to study the abuse of open proxies to send spam. INFOCOMP Journal of

Computer Science.

154


Segmentação de Overlays P2P como Suporte para

Memórias Tolerantes a Intrusões

Davi da Silva Böger 1 , Joni Fraga 1 , Eduardo Alchieri 1 , Michelle Wangham 2

1 Departamento de Automação e Sistemas –UFSC

Florianópolis – SC – Brasil

2 Grupo de Sistemas Embarcados e Distribuídos – UNIVALI

São José – SC – Brasil

{dsboger,fraga,alchieri}@das.ufsc.br, wangham@univali.br

Abstract. This paper describes our experience in developing an infrastructure

which allows building intrusion-tolerant shared memory for large-scale

systems. The infrastructure makes use of a P2P overlay and of the concept of

State Machine Replication (SMR). Segmentation is introduced on the key

space of the overlay to allow the use of algorithms for supporting SMR. In this

paper we describe the proposed infrastructure in its stratification and

corresponding algorithms. Also, analyses of the algorithms described and

their respective costs are presented.

Resumo. Este artigo descreve nossa experiência no desenvolvimento de uma

infraestrutura que permite a construção de memórias compartilhadas

tolerantes a intrusões para sistemas de larga escala. A infraestrutura faz uso

de um overlay P2P e do conceito de Replicação Máquina de Estados (RME).

O conceito de segmentação é introduzido sobre o espaço de chaves do overlay

para permitir o uso de algoritmos de suporte à RME. No presente artigo

descrevemos a infraestrutura proposta em sua estratificação e algoritmos.

Além disso, realizamos uma análise da solução apresentada e dos custos

envolvidos.

1. Introdução

As redes par a par (peer-to-peer, P2P) correspondem a um paradigma de comunicação

que tem sido o foco de muitos trabalhos nos últimos anos. O uso desse paradigma foi

bastante popularizado na Internet, principalmente por ser a base para as aplicações de

compartilhamento de arquivos modernas. Diversas outras aplicações já foram

desenvolvidas usando P2P, como multicast e sistemas de e-mail [Steinmetz and Wehrle

2005]. Apesar disso, P2P ainda é pouco utilizado em aplicações mais complexas que

poderiam se beneficiar de aspectos como a escalabilidade [Baldoni et al. 2005].

As principais características que tornam as redes P2P uma arquitetura

interessante para sistemas distribuídos são o uso eficiente dos recursos ociosos

disponíveis na Internet e a capacidade de aumento do número de nós sem detrimento do

desempenho. Normalmente as redes P2P oferecem primitivas de comunicação com

latência e número de mensagens de ordem logarítmica em relação ao número de nós

presentes na rede [Stoica et al. 2001, Rowstron and Druschel 2001].

155


Apesar das suas vantagens, as redes P2P apresentam desafios para o provimento

de garantias de confiabilidade. Essas redes normalmente são formadas dinamicamente

por nós totalmente autônomos que podem entrar e sair do sistema a qualquer momento.

Essas características de dinamismo tornam difícil manter a consistência das informações

distribuídas no sistema. Ademais, essas redes não possuem uma gerência global, sendo

redes de pares normalmente abertas. Devido a essa característica, as redes P2P podem

conter participantes maliciosos que colocam em risco o funcionamento das aplicações.

Neste trabalho, é apresentada uma infraestrutura tolerante a intrusões para

memórias compartilhadas em sistemas de larga escala. Esta infraestrutura faz uso das

funcionalidades de um overlay P2P estruturado e tolerante a intrusões, sobre o qual é

introduzido o conceito de segmentação tomando como base a divisão do espaço de

chaves da rede P2P e a aplicação de técnicas de Replicação Máquina de Estados (RME)

[Schneider 1990]. A partir de segmentos é possível garantir consistência e tolerar uma

quantidade de participantes maliciosos em um sistema de memória compartilhada. A

segmentação do overlay depende do fornecimento de uma técnica de indexação, isto é,

um mapeamento de objetos para chaves, pela aplicação de memória compartilhada.

O restante do artigo está organizado da seguinte forma: a seção 2 enumera as

premissas do modelo de sistema adotado, a seção 3 introduz a solução proposta neste

trabalho, a seção 4 contém discussões sobre as propostas de nosso trabalho e coloca

problemas em aberto. A seção 5 examina os trabalhos relacionados e conforta os

mesmos diante de nossas soluções. A seção 6 traz as conclusões do artigo.

2. Modelo de Sistema

Consideramos um sistema distribuído formado por um conjunto finito de processos

(ou nós) extraídos de um universo , interconectados por uma rede. Cada nó possui um

endereço único de rede e pode enviar mensagens para qualquer outro nó, desde que

conheça seu endereço. Um nó é considerado correto se age de acordo com a

especificação dos protocolos nos quais participa. Um nó malicioso (ou bizantino

[Lamport et al. 1982]) pode agir de maneira arbitrária ou simplesmente parar em certos

momentos. O sistema proposto tolera certo número de nós maliciosos durante sua

execução. Assume-se que em qualquer momento da execução, no máximo nós

faltosos estão presentes no sistema. O parâmetro é global e conhecido por todos os

nós do sistema.

Imediatamente acima da rede, encontram-se duas camadas independentes que

serão usadas para construir a camada de segmentação proposta neste trabalho. A

camada de overlay, descrita na Seção 2.1, implementa uma rede P2P sobre o sistema,

com busca eficiente de nós distribuídos, e a camada de suporte à replicação, descrita na

Seção 2.2, que fornece uma abstração de Replicação Máquina de Estados (RME)

[Schneider 1990] usada para garantir a disponibilidade e consistência das informações

contidas no sistema. Em geral, os custos da RME não permitem que essa técnica seja

aplicada a uma grande quantidade de nós, portanto neste trabalho dividimos o sistema

Tabela 1: Camadas do Sistema

Segmentação

Overlay

Suporte à Replicação

Rede

156


em diversas máquinas de estados independentes. A camada de segmentação faz uso

dessas duas e provê meios para invocar eficientemente qualquer RME do sistema. A

Tabela 1 apresenta as camadas do sistema.

A camada de rede é acessada a partir de duas operações: A operação

envia a mensagem para o nó de endereço . A operação

aguarda o recebimento de uma mensagem qualquer . Os canais de comunicação da

rede são ponto a ponto e confiáveis, ou seja, não há perda ou alteração de mensagens. O

atraso na entrega das mensagens e as diferenças de velocidades entre os nós do sistema

respeitam um modelo de sincronia parcial [Dwork et al. 1988], no qual é garantido a

terminação de protocolos de Replicação Máquina de Estados que serão usados nas

camadas superiores. No entanto, não há garantia de sincronismo por toda a execução.

2.1.Camada de Overlay

Acima da camada de rede, assume-se a existência de um overlay que provê operações

similares às redes P2P estruturadas, como Pastry [Rowstron e Druschel 2001] e Choord

[Stoica et al. 2003]. Essas redes atribuem identificadores aos nós e distribuem estes em

torno de um anel lógico. Nós conhecem outros nós com identificadores numericamente

próximos, denominados de vizinhos, de forma a manter a estrutura do anel. Além disso,

os nós possuem tabelas de roteamento que são usadas para contatar eficientemente nós

distantes no anel. Aplicações se utilizam dessa estrutura definindo esquemas para a

distribuição de objetos pelo overlay, normalmente atribuindo chaves aos objetos e

armazenando esses objetos em nós com identificadores numericamente próximos a

essas chaves. A busca por um objeto consiste em usar as tabelas de roteamento para

encontrar nós com identificador próximo à chave associada ao mesmo.

Este trabalho utiliza o overlay tolerante a faltas bizantinas definido por Castro et

al. (2002), o qual apresenta a propriedade de garantir alta probabilidade na entrega de

mensagens a todos nós corretos na vizinhança de uma chave, mesmo se uma quantidade

de nós do overlay for maliciosa. A confiabilidade da entrega é alcançada pelo envio de

uma mensagem por múltiplas rotas e pelo uso de tabelas de roteamento especiais que

aumentam a probabilidade de que essas rotas sejam disjuntas, ou seja, não tenham nós

em comum. O número de rotas disjuntas, ao superar o limite estabelecido de faltas

garante a entrega das mensagens. Análises e resultados experimentais [Castro et al.

2002] demonstram que a probabilidade de entrega de uma mensagem é de 99,9% se a

proporção de nós maliciosos for de até 30%.

O funcionamento do overlay depende da geração e atribuição segura de

identificadores a nós da rede, de forma que nós maliciosos não possam escolher seu

identificador nem participar do overlay com múltiplas identidades. Essas propriedades

são garantidas, por exemplo, pelo uso de certificados que associam o identificador do nó

a seu endereço de rede e sua chave pública. Esses certificados são emitidos por uma

autoridade certificadora (AC) confiável, que também pode ser responsável por gerar

identificadores aleatórios para os nós 1 . Na nossa infraestrutura, mantemos o uso desses

certificados na camada de segmentação, onde é denominado de certificados de nó.

1 Não é necessário que esta AC seja uma PKI oficial. A mesma pode ser uma comissão