Crowds

1. Crowds Instituto Superior Técnico Algoritmos e Aplicações de Segurança 2002/2003 Pedro António, M5157 pantonio@est.ipcb.pt Crowds: Anonymity for Web Transactions Michael K. Reiter Aviel D. Rubin AT&T Labs (Artigo de Abril de 1997 – Revisão de Agosto de 1997) Aplicações e Algoritmos de Segurança

2. Motivação • Falta de privacidade em transacções na World-Wide-Web • Comunicação codificada, o atacante continua a poder saber: • IP do cliente e o IP do servidor • A quantidade de dados trocados • Quando foi realizada e a frequência que é realizada • Esta informação pode ser manipulada com outros dados, afectando a privacidade dos clientes! • Aumentar a privacidade e o anonimato em transacções Web Aplicações e Algoritmos de Segurança

3. absolute privacy beyond suspicion probable innocence possible innocence exposed provably exposed Aspectos de Anonimato • 3 tipos de comunicação anónima (1) • Emissor anónimo • Receptor anónimo • Desassociação entre Emissor e Receptor • Um atacante à escuta observa (2) • Algumas ou todas as mensagens enviadas e recebidas • Colaboração entre emissores, receptores ou outros • Grau de anonimato definidos (3) • Contínuo informal Aplicações e Algoritmos de Segurança

4. absolute privacy beyond suspicion probable innocence possible innocence exposed provably exposed Anonimato • Para um emissor anónimo: • Absolute privacy – o atacante não distingue se um potencial emissor transmite ou não uma mensagem. • Beyond suspicion – o atacante não consegue distinguir entre um conjunto de possíveis emissores. • Probable innocence – se do ponto de vista do atacante, o emissor não é provavelmente o originador da mensagem. • Possible innocence – do ponto de vista do atacante, se existe uma probabilidade não trivial de o emissor real ser outro qualquer. • Exposed – se do ponto de vista do atacante existe uma probabilidade elevada sobre quem é o emissor. • Provably Exposed – se o atacante conseguir identificar o emissor e prová-lo a todos. Aplicações e Algoritmos de Segurança

5. Anonimato • O sistema CROWDS consiste num conjunto dinâmico de utilizadores • Crowd – Multidão, ajuntamento, grupo, grande quantidade • Os utilizadores (emissores) do Crowds efectuam pedidos Web a servidores Web (receptores) • 3 tipos de ataques considerados • Escuta local – o atacante observa toda a comunicação do emissor • Membros do Crowds em colaboração – membros que se desviam do protocolo pré-estabelecido • Servidor final – ataque ao servidor Web a que se dirige a transacção Servidor WEB Servidor WEB Servidor WEB 1 2 1 2 1 2 Aplicações e Algoritmos de Segurança

6. Anonimato • Ataques não defendidos pelo Crowds • 1. Não se defende contra ataquesdinial-of-serviceproduzidos por membros do Crowds. Um membro do Crowds recebe uma mensagem e recusa-se a enviar a mensagem. • Comportamento malicioso • Falha não intencional de um membro • Um membro abandona o Crowds • Estes ataques são detectáveis! • 2. Um membro do Crowds altera informação na resposta a questões de outros membros. • Altera a informação, mas não afecta o anonimato • Estes ataques são menos detectáveis! Aplicações e Algoritmos de Segurança

7. Trabalhos Relacionados • Proxy • Adicionar um novo elemento (proxy) entre o emissor e o receptor, para omitir a identidade do emissor ao receptor • Anonymizer (http://www.anonymizer.com/) • Lucent Personalized Web Assistant (http://lpwa.com) • O Crowds garante protecção contra um maior número de ataques do que os proxies • O Crowds não tem um ponto único no qual o atacante pode estropiar o anonimato dos utilizadores • O Proxy possui um ponto único de falha, se falhar compromete todo anonimato dos utilizadores • No Crowds, as falhas isoladas não impedem as transacções de prosseguir. PROXY EMISSOR SERVIDOR WEB Aplicações e Algoritmos de Segurança

8. Trabalhos Relacionados • Mix (1/3) • Proxy melhorado • Esconde o emissor do receptor • Toma medidas para permitir desassociar o emissor do receptor, evitando uma escuta global • Recolhe mensagens de tamanho igual dos emissores • Codificando as mensagens (descodificar através de uma chave privada) • Reenvia as mensagens para o receptor numa ordem diferente • Mensagens de saída versus Mensagens de entrada (numa escuta) • Implementado para vários tipos de comunicação • E-mail, serviço ISDN, comunicações síncronas (web browsing) EMISSORES MIX RECEPTORES Mensagens Mensagens codificadas e com ordem diferente EMISSORES MIX MIX MIX RECEPTORES Aplicações e Algoritmos de Segurança

9. Trabalhos Relacionados • Mix (2/3) • O Crowds oferece probable innocence do anonimato do emissor contra membros em colaboração • Grupo de servidores Mix em colaboração não oferecem anonimato do emissor, apenas desassocia o emissor do receptor • O Crowds não oferece anonimato contra escutas globais (vários domínios) • O Mix confia em chaves públicas de encriptação • O tamanho da mensagem encaminhada, cresce proporcionalmente ao número de Mixes por onde passa • N mixes N chaves públicas  N chaves privadas (operações dispendiosas) • Aumentando o N  melhora o anonimato; degrada o desempenho • No Crowds, o anonimato é melhorado com o aumento médio do número de vezes que o pedido é reencaminhado entre membros antes de submetido ao servidor final, mas o impacto no desempenho é muito menor: • Não há operações de chaves públicas/primárias • Os tamanhos das mensagens não aumentam Aplicações e Algoritmos de Segurança

10. Mix1 Mix1 A B A B Trabalhos Relacionados • Mix (3/3) • M – mensagem; R – instante de tempo; K – chave pública Aplicações e Algoritmos de Segurança

11. Crowds – Funcionamento • Descrição • Crowds é formado por um conjunto de utilizadores • Utilizadores – processo na sua máquina local (jondo – “John Doe”) • Lança o jondo • Escolhido pelo utilizador no Web proxy • Especificar no Web browser, a máquina e o porto como proxy de todos os serviços • Os pedidos do browser são enviados directamente para o jondo • O tamanho do caminho depende da probabilidade de reenviar (pf) um pedido • Os dados estão cifrados nas ligações, mas em claro nos nós • Chave partilhada entre todos os jondos de um caminho • Criada pelo jondo que inicia o caminho • Cada jondo partilha uma chave com o próximo jondo Estabelecer um caminho aleatório até ao servidor Web Lançamento do JONDO Associação à CROWD Aplicações e Algoritmos de Segurança

12. Crowds – Funcionamento • Determinação do caminho • Cada pedido viaja do browser do utilizador, através de alguns jondos e finalmente é enviado para o servidor final • O servidor final responde ao pedido pelo mesmo caminho (mas por ordem inversa) JONDO recebe um pedido Atira moeda ao ar Servidor Final? Enviar para Novo JONDO Aleatoriamente N S Enviar para Servidor Final Aplicações e Algoritmos de Segurança

13. Crowds – Funcionamento • Exemplo de funcionamento Aplicações e Algoritmos de Segurança

14. Crowds – Funcionamento (1) client,request  receive_request() (2) if (client = browser) (3) sanitize(request) /* strip cookies and identifying headers */ (4) if (my_path_id = _|_) /* if my path id is not initialized ... */ (5) my_path_id  new_path_id() (6) next[my_path_id] R Jondos (7) forward_request(my_path_id) (8) else /* client is a jondo */ (9) path_id  remove_path_id(request) /* remove “incoming" path id */ (10) if (translate[path_id] = _|_) /* “incoming" path id is new */ (11) coin  coin_flip(pf ) /* tails with probability pf */ (12) if (coin = heads) (13) translate[path_id]  ‘submit' (14) else (15) translate[path_id]  new_path_id() /* set “outgoing" path id */ (16) next[translate[path_id]] R Jondos /* select next jondo at random */ (17) if (translate[path_id] = ‘submit') (18) submit_request() (19) else (20) forward_request(translate[path_id]) (21) subroutine forward_request(out_path_id) (22) send out_path_id || request to next[out_path_id] (23) reply  await_reply() /* wait for reply or recognizable jondo failure */ (24) if (reply = ‘jondo failed') /* jondo failed */ (25) Jondos  Jondos \ {next[out_path_id]} /* remove the jondo */ (26) next[out_path_id] R Jondos /* assign a new random jondo for this path */ (27) forward_request(out_path_id) /* try again */ (28) else /* received reply from jondo */ (29) send reply to client (30) subroutine submit_request() (31) send request to destination(request) /* send to destination web server */ (32) reply  await reply(timeout) /* wait for reply, timeout, or server failure */ (33) send reply to client /* send reply or error message to client */ • Algoritmo • Para cada caminho existe um • path_id • Next[path_id] é o próximo elemento • do caminho • new_path_id() retorna um valor • aleatório de 128-bit • R escolha aleatória dum conjunto • Em cada posição existe um • identificador de caminho diferente • para um caminho Aplicações e Algoritmos de Segurança

15. Crowds – Funcionamento • Demonstração da Aplicação do Algoritmo translate[path_id]=‘submit’ translate[path_id]=431 4 Servidor WEB 5 translate[path_id]=712 reply 3 reply my_path_id=539 reply 1 2 reply Aplicações e Algoritmos de Segurança

16. Segurança • Escuta local • Este mecanismo impede que um atacante que efectua escuta local de ficar a saber qual o receptor de um pedido. • As mensagens são cifradas, excepto quando enviadas para o servidor final. • O atacante apenas vê a mensagem quando submetida ao servidor final. • A probabilidade do iniciador efectuar o envio para o servidor final é 1/n (n é o número de elementos da Crowd quando o caminho foi criado). • P(saber o ID do receptor) = f(tamanho da Crowd) • Aumentando a Crowd diminui a probabilidade de saber o ID do receptor. • Se o jondo iniciador não enviar o pedido directamente ao servidor final, o atacante apenas vê o endereço cifrado. • Não existe anonimato por parte do servidor contra um atacante de escuta local. • Uma saída não resulta de uma entrada. Servidor WEB 1 2 Aplicações e Algoritmos de Segurança

17. Segurança • Servidor Final • O servidor Web é o receptor, o anonimato é impossível contra o atacante. • No entanto, o anonimato do emissor é forte. • O servidor final nunca é o primeiro elemento do caminho. • O servidor final é igualmente provável em receber um pedido do emissor do que qualquer membro da Crowd. • O iniciador está beyond suspicion (relativamente ao anonimato do emissor) contra um servidor final. • O aumento do caminho não oferece garantias adicionais de anonimato contra atacantes no servidor final. Servidor WEB 1 2 Aplicações e Algoritmos de Segurança

18. Segurança • Membros em Colaboração • Jondos corrompidos; Jondos maliciosos (atacantes) • Jondo decifra o tráfego que passa por eles • Conseguirá determinar quem iniciou o processo? • Um jondo não colaborante é que efectuou o pedido inicial • Existe um jondo colaborante no caminho • O objectivo dos jondos colaborantes consiste em determinar o membro que iniciou o caminho. • Todos os membros não colaborantes são igualmente prováveis de serem o iniciador, mas não menos prováveis que o colaborador anterior. • O iniciador do pedido tem probable innocence contra colaboradores, se • pf > ½ (probabilidade de reenviar o pedido) • n – nº de elementos do Crowds • c – nº de jondos colaboradores Aplicações e Algoritmos de Segurança

19. Segurança • Membros em Colaboração – Ataques de timming • Devido à estrutura do HTML • Quando uma página HTML possuir URLs • Quando a página é carregada o browser lança pedidos automaticamente destas URLs • Oportunidade de ataques de timming dos jondos em colaboração • O primeiro jondo em colaboração no caminho, retorna a página Web com URLs e o browser envia pedidos automaticamente para essas URLs. • Se a duração for suficientemente reduzida, pode indicar que o iniciador do pedido precede o jondo em colaboração. • Solução • Identificar todas as URLs numa página Web. • Enviar as URLs de volta juntamente com a resposta HTML. • Desvantagens da solução • Incompatível com SSL (impede que a página seja percorrida). Servidor WEB 1 2 Aplicações e Algoritmos de Segurança

20. Segurança • Caminhos Estáticos • Inicialmente, os caminhos eram mais dinâmicos do que são. • Cada jondo tinha um caminho diferente para cada utilizador, por períodos de tempo ou por pedido. • Vantagens: Melhores desempenhos, balanceando a carga entre os membros. • Problemas: Caminhos dinâmicos diminuíam as propriedades de anonimato oferecidas contra jondos em colaboração. • Ligar caminhos distintos iniciados pelo mesmo utilizador, com base em conteúdo ou tempos de comunicação. • Caminhos estáticos • Alterar os caminhos em 2 circunstâncias • 1. Quando são detectadas falhas no caminho, os caminhos são refeitos quando a falha de um jondo é detectada. • 2. Novos jondos adicionados à Crowd • Proteger o anonimato do novo jondo. • EventoJoin-commit – os caminhos existentes são esquecidos e os novos jondos passam a participar na Crowd. Não têm frequência. Aplicações e Algoritmos de Segurança

21. Segurança • Propriedades de Anonimato do Crowds Aplicações e Algoritmos de Segurança

22. Desempenho • Resultados obtidos – Jondos Sparc 150 MHz – Web server SGI 133 MHz Latência (ms) em função do tamanho do caminho e do tamanho da página Latência (ms) em função do tamanho do caminho e do número de imagens Aplicações e Algoritmos de Segurança

23. Aspectos de Implementação • Mecanismos (1/2) • Gestão de membros do Crowds • Solução Simples  Solução Centralizada • Os membros existentes no Crowd são controlados e comunicados a todos os membros através de um processo chamado “blender” • O utilizador cria uma conta no blender • Nome e Password • Quando um utilizador lançar um jondo, o jondo e o blender utilizam a password partilhada para se autenticarem mutuamente. • O “blender” adiciona o novo jondo (IP, porto, nome da conta) à lista de membros e envia esta lista para o jondo. • O “blender” gera e comunica de volta uma lista de chaves partilhadas, cada chave pode servir para autenticar membros do Crowd. • O “blender” envia cada chave da lista para os outros jondos e informa esses jondos do novo membro. • Join-commit Aplicações e Algoritmos de Segurança

24. Aspectos de Implementação • Mecanismos (2/2) • Cada membro mantém uma lista própria dos membros do Crowds. • A lista é inicializada e enviada pelo “blender”, quando o jondo se junta ao Crowd. • A lista é actualizada quando o jondo receber uma notificação do blender de um novo membro ou que saiu um membro do Crowd. • Um jondo pode apagar um outro jondo da sua lista, se detectar que esse jondo falhou. • Desvantagens: • Confiar em terceiros para distribuição de chaves e de anunciar alterações de membros (“blender”) • Distribuir o “blender” (réplicas) para tolerar falhas. • Trabalho futuro: • Jondos estabelecer chaves partilhadas utilizando Diffie-Hellman. • O blender apenas distribuirá chaves públicas DH dos membros do Crowd. Aplicações e Algoritmos de Segurança

25. Aspectos de Implementação • Política (1/2) • Manter um certo grau de controlo sobre os membros do Crowds. • 1. Se qualquer um conseguir adicionar vários jondos ao Crowd, então um atacante pode lançar vários jondos em colaboração. • 2. Quando surge um novo jondo são refeitos os caminhos. Se estiverem constantemente a surgir jondos novos e sem qualquer controlo, os caminhos podem ser refeitos vezes suficientes para que os jondos em colaboração formem um ataque. • Os blenders servem como ponto de acesso controlado ao Crowd. • Join-commit • Parâmetro configurável do blender (por exemplo, 1 por dia) • O blender informa todos os membros do Crowd de um evento join-commit, onde os novos membros têm possibilidade de participar e todos os membros antigos apaguem os caminhos. Aplicações e Algoritmos de Segurança

26. Aspectos de Implementação • Política (2/2) • Necessidade de limitar o número de colaboradores que se alistam no Crowd • 1. Conjunto de indivíduos relativamente pequeno que, baseado em conhecimento pessoal, concordam em formar um Crowd. • Cada membro permite incluir no máximo um membro. • Confiança entre membros. • 2. Um Crowd público muito maior, que permite membros que podem não ser conhecidos. • A privacidade oferecida pela multidão contra membros em colaboração (ataque) vai confiar na dimensão da multidão, que por ser tão grande um ataque necessita de um esforço considerável para não ser detectado. • Um utilizador 1 conta • Cada conta 1 jondo • Monitorizar e limitar o número de jondos numa rede • Força o atacante a lançar vários jondos com diversas identidades diferentes e em várias redes diferentes. Aplicações e Algoritmos de Segurança

27. Jondo Blender Ligações Crowds • Exemplo com “blender” Iniciador Aplicações e Algoritmos de Segurança

28. Interface Utilizador • HTTP proxy do browser • ?crowd? no final URLs • Lista: Conta, IP, porto • Título da página – crowd • Aviso de join-commit Aplicações e Algoritmos de Segurança

29. Firewalls • Problemas • Tal como outros servidores, os jondos são identificados pelo endereço IP e pelo número do porto. • Infelizmente, as firewallsnão permitem a ligação a portos não especificados. Assim, as firewalls são uma barreira para a adopção do Crowds. • As firewalls permitem ligações (para fora) a qualquer porto, continua a ser possível a um jondo iniciar o caminho fora da firewall. • O 1º jondo fora da firewall pode verificar que o jondo anterior está dentro do domínio da firewall. Uma ligação de volta, provoca uma falha. Conclui-se que o caminho iniciou-se dentro do domínio da firewall. • Um membro do Crowd por trás de uma firewallnão oferece o mesmo anonimato dos restantes. • Pode reservar-se um porto especial para o Crowds, aberto pela firewall. Aplicações e Algoritmos de Segurança

30. Sumário • Motivação • Anonimato • Graus de anonimato • Crowds (Ataques considerados, Ataques não defendidos) • Trabalhos relacionados • Proxy e Mix • Funcionamento do Crowds • Segurança • Escuta local; Servidor final; Membros em colaboração • Aspectos de implementação • Mecanismos e Política • Interface Utilizador • Problemas com Firewalls Aplicações e Algoritmos de Segurança