Carteiras de hardware e separação de contas

Fonte mestra EN · P03-L06 · needs_review

Apenas estudo offline/somente leitura. Nunca forneça segredos, senhas ou códigos de autenticação. Sem conexão de carteira, aprovação real, revogação em tempo real, assinatura de transação, transferência, fundos ou operação. Recursos visuais são apenas especificações.

Separar papéis de assinatura pode reduzir autoridade rotineiramente exposta, mas benefício depende de capacidades efetivas e dependências compartilhadas. Dispositivo de hardware não é veredicto universal de segurança.

Separar chaves da ação solicitada

Documentação do fabricante descreve assinatura dentro de hardware e verificação de tela confiável [HW]. É descrição de mecanismo, não prova de que toda solicitação suportada seja segura ou plenamente inteligível. Manter chaves dentro de dispositivo não elimina consequências de autorização nociva aceita conscientemente ou por engano.

Projetar papéis no papel

Dados do exercício usam papel de somente observação, papel de interação e papel de assinatura de reserva. Liste tarefas necessárias a cada um: inspeção pública, interação com aplicação ou autorização infrequente. Não presuma que papel pode fazer algo apenas porque tela mostra saldo. Nenhuma conta é criada nem fundo movido neste exercício.

Compare projeto A, em que dois papéis de assinatura compartilham uma capacidade de recuperação, com projeto B, em que dados do exercício estipulam capacidades separadas. Separar rótulos ou endereços não necessariamente separa domínios de falha. Se capacidade compartilhada de recuperação for exposta, dois papéis do exercício dependem do mesmo segredo. BIP-39 explica mecanismo de derivação de recuperação [BIP39]; não é garantia sobre derivação ou independência de toda carteira.

Nomear riscos residuais

Mesmo no projeto B, solicitação não confiável pode pedir permissões excessivas ao papel de interação. Papel de reserva também pode autorizar efeitos nocivos se revisão falhar. Suporte de tela, procedência de firmware/software, manejo físico e manejo de backup confidencial são dependências separadas. Dados do exercício não fornecem avaliação de produto real ou firmware atual.

Use matriz de dependências em vez de afirmação de risco zero. Se cartão não especifica se dois papéis compartilham capacidade de recuperação, marque relação UNKNOWN. Nunca peça ao aluno inserir backup para determiná-la. Declaração arquitetural higienizada basta para exercício de aula.

Declarar benefício delimitado

OBSERVED: linhas estipuladas de papel/capacidade. INFERRED: como dependência compartilhada declarada afeta modelo de separação. UNKNOWN: dispositivos, backups e comportamento operacional reais. INSUFFICIENT EVIDENCE: «hardware garante segurança». Separação é projeto de fluxo a ser avaliado sob pressupostos, não orientação financeira personalizada nem instrução para transferir posses reais.

• Somente observação: papel de observação sem capacidade fornecida de assinatura.
• Papel de assinatura: função de autorização delimitada por capacidade.
• Domínio de falha: dependência compartilhada que pode afetar vários papéis.
• Tela confiável: superfície local do dispositivo para revisão, com próprios limites de suporte.

ILLUSTRATIVE projetos no papel. Papéis WATCH/INTERACT/RESERVE. WATCH tem somente localizadores públicos. Projeto A: INTERACT e RESERVE usam mesmo marcador estipulado RECOVERY-CAP-A. Projeto B: capacidades distintas representadas por CAP-B/C, sem segredos reais. Ambos incluem etapa de revisão no dispositivo; cobertura de decodificação/exibição UNKNOWN. Nenhum saldo ou conta real fornecido.

Grafo de papéis de carteira com ligações tipadas de exibe/autoriza/recuperação compartilhada. Projeto A compartilha um nó de dependência confidencial; projeto B o separa sob estipulação. Acrescentar riscos residuais de solicitação/exibição/procedência a ambos, nunca distintivo verde de «segurança garantida».

Atribuições de papéis e diferenças de dependência compartilhada estipuladas em dois projetos ilustrativos.

Independência de contas reais, imunidade a assinatura nociva, firmware seguro, recuperação correta ou proteção garantida.

• Presumir que endereços diferentes são segredos independentes.
• Presumir que hardware impede toda autorização nociva.
• Coletar backups para provar separação arquitetural.

Construa matriz de papel/capacidade para A/B e liste três riscos restantes. Avalie o que papel de observação pode fazer. Escreva declaração delimitada de benefício sem pedir segredos nem prescrever transferências reais.

Entregue tabela e conclusão delimitada usando apenas material offline fornecido. Distribuição editorial: estudo 12 min, exercício 8 min, correção/questionário 10 min.

• Definir tarefas antes de rótulos de papéis.
• Separar exibição de autorização.
• Registrar dependências compartilhadas sem segredos.
• Listar riscos residuais de revisão/procedência.
• Manter benefícios condicionais e offline.

Separação de papéis deve seguir capacidades e dependências. Isolamento de hardware sustenta mecanismo específico de segurança enquanto riscos de autorização, backup e interface permanecem.

• Projetar fluxo de separação e declarar riscos residuais
• Projetar separação de papéis sem fornecer credenciais.
• Identificar riscos restantes de aprovação, recuperação e interface.

P03-L07 após revisar pré-requisitos e correção.

NONE no catálogo autoritativo. Dados offline fornecidos bastam; não exige compra de produto nem operação de carteira.

• [HW] Documentação de carteira de hardware Trezor — Assinatura isolada no dispositivo e tela confiável; explicação do fabricante, não garantia de segurança.
• [BIP39] Especificação BIP-39 de semente mnemônica — Derivação de mnemônico para semente com frase de acesso opcional; não autenticação dos dados do exercício.

Documentação explica mecanismos. Registros históricos mantêm classe de fonte declarada. Inspeção de fonte não é aceitação editorial independente.