Protocolo de autenticação TESLA

Origem: Wikipédia, a enciclopédia livre.

O protocolo de autenticação TESLA (em inglês: Timed Efficient Stream Loss-tolerant Authentication) consiste em um protocolo de comunicação eficiente com baixo overhead, que escala para um grande número de receptores, e tolera a perda de pacotes. Tesla é baseado na perda de tempo de sincronização entre o emissor e o receptor. Apesar de usar exclusivamente funções de criptografia simétrica (MAC), esse protocolo atinge propriedades assimétricas.

Contexto Geral[editar | editar código-fonte]

Comunicação broadcast está ganhando popularidade por conta da divulgação de dados de forma eficiente e em grande escala. Exemplos de redes de distribuição broadcast são as transmissões via satélite, transmissão de rádio sem fio, ou IP multicasting. Enquanto muitas redes broadcast pode distribuir eficientemente dados para múltiplos receptores, que muitas vezes também permitem que um usuário mal-intencionado se passe pelo o remetente , injetando pacotes na conexão - ataque por injeção de pacotes.

Uma vez que a injeção de pacotes maliciosos é fácil em muitas redes broadcasts, os receptores querem garantir que os pacotes recebidos na transmissão sejam originados por uma fonte confiável. Um protocolo de autenticação de transmissão permite que os receptores verifiquem se um pacote recebido foi realmente enviado pelo remetente esperado.

Porque usar o protocolo TESLA?[editar | editar código-fonte]

Em uma conexão Multicast, um único pacote pode chegar a milhões de receptores. Infelizmente, isso apresenta o perigo de que um invasor pode potencialmente também chegar a milhões de receptores através de um pacote malicioso. Com a autenticação de fonte, os receptores podem garantir que pacote Multicast recebido é originário da fonte correta. Nestes aspectos, a conexão multicast é equivalente a uma transmissão para um superconjunto dos receptores multicast.

Na comunicação unicast, podemos realizar a autenticação de dados através de um mecanismo simples: o remetente e o receptor partem de uma chave secreta para computar um código de autenticação de mensagem (MAC) de todos os dados comunicados. Quando uma mensagem com um MAC correto chega, o receptor pode garantir que o remetente de fato é o autêntico. Mecanismos padrão alcançam autenticação unicast desta forma, por exemplo, TLS ou IPsec.

Autenticações simétricas MAC não são seguras em broadcast. Considere um remetente com transmissões de dados autênticos entre varios receptores. O MAC simétrico não é seguro: cada receptor conhece a chave MAC e, portanto, poderia representar o remetente e forjar mensagens para outros receptores. Intuitivamente, nós precisamos de um mecanismo de transmissão assimétrica para alcançar uma autenticação, de tal forma que cada receptor pode verificar a autenticidade das mensagens que recebe, sem ser capaz de gerar mensagens autênticas. Conseguir isso em uma forma eficiente é um problema desafiador. A abordagem padrão para alcançar tal assimetria para autenticação é a utilização de criptografia assimétrica, por exemplo, uma assinatura digital. Assinaturas digitais têm a propriedade necessária assimétrica: o remetente gera a assinatura com a sua chave privada, e todos os receptores podem verificar a assinatura com a chave pública do remetente, mas um receptor com a chave pública por si só não pode gerar uma assinatura digital para um nova mensagem. Uma assinatura digital fornece um Non-repudiation, mais forte do que a autenticação de propriedade. No entanto, as assinaturas digitais têm um alto custo: eles têm uma alta sobrecarga de processamento para ambos os emissor e o receptor, e mais assinaturas também têm uma alta sobrecarga da largura de banda. Se assumirmos as configurações broadcast para que o remetente não retransmita pacotes perdidos, e o receptor ainda autentique cada pacote que recebe de imediato, seria preciso anexar uma assinatura digital para cada mensagem. Devido a alta sobrecarga de criptografia assimétrica, essa abordagem iria restringir-nos a baixa taxa de transmissão. Podemos tentar amortizar uma assinatura digital ao longo várias mensagens. No entanto, esta abordagem ainda é cara contraste com criptografia simétrica, uma vez criptografia simétrica é em geral 3 vezes mais eficiente do que métodos assimétricos de criptografia. Além disso, a amortização do straight-forward de uma assinatura digital em vários pacotes exige confiabilidade, como o receptor precisa receber todos os pacotes para verificar a assinatura.

Devido ao problema de eficiência, o Protocolo TESLA opta por usar principalmente criptografia simétrica, e atinge assimetrias ao divulgar a chave de forma temporizada. Mesmo assim, TESLA precisa de clocks vagamente sincronizados entre o emissor e os receptores em questão.

Funcionalidades[editar | editar código-fonte]

O Protocolo TESLA fornece autenticação de pacotes baseados em tempo de sincronização e a verificação da integridade dos dados. A ideia para proporcionar eficiência e segurança é uma divulgação tardia das chaves. A chave cuja divulgação foi atrasada resulta em um atraso de autenticação. Na prática, o atraso é da ordem de um RTT (round-trip-time). TESLA tem as seguintes vantagens:

  • Baixo overhead para a geração e verificação de informações de autenticação.
  • Baixo overhead de comunicação.
  • Buffer limitado necessário para o emissor eo receptor, e portanto, a autenticação em tempo útil para cada pacote individual.
  • Robusto contra perda de pacotes.
  • Adaptável o a um grande número de receptores.
  • Protege o receptores de ataques de dano de serviço em determinadas circunstâncias, se configurado adequadamente.
  • Cada o receptor não pode verificar a autenticidade de mensagens a menos que possua o tempo vagamente sincronizado com a fonte, onde a sincronização pode ocorrer no inicio da sessão. Uma vez que a sessão está progresso, os receptores não precisa enviar mensagens ou acknowledgements (ACKs).
  • Non-repudiation não é suportado; cada receptor pode saber que um fluxo é de uma fonte confiável, mas não pode provar isso para terceiros.

TESLA pode ser usado na camada de rede, na camada de transporte, ou até na camada de aplicação. Autenticação de atraso, no entanto, requer um buffer de pacotes até que a autenticação seja concluída. Certas aplicações intolerantes a atraso podem estar dispostas a processar os pacotes em paralelo, enquanto se aguarda a autenticação, desde que o roll-back seja possível. Por exemplo, um vídeo interativo pode jogar fora pacotes que ainda estão aguardando por autenticação, mas se forem descobertos mais tarde como não autenticados, pode-se parar o vídeo e avisar o usuário que os últimos X milissegundos não foram autenticados e devem ser ignorados.

Ligações externas[editar | editar código-fonte]

  • Sketch of TESLA protocol
  • RFC 3817 - Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
  • RFC 4082 - Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction