Yet another insecure group key distribution scheme using secret sharing

Este artigo demonstra que o esquema de distribuição de chaves de grupo UMKESS, baseado em compartilhamento de segredos, é inseguro, falha em funcionar corretamente e possui fundamentos de design insustentáveis, inserindo-se em uma longa série de esquemas similares com falhas.

O essencial

O Grande Fiasco do "Segredo Compartilhado"

Resumo do artigo: "Yet another insecure group key distribution scheme using secret sharing" (Mais um esquema inseguro de distribuição de chaves de grupo usando compartilhamento de segredos)

Imagine que você é o gerente de um grande escritório (o Centro de Geração de Chaves, ou KGC) e precisa entregar chaves secretas para vários grupos de funcionários diferentes ao mesmo tempo. Alguns grupos são de marketing, outros de TI, outros de RH. O objetivo é que cada grupo tenha sua própria chave secreta para conversar em segurança, sem que os outros grupos ou estranhos saibam o que estão dizendo.

O artigo de Chris J. Mitchell analisa um novo método proposto por Hsu, Harn e Zeng (chamado de UMKESS) para fazer isso. A ideia era usar uma técnica matemática antiga chamada "Compartilhamento de Segredos" (como dividir um cofre em pedaços de quebra-cabeça).

A conclusão do autor é devastadora: O método não funciona, é inseguro e a lógica por trás dele é falha. É como tentar construir uma casa de cartas com cartas molhadas.

Aqui estão os problemas principais, explicados de forma simples:

1. O Problema da "Soma Confusa" (O sistema trava)

O método propõe que o gerente (KGC) use a soma dos números de identificação dos funcionários de um grupo para criar uma chave.

• A Analogia: Imagine que o funcionário "1" e o "5" estão no Grupo A. A soma é 6. O funcionário "1", "2" e "3" estão no Grupo B. A soma também é 6.
• O Erro: O sistema matemático fica confuso. Ele tenta criar uma "receita" (um polinômio) para o funcionário 1 baseada no número 6. Mas como dois grupos diferentes têm o mesmo número 6, a receita tenta ser duas coisas ao mesmo tempo. É como tentar seguir duas receitas de bolo diferentes usando a mesma quantidade de farinha; o bolo não vai dar certo. O sistema simplesmente quebra e não entrega as chaves.

2. O Espião Interno (A segurança é nula)

Este é o problema mais grave. O método diz que é seguro contra funcionários mal-intencionados, mas o autor mostra como um funcionário desonesto pode roubar o segredo permanente de outro.

• A Analogia: Imagine que você e seu colega de trabalho (o "Vítima") estão em dois grupos juntos. O colega envia um bilhete secreto para o gerente. O funcionário mal-intencionado (o "Espião") intercepta esse bilhete, rasca uma palavra e escreve outra, e entrega ao gerente.
• O Resultado: O gerente responde com uma "receita" matemática. Como o Espião sabe quais grupos ele e a Vítima compartilham, e como ele modificou o bilhete de uma forma específica, ele consegue usar a resposta do gerente para resolver a equação e descobrir o segredo permanente da Vítima.
• Consequência: Uma vez que o Espião tem o segredo da Vítima, ele pode ler todas as conversas secretas dela, agora e no futuro. A segurança do sistema é como um cadeado de papelão: qualquer um pode abrir.

3. A Falta de "Selos de Garantia" (O problema da confiança)

O protocolo assume que certas mensagens (como a lista de quem está em qual grupo) chegam intactas e não foram alteradas por hackers.

• A Analogia: É como se o gerente escrevesse em um quadro branco: "O Grupo A é formado por João e Maria". Mas o quadro fica no corredor e qualquer um pode passar e apagar "Maria" e escrever "Pedro".
• O Risco: Se um hacker mudar a lista no quadro, ele pode fazer com que João pense que está conversando com Pedro, quando na verdade está conversando com Maria (ou vice-versa), ou fazer com que ele aceite uma chave falsa. O sistema não tem um "selo de garantia" (assinatura digital) para provar que a lista veio realmente do gerente e não foi adulterada.

4. Por que tentar "consertar" isso é inútil?

O autor critica a história de tentativas de corrigir esses esquemas.

• A Analogia: É como tentar consertar um carro que não tem motor, apenas trocando as rodas por rodas mais bonitas. Ou pior: é como tentar consertar um cofre furado adicionando uma armadura de aço pesada.
• O Problema: Para consertar os erros de segurança, os autores do esquema original teriam que adicionar assinaturas digitais (como usar criptografia de chave pública). Mas se você já vai usar essa tecnologia pesada e segura, por que usar o método complicado de "compartilhamento de segredos" desde o início? Seria mais simples, mais rápido e mais seguro usar os métodos que já existem e são comprovados há décadas.

A Lição Final

O autor conclui que a comunidade científica está repetindo um erro triste há 30 anos:

1. Pare de publicar ideias que não foram provadas matematicamente. Não adianta dizer "acho que é seguro"; tem que ter prova.
2. Pare de tentar "consertar" esquemas quebrados. Se a ideia base é falha, tentar colar fita adesiva (ou adicionar assinaturas digitais) não cria uma inovação útil; cria apenas um sistema complexo e desnecessário.

Em resumo: Não use esse método. Ele é como um castelo feito de areia: parece bonito no papel, mas a primeira onda (um ataque simples) derruba tudo.

Resumo técnico

1. Problema

O artigo aborda a persistência de esquemas de distribuição de chaves de grupo baseados em partilha de segredos (secret sharing) que são fundamentalmente inseguros e, em alguns casos, não funcionais. O foco específico é a análise crítica de um protocolo recente chamado UMKESS (proposto por Hsu, Harn e Zeng), que visa permitir que uma Autoridade de Confiança (KGC) distribua múltiplas chaves de grupo para conjuntos distintos de utilizadores.

O autor argumenta que, apesar de uma vasta literatura histórica (desde 1989) demonstrar que abordagens baseadas em partilha de segredos para chaves de grupo sofrem de falhas crônicas (como falta de sigilo forward, vulnerabilidade a ataques de insiders e ausência de provas de segurança rigorosas), novos protocolos com as mesmas falhas continuam a ser publicados sem a devida consideração das vulnerabilidades conhecidas.

2. Metodologia

A metodologia do artigo consiste numa análise técnica rigorosa do protocolo UMKESS, seguindo os seguintes passos:

• Revisão do Protocolo: O autor descreve detalhadamente o funcionamento do UMKESS, que utiliza o esquema de partilha de segredos de Shamir sobre um corpo finito $GF(p)$. O protocolo envolve a KGC gerando polinómios para cada utilizador com base nas suas chaves secretas de longo prazo ($x_i$), valores aleatórios ($r_{ij}$) e identidades de grupo.
• Análise de Funcionalidade: O autor verifica se o protocolo consegue executar corretamente a distribuição de chaves em todos os cenários possíveis.
• Análise de Segurança (Ataques):
  • Ataque de Insider: O autor constrói um ataque onde um utilizador malicioso ($U_a$) intercepta e modifica mensagens enviadas por uma vítima ($U_v$) à KGC. Ao manipular os valores aleatórios enviados pela vítima e interceptar a resposta da KGC, o atacante consegue montar um sistema de equações lineares.
  • Exploração de Falhas de Definição: O autor identifica que a soma dos índices dos membros do grupo ($S(G_i)$) pode colidir (dois grupos diferentes terem a mesma soma), tornando o polinómio de partilha de segredos matematicamente impossível de reconstruir.
  • Análise de Canais de Comunicação: O autor avalia as suposições sobre a integridade e autenticidade dos canais de comunicação (broadcasts e mensagens unicast) e demonstra como a falta de proteção nesses canais permite ataques de manipulação de chaves.
• Comparação de Racional e Custo: O artigo compara o custo computacional do UMKESS com outras soluções, incluindo protocolos de chave pública e outros esquemas de partilha de segredos já conhecidos como inseguros.

3. Contribuições Principais

As contribuições técnicas do artigo são:

1. Demonstração de Falha Funcional: Prova que o protocolo UMKESS não funciona em casos não triviais. Se dois grupos distintos tiverem a mesma soma dos índices dos seus membros ($S(G_i) = S(G_j)$), o KGC não consegue gerar um polinómio válido que satisfaça as condições de partilha de segredos para um utilizador membro de ambos, pois exigiria que o polinómio passasse por dois pontos com a mesma coordenada X mas coordenadas Y diferentes.
2. Quebra de Segurança (Recuperação de Chave de Longo Prazo): O autor demonstra um ataque onde um utilizador insider consegue recuperar a chave secreta de longo prazo ($x_v$) de outro utilizador. Ao modificar um valor aleatório enviado pela vítima e interceptar os pontos do polinómio devolvidos pela KGC, o atacante obtém equações lineares suficientes para resolver o polinómio secreto da vítima e, consequentemente, sua chave $x_v$.
3. Exposição de Vulnerabilidades em Broadcasts: O artigo mostra que, se a lista de grupos ou a lista de hashes das chaves ($h(K_i)$) puderem ser manipuladas (o que o protocolo original não protege explicitamente), um atacante pode forçar a distribuição de chaves incorretas ou fazer com que os utilizadores acreditem estar partilhando chaves com o conjunto errado de pessoas.
4. Crítica ao Racional de Design: O autor argumenta que a comparação de desempenho feita pelos autores originais do UMKESS é enganosa, pois compara o protocolo com soluções de chave pública (mais caras) e com outros esquemas de partilha de segredos já quebrados.
5. Reiteração da Necessidade de Provas Formais: O artigo reforça que a comunidade académica deve parar de publicar "correções" para protocolos inseguros sem uma prova de segurança rigorosa (no modelo de complexidade computacional), pois o ciclo de "quebra-correção-quebra" continua a gerar literatura inútil e perigosa.

4. Resultados

• Insegurança Confirmada: O protocolo UMKESS é comprovadamente inseguro. Um atacante insider pode recuperar as chaves secretas de longo prazo de outros utilizadores e, subsequentemente, derivar todas as chaves de grupo distribuídas a esses utilizadores.
• Não Funcionalidade: O protocolo falha em cenários onde há colisão na soma dos índices dos membros dos grupos, impedindo a execução correta do esquema.
• Falha na Justificativa: As alegações de segurança dos autores originais baseiam-se em argumentos heurísticos e não em provas formais, o que é uma prática desatualizada e perigosa na criptografia moderna.
• Histórico de Falhas: O artigo confirma que o UMKESS é apenas mais um exemplo numa longa linha de esquemas de partilha de segredos para chaves de grupo que falham nos mesmos princípios básicos (falta de sigilo forward, vulnerabilidade a insiders).

5. Significância

A significância deste trabalho reside em:

• Prevenção de Adoção de Protocolos Inseguros: Ao expor falhas críticas no UMKESS antes que ele possa ser adotado ou citado como uma solução viável, o artigo protege a comunidade de implementar sistemas vulneráveis.
• Chamada de Atenção Académica: O autor faz uma crítica severa à cultura de publicação que permite o surgimento de "novos" protocolos que ignoram décadas de literatura sobre as falhas inerentes à partilha de segredos para chaves de grupo.
• Definição de Padrões: O artigo reforça a existência de padrões internacionais (como ISO/IEC 11770-5) e protocolos provados que já resolvem o problema de forma segura e eficiente, sugerindo que o desenvolvimento de novos esquemas baseados em partilha de segredos para este fim é, na maioria dos casos, um esforço fútil e perigoso.
• Conclusão Prática: O artigo conclui que a academia deve cessar a publicação de esquemas de segurança sem provas robustas e de "correções" que, ao adicionar complexidade (como assinaturas digitais) para corrigir falhas, anulam a razão de existir do protocolo original (baixo custo computacional).