Avançar para o conteúdo principal

Serviço de Identificadores Descentralizados Esquecidos (ODIS)

O Serviço de Identificadores Descentralizados Obscuros(ODIS) permite privacidade preservando mapeamentos de números de telefone, endurecimento de senhase outros casos de uso, implementando uma função de pseudorandom pseudorous taxa (PRF). Essencialmente, é um serviço que permite aos usuários calcular um número limitado de hashes (ou seja, Avaliações PRF), sem permitir que o serviço veja os dados sendo hashed. Muitas aplicações úteis são construídas sobre este valor superior, como mapeamentos de números de telefone protegidos por privacidade endurecendo senha e captchas para detecção de bots.

Geração de chave distribuída

Por uma questão de privacidade e segurança dos usuários, nenhuma parte deve ter a capacidade de calcular unilateralmente a função OPRF. Para garantir isso, ODIS foi projetado para ser descentralizado com um conjunto de participantes conceituados. Antes do ODIS ser implantado, um conjunto de operadores participou da cerimônia de Geração de Chave Distribuída (DKG) para gerar segredo compartilhado, com suas peças separadas entre os operadores. Detalhes da instalação do DKG podem ser encontrados no repositório Celo Threhold BLS.

Cada nó ODIS possui uma parte da chave que pode ser usada para calcular uma peça da avaliação OPRF que será enviada ao usuário. Quando um número suficiente dessas partes é combinado, sua combinação pode ser usada para derivar a avaliação OPRF exclusiva (ou seja, hash). O número de titulares de chaves (mm) e o limite de assinaturas necessários (kk) para construir uma avaliação completa são configuráveis no momento da cerimônia DKG.

Configuração de produção

A partir de 2021, ODIS opera com 7 assinantes e um limite de 5 (ou seja, m=7,k=5m=7, k=5). Como resultado, 5 das 7 partes têm de cooperar para produzir uma saída da função (P)OPRF, e enquanto pelo menos 3 forem honestos e seguros, nenhum pedido não será atendido.

Propriedades de segurança

O objetivo que a geração de chaves distribuídas é tornar mais difícil para um hacker ou um operador ODIS corrupto, comprometer a segurança do ODIS. Em particular, se um invasor tem controle sobre qualquer valor menor que o limite de kk de chaves, ele não pode fazer um cálculo não autorizado (e.. consultando o pepper por um número de telefone sem quota) da função OPRF. Além disso, enquanto os operadores de kk permanecerem honestos e tiverem acesso às suas chaves, usuários honestos continuarão a ser capazes de usar o serviço, mesmo que operadores corruptos de mkm-k estejam a recusar os seus pedidos.

Por exemplo, considere o protocolo de privacidade do número de telefone quando houver 7 operadores ODIS e o limiar necessário é 5. Um invasor pode calcular o pepper para todos os números de telefone, se 5 operadores estiverem comprometidos ou corrompidos. Se 3 estiverem corrompidos ou ficarem offline (por exemplo, por ataque DDoS), em seguida, um invasor pode impedir que o resto dos operadores gere o pepper para os usuários.

No caso de uma única chave ser comprometida, os dados do usuário permanecerão privados e o serviço operacional; no entanto é importante que possamos detectar e executar uma rotação de chave antes do número de chaves comprometidas exceder kk ou mk+1m - k + 1 (o que for menor).

Alternando Chaves

Se uma chave mantida por um dos operadores for vazada ou se o operador ficar corrompido, uma rotação de chaves pode permitir que o grupo gere um novo conjunto de chaves. Quando as novas chaves estiverem no lugar, os operadores poderão destruir suas chaves antigas, impedindo qualquer uso da chave comprometida. Rotação de chaves também pode permitir que novos operadores ODIS sejam adicionados, criando novas chaves para todos os operadores existentes, bem como para o operador recentemente adicionado.

Para girar chaves, uma nova cerimônia de DKG deve ser realizada com pelo menos kk das chaves originais de mm. Essas chaves recém-geradas não serão compatíveis com as chaves antigas; no entanto se kk das chaves antigas forem usadas, um invasor ainda pode atingir o limite necessário. Portanto, é extremamente importante que todas as chaves antigas sejam destruídas após uma rotação de chaves bem-sucedida. Esta cerimônia DKG também fornece a oportunidade de alterar os valores por kk e mm, adicionar ou remover operadores, ou modificar o limite necessário para calcular o OPRF. Note que este processo para rotação de chaves não altera a chave pública que o cliente usa para verificar os resultados.

Blinding

Quando um cliente consulta ODIS para obter uma avaliação OPRF, o cliente primeiro ofusca o número de telefone localmente usando uma chave secreta que só poder usada uma vez. Esse processo de ofuscar preserva a privacidade da mensagem subjacente (por exemplo, um número de celular ou senha), tal que os nós ODIS não conhecerão nenhuma das informações confidenciais do usuário. Além de proteger a privacidade do usuário, reduz o risco de censura direccionada. Os operadores ODIS calculam o OPRF contra este valor de entrada oculto e retornam um resultado que também está escondido dos operadores. Depois de receber a resposta, torna visivel o que estava ofuscado para mostrar o resultado final da avaliação. Observe que esse processo de ofuscar fornece privacidade ao usuário até se todos os operadores ODIS estiverem corrompidos. Esse processo de cegueira é o que torna a função pseudo-aleatória inconsciente (OPRF) "inconsciente".

Verificação

Os resultados da consulta do ODIS podem ser verificados contra a chave pública dos serviços, que é compartilhada com os usuários juntamente com a biblioteca do cliente. Verificando os resultados, o cliente pode ter certeza de que o serviço calculou o OPRF corretamente e que ninguém poderia ter interceptado ou alterado o resultado.

Combinador

Para facilitar a comunicação necessária para o kkmm$ OPRF calculado, O ODIS inclui um serviço combinador que executa essa orquestração por conveniência de carteiras e outros clientes construindo no Celo. Tal como os operadores ODIS, o combinador recebe apenas a mensagem ofuscada e, portanto, não pode aprender nada sobre a informação sensível do usuário. O combinador também verifica a resposta de cada operador para garantir que um operador corrupto não possa afetar o pepper resultante. Os clientes podem adicionalmente verificar a resposta que recebem do combinador para garantir que o combinador não possa ter alterado a resposta.

Qualquer um pode gerir um combinador, para seu uso próprio ou para o público. Atualmente, o cLabs opera um combinador que pode ser usado por qualquer construção de projeto no Celo.

Limitar taxa

Como parte de sua função principal, ODIS impõe limites de taxa nas consultas de usuários. Os limites de taxa dependem do contexto de aplicação em que o ODIS está sendo usado (por exemplo, o limite de taxa é muito maior para pepper derivado para números de telefone do que para endurecer um PIN de 6 dígitos)

Privacidade do número de telefone

A API original, direcionada para privacidade de número de telefone, impõe um limite de taxa baseado nas ações, balanceamento e status de verificação ou no usuário na blockchain do Celo. Para medir a cota para um determinado solicitante, ODIS deve verificar as informações da sua conta na cadeia. Para provar a propriedade sobre suas contas, a solicitação de POST contém um cabeçalho de autorização com o corpo da mensagem assinada. Quando os nós ODIS receberem a solicitação, ele autentica o usuário recuperando o signatário da mensagem do cabeçalho e comparando-o ao valor no corpo da mensagem.

Domínios

No domínio mais recente separado por API, o limite de taxa pode depender de uma variedade de fatores configurados para cada tipo de domínio. Mais informações sobre a API de domínios e os tipos de domínio implementado podem ser encontradas nas respectivas páginas.

Uma especificação completa da API de Domínios pode ser encontrada no CIP-40.

Solicitar diagrama de fluxo

solicitar diagrama de fluxo

Arquitetura

diagrama de arquitetura

A arquitetura hospedada é dividida em dois componentes, o combinador e os signatários. Atualmente o combinador é uma função na nuvem e os signers são servidores NodeJS independentes geridos pelos operadores. Ambos os serviços alavancam a biblioteca Celo Threshold BLS que foi compilada para um módulo Web Assembly.

O combinador e os assinantes mantêm algum estado mínimo em um banco de dados SQL, principalmente relacionado ao rastreamento de cota.

Para armazenamento da chave BLS, os assinantes suportam atualmente três keystores: Azure Key Vault, AWS Secret Manager, e Google Secret Manager.