Parte 2: Gênese da Recuperação do Ledger – Distribuindo os compartilhamentos com segurança | Razão

Bem-vindo de volta à segunda parte da nossa série de blogs sobre Recuperação de razãoé a gênese! Nosso objetivo é explorar os muitos obstáculos técnicos encontrados ao criar um serviço de recuperação de sementes e como o Ledger Recover os resolve com um design e infraestrutura seguros.

No parte anterior, examinamos como fazer backup de uma frase de recuperação secreta dividindo-a e como o Ledger Recover faz isso para você usando Compartilhamento secreto verificável de Pedersen.

Agora que você tem três ações, a próxima pergunta é: como você pode distribuí-los com segurança para seus provedores de backup? De fato, se uma parte maliciosa interceptar todos os compartilhamentos enquanto você os está transmitindo, isso anula o propósito de dividir a semente em primeiro lugar. Em segurança cibernética, isso é chamado de Ataque Man-in-the-Middle, onde um invasor fica entre você e seu destinatário e adultera a comunicação para tentar descobrir segredos.

Ao usar o Ledger Recover, a transmissão de sua semente é realizada por meio de um mecanismo de distribuição seguro. Ele conta com várias ferramentas criptográficas e conceitos matemáticos que explicaremos detalhadamente.

Começaremos descrevendo o problema em questão com mais detalhes. Em seguida, apresentaremos várias ferramentas criptográficas e conceitos matemáticos que o Ledger Recover utiliza para distribuir com segurança seus compartilhamentos iniciais para provedores de backup.

Courier-In-The-Middle: Um exemplo do mundo real

A maneira mais óbvia de se proteger de um intermediário mal-intencionado é não ter nenhum. Você pode caminhar até a casa de seus amigos ou reuni-los no mesmo local fechado para entregar as ações. Mas isso se torna muito mais difícil se você não estiver no mesmo local e quiser enviar os compartilhamentos para um conhecido de longa distância.

Assumindo que a rede pela qual nos comunicamos (por exemplo, o serviço postal) é inerentemente não confiável, como podemos garantir que os bisbilhoteiros nunca tenham um vislumbre de nossos compartilhamentos secretos?

É hora de apresentar Alice e Bob, e a infame Eve, três personalidades bem conhecidas da criptografia. Alice tem um segredo que deseja compartilhar com Bob e não tem escolha a não ser enviá-lo por meio de Eve, sua mensageira não confiável. Em palavras criptográficas, Alice e Bob querem estabelecer um canal de comunicação seguro entre si para trocar seu segredo com segurança.

Aqui está o que Alice e Bob poderiam fazer:

• Alice coloca seu segredo em uma caixa, tranca com seu cadeado pessoal, antes de enviar para Bob.
• Quando Bob recebe a caixa, ele acrescenta seu próprio cadeado e o devolve.
• Alice agora pode usar sua chave para remover o cadeado da caixa antes de enviá-lo pela última vez.
• Para finalizar o processo, Bob simplesmente usa sua chave para retirar o cadeado e recuperar – enfim – o segredo de Alice.

Durante toda a troca, sempre que Eve teve a caixa em suas mãos, ela sempre foi protegida, seja pelo cadeado de Alice, seja pelo de Bob, ou por ambos.

Embora este seja um excelente começo, há vários problemas a serem resolvidos neste cenário:

• Autenticação mútua: Alice e Bob precisam de maneiras infalíveis de verificar se cada cadeado vem genuinamente da outra parte. Caso contrário, Eve poderia trocá-lo por sua própria caixa e cadeado e enganar Alice ou Bob fazendo-os acreditar que ela é a outra parte.
• Sigilo de encaminhamento: Se Eve roubou a caixa trancada e depois roubou a chave de Alice ou Bob, ela poderia recuperar o segredo original. Em vez disso, queremos garantir que vazamentos futuros de chaves de longo prazo não comprometam pacotes roubados mais antigos.
• Preservando a privacidade: Nesse cenário, os endereços de Alice e Bob são divulgados ao mensageiro. No equivalente digital desse processo, queremos um protocolo que não divulgue nada sobre os destinatários.

Protegendo mensagens digitais

Na segurança digital, um canal seguro é uma forma de transferir dados entre dois autenticado partes de modo que os dados confidencialidade e integridade são garantidos. Quando você usa um canal seguro, os invasores não podem espionar ou adulterar sua comunicação.

O protocolo do Ledger Recover para backup e restauração é baseado em um Protocolo de canal seguro, ou SCP. Ele usa várias ferramentas da moderna caixa de ferramentas de criptografia, como criptografia simétrica e assimétrica, certificados e assinaturas digitais.
As próximas seções fornecerão uma cartilha rápida sobre todos esses conceitos, o que permitirá que você entenda todo o esquema de segurança usado no Ledger Recover.

Criptografia simétrica: uma ferramenta poderosa, mas limitada

Para garantir a confidencialidade dos dados trocados entre duas partes, os dados geralmente são criptografados e descriptografados com a mesma chave secreta.
Este processo é referido como criptografia simétrica, que é o estudo de primitivas que envolvem uma única chave secreta para garantir uma ou mais das propriedades de um canal seguro.

Embora seja uma ferramenta poderosa para proteger suas comunicações, a criptografia simétrica tem algumas limitações óbvias: suponha que Alice queira trocar várias mensagens criptografadas com Bob. Ela primeiro escolhe uma chave secreta, depois a compartilha com Bob, antes de começar a enviar mensagens.
É claro que o problema agora se torna: como Alice compartilha a chave secreta de forma segura com Bob? Se alguém conseguir a chave, a comunicação de Alice e Bob não será mais confidencial.
Alice poderia se encontrar pessoalmente com Bob para lhe dar a chave, mas, neste caso, por que não conversar com eles, longe de ouvidos curiosos?

Para comunicações digitais, precisamos de um método seguro para compartilhar a chave simétrica e iniciar a troca de dados protegidos. É hora de apresentar o trabalho de dois titãs da criptografia moderna, Whitfield Diffie e Martin Hellmann.

Criptografia assimétrica: ocultando suas partes privadas

Acordo de chave Diffie-Hellman

Com a criptografia de chave pública, Diffie e Hellman criaram uma nova abordagem para proteger as comunicações. Eles definiram um protocolo com duas chaves distintas para criptografia e descriptografia. As duas chaves são comumente chamadas chaves públicas e privadas, formando um par que pode ser usado para criptografar/descriptografar e assinar/verificar dados.

Chaves públicas e privadas
A criptografia de chave pública é a base da maior parte de nossa segurança digital. Ele é usado para protegê-lo na web e também é como você prova a propriedade de moedas e tokens em todas as cadeias de blocos públicas.

Saiba mais sobre este tópico na Ledger Academy!

O que é realmente atraente para nós é como Diffie e Hellman sugeriram o uso de criptografia de chave pública para distribuir chaves simétricas. Seu método, conhecido como Troca de chaves Diffie-Hellman, consiste em trocas de ida e volta entre duas partes para finalmente chegar a um acordo sobre um segredo compartilhado. Se executado corretamente, os bisbilhoteiros não são capazes de calcular o mesmo segredo compartilhado a partir das informações que ouvem.

O TL;DR é que no diagrama acima Eve é matematicamente incapaz de descobrir o segredo k mesmo que ela tenha acesso a todas as comunicações de Alice e Bob. Para entender por que esse segredo compartilhado está a salvo de qualquer bisbilhoteiro, precisamos nos aprofundar um pouco na teoria do grupo. 

A segurança da troca de chaves Diffie-Hellman depende da complexidade do problema do logaritmo discreto sobre um grupo cíclico. Um grupo cíclico é um grupo gerado por um único elemento.
Em poucas palavras, Alice e Bob executam as seguintes etapas para chegar a um acordo sobre um segredo compartilhado k:

1. Alice e Bob concordam em um grupo cíclico G de ordem n gerado por um elemento g
2. Alice sorteia um número aleatório 0 < a < n e envia pa =ga ∈G para Bob
3. Bob sorteia um número aleatório 0 < b < n e envia pb =gb ∈G para Alice
4. Alice calcula o segredo compartilhado k =(pb )a ∈G
5. Bob calcula o segredo compartilhado k =(pa )b ∈G

A segurança do protocolo depende da dificuldade de encontrar k = gab dado g, ga, gb. Isso é chamado de Suposição de computação Diffie-Hellman (CDH). A hipótese de que a CDH é difícil de resolver supõe que o problema de logaritmo discreto é difícil de resolver.

Nesse esquema, embora o segredo compartilhado esteja protegido contra espionagem, não há garantia sobre a origem dos dados que são trocados. Para que a interação seja segura, Alice e Bob precisam provar de alguma forma suas identidades um para o outro.

Autenticação Mútua e Assinatura Digital

Uma assinatura manuscrita é geralmente usada para reconhecer e aceitar o conteúdo de um documento. Apenas o signatário é capaz de produzir a assinatura, mas qualquer pessoa que “sabe” como é a assinatura pode verificar se o documento foi assinado pela pessoa certa.

Embora tenha propriedades semelhantes, uma assinatura digital fornece garantias fortes adicionais ao alavancar a criptografia assimétrica:

• Autenticidade: qualquer um pode verificar se a mensagem foi assinada com a chave privada correspondente à chave pública especificada.
• Não repúdio: o signatário não pode negar ter assinado e enviado a mensagem.
• Integridade: a mensagem não foi alterada durante a transmissão.

Agora, enquanto conhecemos e confiamos na chave pública do nosso correspondente, podemos verificar a autenticidade de todas as mensagens verificando sua assinatura digital.
No entanto, na maioria dos casos do mundo real, ou não conhecemos nosso correspondente intimamente ou eles podem precisar alterar regularmente seu par de chaves pública/privada por motivos de segurança. Isso exige uma camada extra de verificação e confiança na forma de Certificados, que contém a descrição de uma entidade e sua chave pública.

Cada certificado é assinado por uma chave pública pai. Tendo uma Autoridade Certificadora Raiz (ou CA Raiz) na qual sempre confiamos, podemos criar uma cadeia de confiança usando sucessivas assinaturas digitais.

Curvas Elípticas: Criptografia de chave pública de próximo nível

Criptografia de curva elíptica (ECC) é uma subárea da Criptografia de Chave Pública que consiste no uso de curvas elípticas para aplicações criptográficas, por exemplo, para esquemas de criptografia ou assinatura. 
Com base na matemática atualmente compreendida, o ECC fornece uma base significativamente mais segura do que os sistemas anteriores de criptografia de chave pública, como RSA.

Com o mesmo nível de segurança, o ECC envolve tamanhos de chave menores em comparação com outros criptossistemas assimétricos, o que o torna uma boa escolha para sistemas embarcados com recursos limitados.
Se você quiser saber mais, Este artigo pode ajudar a entender melhor as curvas elípticas.

Ordem de uma curva elíptica
A ordem de um elemento g de um grupo é um parâmetro importante da troca de chaves Diffie-Hellman. Quando o grupo é uma curva elíptica, esse elemento é um ponto e sua ordem é o número de vezes que ele pode ser adicionado a si mesmo antes de retornar ao seu valor inicial.
Observe que essa adição não tem nada a ver com sua soma usual sobre números reais, mas tem propriedades de aditividade semelhantes.

Vamos pegar a curva elíptica E: e2 = x3 +2x +3 sobre o campo 𝔽97 como um exemplo. Como uma função discreta, é representada pelos pontos na figura abaixo. Vamos nos concentrar no ponto P = (3, 6) e todos os seus múltiplos.

Vemos isso depois de 5.P, voltamos ao início e atingimos os mesmos pontos de antes. Não importa o valor do escalar P é multiplicado por, sempre atingiremos um dos nossos 5 pontos iniciais.
Assim a ordem de P é 5, e o subgrupo que ele gera contém exatamente 5 pontos. Para aplicações criptográficas, no entanto, a ordem é bem maior que 5, aumentando a aleatoriedade.

Misture tudo: ECDH com autenticação

Agora temos todas as ferramentas necessárias para criar um ótimo protocolo de troca de chaves:  Curva Elíptica Diffie-Hellman (ECDH).

ECDH é um esquema criptográfico padronizado que implementa a troca de chaves Diffie-Hellman descrita acima, usando criptografia de curva elíptica para gerar os pares de chaves e o segredo compartilhado.

Começa selecionando uma Curva Elíptica e seu ponto gerador. As duas partes então trocam certificados confiáveis, o que lhes permite verificar a autenticidade de suas respectivas chaves públicas. Uma vez autenticados, eles podem gerar um segredo compartilhado k que é calculado como:

k = dA . dB . G
dA: Chave Privada de Alice
dB: Chave Privada de Bob
G: ponto CE

Para alcançar o sigilo para a frente propriedade, o par de chaves de Alice e Bob deve ser efêmero, ou seja, são gerados na hora e usados ​​para uma única execução do protocolo. Falamos sobre uma Curva Elíptica Diffie-Hellman Ephemeral (ECDHE). Nesse cenário, as chaves efêmeras são assinadas tanto pelas chaves estáticas do dispositivo quanto pelos HSMs, permitindo uma autenticação forte das chaves. Mesmo que o acesso não autorizado às chaves estáticas ocorra no futuro, isso não concederá recursos de descriptografia para as trocas protegidas pelas chaves efêmeras.

Além disso, implementamos uma melhoria notável no protocolo ocultando as chaves estáticas dos dispositivos dentro do canal seguro. Essa medida de precaução evita que invasores obtenham visibilidade no certificado estático dos dispositivos, o que, por sua vez, pode levar ao vazamento de identificadores exclusivos usados ​​durante as operações de backup/restauração.

Back to Ledger Recover: A jornada de uma semente

Tudo bem, é hora de fazer uma pausa por um minuto.

Cobrimos muitos tópicos, tanto de segurança quanto de matemática, e o resultado é um protocolo para se comunicar com segurança em qualquer rede insegura. Vamos resumir o que vimos até agora:

Duas entidades podem ter comunicação segura através de um canal inseguro concordando em um segredo único graças à ECDHE, que é uma implementação do protocolo de acordo de chave Diffie-Hellman que usa chaves efêmeras para proteger o sigilo avançado. Cada entidade é capaz de verifique a autenticidade de seu correspondente graças a uma inicial Verificação de certificado.

No caso do Ledger Recover, estabelecemos quatro canais seguros utilizando o Secure Channel Protocol. Esses canais conectam o dispositivo a cada um dos provedores de backup e ao orquestrador, todos equipados com Hardware Security Modules (HSMs).

Cada ator detém seu certificado pessoal, assinado por um Certificado Ledger que atua como a raiz da cadeia de confiança. Quando o dispositivo do usuário transmite pela primeira vez sua intenção de realizar um backup para o orquestrador, ele inicia um ECDHE autenticado. Sob estes mTLS sessões, o orquestrador transmite informações que vincularão futuros canais seguros à solicitação de backup específica do usuário, juntamente com a identidade do usuário que será solicitada para validação ao executar uma restauração posterior da semente.

Tudo está pronto para finalmente realizar a parte mais crítica de toda a operação: transmitindo os três compartilhamentos da semente do usuário.

Mais uma vez, criamos novos canais seguros, mas desta vez entre o dispositivo Ledger do usuário e os HSMs dos provedores de backup diretamente. Os compartilhamentos de sementes são transmitidos em um canal criptografado de ponta a ponta para o local final de armazenamento, garantindo que cheguem ao destino correto (é aqui que a verificabilidade do Pedersen Secret Sharing introduzida em parte 1 é útil).
O dispositivo do usuário autentica os HSMs dos provedores de backup um por um, e os provedores de backup sabem que estão trocando com o dispositivo Ledger oficial exclusivo que iniciou essa solicitação de backup específica.
Ninguém, além do dispositivo do usuário e dos HSMs dos provedores de backup, vê os compartilhamentos de propagação criptografados pelas chaves simétricas desses canais seguros mutuamente autenticados, nem mesmo o orquestrador.

Recebido com segurança… e armazenado?

Nesta parte, introduzimos vários novos conceitos, alguns dos quais bastante técnicos. Cada um desses conceitos é necessário para estabelecer uma transmissão segura que garanta a confidencialidade e integridade da troca. Independentemente da segurança da rede, agora podemos enviar nossos compartilhamentos secretos sem medo de que possam ser adulterados ou interceptados. Isso é bastante a atualização!

Todo o processo é apoiado por criptografia sólida e hardware seguro, na forma de seu dispositivo de hardware Ledger e HSMs pertencentes a cada provedor de backup.

Agora é hora de recuperar as ações de sementes! Tudo o que precisamos fazer é pedir aos provedores de backup que nos enviem de volta os compartilhamentos que estão armazenando em sua infraestrutura…

Mas espere: como exatamente eles estão armazenando esses dados tão confidenciais? Não seria bom para nós se tivéssemos os canais de comunicação mais seguros, mas nossos provedores de backup estavam apenas mantendo os compartilhamentos em texto simples, implorando para serem roubados.

Portanto, antes de falarmos sobre recuperação, chegaremos lá, prometo! –, temos que fazer um rápido desvio na Parte 3 para discutir a segurança de nossas ações de sementes em repouso. Fique atento!

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Automotivo / EVs, Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• BlockOffsets. Modernizando a Propriedade de Compensação Ambiental. Acesse aqui.
• Fonte: https://www.ledger.com/blog/part-2-genesis-of-ledger-recover-securely-distributing-the-shares