6.2 Arquitetura do Modelo Proposto
6.2.1 Servi¸cos Fornecidos
Distribui¸c˜ao de Chaves - Suponhamos que uma entidade m´ovel A queira estab- elecer uma conex˜ao ou uma migra¸c˜ao l´ogica para uma entidade m´ovel B. Um t´ıquete de uso tempor´ario ´e exigido para proteger os dados transmitidos entre A e B. A tem uma chave-mestra Ka conhecida apenas por ela mesma e pelo GRSec; de modo semelhante B
compartilha a chave-mestra Kb com GRSec. Ocorrem as seguintes fases como ilustra a Figura 6.2: A emite uma solicita¸c˜ao de conex˜ao, um servi¸co de seguran¸ca local no dispos- itivo A salva a solicita¸c˜ao de A em um buffer e pede permiss˜ao para o GRSec (fase 01). A comunica¸c˜ao entre o dispositivo A e o GRSec ´e criptografada, usando a chave mestra compartilhada pelos dois. Se GRSec aprova a solicita¸c˜ao de conex˜ao, ent˜ao ele gera um t´ıquete criptografado e o entrega respectivamente para A e B, leg´ıtimo par envolvido na conex˜ao (fase 2a e 2b). O t´ıquete ´e entregue criptografado usando uma chave exclusiva para cada (Ka, para A e Kb para B), inicialmente conhecida por A e B. Neste ponto,
um t´ıquete foi entregue com seguran¸ca. A conex˜ao solicitada ´e estabelecida, e a comu- nica¸c˜ao entre A e B ´e feita de forma segura (fase 03 e 04), usando o t´ıquete distribu´ıdo para criptograf´a-la. O t´ıquete gerado - na nossa implementa¸c˜ao ´e composto do ID do dispositivo emissor, uma chave obtida aleatoriamente e um prazo de validade - ´e apenas conhecido por A e B, portanto somente A e B podem decifrar o conte´udo da comunica¸c˜ao. Nas fases 03 e 04 ocorre uma autentica¸c˜ao impl´ıcita de A e B antes do in´ıcio da comuni- ca¸c˜ao. O mecanismo de distribui¸c˜ao de t´ıquete propriamente dito ocorre nas fases: 1, 2a e 2b, conforme a Figura 6.2. No caso de uma migra¸c˜ao l´ogica de A para B, A usa esse t´ıquete para criptografar seu bytecode (c´odigo execut´avel).
6.2 Arquitetura do Modelo Proposto 92
Figura 6.2: Diagrama de Sequˆencia da Autentica¸c˜ao e Distribui¸c˜ao de T´ıquete. E - fun¸c˜ao de Criptografia Sim´etrica; Ka – Chave mestre de A; Kb – Chave mestre de B; IDA – Identidade de A; IDB – Identidade de B; N1 uma marca de controle; Ts – T´ıquete de Sess˜ao.
Autentica¸c˜ao – O servi¸co de autentica¸c˜ao garante a autenticidade da comunica¸c˜ao. No caso de uma ´unica mensagem, como um sinal de alarme, a fun¸c˜ao do servi¸co de autentica¸c˜ao ´e garantir que o emissor seja realmente quem ele diz ser. No caso de uma intera¸c˜ao de mensagens, como por exemplo, a conex˜ao do terminal de um m´edico ou param´edico `a uma esta¸c˜ao do sistema e-sa´ude, dois aspectos s˜ao considerados. No in´ıcio da conex˜ao, o servi¸co deve garantir que as duas entidades (emissora e a receptora) sejam realmente quem elas dizem ser. O segundo aspecto ´e que o servi¸co deve assegurar que uma terceira entidade indesej´avel n˜ao esteja se mascarando e se fazendo passar por uma das duas entidades leg´ıtimas. A nossa proposta implementa os dois casos mencionados acima. No caso de uma ´unica mensagem, o GRSec garante que a parte envolvida ´e realmente quem ela diz ser. No segundo caso, o GRSec assegura que as partes emissoras e receptoras s˜ao autˆenticas e que um intruso n˜ao est´a se passando por uma das partes leg´ıtimas. As fases 2b, 3 e 4 da Figura 6.2 mostram isso. A emite para o GRSec uma mensagem E(Ka, [IDA || IDB || N1]) de solicita¸c˜ao de conex˜ao com B, GRSec identifica
o remetente A e comunica `a identidade de A para B atrav´es da mensagem E(Kb, [Ks ||
IDA]). B comprova a identidade de A enviando para A a mensagem E(Ts, N2), A responde
com E(Ts, f(N2)). Essa etapa, al´em de comprovar a autenticidade da identidade de A
uma autentica¸c˜ao m´utua. Sendo assim, o esquema formal da mensagem ´e composto pelos seguintes itens:
• E: uma fun¸c˜ao de criptografia;
• Ka a chave de criptografia do dispositivo A;
• IDA a identidade do dispositivo emissor A e IDB a identidade do dispositivo desti-
nat´ario B;
• N1 uma marca de controle: n´umero aleat´orio exclusivo.
Confidencialidade - O servi¸co de confidencialidade permite proteger dados contra ataques passivos (exibi¸c˜ao de conte´udo). Esse servi¸co pode ser total ou parcial. O servi¸co parcial ´e um refinamento do servi¸co total; ele protege uma ´unica mensagem ou um campo espec´ıfico da mensagem. Outro aspecto da implementa¸c˜ao da confidencialidade ´e a n˜ao observabilidade: prote¸c˜ao do fluxo de tr´afego impedindo o intruso de analisar o tr´afego, ou seja, impedir que ele observe a origem, o destino, a frequˆencia das mensagens e outras car- acter´ısticas do tr´afego. O terceiro aspecto tratado no modelo ´e a prote¸c˜ao da privacidade do usu´ario atrav´es de anonimato e pseudˆonimo. Boa parte desse servi¸co ´e implementado atrav´es da criptografia e uma marca (n´umero aleat´orio exclusivo) para impedir a exibi¸c˜ao de conte´udo e an´alise de tr´afego. Assim, o GRSec ´e o ´unico que pode ler, com sucesso, a mensagem de solicita¸c˜ao do dispositivo A.
No servi¸co de distribui¸c˜ao de t´ıquetes, os t´ıquetes s˜ao entregues criptografados, per- mitindo suas prote¸c˜oes contra intercepta¸c˜ao por parte de intruso. O uso do t´ıquete pro- porciona a confidencialidade, pois somente as partes que possuem o t´ıquete distribu´ıdo com seguran¸ca podem decifrar o conte´udo das mensagens trocadas. Outra id´eia da dis- tribui¸c˜ao de t´ıquete ´e ocultar as identidades das partes envolvidas na comunica¸c˜ao, de modo a preservar suas identidades, atrav´es de anonimato.
Integridade – Como o servi¸co de confidencialidade, o servi¸co de Integridade pode ser total ou parcial. Esse servi¸co garante que as mensagens sejam recebidas do jeito que elas foram enviadas, sem duplica¸c˜ao, altera¸c˜ao, reordena¸c˜ao e atraso. A recupera¸c˜ao de dados destru´ıdos tamb´em pode ser tratada pelo servi¸co de integridade, mas a nossa proposta n˜ao aborda este aspecto. Quando o servi¸co ´e parcial, geralmente ele protege somente as mensagens contra a altera¸c˜ao. O servi¸co de integridade trata dos ataques ativos, conseq¨uentemente, ele detecta, mas n˜ao previne contra ataques. Quando uma viola¸c˜ao da integridade ´e detectada, o servi¸co notifica ou relata a ocorrˆencia. O servi¸co
6.2 Arquitetura do Modelo Proposto 94
de integridade implementado no nosso modelo ´e parcial. Por exemplo, quando A emite uma solicita¸c˜ao de conex˜ao para o GRSec, a mensagem de solicita¸c˜ao criptografada E(Ka,
[IDA || IDB || N1]) inclui a identidade de A e B e um identificador exclusivo N1 : um
n´umero aleat´orio. O requisito m´ınimo ´e que ele seja diferente a cada solicita¸c˜ao, assim dificultar´a que um oponente ou intruso descubra a sua sequˆencia. O GRSec responde com uma mensagem criptografada com a chave Ka E(Ka, [ Ts || IDA || IDB || N1]), assim A ´e o
´
unico que pode ler essa mensagem. A mensagem inclui a mensagem de solicita¸c˜ao original e N1, para que A combine essa resposta com a solicita¸c˜ao apropriada. Desse modo, A
pode verificar, atrav´es do N1, que sua solicita¸c˜ao original n˜ao foi alterada antes do seu
recebimento, e que essa n˜ao ´e uma repeti¸c˜ao de alguma solicita¸c˜ao anterior, impedindo tamb´em ataques por repeti¸c˜ao. O servi¸co de integridade foi usado para implementar a detec¸c˜ao de intruso.
N˜ao rep´udio – A nossa proposta implementa um mecanismo que impede a enti- dade emissora e a entidade receptora negar, respectivamente, a emiss˜ao e a recep¸c˜ao de mensagens. Quando uma mensagem ´e enviada, a receptora pode provar (atrav´es de uma chave compartilhada por ambas as partes) que a mensagem foi, de fato, enviada por uma emissora declarada. Similarmente, quando uma mensagem ´e recebida, a emissora pode reciprocamente provar que ela foi recebida por uma receptora declarada.
Disponibilidade – Ataques `a seguran¸ca podem resultar em perda total ou redu¸c˜ao da disponibilidade dos elementos do sistema distribu´ıdo. Alguns desses ataques s˜ao corrigidos por medidas como a autentica¸c˜ao e a criptografia. Mas outros requerem a¸c˜oes f´ısicas que n˜ao s˜ao tratadas pela proposta.
Prote¸c˜ao da privacidade – A prote¸c˜ao da privacidade exige quatro crit´erios: Anoni- mato (anonymity), possibilidade de agir com um pseudˆonimo (pseudonomity), impossibil- idade de estabelecer uma liga¸c˜ao ou tra¸co (unlinkability), n˜ao observabilidade (unobserv- ability). Essas exigˆencias constituem a base das tecnologias de prote¸c˜ao da privacidade PET (Privacy-Enhancing Tecnologies). Nos princ´ıpios fundamentais, ´e importante con- siderar que os dados pessoais pertencem a quem com eles se relaciona, e n˜ao ao propriet´ario do sistema que os armazena ou os manipula; s´o podem ser divulgados os ´unicos dados estritamente necess´arios para a execu¸c˜ao da tarefa exigida ou aceita; fala-se do princ´ıpio de minimiza¸c˜ao de dados pessoais. Na divulga¸c˜ao de dados a terceiros para realizar uma tarefa, devem-se respeitar as exigˆencias impostas pelo propriet´ario dos dados: guardar de forma confidencial e apag´a-los ap´os a execu¸c˜ao da tarefa, isso ´e o princ´ıpio de soberania. Para obedecer a esses princ´ıpios utilizamos, na nossa proposta, a abordagem da gest˜ao
de identidades virtuais atrav´es da distribui¸c˜ao de t´ıquete e comunica¸c˜ao anˆonima para acesso a dados e recursos compartilhados.