Middleware de segurança adaptativo para computação móvel

(1)

MIDDLEWARE DE SEGURANÇA ADAPTATIVO

PARA COMPUTAÇO MÓVEL

(2)

Programa de Pós-Graduação em Ciênia da Computação

MIDDLEWARE DE SEGURANÇA ADAPTATIVO

PARA COMPUTAÇO MÓVEL

Dissertação apresentada ao Programa de

Pós-GraduaçãoemCiêniadaComputaçãoda

Uni-versidadeFederalde MinasGeraisomo

requi-sitoparialpara aobtençãodograu deMestre

emCiênia da Computação.

BRUNO PONTES SOARESROCHA

(3)

FOLHADE APROVAÇO

Middleware de Segurança Adaptativo

para Computação Móvel

BRUNO PONTES SOARESROCHA

Dissertação defendidae aprovadapelabana examinadora onstituída por:

Ph.D. Antonio Alfredo Ferreira Loureiro Orientador

UniversidadeFederal de MinasGerais

Doutora Raquel Apareida Freitas Mini

Pontifíia UniversidadeCatóliade Minas Gerais

Ph.D. Gilles J. Barthe

(4)

O paradigma da omputaçãomóvelintroduziu novosproblemas para desenvolvedores e

pro-jetistas deapliações. Desaosinluemaheterogeneidade dehardware, softwaree protoolos

deomuniação,limitaçõesdereursosequalidade deanalsemovariável. Nesseenário,a

segurança setornauma preoupaçãofundamental paraapliações eusuários móveis.

Requi-sitosdesegurançaparaadaapliaçãosãodiferentes, assimomoasapaidadesdehardware

de ada dispositivo. Para tornar a situaçãoainda pior, asondiçõesdo meio semo podem

mudar drastiamenteomo tempo,ausandogrande impatonodesempenhoe emgarantias

de qualidade de serviço da apliação. Atualmente, a maioria dassoluções desegurança para

dispositivosmóveisutilizaumonjuntoestátiodealgoritmoseprotoolosparaserviçosomo

riptograa e integridadede dados.

Neste trabalho propomos um serviço de segurança, que funiona omo um middleware,

om a habilidade de alterar dinamiamente os protoolos de segurança usados entre duas

entidades omputaionais. Mudanças são feitasde aordo om variações nos parâmetros do

meio semoedousodereursosdosistema,apaidadesdehardware, métriasdequalidade

de serviço e níveis desejados de segurança denidos pela apliação. Também apresentamos

uma extensão que permite ao middleware onsiderar o valor semântio de paotes sendo

transmitidos omo objetivo de esolher melhoro protoolo a serusado. Comparamos nossa

soluçãoomalgunsprotoolosestátiosdesegurançabemdifundidosemostramosomonosso

(5)

The mobile omputing paradigm has introdued new problems for appliation developers.

Challenges inlude heterogeneity of hardware, software, and ommuniation protools,

re-soure limitations and varying wireless hannel quality. In this senario, seurity beomes

a major onern for mobile users and appliations. Seurity requirements for eah

applia-tion aredierent, aswellas the hardware apabilities of eah devie. To make thingsworse,

wireless medium onditions may hange dramatially with time, inurring great impat on

performaneandQoSguaranteesfortheappliation. Currently,mostoftheseuritysolutions

formobiledeviesuseastatisetofalgorithmsandprotoolsforserviessuhasryptography

and hashes.

Inthis workweproposea seurityservie, whihworksasa middleware, withtheability

to dynamially hange theseurityprotools usedbetween two peers. Changesaremade

a-ordingtovariationsonthewirelessmediumparametersandsystemresoureusage,hardware

resoures, appliation-dened QoSmetris, and desiredseurity levels. We also present an

extension that allows our middlewareto onsider thesemanti value of pakets being

trans-mitted in order to hoose the best protools to be used. We ompare our solution to some

widespread statiseurityprotoolsandshowhowour middlewareisabletoadapt itselfover

(6)

(7)

Primeiramente,aosmeusfamiliares. MãeePai,fundamentaiseindispensáveisdesdeoomeço

de tudo, orgulhosos, orujas, perfeitas estrelas-guias em minha vida. Vovó Dary, da asa

heia de alegria onde aprendi a andar, a esrever, a nadar e a ser feliz, sempre vibrando e

heiade orgulho. Vovó Jane,peloarinho,amore exemplo,debemomavida sempre. Tati

e Caá, sempre presentes, sempretorendo. Nando, Lí, Lelae Beto, sempre ompanheiros e

orgulhosos. Miguel, de longemas sempreaqui,meforçando aentrar defériastodo nalde

ano.

A todosque me ajudaram dentro do DCC. Ao professor Loureiro, não somente pela

ori-entação aadêmia, mas pelos exemplos, onselhos e pela sinera amizade. A alguns outros

professores que foram exemplos pessoais, notadamente os professores Virgilio, pelo

ompa-nheirismo eajuda,e Mário, peloexemplo.

Aosamigos de mestrado e graduação, pelaaminhada onjunta na lama, farras,

boba-gens, almoços diários, hurrasos. Marus e Lília, pelo apoio fundamental bem no omeço

dessa aminhada. Aos amigos da Smart Prie, ampeões do bom humor em meio às rises.

E, nalmente, mas não menos importante, aos amigos dos esparros, sempre presentes nas

(8)

1 Introdução 1

1.1 Objetivo . . . 2

1.2 Motivação . . . 2

1.3 Contribuição . . . 3

1.4 Organização doTexto . . . 3

2 Fundamentos Teórios 4 2.1 Pilhade Protoolos de Rede . . . 4

2.2 Serviços deSegurança . . . 5

2.3 PrimitivasCriptográas . . . 8

2.4 TrabalhosRelaionados . . . 12

3 Modelos e Denições 14 3.1 Modelode Rede. . . 14

3.2 Algoritmose Protoolos de Segurança . . . 14

3.3 Parâmetros e Métrias . . . 16

3.4 Caraterização do Problema . . . 19

4 O Middleware Proposto 21 4.1 Conguraçãodo Middleware. . . 21

4.2 Arquitetura . . . 22

4.3 AlgoritmosparaSeleção de Protoolos de Segurança . . . 22

4.3.1 Instalação . . . 24

4.3.2 Iniialização . . . 24

4.3.3 Conexão . . . 24

4.3.4 Transmissão . . . 27

4.4 Integração omMódulode AnáliseSemântia deDados . . . 28

4.4.1 A CamadadeConguração de Segurança . . . 28

4.4.2 Adaptaçãoda Lógia deSeleção de Protoolos . . . 30

(9)

5.2 Análisesemântia dedados . . . 46

6 Considerações Finais 50

6.1 Conlusões . . . 50

6.2 TrabalhosFuturos . . . 50

A Detalhamento de Parâmetros e Protoolosdos Experimentos 52

A.1 ASeMidomparado a meanismos estátios . . . 52

A.2 Análisesemântia dedados . . . 64

B Arquivosde Anotação Usados nos Experimentos 66

(10)

2.1 Camadas domodelo TCP/IP omparadasao modelo OSI . . . 5

2.2 Protoolos maisfamosos usadosno modeloTCP/IP . . . 5

2.3 Loalização domiddlewareproposto napilha de protoolos TCP/IP . . . 6

4.1 Arquitetura domiddlewareproposto . . . 23

5.1 Exeução típia, om restrições de QoS e níveis de segurança altos, e variação aleatória de parâmetros . . . 37

5.2 Exeução om baixas restrições de QoSe segurança, e reursos seexaurindo om o tempo . . . 38

5.3 Exeução om baixas restriçõesde QoS e segurança, e qualidade do meio sem o piorando omo tempo . . . 39

5.4 Exeução om altas restrições de QoS e segurança, e qualidade do meio sem o piorando omo tempo . . . 40

5.5 Exeução om altas restrições de QoS e segurança, reursos se exaurindo om o tempoe exemplo deaonteimento de deadlok de requisitos. . . 41

5.6 ExeuçãoomrestriçõesdeQoSenãodesegurança,parâmetrosaleatóriosebateria diminuindo omotempo. . . 42

5.7 ExeuçãoomrestriçõesdesegurançaenãodeQoS,parâmetrosaleatóriosebateria diminuindo omotempo. . . 43

5.8 Exeução om restrições medianas de QoS e segurança, parâmetros aleatórios e bateriadiminuindo omo tempo . . . 44

5.9 ExeuçãoomaltasrestriçõesdeQoSesegurançaeparâmetrosxos,omexeção da bateria . . . 45

5.10 Exeução de transmissão dedados FTP . . . 47

5.11 Exeução de transmissão de dados que alternam entremensagens om e sem im-portâniade segurança . . . 48

5.12 Exeução de transmissão dedados MPEG . . . 49

6.1 Possibilidade deextensão domiddleware para tratar roteamento . . . 51

(11)

A.3 Variação de força riptográa e throughput do middleware, om intervalos de

onança de90%, parao experimento da Figura5.3(d). . . 56

(12)

2.1 Tiposde diretivasriptográas. . . 9

3.1 Parâmetros usadospelomiddleware . . . 17

3.2 Mapeamento de parâmetros e métriasafetadas . . . 18

4.1 Constantes de seleçãodeonjunto de protoolos. . . 31

4.2 Constantes

K

de seleçãode protoolos em tempo real . . . 32

A.1 Variação de parâmetros noexperimento da Figura5.1 . . . 52

A.2 Protoolos usados no experimento da Figura5.1 . . . 53

A.10Protoolos usados no experimento da Figura5.5 . . . 58

A.11Variação de parâmetros noexperimento da Figura5.6 . . . 59

A.19Variação de parâmetros paraexperimentos pseudo-aleatórios. . . 64

A.20Parâmetros paraexperimentos xos . . . 64

(13)

4.1 Fluxo deexeuçãobásio da máquinade segurança . . . 23

(14)

Introdução

A omputação móvelpermite ariaçãode umnovo paradigmaomputaional. Umaenorme

gama de diferentes dispositivos omputaionais podem se onetar uns aos outros om o

objetivodeexeutarumgrandeonjuntodepossíveisapliaçõesdistribuídas. Transmissãode

uxos de vídeo ou voz,transferênia de arquivos, notiação, loalização e mapas esistemas

interativosemultimídias sãomerosexemplosdeapliaçõesdesenvolvidasparaesteambiente.

Além disso, a omuniação pode ser feita por diferentes protoolos de omuniação, omo o

IEEE 802.11 (também onheido omo WiFi), Bluetooth, IEEE 802.16 (WiMAX), GPRS

e outros. O meio sem o, no qual a omuniação é feita, é também susetível a variações

dramátias eimprevisíveis naqualidade do analde transmissão dedados.

Com toda essa heterogeneidade, é difíil riar espeiações estátiaspara qualquer tipo

dehardwareesoftwaredeomputaçãomóvel. Projetistas edesenvolvedoresdevemonsiderar

limitaçõesno hardware, demandas de segurança e QoS dosoftwaree propriedades do

proto-olo de omuniação. QoS (Quality of Servie), tradução de qualidade de serviço, signia

métrias que devem ser respeitadas para que uma apliação provenha suas funionalidades

mínimas. Como toda essa informação nem sempre está disponível, soluções integradas e

adaptativasparadispositivosmóveis sãodesejáveis.

Neste ontexto, a espeiação de protoolos de segurança se torna uma preoupação

importante. Do ponto de vista do sistema, ada apliação pode não apenas ter diferentes

neessidades de segurança, omotambémdiferentes demandas de QoS. Já doponto devista

da apliação, ela pode estar sendo exeutadaem hardware om diferentes apaidades, bem

omo sobre diferentes protoolos de omuniação. As atuais soluções nativas dos protoolos

de omuniação,omoaspresentesno IEEE802.11enoBluetooth, propoemsoluções

onhe-idamenteinompletasoufalhas(Karygiannise Owens ,2002 ), alémdeseremfoadasapenas

na amada deenlae da pilhade protoolos.

Umasoluçãoomumenteapliadaaesteproblemaéaadoçãodemeanismosdesegurança

naamadadeapliação, originalmente desenvolvidosparaomputadoresdemesaeapliações

na Internet. Essaabordagemnemsempreébemsuedida,àmedidaqueosdesaospostados

pelos dispositivos móveis são diferentes daqueles de apliações onvenionais da Internet e,

(15)

apa-idades de hardware. Meanismos de segurança desenvolvidos paraapliações onvenionais

de Internet normalmente não onsideram as propriedades distintas do meio sem o, que são

importantes fontesde informaçãoque dizem respeito aoambienteloal(Li etal. ,2006 ).

Parasuperarosproblemasrelaionados àheterogeneidade dehardware, softwaree

omu-niação, odesenvolvimento demiddlewaretem setornadoprátiaomum. Ummiddlewareé

umaamadadeprogramaçãoquemediaaomuniaçãoentreapliaçõesediretivasdesistema

de maisbaixos níveis,omo aesso à rede. Seu papel é prover à apliação diretivas para

in-teração transparente om o sistemadistribuído subjaente(Rohaetal., 2007 ; Capra etal.,

2001 ).

1.1 Objetivo

Neste trabalhoépropostoummiddlewaredesegurançaadaptativoquealteradinamiamente

osprotoolosdesegurança usadosentredoisparesomuniantes, deaordoomvariaçõesem

umonjuntodeparâmetros. Oserviçoemquestão,nomeadoASeMid,siglaparaotermoem

inglêsAdaptiveSeurityMiddleware,monitoraparâmetrosrelaionadosàsondiçõesdomeio

semo,usodereursosdosistema,apaidadesdehardwareedeniçõesdaapliaçãoquantoa

métriasdeQoSeníveisdesegurançadesejados. Émantidaumagrandeoleçãodeprotoolos

de segurança que podem ser usados, e o mais viável para ada transmissão é esolhido de

aordo om os parâmetros monitorados. Apliações aessam o middleware de uma forma

transparente, omo um soquete de rede tradiional, não iente dos protoolos de segurança

apliados. A idéia deste trabalho não é desenvolver novos algoritmos de segurança, mas sim

usar os existentes da maneira mais eiente possível, om base no Prinípio de Proteção

Adequada (Peeger e Peeger ,2006 ),quedizquesedeveapliarasegurança adequadapara

ada tipode dado eontexto. Osresultados obtidos mostram a eáia dasolução.

É também proposta e testada uma integração do middleware omum meanismo

desen-volvido pelo aluno de mestrado do DCC/UFMG Daniel N.O. Costa (Costa , 2008 )que tem

omo objetivo promover uma análise semântia de tipos de dados estruturados, de forma a

determinar diferentesrequisitosdesegurançaparadiferentespartesdodado. Sãoomparados

osresultados om esem a análisesemântia dosdados.

A seguirsãoapresentadas a motivação e ontribuição do trabalho, osfundamentossobre

segurança emredesusados no textoeostrabalhos relaionados.

1.2 Motivação

Asprinipais motivaçõesparaestetrabalho surgemda heterogeneidade de dispositivos,

apli-açõese protoolos de omuniação existentes nomeio móvele sem o,omo expliitado no

omeçodesteapítulo. Diantedisso,odesenvolvimentodomiddlewarejáébenéonosentido

de proverumaúnia amada desegurança para diferentes ontextosde hardware, softwaree

(16)

Alémdisso,otrabalhotoanumponto importanteaoseproversegurançaparaapliações

móveis: arelaçãousto/benefíioentreproversegurançaemanteraqualidadedeomuniação

edesempenhodosistema. Omiddlewaretemoobjetivodetrabalharsobreessarelação,

man-tendoo equilíbrio entre segurançae desempenho deaordo omoongurado pelaapliação

sobrejaente.

Asaraterístiasdomeioemqueumdispositivoestáinseridomuitasvezessãopoderosas

fontesdeinformação(Lietal. ,2006 ). Comisso,autilização deparâmetrosdediversasfontes

(apliação,meio semo,reursosdosistema)éumaabordageminteressanteparaseriar um

meanismo adaptativo e quesejasensívelàsmudanças noontexto.

1.3 Contribuição

Asontribuiçõesdeste trabalho são:

•

Denição do problemade seleionar protoolos de segurança om baseem métriasde

segurança (forçariptográa)e usode reursos(proessamento, memória erede);

•

Proposição de uma metodologia para tratamento do problema, dividida em estágios e

om objetivode não proporionarumoverhead onsiderável ao sistema;

•

Desenvolvimentodeumaimplementaçãodereferêniadomeanismoproposto,naforma

deummiddleware, prontoparaserexeutadonoambienteLinuxedeódigofailmente

portável paraoutrossistemas;

•

Avaliação da solução quanto a sua adaptabilidade emrelação a mudanças no ontexto

de exeução;

•

Integração da solução propostaomumsoftwarede análisesemântia de dados;

•

Avaliaçãodasoluçãoomanálisesemântiadosdados,emomparaçãoomomeanismo

sem a mesmaanálise.

1.4 Organização do Texto

Este doumento é organizado da seguinte forma. Fundamentos teórios e trabalhos

relaio-nadossãoapresentadosnoCapítulo 2 . NoCapítulo 3sãodisutidososmodelos onsiderados

para rede, algoritmos e protoolos de segurança e parâmetros e métrias onsiderados, bem

omo um detalhamento do problema tratado pelo middleware. O middleware em si é

apre-sentado no Capítulo 4, om detalhamento de suas funionalidades, projeto e arquitetura e

lógia de tomada dedeisões. Os resultados experimentais sãodisutidos no Capítulo 5. No

(17)

Fundamentos Teórios

Neste apítulo são apresentados alguns fundamentos teórios deste trabalho. Serão

apre-sentados alguns tópios fundamentais om o objetivo de eslareer suposições do trabalho

e omo ele se enaixa nas áreas da Ciênia da Computação estudadas. Para estudos mais

aprofundados sobre osfundamentos, é indiada emada subseçãoumabibliograa didátia.

2.1 Pilha de Protoolos de Rede

NaáreadeRedesdeComputadores, aespeiaçãoedesenvolvimentodeprotoolosderedeé

normalmente feitaapartirdeumaarquiteturaemamadas. Destaforma,diferentesamadas

de software têm funções espeías, om o objetivo de alançar modularidade, failidade de

implementação e modiação de ódigoe separaçãode funções.

Nonaldadéadade70surgiuentãoomodeloOSI,sigladotermoeminglêsOpenSystems

Interonnetion BasiReferene Model ou simplesmenteOSI Model, queserviu de basepara

grande partedossistemas deredes de omputadores desdeentão.

Hoje em dia, a pilha de protoolos TCP/IP se tornou muito difundida, devido ao fato

de ser a arquiteturade rededa Internet. O padrãoTCP/IP não segue a espeiaçãoOSIà

risa, mas sebaseia nela. A Figura2.1 mostraum esquemada pilha de protoolos TCP/IP,

omparadaaomodeloOSI.AFigura2.2mostraalgunsdosprotoolosusadosemadaamada

do modelo.

Alógiapropostanestetrabalhopodeseradaptadaeimplementadaemdiferentesmodelos

de rede, eusamosaqui omodeloTCP/IP omo exempliação domodelomaisdifundido. A

implementação de referênia, usada para os experimentos e disutida na seção 4.5, oloa o

middleware entre as amadas de apliação e transporte do modelo TCP/IP. Além disso, ele

interage oma sub-amada de aessoao meio (MAC),da amada de enlae (ou de interfae

de rede), araterizando-o omoum software queutiliza ruzamento de amadas, do inglês

ross-layerdesign (Shakkottai etal.,2003 ). AFigura2.3ilustraomoomiddlewareproposto

neste trabalho seenaixa napilha de protoolos do modeloTCP/IP.

Paraumestudoaprofundadosobreprotoolosderede,modeloOSIemodelosdeamadas,

(18)

Figura2.1: Camadas do modeloTCP/IP omparadas aomodelo OSI

Figura2.2: Protoolos maisfamososusados no modeloTCP/IP

da obrade Tanenbaum(2002 ).

2.2 Serviços de Segurança

Ouniversode segurançaemomputaçãoonta umagrandequantidadede diferentes

aborda-gens eténias. Segurançapodesertratada emdiferentespartes de umsistema

omputaio-nal, omo por exemplo:

•

Software: téniasdedesenvolvimentoe engenhariadesoftwareparaprevenir ataques

e erros queausam brehasde segurança, bemomo tratamento de softwaremaliioso

(19)

Figura2.3: Loalizaçãodo middlewareproposto napilha de protoolos TCP/IP

•

Sistemas Operaionais: desenvolvimento de sistemas que fazem de forma segura

tarefasomoexeuçãodemúltiplosprogramas,gereniamentodememória,autentiação

de usuáriose outros.

•

Banos de Dados: manter dadossensíveis deforma segura, impedindo queviolações

de ontrole de aessooorram.

•

Redes: garantir que troas de dados entre elementos distintos sejam seguras e não

ausem danos, perdasou vazamento deinformações,tanto doponto de vistadosdados

quanto dosdispositivos.

Este trabalho é direionado para asegurança em redes, tratando, portanto, da

omu-niação entrediferentesdispositivosomputaionais. Apesardaimplementação dereferênia

queiremos proporonsiderar váriosaspetos desegurança de software, opropósito do

traba-lhoéoestudo eavaliaçãodaténiadesegurança emrede, podendoelaserimplementadade

diversasmaneiras.

Um meanismo de segurança pode ter qualquer um dos seguintes objetivos: prevenção,

deteção e ação. O primeiro india que osistema em questãotem o propósito de evitar que

falhas de segurança oorram. O segundo aontee quando o sistema tenta detetar brehas,

falhas e ataques a um dispositivo, rede ou sistema de software. Por m, o último objetivo

onsiste no sistema que exeutaações espeías ontra ataquese brehas de segurança, no

(20)

Ao abordar segurança preventiva em redes de omputadores, podem ser providos os

se-guintes serviçosde segurança:

•

Autentiação: asserção da identidade deumaentidade queenvia dadospelarede.

•

ControledeAesso: garantiadequediferentespartesdeumsistema(dados,diretivas,

omandos, et) são aessadassomente por entidades quepossuemnívelde aessopara

tal e que, reiproamente, uma entidade só possua aesso para as partes que lhes são

permitidas.

•

Condenialidade: garantia de que dados serão lidos somente pela(s) entidade(s) a

quem sãodestinados.

•

Integridade: ertiação de quedados alançarãoseudestinosem sofrerem

modia-ções.

•

Não-repudiação: erteza que nenhuma das partes envolvidas em uma omuniação

irá negar seus serviços (aeitação de onexões, envio de dados, aesso a reursos, et.)

aso tenhareursosdisponíveispara tal.

Estetrabalhopropõeumsistemadesegurançaquepodeserusadopor virtualmente

qual-quer tipo de apliação. Dado suanatureza genéria, este trabalho provê os serviços de

au-tentiação, ondenialidade e integridade. Os serviços de ontrole de aesso e

não-repudiaçãogeralmenteneessitamdemaior onheimento sobreaapliaçãoespeíaemque

estão inseridos, para que possam ser providos. No intuito de manter a simpliidade da

in-terfae domiddleware propostoom asapliações, estesdois serviços não sãotratadosneste

trabalho.

Por m, podemos listar asategorias de possíveisataques a umsistemade redede

om-putadores:

•

Ataques Passivos

-Espionagem 1

: aomuniaçãoéouvida porumaentidadenãoautorizadaedados

sensíveis sãorevelados.

- Análise de Tráfego: o padrão de omuniação (número de mensagens, tamanho,

duração, et) é analisado por umaentidade maliiosa que infere informações

onden-iais apartir dessa análise.

•

Ataques Ativos

- Masaragem 2

: umaentidademaliiosaassumeumafalsaidentidade,sepassando

por umaentidade onável, e tendoaessoa dadose diretivasnão autorizadas aela.

-Reenvio: oinfratoraptamensagensenviadasnaredeeasreenviaemummomento

posterior, ausando algum tipo de resposta dasentidades que, por sua vez, irá ausar

umafalha desegurança.

1

Eminglês, éusadootermoeavesdropping.

(21)

- Modiação: entidade maliiosa aptura mensagens enviadas, impede que elas

heguem ao seu destino, modia seus onteúdos e então as reenvia, podendo assim

ausar perdadeinformação e induzirfalhas desegurança.

- DoS 3

:aontee quandoo infrator exaure osreursos de umadada entidade, até

que elanão onsiga maisatender arequisitos de entidades legítimas.

Estetrabalho nãofoaemnenhumtipodeataqueespeío,esimnosserviçosabordados

anteriormente. Ao prover os serviços de segurança de forma eaz, o sistema aaba por

tratar ada um dos ataques listados aima. Por exemplo, o serviço de ondenialidade

está diretamente ligado aoataque de espionagem,enquanto que ode integridade está ligado

ao ataque de modiação. A ombinação dos três serviços fundamentais (ondenialidade,

integridade e autentiação), que são os providos pelo middleware proposto neste trabalho,

permite,assim,tratar de ada umdostiposde ataquesaima.

Paraumestudodetalhadosobreserviçosdesegurança,tiposdesegurançaemomputação

e debates sobre sua administração, questões étias, privaidade e outros tópios da área,

reomenda-se otrabalho didátiode Peegere Peeger (2006 ).

2.3 Primitivas Criptográas

A riptograa é a base da maioria dos serviços de segurança. Ela onsiste em ténias para

odiar um dado de forma que entidades não-autorizadas não onsigam deifrá-lo, mas ao

mesmotempogarantindoqueoreeptorpretendidoonsiga. Ariptograa temumaextensa

história que data desde a antiguidade. Um estudo sobre a história da riptograa pode ser

enontrada no trabalho de Kahn (1996 ). Não está no esopo deste trabalho a disussão de

algoritmos individuais de segurança, inluindo possíveis falhas ou qualidades dos mesmos.

Como será expliado adiante, o middleware proposto pode ser ongurado para operar om

o onjunto desejado de algoritmos, inluindo somente os onáveis pelo administrador do

sistema.

OsprinipaistiposdediretivasriptográassãomostradosnaTabela2.1 . Aseguir,ada

tipo de diretiva é desrita em maisdetalhe. Para um estudo mais aprofundado de diretivas

riptográas, bemomodetodasasténiasealgoritmositamosnessaseção,

reomendam-se ostrabalhos de Stallings (2005 )e Peeger ePeeger (2006 ).

Algoritmos de riptograa

Osalgoritmosderiptograaonsistemnotipomaisbásiodediretivasriptográas. Têmo

objetivoderiptografarederiptografardados. Osalgoritmosmodernossãotodosbaseadosno

usodehaves. Umahavederiptograa éumbloodedado detamanho pré-denidousado

noproessoderiptaçãoederiptaçãododado. Dessaforma,parapoderdeodiarumdado

riptografado, éneessáriaahave orrespondenteausadanoproesso deodiação. Ouso

de haves éproveitoso pois omeanismo usado na riptograa pode ser de domíniopúblio,

(22)

Diretiva Serviço provido Exemplosde al-goritmos Usado pelo middleware Criptograa de have simétria

Condenialidade DES,3DES,AES,

RC4, RC2

Sim

Criptograa de

have públia

Condenialidade RSA,ECC Sim

Distribuição de

haves

Neessário para

qualquer

algo-ritmo que use

haves

Die-Hellman,

troa

deentrali-zada, publiação

de have públia

Sim

Medidas

on-tra análise de

tráfego 4

Condenialidade padding e salting Não

Funçõesde hash Integridade MD5, SHA-1,

Whirlpool

Sim

Algoritmos MAC Integridade HMAC-SHA-1,

HMAC-MD5, CMAC-DES, CMAC-AES Sim Assinaturas digi-tais

Autentiação DSA, ECC-sign,

RSA-sign,

RSA-priv

Sim

Controle de meio

sem o 4

Condenialidade Saltos de

freqüên-ia, ontrole de

potênia derádio

Não

Tabela2.1: Tiposdediretivasriptográas

enorajando assim odesenvolvimento edivulgação de meanismos maisfortes,enquanto que

a partesereta doesquema a sendoa have usada.

Osalgoritmos de riptograa modernos podemser lassiadosquanto aotipode haves

utilizadas, em: algoritmosdehavessimétrias,algoritmosdehavesassimétrias. Os

primei-ros utilizam umamesma have tanto parariptografar quanto paraderiptografar osdados.

Esses algoritmos geralmente são rápidos e eientes, mas riam o problema de se enontrar

umamaneiraseguraparadistribuirashavesseretas. Osdosegundotipo,também

onhei-dos omoalgoritmos de have públia,utilizam umpar de haves. Umdado é riptografado

om uma have do par e deriptografado om a outra. Com isso, uma das haves de uma

erta entidade normalmente é a have privada, sendo ela sereta. A have públia, por

sua vez, pode ser divulgada para todos. Se uma entidade A deseja enviar um dado para a

entidade B, elariptografa o dadoom ahave públia de B.A entidade B,por suavez, éa

úniadetentoradahaveprivadaqueiráderiptografarodadoreebido. Essesalgoritmossão

geralmente omputaionalmente pesados e utilizadosem operaçõesde distribuiçãode haves

4

(23)

simétrias ouautentiação depaotes, desritasaseguir.

Outra lassiação de algoritmos de riptograa é quanto ao tamanho de dados em que

eles operam. A grande maioria dos algoritmos atuais são ifras de bloo pois trabalham

em bloos de dados detamanhos pré-determinados. Mensagens longas devem serquebradas

e (de)riptografadas bloo a bloo. Um outro tipo, mais omum em algoritmos de have

simétria, sãoasifrasde uxo, oustream iphers,que trabalham nodado bita bit. ORC4

é umexemplo dealgoritmo deuxo.

Distribuição de haves

Algoritmos que usam haves riam o problema de omo distribuir essas haves. Se uma

have sereta é enviada por um anal aberto, um intruso pode failmente intereptar essa

omuniação e ter onheimento do valor da have. Dessa forma, é preiso que se tenham

métodossegurosparaadistribuiçãodehaves. Primeiramente,épreisoonsiderarquehaves

assimétriasesimétriaspropõemdiferentesdesaosdedistribuição,devidoàssuasdiferentes

naturezas. Em segundo lugar, pode existir uma have mestra que é um valor qualquer,

possivelmente na forma de umasenha emtexto, que osdois lados de uma omuniação têm

onheimento a priori. A existênia deumahave mestrafailita oproesso de distribuição.

Se tratando de haves assimétrias, somente haves públias devem ser divulgadas. Isso

propõe uma maior failidade, pois pode-se simplesmente publiar as haves públias. No

entanto, dependendo do enário emque uma entidade se enontra, pode haver problema de

falsiação de identidade, om entidades publiando haves enquanto armam serem outras

entidades. Esserisoémuitasvezesresolvidoomténiasquesupõemaexistêniade

entida-des entrais,reguladoras, que atestamautentiidade. Essetipode ténia nãoé onsiderada

nessetrabalho,umavezqueeleéfoadoemredesadho. Casoexistaumahavemestraentre

entidades omuniantes, pode-se usar um esquema de distribuição deentralizada, usando a

have mestraom algumalgoritmo dehavesimétria.

Chaves simétrias apresentam um problema maior de distribuição. No entanto, ao

on-trário das assimétrias, as haves simétrias podem ser geradas mais failmente, podendo

ter qualquer valor dentro do tamanho de have espeiado. Com isso, na presença de uma

have mestra, além de se poder usar o esquema de distribuição deentralizada previamente

menionado, pode-setambémderivarumahavesimétriaapartir dahave mestra,demodo

que todas as partes envolvidas gerem a mesma have sem a neessidade de omuniação.

Caso não exista uma have mestra, o meanismo mais usado onsiste em alguma apliação

de algoritmos de haves assimétrias(previamente distribuídas) paratransmitirem ashaves

simétrias. Além disso, existem esquemas omo o Die-Hellman, que usam ténias

pare-idas om as de algoritmos de have assimétria para gerar haves simétrias idêntias em

duas entidades distintas, troando apenas informações insuientes para umintruso deduzir

(24)

Medidas ontra análise de tráfego

Alémdasmedidasbásiasderiptograa, hasheseódigosMAC(disutidosadiante),pode-se

tambémadotarmedidasespeíasontraanálisedetráfego. Essasonsistemprinipalmente

na ténia de tra padding (enhimento de tráfego), que onsiste em adiionar bits entre

mensagens ou ampos para tornar difíil a análise baseada em volume de omuniação, e

também o message salting (salgamento de mensagens), que onsiste em onatenar bits

(salt,ousal)aonaldemensagensantesdoproessoderiptação, omoobjetivodediultar

análises de mensagensde tamanhoxo. Por exemplo,duasmensagens idêntiasproduziriam

o mesmo dado riptografado. Com a adição do sal antes de riptografar, elas produzem

resultados diferentes, enganando aentidade maliiosa.

Como este trabalho apresenta um meanismo que proura o equilíbrio entre segurança

e uso de reursos (CPU, memória, rede), não onsideramos essas duas ténias de medidas

ontra análise de tráfego. O overhead ausado por essas ténias pode ser prejudiial para

determinados ontextosde omputaçãomóvel,omo emondiçõesde máqualidade deanal

de transmissão.

Funções hash

Sãofunçõesquetrabalhamsobreumonjuntodedadoseproduzemumbloodetamanhoxo,

geralmentemenor que a mensagem em si. Não possuem have e produzem sempre a mesma

saída para ummesmo dado. Dessaforma, sãoúteis paraveriara integridade de umerto

dado. Oódigohashdeumamensagempodeseronatenado aonaldamesma,eoseuvalor

veriado peloreeptor. Éuma dasdiretivasriptográas maislevesomputaionalmente.

Algoritmos MAC

São semelhantes aos ódigos hash, mas a diferença prátia é que os ódigos MAC utilizam

haves. Os HMAC trabalham em onjunto om alguma função de hash, enquanto que os

CMAC trabalham em onjunto om algum algoritmo de riptograa. São mais difíeis de

serem quebrados queosódigos hash.

Assinaturas digitais

São téniasparagarantir aautentiidadede umaentidadetransmissora. Amaioria das

té-nias onsisteemriptografar mensagens,hashes ouódigosMACusandoahave privadado

transmissor. Oreeptorderiptografaoblooemquestãoomahavepúbliadotransmissor,

e om issoassegura sua identidade, sabendo que sóele pode ter feito a riptograa daquele

dado. Variações dessaténia usandodiretivasdosalgoritmos de havesassimétrias RSA e

ECC sãoomuns. OutraténiaomumsãoalgoritmosomooDSA,queproduzemumbloo

(25)

Controle de meio sem o

Em redes sem o, pode-se usar ontrole relaionado ao meio de transmissão para garantir

maior ondenialidade. O salto ontínuo de freqüênias ou anais de omuniação

(fre-queny/hannel hopping) é útil pois diulta o trabalho de um intruso tentar espionar no

anal de omuniação. Outra ténia omumé oontrole da potênia do rádio de

transmis-são, de forma que mensagens tenham potênia para alançar distânias não maiores que as

do reeptor da mensagem. Como este trabalho propõe um meanismo adequado a

diferen-tes tenologias de transmissão, foi optado por não trabalhar om ontrole de meio sem o,

dependente da tenologia espeía paraaqual é apliado.

2.4 Trabalhos Relaionados

Meanismos de segurança padrões para redes sem o têm sido amplamente estudados, om

suasfalhas disutidasna literatura. Patiyoot e Shepherd(1999 )disutemasprinipais

téni-as riptográaspararedes semo,inluindo oIEEE 802.11, ATMsemo,GSM, UMTSe

outras. Umestudodetalhado dasfalhas evulnerabilidades dosserviçosde segurança nativos

providos pelo IEEE 802.11(onheido omoWiFi) e pelo Bluetooth pode serenontrado no

trabalho de Karygiannise Owens (2002 ). Bhagyavatiet al. (2004 ) analisam ténias de

se-gurança para o protoolo IEEE 802.11 e suas variações (IEEE 802.11i e a família 802.1X) e

Patiyoot (2002 )estuda problemas desegurança emredesATMsem o.

Alguns estudos enontrados na literatura identiaram abordagens espeiais para

pro-mover segurança em ambientes sem o, apontando desaos para alançá-los. Alguns desses

desaosinluemoproblemadaapaidadedeproessamentorestritadosdispositivosmóveis,

omo apontado por Ravietal. (2002 ). Desaos espeíos em relação ao protoolo IEEE

802.11 sãodisutidos por Arbaugh (2003 ) e Potter (2006 ), omo últimofoando nospontos

de aesso, ouhotspots.

Propostas têmsido feitasna tentativade promoversegurança onsiderando propriedades

da omputação móvel. Solimane Omari (2005 ) propõem um sistema riptográo foado

no domínio móvel, usando algoritmos de ifra de uxo. Mais reentemente, Lietal. (2006 )

propuseramumsistemaqueusaaspropriedadesdosinalderádioparaautentiaçãoe

onden-iabilidade naamada físiadapilha deprotoolos, delineandoaneessidade de setrabalhar

om projetoemmúltiplas amadas nessetipode enário.

Tripathi (2002 ) disute requisitos e desaos de projetar um sistemado tipo middleware.

Em(Capraetal. ,2001 ;Masolo etal.,2002a )osautoresidentiamnovosrequisitosparaum

middleware que suporta mobilidade, disutem as prinipais diferenças entre os meios sem e

omoeategorizameanalisamalgumaspossíveissoluçõesparaummiddleware móvel. Eles

também propõem o uso de um middleware reexivo para omputação móvel (Capraetal.,

2002 ) edesrevemum exemplopararedes ad ho (Masoloetal., 2002b ). Em (Capraetal.,

(26)

on-Alguns exemplos de propostas onretas de middleware de segurança também são

apre-sentadosnaliteratura. Foadoemredesabeadas, Foley etal.(2004 )propõemumarabouço

para inter-operação om middleware de serviçosWeb padrões, omo .NET, CORBA e EJB.

Foado no meio sem o, Corradi etal. (2005 ) desrevem um middleware que lida om

pro-blemasde ontrolede aessousandoagentes móveispara aessarredesabeadasemnomede

usuários móveis queseenontram forade alane outemporariamentedesonetados.

Até a data de onfeção deste doumento, não foi enontrado na literatura um trabalho

existente quepropõe aesolhadinâmia deprotoolos desegurança deaordoomondições

(27)

Modelos e Denições

Neste apítulo apresentamos alguns modelos onsiderados para este trabalho. São também

denidos termoseoneitosutilizadosaolongodotexto,bemomoumadeniçãosuintado

problema aser resolvido.

3.1 Modelo de Rede

O sistema proposto neste trabalho onsidera uma rede ad ho, sem pressupor nenhum tipo

de infra-estrutura. Essaredepossuiumadistribuição heterogênea dedispositivos,apliações

desoftwaresendoexeutadaseprotoolos deomuniação sendousados. Dispositivospodem

ser móveis e omeio sem o podesofrer interferênia evariaçõesna latêniade omuniação.

Abaixosãoapresentados exemplosde elementosdessa rede:

•

Dispositivos de hardware: aparelhos elulares om pouos KBytes de memória e

proessadores limitados, PDAs (Personal Digital Assistant, também onheidos omo

palmtops)omapaidadesdeproessamentoememóriavariáveis,laptopsom

Gigaby-tes dememória e proessadoresde maior desempenho.

•

Apliaçõesemsoftware: apliaçãoWebomrajadasdeomuniaçãointensaseguidas

de momentos depausa, uxosdevídeo ouáudioomintensa omuniação bidireional,

transferênia dearquivosom paotesde tamanho xo.

•

Protoolos de omuniação: WiFi (IEEE 802.11, om ousem meanismosde

segu-rança nativos,omo WEPou WPA), Bluetooth,WiMAX, GPRS.

3.2 Algoritmos e Protoolos de Segurança

Existe uma erta ambigüidade na literaturaem relaçãoaostermos algoritmo de segurança

e protoolode segurança. Primeiramente, vamosanalisar deniçõesdostermosalgoritmo e

(28)

algoritmo 1

: substantivo,al.go.rit.momasulino (plural: algoritmos)

1. (Matemátia)Conjuntoderegrasneessáriaspararesoluçãodeumproblemaouálulo.

2. (Informátia) Proesso omputaional bemdenido, baseado num onjunto de regras,

que exeutaumadeterminada tarefa.

protoolo: substantivo próprio, pro.to.o.lomasulino

1. Conjuntode regrasa observar emmatériade etiqueta,omoasseguidasemerimnias

oiais.

2. Proesso verbal reunindo asresoluçõesde umaassembléia, de umaonferênia.

3. (Informátia) Código (linguagem) utilizado entre dois sistemas (omputadores) para

omuniarementre si. A identiaçãode umdoumento.

4. (Ciênia)Conjunto deregras, deondiçõesrelativasaodesenrolar deumaexperiênia.

Analisamosentãodeniçõesmaisespeíasdentrodaliteraturaientía. SegundoSavage

(1987 ) eGurevih (2000 ),um algoritmoé umproessoomputaionaldenidoporuma

má-quina de Turing. Já ThayerFabrega etal. (1998 ) dizem que um protoolo de segurança é

uma seqüênia demensagens entreduasou maisentidades naqual riptograa é usadapara

prover autentiaçãoou paradistribuirhavesriptográasparanovassessões.

Muitas das diretivas riptográas usadas pelo middleware proposto neste trabalho

po-dem ser lassias tanto omo algoritmos quanto omo protoolos. Podemos tomar omo

exemplo o aso do esquema Die-Hellman de distribuição de haves. O esquema, proposto

por Diee Hellman (1976 ), é onsiderado umalgoritmo pois é perfeitamentedesrito omo

umproessoomputaionalseqüenial,denidonosmoldeslássiosdaomputação,seguindo

o modelodamáquinade Turing. Aomesmotempo,elepressupõe troa demensagensde

na-tureza riptográa entredois pares,araterizando-o omoum protoolode segurança.

Com isto,usaremos aolongo destetexto asseguintes denições:

Denição 3.1. Chamamos de algoritmo de segurança um proesso omputaional que

representaumaoperaçãodesegurançaatmiasobreumbloodedados,omumúnioobjetivo

riptográo. Por exemplo, odiar/deodiar o dado, gerar um ódigohash,troar umaou

mais haves riptográas.

Denição 3.2. Chamamos de protoolo de segurança um onjunto de um ou mais

algo-ritmos, de aordo om a denição 3.1, que serão apliados sobre bloos de dados em omum

aordo por duas ou mais entidades, e que juntos podem prover um oumais serviçosde

segu-rança.

Dessa forma, o esquema Die-Hellman é denido neste trabalho omo um algoritmo

de segurança. Outrosexemplos de algoritmos inluem o DES parariptograa, SHA-1 de

ódigos hash, qualquer algoritmo de ódigos MAC ou qualquer outro esquema de troas de

(29)

haves. Oaordo entre duasentidadesde publiar suashavespúblias de RSA,usar

Die-Hellman para gerar haves simétrias de 128 bits e a ada envio de dados gerar um ódigo

hash MD5, enriptá-lo om a have privada, anexar essa informação ao paote de dados e

então riptografar tudo om umtriplo DES usandoos primeiros 112 bits da have simétria

gerada, arateriza umprotoolo de segurança.

3.3 Parâmetros e Métrias

Omiddleware propostotrabalha omdiferentes valoresparapoderesolher osmelhores

pro-toolos de segurança. Esses valoressão divididos entre parâmetros e métrias e possuem

diferentes propósitos. Asdenições3.3 e 3.4ilustram omo essestermos são usados no

on-textodeste trabalho.

Denição 3.3. Um parâmetroé umvalorque arregainformaçõessobre oontexto emque

o middleware está inserido, e que é usado omo auxílio no proesso de esolha de protoolos

de segurança a seremutilizados.

Denição 3.4. Umamétriaé um valorassoiado a um algoritmo desegurança que dene

umapropriedadedomesmo. Métriaspodemdenirtantopropriedadesfunionaisdos

algorit-mos, quantopropriedadesrelaionadas aserviçosdesegurança. Umamétria deumprotoolo

de segurança representa a agregação dos valores daquela métria para ada algoritmoontido

no protoolo.

O middleware monitora parâmetros de diferentes fontes: meio sem o, apaidades de

hardware, usode reursosdosistemaediretivasde QoSe níveis desegurança vindasda

apli-ação. Os parâmetros usados no sistemaproposto são listados na Tabela 3.1. As unidades

usadas têm omo nalidade failitar no proesso de deisão de protoolos, detalhado no

Ca-pítulo 4. Dessaforma,sãoprivilegiadasunidadesperentuais,poronsistiremdevaloresom

mínimos emáximos onheidos.

Cadaalgoritmodesegurança é assoiadoa seispropriedades denidaspormétrias.

Des-sas, três são métrias de força de segurança (ou força riptográa): ondenialidade,

integridadee autentiação, e outras trêssão métriasrelaionadasa usode reursos: uso

de memória, tabelas de tempo de proessamento e de overhead de rede (em quanto o

paote dedadosoriginalaumenta detamanho). Asmétriasdeforçadesegurança são

repre-sentadas por números inteiros, de 0 a 100, uja utilidade é omparar diferentes algoritmos.

Como disutido no Capítulo 4, esses valores são denidos pelo administrador do sistema,

através de um arquivo de onguração. Por exemplo, a riptograa AES deve ter um valor

de ondenialidade maior que a DES, por ser um algoritmo oneitualmente mais forte e

seguro. A diferença entre uma mesma métria de dois algoritmos deve representar o quão

mais forteumalgoritmoé emrelação aooutro. Asmétrias deusode reursos sãomedidas,

(30)

Fonte Parâmetro Unidade

Meiosemo

Mobilidade porentagem

Qualidadedo anal porentagem

Latênia mirossegundos

Roteamento direto ou roteado

Capaidades de

hardware

Memória bytes

Informação dorádio rádio usado(WiFi,

Blu-etooth, et)

Usodereursos

Consumode memória bytes

Usode CPU porentagem

Bateria(se presente) porentagem

Apliação(QoS)

Latênia máxima mirossegundos

Máximousode memória bytes

Máximooverhead derede bytes

Máximooverhead denegoiação bytes

Apliação(níveis

desegurança)

Condenialidade níveis: desligado,

opional,desejável,

mandatório ou rítio Integridade

Autentiação

Tabela 3.1: Parâmetros usados pelomiddleware

por tabelas, om entradas para diferentes tamanhosde dados. A geração dosvalores dessas

métrias édisutida emdetalhe no Capítulo 4.

Daslistas apresentadas pode-se pereberfailmenteque ertosparâmetros se relaionam

aertasmétrias. Denimosissoomoummapeamentodeadamétriaparaumoumais

pa-râmetros de ontexto. Adenição formaldesse mapeamento éapresentadanaSeção3.4 , que

tratadaaraterizaçãodoproblema. NaTabela3.2apresentamosquaismétriassãoafetadas

por ada parâmetro onsiderado paraeste trabalho. Por exemplo, umalto índie de

mobili-dade implia em maior número de possíveis outros dispositivos na região, relaionando-se à

neessidades de ondenialidade e autentiação. No entanto, a mobilidade não serelaiona

(31)

Parâmetro Métrias

Mobilidade Condenialidade e Autentiação

Qualidade doanal Condenialidade,Integridadee Rede

Latênia Proessamento

Roteamento Condenialidade e Autentiação

Capaidade dememória Memória

Informação dorádio Condenialidade,Integridadee Autentiação

Consumode memória Memória

Usode CPU Proessamento

Bateria Proessamento, Rede e Memória

Latênia máxima (QoS) Proessamento

Memóriamáxima (QoS) Memória

Máximooverhead de rede(QoS) Rede

Máximooverhead emnegoiações(QoS) Rede

Nívelde ondenialidade Condenialidade

Nívelde integridade Integridade

Nívelde autentiação Autentiação

(32)

3.4 Caraterização do Problema

Com as denições apresentadas nas seçõesanteriores podemos araterizaro problema aser

tratadopelomiddlewareproposto. Primeiramente,vamoslistartodososelementosenvolvidos

no problema:

•

Umonjunto de protoolosde segurança, deaordo oma denição 3.2 .

•

Cada protoolo possui um onjunto de métrias, om seis elementos, disutidos na

Seção3.3 .

•

Um onjunto de parâmetros relaionados ao ontexto de exeução, disutidos na

Se-ção 3.3.

•

Sabemos que ada parâmetro está diretamente ligado a pelo menos uma métria, de

aordo oma Tabela3.2.

Com isso,podemos formalizaroselementos do problemae suasrelaçõesna denição 3.5.

Denição 3.5 (Elementos do problema). Seja

S

o onjunto de protoolos de segurança

dis-poníveis. Denotamos

M

i

o onjunto de métrias do protoolo

S

i

, sendo

M

i,j

a métria

j

do

referido protoolo. Denotamos também

P

omo o onjunto de parâmetros relaionados ao

ontexto de exeução. Sabemos que ada métria

M

i,j

é mapeada a um ou mais parâmetros,

para todo protoolo

S

i

, ou seja:

∀

j

∃

k

∀

i M

i,j

7→

P

k

A existênia ou não demapeamento entre uma métria e um parâmetro é sabida a priori.

Sabemos que o onjunto de métrias de ada protoolo é formado pelas métrias:

on-denialidade, integridade, autentiação, memória, proessamento e rede. Por onveniênia,

hamaremos essasmétrias

c

,

i

,

a

,

m

,

p

e

r

. Comisso,estendemos ooneitodeprotoolode

segurança, apliando-o maisao problematratado,na denição 3.6 .

Denição 3.6 (Protoolo de segurança, no ontexto do problema). Sobre o onjunto

M

i

de

métrias doprotoolo

S

i

, sabemos que:

∀

i M

i

=

{

c

i

, i

i

, a

i

, m

i

, p

i

, r

i

}

Simpliando, podemos denotaradaprotoolo

S

omo uma 6-tupla:

S

= (c, i, a, m, p, r)

Por m, denimos que ada uma das seis métrias tem um valor normalizado, om todas

no mesmo intervalo, onsistindo de números inteiros. As métrias

c

,

i

e

a

representam a

força riptográa do protoolo, om valores mais altos sendo mais desejáveis, enquanto que

as métrias

m

,

p

e

r

representam usode reursos desistema,portantosendo osvalores mais

baixosos mais desejáveis. Se espeiarmos

Q

omo a qualidade deum protoolo, podemos

dizer que:

Q

∼

_c

₊

_i

₊

_a

(33)

No entanto, ésabido que protoolos riptograamente mais fortestendem ausar mais

reur-sos desistema, riando a relação:

c

+

i

+

a

∼

m

+

p

+

r

Fazendo

Q

tender a 1 para a maioria dos asos.

Da denição aima podemos identiar o problema a ser resolvido. O objetivo do

mid-dlewarepropostopassaaserodeseleionar,emtemporeal,omelhor protoolodesegurança

paraumdadoontexto. Noentanto,seguedadeniçãoqueosníveisdequalidadedos

proto-olos,seguindoasmétriasusadas,tendeasersemelhanteparatodoouniversodeprotoolos.

Com isso, a informação da denição 3.5 sobre o mapeamento de métrias a parâmetros de

ontexto passa a ter importânia signiativa na tentativa de resolver o problema. Assim,

formalizamos o problemaa sertratado neste trabalho na denição 3.7.

Denição 3.7 (Problema da esolha de protoolos de segurança em tempo real,no modelo

de forçariptográa e usode reursos). Tendo um onjunto

S

de protoolos, de aordoom

a denição3.6,esolher oprotoolomaisadequado para umdeterminadoontexto. Étambém

onheidoumonjunto

P

deparâmetrosdeontexto,e relações demapeamentoentre métrias

dos protoolos e parâmetros de

P

, de aordooma denição 3.5.

A abordagem tomada, bem omo a geração de protoolos e métrias, obtenção de

(34)

O Middleware Proposto

Comodisutidoanteriormente,oprinipalobjetivodomiddlewarepropostonestetrabalhoéo

de esolher dinamiamente oprotoolode segurança maisadequado paraomuniação entre

dois pares. O protoolo esolhido pode ser troado durante a exeução, aso as ondições

de ontexto variem. Em termos gerais, o middleware busa esse objetivo mantendo uma

bibliotea de algoritmos de segurança existentes, avalia-os de aordo om as seis métrias

denidas e monitora parâmetros de ontexto para serem usados no proesso de tomada de

deisões.

Nesseapítulodisutimos a solução proposta. Primeiramente apresentamos omo o

mid-dleware pode ser ongurado por usuários, omo administradores de sistema ou apliações.

Depoisapresentamos a arquitetura, e entãoos algoritmosda lógiade seleçãode protoolos.

Mostramos ainda a extensão de análise semântia dos dados e nalmente disutimos nossa

implementação de referênia.

4.1 Conguração do Middleware

Um arquivo de onguração é lido pelo middleware toda vez que ele é iniializado. Esse

arquivo ontém a bibliotea de possíveis algoritmos de segurança a serem usados. Cada

entrada no arquivo representa um algoritmo e informações sobre ele, inluindo aíos valores

dasseismétrias. Osvaloresdasmétriasdeusodereursossãoautomatiamentealulados

egeradosduranteainstalaçãodomiddleware(Seção4.3.1 ). Oomportamentodomiddleware

podeser onguradodasseguintes formas:

1. Editando o arquivode onguração e nele exluir quaisqueralgoritmos quenão devem

ser usados.

2. Ainda no arquivo de onguração, editar os valores das três métrias de força

ripto-gráa deada algoritmo, denindo oquanto um algoritmo émais fortequeoutro.

3. Em tempo de exeução, a apliação pode denir os parâmetros relaionados a níveis

(35)

limites de QoS (latênia, uso de memória, overheads de rede por paote e tempo de

negoiação).

Dessaforma,aapliaçãoe/ou administradordosistemapodemgarantirqueomiddleware

irá exeutar apenas algoritmos que eles onam, e ainda denir quaisdeles são maisfortes.

A apliação irátambém denir níveis de segurança mínimosde formaindependentepara os

três serviçosdesegurança, além daslimitaçõesdeQoS. Se,por exemplo,aapliação deneo

nível de ondenialidade para mandatório,isso signia que o middleware sempre utilizará

um protooloqueinluiriptaçãodedados. Opionalmente,aapliação(ambososseuslados

narede)podetambémsuprirumasenha,queseráusadaparaageraçãodeumahave mestra

riptográa.

4.2 Arquitetura

Omiddlewareédivididoemtrêspartesfundamentais: onexãosegura,máquinadesegurança

e ontrole de parâmetros. A onexão segura fornee a API paraa apliação aessar o

mid-dleware. Sua interfae é muito similara umabibliotea de rede padrão(sokets) e múltiplas

instânias podem ser exeutadas ao mesmo tempo. A máquina de segurança é responsável

por exeutar a lógia de tomada de deisões, bem omo apliar os protoolos de segurança

empaotesenviadosoureebidospelasonexõesseguras. Oontrole deparâmetrosmonitora

todososparâmetroseostornadisponíveisparaamáquinadesegurança. AFigura4.1ilustra

a arquiteturado sistema.

O módulo de ontrole de parâmetros usamétodos diferentes para adquirir ada tipo de

parâmetro. Parâmetros domeiosemosãomonitoradosporumsoftwareseparadoqueaessa

drivers de interfaes de rede sem o. A informação sobre o meio é guardada em um buer

ompartilhado om o middleware. Capaidades de hardware e uso de reursos de sistema

são obtidos através de primitivas do sistema operaional, enquanto que limitações de QoS e

níveis desejadosde segurança sãopassados pela apliação, usandoa API da onexão segura.

Éimportante observarqueosparâmetrospodemserdivididosentreaquelesquepossuemum

valorxoeosquepossuemvalorvariávelemtemporeal. Capaidadesdehardware,restrições

de QoS e níveis de segurança têm valores xos e só preisam ser adquiridos uma únia vez.

Por outro lado, informação do meio sem o e uso de reursos do sistemasão neessários em

tempo reale preisam serontinuamente monitorados.

4.3 Algoritmos para Seleção de Protoolos de Segurança

Em função de tornar a seleção de protoolos maisfáil, o middleware divide o proesso em

estágios. Cálulos e testes omputaionalmente pesados são feitos durante o proesso de

instalação no dispositivo alvo. Durante a exeução, algum overhead de proessamento é

ausadona iniializaçãodomiddleware, bemomoaoestabeleimentode adanovaonexão,

(36)

Figura 4.1: Arquitetura domiddleware proposto

o proesso de instalação) da máquina de segurança. Nas próximas subseções disutimos os

passosindividualmente.

Algoritmo 4.1Fluxode exeuçãobásio da máquinade segurança

1: Iniialização dealgoritmos e protoolos de segurança

2: Aquisiçãode parâmetros permanentes

3: para todoonexõesativasfaça

4: Fusãoderequisitospermanentes loaise remotos

5: Seleção de protoolos válidos

6: Esolha do onjunto de protoolos aserem usados

7: Esolha dosalgoritmos de troa dehaves

8: Transmissãodoonjunto deprotoolos ealgoritmosdetroa dehavesaseremusados

9: Geração etroasde havesneessárias

10: enquantoConetado faça

11: seEnvio de mensagem então

12: Seleionamelhor protoolo, de aordoom parâmetrosde temporeal

13: Apliaprotoolo eonatena seu ódigo noomeço da mensagem

14: Envia mensagem paraamadas de redeinferiores

15: senãoseReepção de mensagem então

16: Lê ódigodoprotoolousadono omeço da mensagem

17: Apliaprotoolo reverso

18: Envia mensagem paraamada daapliação

19: mse

20: m enquanto

(37)

4.3.1 Instalação

Duranteoproesso deinstalação omiddleware lêoarquivode onguração,quenesse ponto

aindanão possuiasmétriasdeusode reursosdeadaalgoritmo, ealulaosvaloresdessas

métrias. Para isso, ada algoritmo é testado om diferentes ombinações de dadose haves

gerados aleatoriamente e de diferentes tamanhos. Os tamanhos de bloos e o número de

exeuções para ada tamanho podem ser ongurados. Durante esses testes o middleware

mede o uso de memória, tempo de proessamento e overhead em bytes de ada algoritmo.

Para o uso de memória é onsiderada a média de todas as exeuções, enquanto que para

as tabelas de proessamento e overhead são onsideradas as médias de exeuções para ada

tamanho dedados. Osresultadosdasmediçõessãoentãoesritosnoarquivodeonguração,

de forma que esse proesso não tenha que ser repetido (a não ser que o sistema sofra uma

modiação dehardware, oqueinvalidaria osresultados anteriores).

4.3.2 Iniialização

Quandoo middlewareé iniializadopelaapliação, suaprinipaltarefaélere proessaro

ar-quivodeonguração. Comisso,omiddlewarelêasdeniçõesdealgoritmosdoaquivoeentão

geraumonjunto omtodosospossíveisprotoolos desegurança(vejaasdenições3.1e3.2,

pág. 15). O proedimento de geração dos protoolos respeita regras básias de onsistênia,

omo não gerar um protoolo que inlua dois algoritmos do mesmo tipo (omo uma função

hash). Além disso, são disponibilizados protoolos que não ontêm algoritmos de todos os

três serviçosriptográostratados(ondenialidade, integridadeeautentiação), inluindo

protoolos omsomenteumalgoritmo. Osalgoritmos de troa dehavessãomantidos omo

algoritmos simples e não são adiionados a nenhum protoolo. Eles são tratados de forma

um pouo diferente, omo mostrado nas próximas seções. O sistema também gera um aso

espeial que representa a ausênia de algoritmos de segurança, omo um protoolo vazio,

para asosem queneessitaráde usartransmissão aberta.

Asmétrias de ada protoolo sãogeradas através da fusãodas métrias dosalgoritmos

individuais. Paraadamétriadesegurançaéonsideradoovalormaisaltoentreosalgoritmos

presentes. Para as métrias de uso de reursos é feita a soma dos ustos dos algoritmos

individuais.

Finalmente,duranteainiialização,oontroledeparâmetros adquireosparâmetros xos.

As apaidades de hardware são obtidas do sistema operaional e nesta fase espera-se quea

apliação hameasdiretivasparadenição derestriçõesde QoSe níveisde segurança.

4.3.3 Conexão

Para ada onexão estabeleida, o middleware exeuta quatro passos básios: (1) ombinar

os parâmetros xos, (2) seleionar o onjunto de protoolos a serem usados durante aquela

onexão, (3) seleionar algoritmos para troa de haves e (4) gerar e troar as haves. O

(38)

emosdoisparestransmitiremseusparâmetrosxosemanterem,paraadaparâmetro,ovalor

maisrestritivo.

Depoisdisso,omiddlewaresegueparaseleionaroonjunto deprotoolos aseremusados

na onexão. Oobjetivo desse passo é diminuir o número de protoolos a seremonsiderados

duranteatransmissão,paraqueoproesso dedeisãoemtempo realnãosejamuitoustoso.

Nos nossos experimentos, disutidos no Capítulo 5, o onjunto iniial onsiste em mais de

7.000 protoolos, devido àsdiferentes possibilidadesde ombinações.

A primeira parte dessa esolha (linha 5 do algoritmo) onsiste em eliminar protoolos

ujas métrias não satisfazem os parâmetros xos. Esse proesso elimina protoolos que

satisfaçam quaisqueruma dasrelaçõesabaixo (lembre-seda nomenlatura dasdenições 3.5

e 3.6 , pág.19):

m > P

capac.mem.

(4.1)

m > P

max.mem.

(4.2)

∀

i

(p

i

> P

max.lat

ˆ

encia

)

(4.3)

∀

i

(r

i

> P

max.ovhd

)

(4.4)

(P

n

´

ıvel.conf.

≥

mandat´

orio)

∧

(c

= 0)

(4.5)

(P

n

´

ıvel.int.

≥

mandat´

orio)

∧

(i

= 0)

(4.6)

(P

n´

ıvel.aut.

≥

mandat´

orio)

∧

(a

= 0)

(4.7)

(P

n´

ıvel.conf.

=

desligado)

∧

(c >

0)

(4.8)

(P

n

´

ıvel.int.

=

desligado)

∧

(i >

0)

(4.9)

(P

n

´

ıvel.aut.

=

desligado)

∧

(a >

0)

(4.10)

Depoisdessaeliminaçãoiniial deprotoolos,osistemaadotaumaestratégiagulosa para

esolherumapequenaporçãodeprotoolosaseremusadosduranteaonexão(linha6). Neste

ponto,o sistemaesolhedalista osseguintesprotoolos:

•

Os

n

1

que têmmaiores valores deada métria de segurança;

•

Os

n

2

que têmmenoresgastosde memória;

•

Os

n

3

que têm menores valores de proessamento e os

n

3

om menor overhead, para

bloos dedados pequenos(10bytes);

•

Os

n

4

que têm menores valores de proessamento e os

n

4

om menor overhead, para

bloos dedados grandes(128KBytes);

•

Os

n

5

que têmasmaiores somasdastrês métriasdesegurança; e

•

Os

n

6

que têmasmenoressomasdastrês métriasde segurança.

Asonstantes

n

i

sãoonguráveis e osvaloresusados sãodisutidosna Seção4.5 . Dessa

forma, um pequeno grupo ontendo protoolos difereniados em termos dosvalores das

mé-triasériado. Essaesolhaé feitaporsomenteumdosladosdaomuniação (oqueaeitaa

(39)

A última deisão a sertomada na fase de onexão é a esolha de algoritmos de troa de

havesaseremutilizados (linha7). Primeiramente, o onjunto de protoolos seleionadosno

passo anterior é analisado para determinar o número e tipos de haves neessárias. Para as

haves assimétrias, um únio meanismo é esolhido, priorizando aquele que entra dentro

da restrição de bytes máximos de negoiação e possui maior força riptográa (soma das

métrias). Caso a apliação tenha forneido umahave mestra, será priorizada e esolhade

um algoritmoque ause. Paraashavessimétrias, sãoesolhidos umnúmero de algoritmos

entre um e o número de haves a seremesolhidas, priorizando algoritmos de aordo om a

seguinteordemderequisitos: (1)usaumahavemestraexistentee fazautentiaçãodospares,

(2) usaumahave mestraexistente, (3)autentia ospares,(4)usariptograa assimétriae

(5) o restante. OAlgoritmo 4.2 ilustra esse proesso. A informação de bytes de negoiação

usados é umapropriedade típiadosalgoritmos de distribuição de haves, fazendoparte das

informaçõesdo algoritmolidasdoarquivo deonguração.

Algoritmo 4.2Seleção de algoritmosde distribuição dehaves

1: // Distribuição de haves assimétrias

2: para todoAlgoritmosde distribuição de havesassimétrias faça

3: se Algoritmopossuioverhead denegoiação dentroda restrição de QoSentão

4: se Existe have mestra e o algoritmo a usaou não existe have mestra e algoritmo

nãoa neessita então

5: seAlgoritmo possuimaiorforçariptográa que oatual então

6: Seleiona algoritmoomoatual paradistribuição dehavesassimétrias

7: mse

8: mse

9: m se

10: mpara

11: // Distribuição de haves simétrias

12: enquantoNúmero de algoritmos adiionados

≤

número dehavesneessárias faça

13: // ondiçãoé heada a ada algoritmo adiionado

14: se Existehave mestraentão

15: Adiiona algoritmos queusam have mestra eautentiam pares

16: Adiiona algoritmos queusam have mestra masnão autentiampares

17: m se

18: Adiiona algoritmos queautentiam pares

19: Adiiona algoritmos queusam riptograaassimétria

20: Adiiona restantedosalgoritmos

21: menquanto

Por m, o lado que tomou as deisões envia o onjunto de protoolos e algoritmos de

distribuiçãode havesparaooutroladoeentãoeles fazemageração edistribuição dehaves.

Os algoritmosdedistribuição dehavessãoexeutados uma um,naordem queforam

selei-onados, paragerarada umdostamanhosdehavesneessárias. Se onúmero dealgoritmo é

menorqueodehavesneessárias,alistadealgoritmoséiteradadeformaília,reiniiando

(40)

ripto-é feitoparaevitarintrusosdengiremserumainstâniadomiddleware, apesar dessetipode

proteção não sero foo destetrabalho.

4.3.4 Transmissão

Opassonaléexeutadoaadatransmissãodedados. Quandoumpar deidetransmitirum

paote, o middleware analisa os parâmetros de tempo real para esolher o melhor protoolo

naquele momento, aplia-o sobrea mensageme onatena opaote geradoomo número do

protooloutilizado eostamanhosde adasegmento, demodo queooutro ladopossa apliar

omesmoprotoolodeformareversa. Nesseponto,omiddlewarepossuiumpequenoonjunto

deprotoolos(númerodepende dasonstantes

n

i

),adaumomsuasseismétrias,eogrupo

de parâmetros que pode inueniar em quais métrias devem ser maisimportantes naquela

situação. O fato dessa esolha ser rítia em termos de tempo arateriza essa parte do

proesso omo umalgoritmo online (Borodine El-Yaniv , 1998 ),tornando impratiávelo uso

de ténias pesadas omputaionalmente, omo aquelas baseadas em otimização e pesquisa

operaional. Para uma omputação rápida e eaz, nosso método obtém uma pontuação

para ada protoolo. Dados os valores linearizados de ada métria, a pontuação

X

de um

protoolo

i

é aluladaomo:

X

i

= (c

×

W

c

+

i

×

W

i

+

a

×

W

a

)

−

(p

×

W

p

+

r

×

W

r

+

m

×

W

m

)

(4.11)

onde

W

j

éo peso damétria

j

.

Antes de alular esses pesos, no entanto, o middleware deve hear se ada protoolo é

apliável às ondições de tempo real. Por exemplo, o overhead ausado por um protoolo

podeserabaixo dasrestriçõesdeQoSparatamanhosdedadosde até10KBytes, masaima

aso ontrário. Destaforma,o middlewaredesarta protoolos quesatisfaçam qualquer uma

dasseguintes ondições:

m

>

min(P

max.mem.

, P

mem.livre

)

(4.12)

p[tamanho] +

P

latˆ

encia

>

P

max.latˆ

encia

(4.13)

r[tamanho]

>

P

max.ovhd

(4.14)

Caso não exista a entrada

tamanho

nastabelas de tempo de proessamento e overhead,

é feita umainterpolação simplesomosvaloresdasduasentradas maispróximas (superior e

inferior).

Depois disso ada uma das seis métrias tem seu valor linearizado (denido dentro do

intervalode0a100). Asmétriasdesegurançajápossuemvaloresentre0e100pordenição.

Tempodeproessamentoédenidoomoaporentagem dotemporestante disponívelpara

o protoolo, ouseja,arazãoentreaentradanatabeladeproessamento eadiferençaentrea

latêniamáximaeaatuallatêniadarede. Overhead deredeélinearizadoomoporentagem

(41)

Opróximopasso éa determinaçãode ada umdospesos dasmétrias,usados no álulo

da pontuação dos protoolos. Sabendo do mapeamento entre métrias e parâmetros

(Ta-bela 3.2 , pág. 18 ), o valor linearizado de ada parâmetro é multipliado por umaonstante,

que representa o peso

K

daquele parâmetro sobre o peso

W

daquela métria na pontuação

nal

X

. Destaforma,opesodeumamétria

i

éaluladopelaseguinteequação,onde

K

P

j

,M

i

é a onstante que representa o impatodo parâmetro

j

no peso damétria

i

:

W

i

=

X

j

P

j

×

K

P

j

,M

i

(4.15)

Comospesospropriamentealulados,omiddlewareiterasobreoonjuntode protoolos

om o objetivo de enontrar a maiorpontuação. Apesar de todo o proesso pareer

ompli-ado, ele onsiste em apenas alular valores por aritmétia simples e então iterar sobre um

pequeno onjunto de protoolos, desartando os não apliáveis e mantendo registro do que

possuia maiorpontuação. Asonstantes

K

,assim omo as

n

,sãoonguráveis e osvalores

utilizados sãodisutidosna Seção4.5 , sobrea implementação.

4.4 Integração om Módulo de Análise Semântia de Dados

Uma segunda parte dessetrabalho, proposta omo umaextensão ao meanismo, onsiste na

integração omotrabalho de Costa(2008 ). Aintegração étratada separadamente na

imple-mentaçãoe nosexperimentos. Aspróximas subseçõesdetalham omofoifeita aintegração.

4.4.1 A Camada de Conguração de Segurança

Aamadadeonguraçãotemomoobjetivopermitiràapliaçãoongurarasegurança que

deseja obteremadamensagem quetransmite. Com isto,aapliaçãopodepersonalizarsuas

transmissõesindiando osníveis desegurança desejadospara ada treho dedados.

Aapliação aessaaamada atravésde umarquivo de anotação, queontém adesrição

semântia dosdados a serem enviados. Essa desrição é feita através de uma linguagem de

anotação baseada em XML. A linguagem de anotação permite a denição de ongurações

de segurança, que onsistem em onjuntos de valores para osrequisitos de segurança e QoS

onsiderados pelaamada de onguração. Essesrequisitos são:

•

Segurança

- Condenialidade

- Integridade

- Autentiação

•

QoS

- Latênia máxima

- Taxa detransmissão mínima

- Máximooverhead porpaote