Después de COLDCARD, Trezor y SafePal: el argumento de CLAVI por la minimización de datos

Cierre de la investigación: 19 de agosto de 2026. Los totales declarados por los proveedores se identifican como tales. Este artículo es educativo y no constituye asesoramiento jurídico ni de respuesta a incidentes.

La respuesta directa: menos datos retenidos significan menos exposición del lado del operador

La minimización de datos es un control de seguridad porque un operador no puede perder un registro que nunca recopiló. La segunda mejor opción es recopilar solo lo que exige una finalidad definida, aislarlo de otros sistemas y eliminarlo según un calendario verificado. Pero «cero datos» no es una promesa creíble para una empresa operativa. Los envíos, las facturas, el soporte, la prevención del fraude y los servicios regulados pueden crear necesidades limitadas de conservación de registros. El objetivo defendible es cero acceso del operador a los secretos del vault y la retención mínima necesaria en todo lo demás.

La distinción importa porque, durante el ciclo informativo de agosto de 2026, tres historias de seguridad se comprimieron a menudo en un único titular alarmante sobre «hacks de hardware wallets». No eran un mismo problema.

• El incidente de COLDCARD afectó a la generación de secretos de wallets.
• El incidente de Trezor afectó a un acceso no autorizado en un proveedor de envíos.
• La divulgación de SafePal afectó a un fallo de autorización en un componente de seguimiento de pedidos.

¿Qué ocurrió en julio y agosto de 2026?

Incidente	Divulgación o actualización pública	Plano de seguridad	Relato apto para publicación	Confianza
Incidente de RNG predecible de COLDCARD	Aviso publicado el 30 de julio; guía actualizada el 14 de agosto de 2026	Generación de secretos	Coinkite y Block atribuyeron de forma independiente el problema a un error de integración del firmware que permitió a un generador de respaldo determinista aportar la aleatoriedad usada para generar seeds.	Causa raíz confirmada; algunos detalles sobre versiones e impacto siguen siendo discutidos o estimados.
Exposición Trezor/ShipMonk	Aviso publicado el 13 de agosto de 2026	Datos logísticos y de identidad	Trezor afirma que ShipMonk le informó de un acceso no autorizado que afectó a aproximadamente 13.689 registros de clientes. Trezor sostiene que sus dispositivos, claves y copias de seguridad no se vieron afectados.	Alcance declarado por el proveedor, con la existencia de la divulgación corroborada por información independiente; el conjunto de datos no fue auditado de forma independiente.
Exposición del seguimiento de pedidos de SafePal	Divulgación publicada el 16 de agosto de 2026	Datos logísticos y de compra	SafePal afirma que un fallo de autorización expuso información de pedidos de aproximadamente 39.798 clientes. Dice que no estaban implicadas las credenciales de wallets ni los datos de tarjetas de pago.	Declaración del proveedor; la situación sigue evolucionando.

COLDCARD: el air-gap no puede compensar una entropía débil

La vulnerabilidad de COLDCARD fue un fallo al crear secretos, no la vulneración de una base de datos de clientes. Tanto el relato técnico de Coinkite como el análisis independiente del código de Block concluyeron que un error de compilación o enlazado permitió utilizar un generador de respaldo determinista de MicroPython donde se pretendía usar aleatoriedad generada por hardware.

La seed de una wallet debe ser impredecible. Si el espacio de seeds posibles se reduce lo suficiente como para poder explorarlo, un atacante puede reconstruir claves candidatas fuera del dispositivo. La wallet puede estar apagada, guardada en una caja fuerte y no haberse conectado nunca a internet; esas protecciones no restauran la aleatoriedad ausente cuando se creó el secreto.

Esta es una corrección importante frente a las descripciones simplistas de un «air-gap». El aislamiento físico y de red puede reducir mucho las vías de ataque remoto, pero no demuestra que todos los componentes dentro del límite aislado funcionen correctamente. La generación de entropía, la integración del firmware, los builds reproducibles, los procedimientos de actualización y la revisión independiente siguen formando parte del modelo de seguridad.

El límite exacto de versiones Mk2/Mk3 es en sí mismo una lección útil sobre el tratamiento de la evidencia. El análisis de Block remonta la ruta afectada a la versión 4.0.0. El aviso actual de Coinkite comienza en la versión 4.0.1. En vez de escoger una en silencio, usuarios y editores deberían reconocer la discrepancia y tratar con prudencia una seed creada bajo cualquiera de esos límites.

Coinkite también afirma que instalar el firmware corregido no refuerza una seed ya creada con firmware afectado. La actualización protege la generación futura de seeds; una seed afectada todavía requiere una migración cuidadosa a una wallet recién generada, sujeta a las salvedades del proveedor sobre dados y passphrases. Esta distinción debería aparecer en cualquier resumen de remediación.

El análisis on-chain de Galaxy Research del 3 de agosto atribuyó 1.596 BTC a tres oleadas de alta confianza y 14 incidentes menores. Esa cifra solo debe utilizarse con su atribución. No es un total de pérdidas verificado por Coinkite, y este artículo no repite las estimaciones superiores de una cuarta oleada o en dólares que seguían sin confirmarse.

El registro público no identifica al atacante ni demuestra que la inteligencia artificial descubriera el fallo. Una campaña de phishing independiente explotó la preocupación por COLDCARD, pero ninguna fuente revisada establece que utilizara una lista filtrada de clientes de Coinkite.

Trezor: la minimización parece haber reducido, no eliminado, la exposición

El aviso de Trezor del 13 de agosto se refería a datos logísticos en poder de ShipMonk, no a hardware de wallets comprometido. Trezor afirma que ShipMonk le informó el 10 de agosto. Esa fue la fecha de notificación, no necesariamente la fecha de la intrusión.

El aviso de Trezor no nombró el exploit. BleepingComputer informó después de que los correos de notificación de ShipMonk que revisó vinculaban el acceso con una vulnerabilidad de Metabase. El aviso primario de Metabase identifica CVE-2026-72898 como una vulnerabilidad crítica de inyección SQL sin autenticación y explotada activamente. Hasta el cierre de la investigación no se había localizado un postmortem público de ShipMonk ni un informe forense independiente.

Trezor informó de dos grupos afectados:

• 11.742 clientes cuyos nombres, direcciones de correo electrónico, números de teléfono y direcciones de envío quedaron expuestos.
• 1.947 clientes cuyos nombres, ciudades y direcciones de correo electrónico quedaron expuestos sin las direcciones de envío completas.

Esto produce un total aproximado declarado de 13.689, no «exactamente 14.000». Trezor afirma que la mayoría de los registros afectados correspondían a clientes que recibieron pedidos en Estados Unidos, Reino Unido, Suecia, Colombia, Brasil, Italia o Portugal entre el 10 de mayo y el 8 de agosto de 2026. También advirtió por separado que los registros parciales podrían incluir pedidos más antiguos y que todavía estaba comprobando el periodo exacto con ShipMonk.

Según Trezor, sus propios sistemas, hardware wallets, claves privadas y copias de seguridad de wallets no se vieron afectados. Trezor también afirma que no se expuso el contenido de los paquetes. Son límites significativos, pero no hacen inofensivos los nombres y domicilios. La información de identidad y entrega puede volver más convincente un mensaje de soporte fraudulento y aumentar el riesgo de ser objeto de ataques. El aviso no establece que se produjera un ataque físico, por lo que el riesgo no debe reescribirse como una consecuencia confirmada.

La tabla de retención publicada por Trezor dice que los datos principales de pedidos y entregas de su tienda electrónica, una vez completados o cancelados, se eliminan por lo general tras 90 días, con excepciones para pedidos en curso. Esa política parece haber limitado el número de direcciones de envío completas disponibles. No eliminó el incidente, y la salvedad sobre registros parciales antiguos impide presentar la política como ejecutada a la perfección.

La misma tabla demuestra también por qué es falsa la afirmación «Trezor elimina los datos de clientes después de 90 días». Enumera periodos distintos para finalidades separadas: datos de facturas durante diez años en un entorno separado, datos de pagos fiat de terceros durante un máximo de siete años, ciertos registros de pagos cripto durante cinco años después de que termine la relación y tickets de soporte cerrados anonimizados después de 120 días. Los datos de marketing y referidos siguen otras reglas.

Así es la minimización real: no un eslogan ni un único temporizador, sino un mapa de categorías de datos. La pregunta crítica es si el mapa se aplica en el comercio, el almacén, el transportista, la plataforma de soporte, el procesador de pagos, las réplicas y las copias de seguridad.

SafePal: una wallet puede seguir intacta mientras sus compradores quedan visibles

La divulgación de SafePal describe otro fallo de datos comerciales, no un compromiso declarado de secretos de wallets. SafePal afirma que un fallo de autorización en un plug-in de seguimiento de pedidos expuso información de aproximadamente 39.798 clientes que hicieron pedidos entre el 2 de marzo de 2025 y el 11 de abril de 2026.

Según SafePal, los campos expuestos incluían nombres, direcciones de correo electrónico, direcciones de envío, números de teléfono y detalles de compra. La empresa afirma que el incidente no afectó a frases seed, claves privadas, contraseñas de wallets, otras credenciales de wallets, información de cuentas bancarias, números de tarjetas de pago ni números oficiales de identificación.

Esas afirmaciones siguen siendo declaraciones del proveedor. La conclusión segura es más estrecha: saber que una persona identificada compró un producto de seguridad puede tener valor incluso cuando los secretos del producto permanecen protegidos.

Para un proveedor de hardware, el stack de checkout y seguimiento no es «comercio electrónico ordinario» fuera del perímetro de seguridad. Puede conectar una identidad real, un lugar de entrega, canales de contacto y una compra sensible para la seguridad. Cada plug-in y socio logístico que maneje esa combinación pasa a formar parte del modelo de amenazas del cliente.

Cero datos no es una sola cosa

«No recopilar datos» es un reto de diseño útil, pero una política operativa incompleta. Un Personal Vault y la empresa que lo fabrica o presta soporte manejan categorías de información distintas.

El objetivo más fuerte se aplica al plano de secretos del vault: el proveedor no debería recibir en primer lugar claves privadas, material de recuperación, prompts locales de la IA propietaria de CLAVI ni otros contenidos protegidos. La documentación pública de CLAVI lo describe como el objetivo de diseño de su Personal Vault. Es una afirmación sobre la arquitectura del producto y el acceso del operador a los secretos del usuario, no una afirmación de que CLAVI Switzerland AG carezca de registros comerciales.

Los registros comerciales y corporativos requieren otra disciplina:

Clase de datos	Objetivo defendible	Por qué «no guardar nada» puede ser incompleto
Secretos del vault y contenido local protegido	Mantenerlos inaccesibles para el operador mediante la arquitectura; no solicitarlos nunca a través del soporte.	Son los registros cuya no recopilación elimina de forma más directa la exposición del lado del operador.
Datos de pedido y entrega	Recopilar los campos mínimos exigidos por el transportista elegido; separarlos; hacerlos expirar después de la entrega y de los plazos de devolución y disputa.	Un producto físico no puede llegar a un cliente sin algún mecanismo de entrega, salvo que se utilice una opción de recogida que preserve la privacidad.
Facturas y evidencia contable	Conservar solo la información necesaria para constituir y justificar los registros contables exigidos, en un sistema separado.	Las normas contables suizas pueden exigir que los registros y comprobantes contables, junto con el informe anual y el informe de auditoría, se conserven durante diez años; esto no autoriza a conservar un perfil CRM completo.
Registros de soporte	Prohibir secretos, minimizar adjuntos, separar direcciones de reenvío y hacer expirar o anonimizar los casos cerrados.	Una garantía, sustitución o disputa activa puede requerir un registro limitado.
Datos de marketing	Hacer opcional la participación y mantener los registros de consentimiento separados de los datos logísticos.	Un pedido no debería convertirse silenciosamente en un permiso indefinido de perfilado.
Evidencia de seguridad y retenciones legales	Preservar un conjunto documentado y de alcance limitado cuando un incidente o una obligación legal válida lo exija; revisar la excepción.	La eliminación rutinaria puede detenerse legalmente por una investigación concreta o un deber de conservación, pero la excepción no debería convertirse en el valor por defecto permanente.

El principio no es «eliminarlo todo sin importar las consecuencias». Es «hacer que cada campo retenido justifique su existencia».

¿Qué exigen realmente el GDPR, la ley suiza y las normas cripto?

El panorama jurídico respalda la minimización, pero no prescribe un calendario universal de retención. La aplicabilidad depende de la empresa, el cliente, la finalidad del tratamiento, el servicio y la jurisdicción. Lo que sigue es un mapa de alcance, no asesoramiento jurídico.

Marco	Qué puede afirmarse con seguridad	Qué no significa
GDPR	El artículo 5 exige que los datos personales sean adecuados, pertinentes y limitados a lo necesario, y que no se conserven más tiempo del necesario. El artículo 25 exige protección de datos desde el diseño y por defecto.	El GDPR no exige que todas las empresas recopilen cero datos ni prescribe una única arquitectura solo local.
Notificación de brechas según el GDPR	Un responsable notifica a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas posteriores a tener conocimiento, salvo que sea improbable que la brecha entrañe un riesgo para los derechos y libertades de las personas físicas. Se informa a las personas sin dilación indebida cuando es probable un riesgo alto, con sujeción a excepciones.	No todos los incidentes deben anunciarse a todo el mundo dentro de 72 horas.
FADP suiza	El artículo 7 exige protección de datos desde el diseño y por defecto, incluidos ajustes por defecto limitados al tratamiento necesario para la finalidad. El artículo 24 aplica el estándar «lo antes posible» cuando es probable que una brecha genere un riesgo alto.	La ley suiza no utiliza la formulación fija de 72 horas del GDPR.
Derecho contable suizo	El artículo 958f del Código de Obligaciones exige conservar los registros y comprobantes contables, junto con el informe anual y el informe de auditoría, durante diez años desde el final del ejercicio financiero.	No impone diez años de almacenamiento a telemetría no relacionada, perfiles de marketing, archivos de soporte ni datos de wallets.
MiCA	Un proveedor de servicios de criptoactivos incluido en su ámbito conserva registros determinados de servicios, actividades, órdenes y transacciones durante cinco años, y potencialmente siete tras una solicitud oportuna de la autoridad. La condición de CASP depende de si el proveedor presta profesionalmente a clientes uno o más de los servicios enumerados por MiCA. La custodia o el control de criptoactivos de clientes o de sus medios de acceso es específicamente relevante para el servicio de custodia; la transferencia, ejecución, canje, asesoramiento y otros servicios enumerados tienen criterios separados.	No todo vendedor de hardware es automáticamente un CASP, y MiCA no exige conservar todos los campos del cliente.
Reglamento de la UE sobre transferencias de fondos	Las obligaciones de información se aplican a todas las transferencias incluidas en su ámbito que involucren a un CASP de la UE. Las transferencias que excedan 1.000 € hacia o desde una dirección autocustodiada del cliente activan una evaluación adicional de si el cliente posee o controla esa dirección. La información prescrita se conserva durante cinco años; un Estado miembro solo puede permitir o exigir hasta cinco años adicionales tras evaluar la necesidad y proporcionalidad para fines de PBC/FT.	1.000 € no es un umbral general de la Travel Rule. Las transferencias puramente entre personas sin CASP quedan excluidas.
Implementación suiza de CARF	La SIF suiza afirma que el marco no puede implementarse antes del 1 de enero de 2027 y que su base jurídica no se aplica en 2026. El CARF de la OCDE cubre la identidad de usuarios declarables y las transacciones relevantes agregadas de los proveedores de servicios incluidos en su ámbito.	Suiza no implementó CARF el 1 de enero de 2026, y CARF no es una base de datos universal de las tenencias de todos los compradores de hardware wallets.

MiCA, la Travel Rule, DORA, la AMLA suiza y CARF no pueden aplicarse a CLAVI a partir de etiquetas como «hardware», «autocustodia» o «no custodial». El análisis puede cambiar con el acceso a claves, la capacidad de firma o intervención, los servicios de transferencia y cambio, los controles de smart contracts, los papeles contractuales y las relaciones continuadas con clientes. Las funciones de producción requieren una revisión jurídica cualificada antes de declarar públicamente una exclusión.

Las Directrices 02/2025 v2.0 finales del Comité Europeo de Protección de Datos, adoptadas el 7 de julio de 2026, añaden otro límite. Las direcciones de wallets y las claves públicas pueden ser datos personales cuando pueden vincularse razonablemente a una persona física. El cifrado puede proteger datos personales sin volverlos anónimos. Las directrices aconsejan por lo general no introducir datos personales on-chain porque el almacenamiento inmutable complica su eliminación, pero no constituyen una prohibición jurídica categórica de todo ese tratamiento.

Un modelo de límites de datos para el Personal Vault de CLAVI

CLAVI debería describir la privacidad como un límite inspeccionable, no como un adjetivo absoluto. La definición canónica de CLAVI presenta el producto como un Personal Vault para activos digitales, datos privados y comunicaciones privadas. El siguiente paso útil es una declaración categoría por categoría de aquello a lo que el operador puede acceder y lo que la empresa operativa todavía necesita tratar.

El modelo público debería responder siete preguntas para cada clase de datos:

1. Finalidad: ¿por qué existe este campo?
2. Campos mínimos: ¿qué atributos son estrictamente necesarios?
3. Sistema: ¿dónde se almacena el registro y está separado de otras finalidades?
4. Acceso: ¿qué roles y encargados pueden verlo?
5. Activador de expiración: ¿empieza el plazo en la recopilación, entrega, cierre del ticket, final de la relación o cierre del ejercicio?
6. Evidencia de eliminación: ¿cómo se cubren las copias de producción, réplicas, sistemas de encargados y copias de seguridad?
7. Excepción: ¿qué puede detener la eliminación, quién lo aprueba y cuándo se revisa?

Leído junto con Por qué CLAVI no compite con Ledger, el argumento no es que un único mecanismo de seguridad derrote todos los ataques. Un Personal Vault combina capas: generación de secretos, autoridad de firma, tratamiento local, control físico, datos corporativos cuidadosamente delimitados y un entorno jurídico. Cada capa tiene un modo de fallo distinto.

Nueve controles que convierten la minimización en operaciones

Una política reduce el riesgo solo cuando los sistemas y los encargados la aplican. Para proveedores de hardware y Personal Vaults, el conjunto práctico de controles es sencillo de expresar, aunque implementarlo resulte difícil.

1. Mantener un registro de finalidades a nivel de campo. «Datos de pedido» es demasiado impreciso. Nombre, dirección postal, teléfono, correo electrónico, SKU e identificador de seguimiento necesitan cada uno una finalidad y un responsable documentados.
2. Separar los datos por finalidad. Logística, contabilidad, soporte, marketing y evidencia de seguridad no deberían convertirse en un único perfil de cliente consultable.
3. Hacer que los campos opcionales sean realmente opcionales. Un requisito local de un transportista no debería convertirse en un requisito universal del checkout.
4. Usar vidas operativas cortas. Iniciar la expiración desde un evento definido y documentar las extensiones por devoluciones, garantías o disputas activas.
5. Verificar la eliminación de los encargados. El lenguaje contractual debería estar respaldado por tareas de eliminación, informes, muestreo o derechos de auditoría que cubran almacenes, transportistas y subencargados.
6. Diseñar las copias de seguridad para la expiración. Un registro no está eliminado de forma significativa si sigue siendo restaurable y consultable de manera rutinaria desde copias de larga duración. Cuando la retirada inmediata no sea práctica, hay que restringir la restauración y volver a aplicar la eliminación antes de que los datos restaurados se activen.
7. Mantener los secretos fuera del soporte. El personal, los formularios y las herramientas automatizadas nunca deberían pedir frases de recuperación, claves privadas ni contenidos del vault. Los adjuntos sensibles necesitan reglas explícitas de tratamiento y expiración.
8. Reducir lo que revela un paquete. El embalaje neutro, los datos genéricos del remitente y las opciones legales de locker o recogida pueden reducir la asociación, pero ninguna debería comercializarse como anonimato garantizado.
9. Planificar las excepciones sin normalizarlas. La evidencia de incidentes y las retenciones legales necesitan un alcance registrado, aprobación, fecha de revisión y proceso de liberación.

Ningún control vuelve estático el panorama. Los atacantes cambian de tácticas, las dependencias de software cambian, las cadenas logísticas cambian y la regulación cambia. La respuesta correcta no es recopilar indefinidamente «por si acaso». Es un mapa vivo de datos cuyas finalidades, encargados y evidencias de eliminación se revisan a medida que evoluciona el mundo.

Preguntas frecuentes

¿Fue hackeado el hardware de Trezor en agosto de 2026?

Trezor dice que no. Su aviso del 13 de agosto se refería a un acceso no autorizado en ShipMonk y a datos logísticos expuestos. Trezor afirmó que sus sistemas, hardware wallets, claves privadas y copias de seguridad no se vieron afectados. El aviso de Trezor no nombró el exploit; BleepingComputer informó después que correos de ShipMonk vinculaban el acceso con una vulnerabilidad de Metabase, identificada por Metabase como CVE-2026-72898.

¿Fue el incidente de COLDCARD una filtración de datos de clientes?

No se ha establecido ninguna vulneración de una base de datos de clientes en relación con la vulnerabilidad de COLDCARD. El problema confirmado estaba en la generación de seeds: un error de integración del firmware permitió que un generador de respaldo determinista aportara la aleatoriedad. Una campaña de phishing independiente explotó después la inquietud pública por el incidente, pero la evidencia pública no demuestra que utilizara una lista filtrada de clientes de Coinkite.

¿Qué información declararon Trezor y SafePal como expuesta?

Trezor informó de nombres, correos electrónicos, números de teléfono y direcciones de envío de 11.742 clientes, además de nombres, ciudades y correos electrónicos de otros 1.947. SafePal informó de nombres, correos electrónicos, números de teléfono, direcciones de envío y detalles de compra de aproximadamente 39.798 clientes. Son cifras declaradas por las empresas, no totales auditados de forma independiente, y ninguna de las dos comunicó la exposición de secretos de wallets en estos avisos.

¿Exige el GDPR que una empresa de hardware wallets no recopile ningún dato?

No. Cuando el GDPR resulta aplicable, exige que los datos personales sean adecuados, pertinentes y limitados a lo necesario para una finalidad definida, y que no se conserven más tiempo del necesario. También exige protección de datos desde el diseño y por defecto. Esto respalda la minimización, la separación y los calendarios de eliminación, pero no crea una regla universal de recopilación cero.

¿Exime automáticamente la autocustodia a un proveedor de la regulación financiera?

No. La condición regulatoria depende de lo que el proveedor haga realmente, incluido el control de claves, las facultades de firma o intervención, los servicios de transferencia o cambio, los roles en smart contracts y las relaciones continuadas con clientes. La venta de hardware por sí sola no resuelve el análisis. Por ello, las funciones de producción y el papel contractual de CLAVI requieren una revisión jurídica específica de cada jurisdicción antes de afirmar cualquier exclusión de MiCA, Travel Rule, AMLA, DORA o CARF.

¿Qué debería significar zero knowledge para un Personal Vault?

Para un Personal Vault, zero knowledge debería describir un límite técnico preciso: el operador no debería recibir ni poder recuperar los secretos del vault del usuario. No debería emplearse para sugerir que una empresa operativa carece de registros de pedidos, facturas, soporte o cumplimiento. Esos registros comerciales necesitan finalidades, controles de acceso y calendarios de retención separados.

¿Por qué debe verificarse la eliminación en logística y otros encargados del tratamiento?

La política de eliminación de un responsable no puede reducir la exposición si siguen activas copias en un almacén, transportista, procesador de pagos, plataforma de soporte, proveedor de copias de seguridad o servicio de marketing. Los contratos son necesarios, pero el control más sólido es una eliminación verificable en sistemas de producción, réplicas y copias de seguridad, con excepciones documentadas para pedidos sin resolver o conservación legalmente exigida.

La posición duradera: ningún secreto del vault, menos datos comerciales, más evidencia

El registro de cliente más seguro es el que nunca entra en los sistemas del operador. Este principio debería aplicarse con mayor rigor a claves privadas, material de recuperación y contenido protegido del vault. Para la información más limitada que una empresa operativa debe tratar, el estándar es distinto pero sigue siendo exigente: recopilar menos, separar finalidades, hacer expirar registros, verificar la eliminación posterior y documentar la excepción.

COLDCARD demuestra por qué la privacidad no puede sustituir una implementación criptográfica sólida. Trezor y SafePal demuestran cómo los sistemas comerciales pueden exponer a personas mientras el hardware de wallets queda fuera del incidente comunicado. Una definición más honesta de la seguridad de un Personal Vault debe proteger el secreto, proteger a la persona e identificar los datos que existen entre ambos.