fbpx

Detalhes das atualizações de firmware para a Trezor One (versão 1.9.0) e Trezor T (versão 2.3.0)

Nesta quarta-feira (15/04/2020), lançamos a atualização de firmware 1.9.0 para dispositivos Trezor One e a atualização de firmware 2.3.0 para dispositivos Trezor Modelo T. Esta publicação descreve os novos recursos e correções de segurança trazidos por essas atualizações.

Novos recursos

Redesign de Passphrase + Cache de sessão (Passphrase caching)

A senha BIP39 é uma parte importante de todo o ecossistema Trezor. Nessas atualizações de firmware, revisamos o design e fizemos muitas melhorias internas e duas grandes mudanças voltadas para o usuário.

Primeiro, em ambos os modelos de dispositivos, estamos introduzindo o cache de passphrase. Até agora, se você usasse várias passphrases, teria que inserir a passphrase novamente toda vez que alternasse para uma carteira diferente protegida por senha. Dependendo do uso, a Trezor agora é capaz de armazenar em cache até 10 passphrases ao mesmo tempo. No momento, isso não diz respeito à Carteira web porque exige que a Trezor seja reconectado para alterar a senha. No entanto, isso está pronto para a próxima geração de nossa carteira desktop, que será lançada em breve. Fique ligado!

Segundo, no Trezor Model T, a decisão de digitar a senha no dispositivo é solicitada diretamente na Carteira (veja a figura abaixo). Isso ajuda o UX geral, pois o foco do usuário permanece na Carteira até que a frase secreta precise ser inserida no dispositivo. Por outro lado, se você deseja que a senha seja solicitada no dispositivo toda vez, é possível
trezorctl set passphrase enabled --force-on-device para aplicá-la.

WIPE CODE - pin destrutivo

O PIN destrutivo funciona como um “PIN de autodestruição”. Se o PIN destrutivo for inserido em qualquer caixa de diálogo de entrada de PIN, todos os dados particulares serão imediatamente apagados da Trezor e o dispositivo será redefinido para os padrões de fábrica. Você pode escrever o PIN destrutivo em algum lugar próximo ao Trezor como um PIN de isca, para que, se alguém tentar desbloquear o dispositivo sem o seu consentimento, ele faça com que ele se limpe.

Para ativar esse recurso, você precisará do trezorctl versão 0.11.6 ou posterior. O comando para definir ou alterar o PIN destrutivo é: trezorctl set wipe-code

Observe que, ao alterar o PIN destrutivo, primeiro é necessário inserir seu PIN. O Trezor nunca pede o PIN destrutivo antigo, portanto, se você o inserir acidentalmente, o dispositivo será apagado!

Para desativar o recurso do PIN destrutivo, use: trezorctl set wipe-code -r

MultiSig: Mostrar XPUBs

Ao mostrar um endereço multisig no dispositivo Trezor, o usuário também pode mostrar XPUBs individuais envolvidos e confirmar se o endereço está correto.

Ed25519 em FIDO2

Os padrões de autenticação de dois fatores (2FA) suportados pela Trezor (U2F e FIDO2) usam assinaturas ECDSA com a curva NISP P-256 por padrão. Mas para aqueles que se esforçam para usar a criptografia de ponta para proteger seus logins, o Trezor Model T agora suporta assinaturas Ed25519 no FIDO2. Você apreciará isso principalmente se usar o OpenSSH com FIDO2.

Proteção do cartão SD

Esse recurso serve como proteção adicional contra ataques físicos ao Trezor Model T. Quando ativado, um código gerado aleatoriamente é armazenado no cartão microSD que você pode inserir na Trezor Model T. Durante cada operação de verificação e desbloqueio de PIN, esse código é combinado com o código PIN inserido para descriptografar os dados armazenados no dispositivo. Simplificando, o dispositivo fica vinculado ao cartão SD e não pode ser desbloqueado sem ele até que você desative intencionalmente o recurso ou restaure a Trezor de fábrica. Portanto, se você estiver preocupado com ataques físicos, poderá remover o cartão SD sempre que o dispositivo não estiver em uso e mantê-los em locais separados. Um sem o outro é inútil para um invasor, porque o código do cartão SD é um valor totalmente aleatório que não carrega informações sobre sua semente ou senha.

Para ativar esse recurso, você precisará do trezorctl versão 0.11.6 ou posterior e um cartão microSD formatado em FAT32. Se o cartão não estiver formatado corretamente, o Trezor oferecerá a exclusão e formatação do cartão para você. Existem três comandos relacionados à proteção SD:

trezorctl device sd-protect enable

trezorctl device sd-protect disable

trezorctl device sd-protect refresh

O comando refresh substitui o código atual do cartão SD por um novo. Isso é útil se você inseriu o cartão SD em um computador infectado por malware e está preocupado que o segredo armazenado no cartão possa ter sido comprometido.

Correções de segurança

Esta rodada de atualizações também traz cinco correções para vulnerabilidades de segurança. Quatro deles foram relatados por um colaborador de longa data da Trezor: Saleem Rashid, enquanto o último foi relatado por Sebastian Kung, da ShiftCrypto. Gostaríamos de aplaudir os especialistas em segurança por seu excelente trabalho e por divulgar suas descobertas por meio de nosso programa de divulgação responsável. Obrigado!

OP_RETURN tratado como saída de alteração

Essa vulnerabilidade estava presente apenas no modelo Trezor T.

OP_RETURN é um opcode de script especial no Bitcoin, que permite adicionar dados arbitrários à transação na blockchain. As saídas OP_RETURN não têm destino e esses outputs não são gastáveis.

Considere uma transação com duas saídas, uma das quais é OP_RETURN e a outra é um output de troco. Por “output de troco”, nos referimos a um output gerado a partir da semente do usuário definida pelo caminho enviado no campo address_n. Este campo não tem significado para OP_RETURN, pois não possui nenhum destino ou endereço.

No entanto, quando esse campo foi enviado para uma saída OP_RETURN na Trezor, igual às outras saídas address_n, a Trezor avaliou o OP_RETURN como uma saída alterada. Como as saídas de troco não exigem confirmação na Trezor, a caixa de diálogo de confirmação da saída OP_RETURN não foi exibida. Felizmente, a Trezor verifica se o valor é igual a 0 para cada saída do OP_RETURN, portanto não foi possível gravar nenhuma moeda. No entanto, isso ainda é um bug, porque alguns aplicativos são construídos sobre o blockchain do Bitcoin usando o OP_RETURN (como a camada Omni).

Como a vulnerabilidade foi corrigida?

a Trezor agora valida rigorosamente todas as saídas da transação antes de assinar. Para OP_RETURN, um erro será gerado se alguns campos inesperados forem fornecidos. Também garantimos que uma saída seja marcada apenas como uma saída de troco se o tipo de script corresponder ao subconjunto correto.

Troco malicioso em transações mistas

Essa vulnerabilidade estava presente apenas no modelo Trezor T.

Para poder assinar grandes transações com muitos inputs ou outputs, criamos uma técnica chamada assinatura em fluxo. Este processo tem duas fases principais. Na primeira fase, todas os outputs são enviados a carteira para determinar a quantia gasta e todas as saídas são confirmadas uma a uma na tela da carteira pelo usuário. Há uma exceção: uma saída de troco não requer confirmação do usuário, porque os fundos que vão para esse output permanecem na posse do usuário. Na segunda fase, todas os inputs são novamente enviados à carteira para serem assinadas uma a uma, enquanto se verifica que nada mudou.

Um endereço multisig também pode servir como uma saída de troco, mas apenas se todas as entradas vierem desse mesmo endereço multisig. Foi possível afirmar na primeira fase que uma entrada vem de algum endereço multisig, quando na verdade não ocorreu. Essa vulnerabilidade permitiria que um computador infectado por malware induzisse a Trezor Model T a identificar incorretamente uma saída multisig como uma saída alterada. O malware seria, portanto, capaz de fornecer uma saída multisig 1 em 2, o que não exigiria confirmação do usuário. Os dois participantes multisig dessa saída seriam o usuário e o atacante, sendo que um deles poderia gastar esse output, levando a um possível roubo de fundos do usuário.

Como a vulnerabilidade foi corrigida?

A causa dessa vulnerabilidade foi que a Trezor Model T não verificou corretamente se as informações fornecidas sobre os inputs eram as mesmas nas duas fases. Na segunda fase, uma etapa de verificação adicional foi adicionada para garantir que, se todas as entradas na primeira fase tivessem o mesmo endereço multisig, então todas elas ainda tem o mesmo endereço na segunda fase.

Verificação insuficiente do tamanho do campo no Protobuf

Essa vulnerabilidade estava presente apenas no modelo Trezor T.

A Trezor se comunica com o computador host por meio de mensagens codificadas pelo Protobuf. Cada mensagem consiste em vários campos e cada campo pode conter um número, texto, sequência de bytes ou uma sub-mensagem. Notavelmente, no entanto, o Protobuf não impõe restrições quanto ao comprimento do campo. Quando você recebe uma mensagem com um campo de bytes, ela pode ser de um byte, zero bytes ou 4 000 000 bytes.

Cada input de transação Bitcoin é enviada a Trezor como uma mensagem protobuf, que contém o hash da transação anterior (ou prevhash ) codificado como bytes. O prevhash deve sempre ter exatamente 32 bytes, mas a Trezor Model T aceita um prevhash de qualquer tamanho.

Por esse motivo, um malware poderia criar uma transação que possa ser interpretada de duas maneiras diferentes: primeiro, uma transação legítima que, sem saber, contém uma prevhash muito longo; e segundo, oculto no prevhash longo, há um output enviando todos os fundos para o endereço do atacante. A primeira versão seria enviada ao Trezor na primeira fase, onde o usuário é solicitado a confirmar as saídas. A segunda versão seria enviada na segunda fase, onde as assinaturas são geradas.

Felizmente, devido a limitações não relacionadas, a transação resultante não seria padrão e não seria propagada pela rede Bitcoin. Um invasor que deseja gastar essa transação teria que minar seu próprio bloco.

Como a vulnerabilidade foi corrigida?

Foi adicionada uma verificação que rejeita os hashes de transação enviados do computador se eles não tiverem exatamente 32 bytes de comprimento. Além disso, o comprimento do campo é verificado duas vezes ao gerar a representação binária de uma transação.

Sanitização inconsistente de inputs da transação

Da mesma forma que os outros ataques descritos acima, alguns campos não foram saneados adequadamente. Nesse caso, um invasor poderia ter criado uma transação especial que consiste em um input tradicional (assinatura única) e uma saída multisig. O atacante compôs a parte multisig do output como um multisig 1 ou 2, onde um dos participantes era a vítima e o outro, o atacante. Quando o campo multisig também foi enviado para o input (embora marcado como uma única assinatura), a Trezor concluiu incorretamente que o output é um output de troco.

Como a vulnerabilidade foi corrigida?

As entradas e saídas agora são completamente validadas na chegada.

Monero unlock_time issue

Essa vulnerabilidade estava presente apenas no modelo Trezor T.

O campo Monero unlock_time não foi confirmado no visor do dispositivo. Como a rede Monero não realiza nenhuma verificação de sanidade nesse campo, isso permite que um agressor bloqueie os fundos do usuário por um período muito longo, simplesmente configurando-o para um valor muito alto.

Como a vulnerabilidade foi corrigida?

Corrigimos o problema, mostrando o conteúdo do campo unlock_time no visor do dispositivo, se ele estiver definido como um valor não padrão (diferente de zero).

Resumo e principais tópicos

Nesta rodada de atualizações de firmware, introduzimos vários novos recursos (como proteção de código Wipe e cartão SD) e corrigimos cinco problemas de segurança. No momento da redação deste artigo, não há evidências de que alguma dessas vulnerabilidades já tenha sido explorada. Como sempre, é altamente recomendável manter todos os dispositivos Trezor atualizados com o firmware mais recente para manter o nível máximo de segurança.

Como posso atualizar minha Trezor?

Você encontrará as instruções passo a passo em nosso manual do usuário. Antes de começar, certifique-se de ter sua semente de recuperação pronta em mãos.

Observe que, se o seu dispositivo Trezor One estiver atualmente executando a versão de firmware 1.6.1 (bootloader versão 1.4.0), a memória do dispositivo será apagada após esta atualização. Verifique se você possui a semente de recuperação correta, pois precisará recuperar o dispositivo Trezor do backup de semente. Você pode testar sua semente de recuperação antes de atualizar o firmware do dispositivo.

Timeline

  • 2020–02–01 — “Monero unlock_time issue” reported by Sebastian Kung
  • 2020–03–02 — “OP_RETURN treated as change output” reported by Saleem Rashid
  • 2020–03–02 — “Malicious change in mixed transactions” reported by Saleem Rashid
  • 2020–03–05 — “Insufficient field size check in Protobuf” reported by Saleem Rashid
  • 2020–03–07 — “Inconsistent sanitization of transaction inputs” reported by Saleem Rashid
  • 2020–04–15 — firmware update 1.9.0 for Trezor One released
  • 2020–04–15 — firmware update 2.3.0 for Trezor Model T released

Escrito por: blog.trezor.io

VOCÊ AINDA GUARDA SUAS CHAVES DE RECUPERAÇÃO EM UM PAPEL?

Um pedaço de papel tem um tempo de vida curto e está propício as intempéries da natureza. Além disso, já pensou se um desavisado da sua família – que não sabe do que se trata – vê um pedaço de papel repleto de palavras sem sentido e joga no lixo? Afinal, para quem não vive no mundo das criptomoedas, não faz sentido algum encontrar um pedaço de papel com palavras aleatórias anotadas.

Compre já sua KriptoSteel com preço especial de Lançamento, clicando aqui.

-35%
Lançamento

Hardware Wallets

Trezor T – Frete grátis

R$1.699,00 R$1.099,00
-21%
Pré Venda
R$699,00 R$549,00
-21%
Novidade
R$699,00 R$549,00
-39%
Fora de estoque
R$359,00 R$219,00
-23%
Fora de estoque
R$49,90R$64,90
-33%