Wallet hardware e separazione dei conti

Master sorgente EN · P03-L06 · needs_review

Solo studio senza rete/in sola lettura. Non fornire mai segreti, password o codici di autenticazione. Nessuna connessione del wallet, approvazione reale, revoca in tempo reale, firma di transazione, trasferimento, fondi o operazione di trading. I visual sono soltanto specifiche.

Separare i ruoli di firma può ridurre l'autorità esposta abitualmente, ma il beneficio dipende dalle capacità effettive e dalle dipendenze condivise. Un dispositivo hardware non è un verdetto universale di sicurezza.

Separare le chiavi dall'azione richiesta

La documentazione del produttore descrive firma dentro l'hardware e controllo di un display fidato [HW]. È una descrizione del meccanismo, non prova che ogni richiesta supportata sia sicura o interamente comprensibile. Conservare le chiavi in un dispositivo non elimina le conseguenze di un'autorizzazione dannosa accettata consapevolmente o per errore.

Progettare i ruoli su carta

I dati dell'esercizio usano un ruolo watch-only, un ruolo di interazione e un ruolo di firma per la riserva. Elencare quali compiti servano a ciascuno: esame pubblico, interazione con applicazioni o autorizzazione poco frequente. Non assumere che un ruolo possa fare qualcosa soltanto perché la schermata mostra un saldo. In questo esercizio non vengono creati conti né spostati fondi.

Confrontare il progetto A, in cui due ruoli di firma condividono una capacità di recupero, con il progetto B, in cui i dati dell'esercizio stipulano capacità separate. Separare etichette o indirizzi non separa necessariamente i domini di guasto. Se una capacità condivisa di recupero viene esposta, i due ruoli dei dati dell'esercizio dipendono dallo stesso segreto. BIP-39 spiega un meccanismo di derivazione per il recupero [BIP39]; non è una garanzia sulla derivazione o indipendenza di ogni wallet.

Indicare i rischi residui

Anche nel progetto B, una richiesta non fidata può chiedere al ruolo di interazione autorizzazioni eccessive. Anche il ruolo di riserva può autorizzare effetti dannosi se la revisione fallisce. Supporto del display, provenienza di firmware/software, gestione fisica e gestione riservata dei backup sono dipendenze separate. I dati dell'esercizio non forniscono valutazioni di un prodotto reale o firmware attuale.

Usare una matrice delle dipendenze anziché affermare rischio zero. Se la scheda non specifica se due ruoli condividano una capacità di recupero, segnare la relazione UNKNOWN. Non chiedere mai allo studente di inserire un backup per determinarla. Una dichiarazione architetturale priva di dati sensibili basta per l'esercizio didattico.

Dichiarare il beneficio circoscritto

OBSERVED: righe stipulate di ruoli/capacità. INFERRED: come la dipendenza condivisa dichiarata influenzi il modello di separazione. UNKNOWN: dispositivi effettivi, backup e comportamento operativo. INSUFFICIENT EVIDENCE: «l'hardware garantisce sicurezza». La separazione è un progetto di flusso da valutare secondo assunzioni, non indicazioni finanziarie personalizzate o istruzioni per trasferire disponibilità reali.

• Watch-only: ruolo di osservazione senza capacità di firma fornita.
• Ruolo di firma: funzione di autorizzazione delimitata dalla capacità.
• Dominio di guasto: dipendenza condivisa che può influenzare più ruoli.
• Display fidato: superficie di revisione locale al dispositivo con limiti propri di supporto.

ILLUSTRATIVE progetti su carta. Ruoli WATCH/INTERACT/RESERVE. WATCH ha soltanto localizzatori pubblici. Progetto A: INTERACT e RESERVE usano lo stesso segnaposto stipulato RECOVERY-CAP-A. Progetto B: capacità segnaposto distinte CAP-B/C, nessun segreto reale. Entrambi includono un passaggio di revisione sul dispositivo; copertura decodifica/display UNKNOWN. Nessun saldo o conto reale fornito.

Grafo dei ruoli del wallet con collegamenti tipizzati visualizza/autorizza/recupero condiviso. Il progetto A condivide un nodo di dipendenza riservata; il progetto B lo separa secondo quanto stipulato. Aggiungere a entrambi rischi residui di richiesta/display/provenienza, mai un badge verde «sicurezza garantita».

Assegnazioni dei ruoli e differenze di dipendenze condivise stipulate in due progetti illustrativi.

Indipendenza di conti reali, immunità a firme dannose, firmware sicuro, correttezza del recupero o protezione garantita.

• Assumere che indirizzi diversi abbiano segreti indipendenti.
• Assumere che l'hardware impedisca ogni autorizzazione dannosa.
• Raccogliere backup per provare la separazione architetturale.

Costruire una matrice ruoli/capacità per A/B ed elencare tre rischi residui. Valutare che cosa possa fare il ruolo di osservazione. Scrivere una dichiarazione di beneficio circoscritta senza chiedere segreti o prescrivere trasferimenti reali.

Consegnare tabella e conclusione circoscritta basate solo sul materiale fornito senza rete. Ripartizione editoriale: studio 12 min, esercizio 8 min, correzione/quiz 10 min.

• Definire i compiti prima delle etichette dei ruoli.
• Separare visualizzazione e autorizzazione.
• Registrare le dipendenze condivise senza segreti.
• Elencare rischi residui di revisione/provenienza.
• Tenere i benefici condizionali e senza rete.

La separazione dei ruoli deve seguire capacità e dipendenze. L'isolamento hardware sostiene uno specifico meccanismo di sicurezza mentre restano rischi di autorizzazione, backup e interfaccia.

• Progettare un flusso di separazione e dichiararne i rischi residui
• Progettare la separazione dei ruoli senza fornire credenziali.
• Identificare i rischi residui di approvazione, recupero e interfaccia.

P03-L07 dopo la verifica dei prerequisiti e della correzione.

NONE nel catalogo autorevole. Bastano i dati forniti senza rete; non servono acquisto del prodotto o operazioni di wallet.

• [HW] Documentazione dei wallet hardware Trezor — Firma isolata sul dispositivo e display fidato; spiegazione del produttore, non garanzia di sicurezza.
• [BIP39] Specifica del seed mnemonico BIP-39 — Derivazione dal mnemonico al seed con passphrase opzionale; non autenticazione dei dati dell'esercizio.

La documentazione spiega meccanismi. I record storici mantengono la classe dichiarata della fonte. La verifica delle fonti non è un’approvazione editoriale indipendente.