Carteras de hardware y separación de cuentas

Máster de origen EN · P03-L06 · needs_review

Solo estudio sin conexión/de solo lectura. Nunca facilite secretos, contraseñas ni códigos de autenticación. Sin conexión de cartera, aprobación real, revocación en vivo, firma de transacción, transferencia, fondos ni operación. Los recursos visuales son solo especificaciones.

Separar roles de firma puede reducir cuánta autoridad se expone habitualmente, pero el beneficio depende de las capacidades reales y las dependencias compartidas. Un dispositivo de hardware no es un veredicto universal de seguridad.

Separar las claves de la acción solicitada

La documentación del fabricante describe la firma dentro del hardware y la comprobación de una pantalla confiable [HW]. Es una descripción de mecanismo, no prueba de que toda solicitud compatible sea segura o completamente comprensible. Mantener las claves dentro de un dispositivo no elimina las consecuencias de una autorización perjudicial aceptada a sabiendas o por error.

Diseñar los roles en papel

El conjunto ficticio usa un rol de solo observación, un rol de interacción y un rol de firma de reservas. Enumere qué tareas necesita cada uno: inspección pública, interacción con aplicaciones o autorización infrecuente. No suponga que un rol puede hacer algo solo porque su pantalla muestre saldo. En este ejercicio no se crean cuentas ni se mueven fondos.

Compare el diseño A, donde dos roles de firma comparten una capacidad de recuperación, con el diseño B, donde el conjunto ficticio estipula capacidades separadas. Separar etiquetas o direcciones no separa necesariamente dominios de fallo. Si se expone una capacidad de recuperación compartida, los dos roles del conjunto ficticio dependen del mismo secreto. BIP-39 explica un mecanismo de derivación de recuperación [BIP39]; no garantiza la derivación ni la independencia de todas las carteras.

Nombrar los riesgos residuales

Incluso en el diseño B, una solicitud no confiable puede pedir permisos excesivos al rol de interacción. El rol de reservas también puede autorizar efectos perjudiciales si falla la revisión. Compatibilidad de pantalla, procedencia de firmware/software, manejo físico y manejo confidencial de copias de seguridad son dependencias separadas. El conjunto ficticio no proporciona evaluación de un producto real ni firmware actual.

Use una matriz de dependencias en lugar de afirmar riesgo cero. Si la tarjeta no especifica si dos roles comparten una capacidad de recuperación, marque esa relación UNKNOWN. Nunca pida al alumno introducir una copia de seguridad para determinarlo. Una declaración saneada de arquitectura basta para el ejercicio de aula.

Indicar el beneficio acotado

OBSERVED: filas estipuladas de roles/capacidades. INFERRED: cómo afecta la dependencia compartida indicada al modelo de separación. UNKNOWN: dispositivos, copias de seguridad y comportamiento operativo reales. INSUFFICIENT EVIDENCE: «el hardware garantiza seguridad». La separación es un diseño de flujo de trabajo que debe evaluarse bajo supuestos, no orientación financiera personalizada ni instrucción de transferir tenencias reales.

• Solo observación: rol de observación sin capacidad de firma proporcionada.
• Rol de firma: función de autorización ligada a una capacidad.
• Dominio de fallo: dependencia compartida que puede afectar a varios roles.
• Pantalla confiable: superficie de revisión local del dispositivo con sus propios límites de compatibilidad.

ILLUSTRATIVE, diseños en papel. Roles WATCH/INTERACT/RESERVE. WATCH solo tiene localizadores públicos. Diseño A: INTERACT y RESERVE usan el mismo marcador estipulado RECOVERY-CAP-A. Diseño B: capacidades distintas de marcador CAP-B/C, sin secretos reales. Ambos incluyen un paso de revisión en dispositivo; cobertura de decodificación/pantalla UNKNOWN. No se proporcionan saldos ni cuentas reales.

Grafo de roles de cartera con enlaces tipados de muestra/autoriza/recuperación compartida. El diseño A comparte un nodo de dependencia confidencial; el diseño B lo separa bajo estipulación. Añadir riesgos residuales de solicitudes/pantalla/procedencia a ambos, nunca un distintivo verde de «seguridad garantizada».

Asignaciones de roles y diferencias de dependencias compartidas estipuladas en dos diseños ilustrativos.

Independencia real de cuentas, inmunidad a firmas perjudiciales, firmware seguro, recuperación correcta o protección garantizada.

• Suponer que direcciones distintas implican secretos independientes.
• Suponer que el hardware impide toda autorización perjudicial.
• Recopilar copias de seguridad para demostrar separación arquitectónica.

Construya una matriz de roles/capacidades para A/B y enumere tres riesgos restantes. Evalúe qué puede hacer el rol de observación. Escriba una declaración acotada de beneficio sin pedir secretos ni prescribir transferencias reales.

Entregue una tabla y una conclusión acotada usando solo el material sin conexión proporcionado. Distribución editorial del tiempo: estudio 12 min, ejercicio 8 min, corrección/cuestionario 10 min.

• Definir tareas antes que etiquetas de rol.
• Separar visualización de autorización.
• Registrar dependencias compartidas sin secretos.
• Enumerar riesgos residuales de revisión/procedencia.
• Mantener beneficios condicionales y sin conexión.

La separación de roles debe seguir capacidades y dependencias. El aislamiento por hardware respalda un mecanismo específico de seguridad mientras persisten riesgos de autorización, copias de seguridad e interfaz.

• Diseñar un flujo de separación e indicar sus riesgos residuales
• Diseñar separación de roles sin proporcionar credenciales.
• Identificar riesgos restantes de aprobación, recuperación e interfaz.

P03-L07 después de revisar el prerrequisito y la corrección.

NONE en el catálogo autorizado. Los datos sin conexión proporcionados bastan; no se requiere comprar un producto ni operar con una cartera.

• [HW] Documentación de carteras de hardware Trezor — Firma aislada en dispositivo y pantalla confiable; explicación del fabricante, no garantía de seguridad.
• [BIP39] Especificación de semilla mnemónica BIP-39 — Derivación de frase mnemónica a semilla con frase de contraseña opcional; no autentica el conjunto ficticio.

La documentación explica mecanismos. Los registros históricos conservan su clase de fuente declarada. La inspección de fuentes no es aceptación editorial independiente.