Inteligência de dados generativa

Como a Kraken Wallet aborda os desafios da segurança criptográfica móvel

Data:

Acreditamos que a carteira criptografada móvel mais segura é aquela que supera as restrições inerentes ao seu sistema operacional móvel. Por exemplo, no iOS, o CryptoKit da Apple não suporta o curva elíptica secp256k1, um padrão para Bitcoin, Ethereum e muitos outros blockchains.

Essa limitação impede que os desenvolvedores utilizem o elemento seguro dos dispositivos para armazenamento de chaves e assinatura de transações. Como resultado, as carteiras criptográficas móveis são classificadas como carteiras quentes, uma vez que estão ambas ligadas à Internet e assinam transacções fora de um elemento seguro utilizando uma implementação de software dos algoritmos criptográficos.

Isso significa que as chaves privadas devem ser expostas – pelo menos durante a assinatura – na memória do ambiente do aplicativo em área restrita. Isto os deixa mais expostos a ameaças potenciais do que uma carteira que utiliza um elemento seguro para assinar transações.

Apesar da impossibilidade de realizar a assinatura diretamente nos elementos seguros, o que ofereceria maior proteção, nos comprometemos a fornecer uma carteira criptográfica móvel de código aberto que priorize a segurança, a transparência e o controle do usuário.

Nossa arquitetura de segurança foi desenvolvida especificamente para:

  • Suporta vários blockchains
  • Gere chaves privadas com alta entropia, uma medida de imprevisibilidade que reforça a segurança
  • Aproveite a criptografia testada em batalha para criptografar com segurança as chaves privadas dos usuários, aproveitando o hardware de segurança dos telefones celulares e os recursos de segurança do sistema operacional
  • Ofereça segurança aprimorada com uma senha gerada pelo usuário para usuários avançados que desejam um nível adicional de criptografia (além da proteção das chaves do sistema operacional para a chave de descriptografia)
  • Criar uma base sólida para incorporação futura de novos tipos de gerenciamento de chaves, como carteiras de hardware e sistemas baseados em quórum MPC

A vantagem do código aberto

Como um dos seus princípios fundamentais de segurança, Carteira Kraken é um software gratuito e de código aberto, distribuído sob a licença do MIT. Construindo uma nova carteira do zero, era importante para nós ajudar a promover o código aberto e o ecossistema distribuído.

Sem código-fonte aberto, a Kraken Wallet exigiria muita confiança sem transparência. Isto daria aos clientes menos proteção; você não poderia verificar, modificar ou executar o cliente sozinho, se quisesse. “Não confie, verifique!” não é apenas uma máxima da indústria, é um dos nossos princípios orientadores.

O código aberto de nosso software atende a dois objetivos fundamentais que definimos inicialmente para este produto: minimização da confiança verificável e auditável:

  • Verificabilidade: A capacidade de verificar se as suposições de segurança apresentadas nesta postagem do blog são verdadeiras. Qualquer um pode veja o código fonte para entender especificamente o que está e o que não está sendo feito nesta carteira. 
  • Auditabilidade: A capacidade de verificar se o resultado da nossa implementação de segurança está correto e reportar quando não estiver. Contratamos equipes internas e externas para realizar auditorias de segurança diversas vezes antes do lançamento. No futuro, qualquer pessoa poderá auditar o código e produzir um relatório sobre suas descobertas.

Geração e importação de chaves

React Native, embora seja uma ferramenta poderosa, não possui um módulo criptográfico integrado. Para contornar isso, usamos uma implementação pure-js (crypto-browserify) do módulo criptográfico do NodeJS. O método crypto.randomBytes() – que gera os bytes aleatórios reais que necessitamos durante a geração da chave – é tratado pelo reagir-nativo-obter-valores-aleatórios polifill.

React-native-get-random-values ​​usa código nativo para utilizar o gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG) disponível no dispositivo para gerar números aleatórios. Em praticamente todos os dispositivos modernos, este gerador de números aleatórios é apoiado por um gerador de números aleatórios de hardware seguro.

Durante a inicialização da carteira, extraímos entropia do CSPRNG e a convertemos em uma semente mnemônica usando pacotes npm bem estabelecidos (BIP32, BIP39).

As chaves são convertidas, armazenadas e apresentadas ao usuário sob o padrão BIP39, que oferece um método mnemônico fácil de fazer backup com interoperabilidade para a maioria das carteiras do ecossistema. O recurso de importação suporta a recuperação de sementes compatíveis com BIP39, que proporcionam a melhor interoperabilidade no ecossistema. 

Gerenciamento de chave 

A Kraken Wallet contém dois valores secretos – a semente e o mnemônico – e vários valores não secretos (mas ainda privados), como endereços de carteira, nomes de carteira e descrições de transações.

O material da chave privada (seed/mnemônico) é armazenado no Keychain (no iOS) e no Keystore (no Android). O material da chave pública e os dados não confidenciais (chaves públicas estendidas, endereços e descrições) são armazenados no banco de dados criptografado do aplicativo (usando Reino).

Existem vários controles de segurança protegendo os dados:

  • Bloqueio de aplicativos: uma string de 64 bytes gerada aleatoriamente e armazenada em Keychain ou Keystore. O acesso ao segredo é protegido por requisitos de presença do usuário – autenticação biométrica ou por senha.
  • Senha: fornecido pelo usuário e não mantido em um dispositivo. Em vez disso, o usuário deverá fornecer a senha manualmente sempre que solicitado pelo aplicativo. A carteira determina se a senha é necessária consultando dois sinalizadores (is_storage_encrypted e is_seed_encrypted) armazenados em Keychain ou Keystore. O algoritmo Argon2 é usado como uma função de derivação de chave.
  • Criptografia de banco de dados: O banco de dados (Realm) é usado para armazenar dados não secretos. Os dados são criptografados com uma chave aleatória de 64 bytes.
  • Mecanismo de bloqueio: inserir uma senha incorreta aciona atrasos antes que tentativas subsequentes de senha possam ser feitas. Este mecanismo impede efetivamente ataques de senha de força bruta. As informações relativas aos parâmetros de bloqueio, como o número de tentativas e a duração dos atrasos, são armazenadas com segurança no Keychain ou Keystore.

A semente, o mnemônico e a chave de criptografia do banco de dados são sempre armazenados de forma criptografada

  • Quando nenhuma proteção está habilitada: A chave inicial, mnemônica e de criptografia do Realm são armazenadas diretamente no Keychain ou Keystore sem controle de acesso de presença do usuário.
  • Quando o bloqueio de aplicativo está ativado: o mnemônico e a semente são primeiro criptografados com o segredo de bloqueio do aplicativo e depois armazenados com segurança no Keychain ou Keystore. A chave de criptografia do Realm também é armazenada diretamente no Keychain ou Keystore.
  • Quando a proteção por senha está ativada: o mnemônico e a semente são criptografados com a senha, enquanto a chave de criptografia do Realm é criptografada com a senha somente se is_storage_encrypted tiver sido definido como verdadeiro.
  • Quando o bloqueio de aplicativos e a proteção por senha estão ativados: o mnemônico e a semente são criptografados com uma senha (primeira) e bloqueio de aplicativo (segunda). A chave de criptografia do Realm é criptografada somente com a senha e somente se is_storage_encrypted tiver sido configurado como true.

Uso da chave

O seed/mnemônico é armazenado em Keychain ou Keystore e desempenha um papel crucial nas operações criptográficas. Quando um novo endereço de carteira precisa ser gerado ou uma transação precisa ser assinada, derivamos as informações necessárias, como a chave privada, dessa semente.

No entanto, é importante observar que a chave privada deve ser carregada na memória durante estas operações. Esta necessidade decorre das restrições que mencionamos anteriormente sobre carteiras móveis e da falta de acesso direto ao elemento seguro para assinatura de transações.

  • Assinatura de transação (envio de tokens)
  • Assinatura de dados WalletConnect (tratamento de solicitações de sessão)
  • Adicionando uma nova carteira
  • Habilitando cadeias testnet (adicionando carteiras testnet)
  • Exibindo o mnemônico
  • Verificando o mnemônico
  • Ativando e desativando o bloqueio de aplicativos
  • Habilitando e desabilitando a senha

A autenticação biométrica adicional é realizada para as seguintes funcionalidades:

  • Ativando o bloqueio de aplicativos
  • Limpando todos os dados
  • Excluindo uma carteira (conta)
  • Ativar ou desativar uma senha (além da recuperação do bloqueio do aplicativo)
  • Abrindo o aplicativo
  • Movendo o aplicativo para o primeiro plano
  • Visualizando chaves públicas estendidas
  • Conectando-se a um aplicativo descentralizado (dApp)

Além disso, a senha pode ser necessária para abrir o aplicativo. Keychain e Keystore são sempre usados ​​através do chaveiro react-nativo embrulho:

  • O wrapper gera uma nova chave no Keychain ou Keystore para cada item
  • O wrapper é responsável por passar os sinalizadores de configuração corretos para Keychain e Keystore
  • A carteira sempre solicita ao wrapper que configure as flags para que o dispositivo seja desbloqueado para acessar a chave
  • Uma verificação de presença do usuário (biométrica) é configurada para ser baseada no tempo e é válida por 5 segundos; a verificação de presença do usuário não é realizada por acesso

O algoritmo de criptografia é o mesmo para todos os itens:

  • A chave é derivada com Argon2id de um segredo normalizado por NFC
  • O salt para Argon2id é o ID exclusivo do dispositivo
  • O modo de criptografia é AES-GCM
  • O vetor de inicialização (IV) para AES é de 16 bytes aleatórios
  • A tag de autenticação para AES deve ter 16 bytes de comprimento

Assinatura de transação

Além das medidas mencionadas anteriormente em relação ao armazenamento de chaves, biometria e proteção por senha, a assinatura de transações continua sendo uma área crítica de foco para melhoria contínua. Como passo inicial, implementámos diversas medidas dignas de nota neste domínio, incluindo:

Simulação de transação

Usamos serviços de API externos (como Blowfish e outros) para verificar os possíveis níveis de “severidade” que uma transação pode trazer ao usuário (uma pontuação de risco). Isso vai desde tela cheia de bloqueio para possíveis transações maliciosas (ou assinatura de mensagens) até avisos sobre os diferentes níveis de cuidado que o usuário deve ter antes de assinar ou confirmar uma transação. 

Outras medidas incluem:

  • Validação de endereço para garantir que você não envie para um endereço errado
  • Endereços que estão sempre visíveis na sua totalidade para garantir que o utilizador não seja alvo de ataques específicos relacionados com a composição do endereço
  • Validação de rede e avisos para garantir que o usuário não envie para a rede errada
  • Verificações de sanidade de taxas para garantir que o usuário não pague a mais por uma transação

Privacidade de rede

Para proteger a privacidade e os dados pessoais dos usuários de forma que esses dados não sejam vazados em solicitações de rede – especialmente para serviços de terceiros – desenvolvemos um gateway de API para solicitações de proxy. Este proxy nos permite não repassar solicitações de usuários a serviços de terceiros e não revelar o IP de um cliente a provedores externos ou públicos. 

Este serviço de back-end é basicamente uma API para consultar dados públicos de blockchain. Dentro da arquitetura de segurança da carteira, seu objetivo é encapsular essa funcionalidade por trás de uma API comum em todas as blockchains, para que a Kraken Wallet não precise implementar comportamentos específicos da blockchain para consulta de dados.

Este serviço de backend define esta API comum. Em última análise, ele faz proxy de solicitações para outras partes das quais busca os dados reais. Ele não indexa blockchains nem mantém o estado.

Suposições de segurança

Nossa arquitetura de segurança opera com base em algumas premissas importantes para uma proteção ideal. Presumimos:

  • O dispositivo do usuário não está enraizado, nem o sistema operacional está desatualizado e é suscetível a vulnerabilidades críticas que poderiam conceder a um invasor acesso à memória do dispositivo
  • O pacote Keychain ou Keystore oferece proteção forte o suficiente
  • O sistema operacional móvel oferece sandboxing sólido entre os processos dos aplicativos, garantindo que a memória que contém dados confidenciais, como sementes, seja gerenciada adequadamente

Funcionalidade adicional

  • O aplicativo opera com base no princípio de armazenar apenas os dados mínimos necessários para operar a carteira
  • Nenhuma análise de terceiros ou kits de desenvolvimento de software (SDKs) de relatório de falhas são usados ​​no cliente
    • Com nossos esforços para não vazar dados para terceiros, não faria sentido incluir rastreamento de dados extra – o que significa que você não encontrará nenhum software de análise ou relatório de falhas no cliente
  • Nenhuma atualização over-the-air (fora do fluxo regular de atualização da AppStore/Play Store) é permitida ou implementada na base de código
    • O usuário pode esperar um software compilado que não pode ser atualizado sem seu consentimento
  • Lista de tokens e sistema de reputação
    • Para ajudar os usuários a gerenciar seus tokens, implementamos um sistema de lista e reputação baseado nos ativos fornecidos pela Kraken e outros terceiros
  • Spam de NFT
    • Um esforço inicial que pretendemos continuar melhorando é a detecção de spam e ataques relacionados a spam, onde o spam é automaticamente arquivado na pasta do usuário

Auditoria de segurança externa

A segurança da nossa carteira de autocustódia foi rigorosamente avaliada através de uma auditoria realizada pela Trilha dos Bits, uma empresa de auditoria de segurança bem conceituada no setor. Esta auditoria abrangeu um exame detalhado da nossa base de código e arquitetura do cliente, com o objetivo de identificar e resolver potenciais vulnerabilidades de segurança.

Para garantir a transparência e fornecer informações sobre a segurança da nossa plataforma, os resultados desta auditoria estão disponíveis publicamente. Este acesso aberto permite que usuários e partes interessadas revisem as conclusões da análise de segurança conduzida pela Trail of Bits. O relatório serve como um recurso importante para a compreensão das medidas de segurança que implementamos e do nosso compromisso em manter um ambiente seguro para os nossos utilizadores.

Priorizando segurança, transparência e controle do usuário

A Kraken Wallet atinge um equilíbrio delicado entre conveniência e proteção robusta diante das restrições inerentes à plataforma. Nossa abordagem sempre foi começar com uma estrutura de carteira interoperável amplamente reconhecida. Essa base sólida prepara o terreno para inovarmos e adicionarmos novos recursos, com o objetivo de oferecer aos nossos usuários uma solução de segurança de alto nível em constante evolução para a autocustódia de seus ativos criptográficos.

Estes materiais são apenas para fins de informação geral e não são conselhos de investimento ou uma recomendação ou solicitação para comprar, vender, apostar ou manter qualquer criptoativo ou para se envolver em qualquer estratégia de negociação específica. Kraken não trabalha e não trabalhará para aumentar ou diminuir o preço de qualquer criptoativo específico que disponibiliza. Alguns produtos e mercados criptográficos não são regulamentados e você pode não estar protegido por compensação governamental e/ou esquemas de proteção regulatória. A natureza imprevisível dos mercados de criptoativos pode levar à perda de fundos. Poderá ser devido imposto sobre qualquer retorno e/ou sobre qualquer aumento no valor dos seus criptoativos e você deve procurar aconselhamento independente sobre sua situação tributária. Podem ser aplicadas restrições geográficas.

local_img

Inteligência mais recente

local_img