Creemos que la billetera criptográfica móvil más segura es aquella que supera las limitaciones inherentes de su sistema operativo móvil. Por ejemplo, en iOS, CryptoKit de Apple no es compatible con curva elíptica secp256k1, un estándar para Bitcoin, Ethereum y muchas otras cadenas de bloques.

Esta limitación impide que los desarrolladores utilicen el elemento seguro de los dispositivos para el almacenamiento de claves y la firma de transacciones. Como resultado, las billeteras criptográficas móviles se clasifican como billeteras activas, ya que están conectadas a Internet y firman transacciones fuera de un elemento seguro utilizando una implementación de software de algoritmos criptográficos.

Esto significa que las claves privadas deben estar expuestas (al menos durante la firma) dentro de la memoria del entorno de la aplicación en el espacio aislado. Esto los deja más expuestos a posibles amenazas que una billetera que utiliza un elemento seguro para firmar transacciones.

A pesar de la imposibilidad de realizar la firma directamente en los elementos seguros, lo que ofrecería una mayor protección, nos hemos comprometido a proporcionar una billetera criptográfica móvil de código abierto que prioriza la seguridad, la transparencia y el control del usuario.

Nuestra arquitectura de seguridad está diseñada específicamente para:

• Admite múltiples cadenas de bloques
• Generar claves privadas con alta entropía, una medida de imprevisibilidad que refuerza la seguridad.
• Aproveche la criptografía probada en batalla para cifrar de forma segura las claves privadas de los usuarios, aprovechando el hardware de seguridad de los teléfonos móviles y las características de seguridad del sistema operativo.
• Ofrezca seguridad mejorada con una contraseña generada por el usuario para usuarios avanzados que deseen un nivel adicional de cifrado (además de la protección del llavero del sistema operativo para la clave de descifrado)
• Crear una base sólida para la futura incorporación de nuevos tipos de gestión de claves, como carteras de hardware y sistemas basados ​​en quórum MPC.

La ventaja del código abierto

Como uno de sus principios fundamentales de seguridad, Monedero Kraken es un software gratuito y de código abierto, distribuido bajo la licencia MIT. Al crear una nueva billetera desde cero, era importante para nosotros ayudar a fomentar el ecosistema distribuido y de código abierto.

Sin código fuente abierto, Kraken Wallet requeriría una gran cantidad de confianza sin transparencia. Esto daría a los clientes menos protección; No podría verificar, modificar o ejecutar el cliente usted mismo si así lo deseara. “¡No confíes, verifica!” No es sólo una máxima de la industria, es uno de nuestros principios rectores.

El código abierto de nuestro software cumple dos objetivos fundamentales que fijamos inicialmente para este producto: minimización de la confianza verificable y auditable:

• Verificabilidad: La capacidad de verificar que los supuestos de seguridad presentados en esta publicación de blog son ciertos. Cualquiera puede mira el código fuente para comprender específicamente qué se hace y qué no se hace en esta billetera. 

• Auditabilidad: La capacidad de verificar que el resultado de nuestra implementación de seguridad sea correcto e informar cuando no lo sea. Hemos contratado a equipos internos y externos para realizar auditorías de seguridad varias veces antes del lanzamiento. En el futuro, cualquiera podrá auditar el código y producir un informe sobre sus hallazgos.

Generación e importación de claves

React Native, si bien es una herramienta poderosa, no tiene un módulo criptográfico incorporado. Para navegar por esto utilizamos una implementación puramente js (crypto-browserify) del módulo criptográfico de NodeJS. El método crypto.randomBytes(), que genera los bytes aleatorios reales que necesitamos durante la generación de claves, es manejado por reaccionar-nativo-obtener-valores-aleatorios polirelleno.

React-native-get-random-values ​​utiliza código nativo para utilizar el Generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) disponible en el dispositivo para generar números aleatorios. Prácticamente en todos los dispositivos modernos, este generador de números aleatorios está respaldado por un generador de números aleatorios de hardware seguro.

Durante la inicialización de la billetera, extraemos entropía del CSPRNG y la convertimos en una semilla mnemotécnica usando paquetes npm bien establecidos (BIP32, BIP39).

Las claves se convierten, almacenan y presentan al usuario según el estándar BIP39, que ofrece un método mnemotécnico de fácil copia de seguridad con interoperabilidad para la mayoría de las billeteras del ecosistema. La función de importación admite la recuperación de semillas compatibles con BIP39, que brindan la mejor interoperabilidad en el ecosistema. 

Gestión de claves 

Kraken Wallet contiene dos valores secretos (la semilla y el mnemotécnico) y múltiples valores no secretos (pero aún privados), como direcciones de billetera, nombres de billetera y descripciones de transacciones.

El material de clave privada (semilla/mnemotécnica) se almacena en Keychain (en iOS) y Keystore (en Android). El material de clave pública y los datos no confidenciales (claves públicas extendidas, direcciones y descripciones) se almacenan en la base de datos cifrada de la aplicación (utilizando Reino).

Existen múltiples controles de seguridad protegiendo los datos:

• Bloqueo de la aplicación: una cadena de 64 bytes generada aleatoriamente almacenada en Keychain o Keystore. El acceso al secreto está protegido con requisitos de presencia del usuario: autenticación biométrica o mediante contraseña.

• Contraseña: Proporcionado por el usuario y no guardado en un dispositivo. En cambio, el usuario debe proporcionar la contraseña manualmente cada vez que la aplicación se lo solicite. La billetera determina si la contraseña es necesaria consultando dos indicadores (is_storage_encrypted y is_seed_encrypted) almacenados en Keychain o Keystore. El algoritmo Argon2 se utiliza como función de derivación de claves.

• Cifrado de base de datos: La base de datos (Reino) se utiliza para almacenar datos no secretos. Los datos se cifran con una clave aleatoria de 64 bytes.

• Mecanismo de bloqueo: Introducir una contraseña incorrecta provoca retrasos antes de que se puedan realizar intentos de contraseña posteriores. Este mecanismo disuade eficazmente los ataques de contraseñas por fuerza bruta. La información sobre los parámetros de bloqueo, como el número de intentos y la duración de los retrasos, se almacena de forma segura en Keychain o Keystore.

La clave de cifrado inicial, mnemónica y de base de datos siempre se almacena en forma cifrada.

• Cuando no hay protecciones habilitadas: La clave de cifrado semilla, mnemónica y Realm se almacena directamente en Keychain o Keystore sin un control de acceso de presencia del usuario.
• Cuando el bloqueo de aplicaciones está activado: El mnemónico y la semilla primero se cifran con el secreto de bloqueo de la aplicación y luego se almacenan de forma segura en Keychain o Keystore. La clave de cifrado de Realm también se almacena directamente en el llavero o almacén de claves.
• Cuando la protección con contraseña está habilitada: El mnemónico y la semilla se cifran con la contraseña, mientras que la clave de cifrado Realm se cifra con la contraseña solo si is_storage_encrypted se configuró en verdadero.
• Cuando tanto el bloqueo de aplicaciones como la protección con contraseña están habilitados: El mnemotécnico y la semilla están cifrados con una contraseña (primera) y un bloqueo de aplicación (segunda). La clave de cifrado de Realm se cifra solo con la contraseña y solo si is_storage_encrypted se configuró en verdadero.

Uso de claves

La semilla/mnemónico se almacena en Keychain o Keystore y juega un papel crucial en las operaciones criptográficas. Cuando es necesario generar una nueva dirección de billetera o firmar una transacción, derivamos la información necesaria, como la clave privada, de esta semilla.

Sin embargo, es importante tener en cuenta que la clave privada debe cargarse en la memoria durante estas operaciones. Esta necesidad surge de las limitaciones que mencionamos anteriormente sobre las billeteras móviles y la falta de acceso directo al elemento seguro para la firma de transacciones.

• Firma de transacciones (envío de tokens)
• Firma de datos de WalletConnect (manejo de solicitudes de sesión)
• Agregar una nueva billetera
• Habilitar cadenas de testnet (agregar billeteras de testnet)
• Mostrando el mnemotécnico
• Verificando el mnemotécnico
• Activar y desactivar el bloqueo de aplicaciones
• Habilitar y deshabilitar la contraseña

Se realiza autenticación biométrica adicional para las siguientes funcionalidades:

• Habilitar el bloqueo de aplicaciones
• Borrando todos los datos
• Eliminar una billetera (cuenta)
• Habilitar o deshabilitar una contraseña (además de la recuperación del bloqueo de la aplicación)
• Abriendo la aplicación
• Mover la aplicación al primer plano
• Ver claves públicas extendidas
• Conexión a una aplicación descentralizada (dApp)

Además, es posible que se solicite la contraseña para abrir la aplicación. El llavero y el almacén de claves siempre se utilizan a través del reaccionar-nativo-llavero envoltura:

• El contenedor genera una nueva clave en Llavero o Almacén de claves para cada elemento
• El contenedor es responsable de pasar los indicadores de configuración correctos para Keychain y Keystore.
• La billetera siempre solicita al contenedor que configure las banderas para que el dispositivo deba estar desbloqueado para acceder a la clave.
• Una verificación de presencia de usuario (biométrica) está configurada para que se base en el tiempo y la verificación es válida durante 5 segundos; la verificación de presencia del usuario no se realiza por acceso

El algoritmo de cifrado es el mismo para todos los elementos:

• La clave se deriva con Argon2id de un secreto normalizado por NFC
• La sal de Argon2id es la identificación única del dispositivo.
• El modo de cifrado es AES-GCM
• El vector de inicialización (IV) para AES es de 16 bytes aleatorios.
• La etiqueta de autenticación para AES debe tener una longitud de 16 bytes.

firma de transacciones

Además de las medidas mencionadas anteriormente con respecto al almacenamiento de claves, la biometría y la protección con contraseña, la firma de transacciones sigue siendo un área crítica de enfoque para la mejora continua. Como paso inicial, hemos implementado varias medidas notables en este ámbito, que incluyen:

Simulación de transacciones

Utilizamos servicios API externos (como Blowfish y otros) para comprobar los posibles niveles de “severidad” que una transacción puede aportar al usuario (una puntuación de riesgo). Esto va desde pantalla de bloqueo completo para posibles transacciones maliciosas (o firma de mensajes) hasta advertencias de los diferentes niveles de precaución que debe tener el usuario antes de firmar o confirmar una transacción. 

Otras medidas incluyen:

• Validación de dirección para asegurarse de no enviar a una dirección incorrecta
• Direcciones que siempre son visibles en su totalidad para garantizar que el usuario no sea blanco de ataques específicos relacionados con la composición de direcciones.
• Validación de red y advertencias para asegurarse de que el usuario no envíe a la red incorrecta
• Verificaciones de cordura de tarifas para asegurarse de que el usuario no pague de más por una transacción

Privacidad de la red

Para proteger la privacidad y los datos personales de los usuarios de manera que estos datos no se filtren en solicitudes de red (especialmente a servicios de terceros), hemos desarrollado una puerta de enlace API para solicitudes de proxy. Este proxy nos permite no pasar solicitudes de usuarios a servicios de terceros y no revela la IP de un cliente a proveedores públicos o externos. 

Este servicio de backend es básicamente una API para consultar datos públicos de blockchain. Dentro de la arquitectura de seguridad de la billetera, su propósito es encapsular esta funcionalidad detrás de una API común en todas las cadenas de bloques para que Kraken Wallet no tenga que implementar comportamientos específicos de la cadena de bloques para la consulta de datos.

Este servicio de backend define esta API común. En última instancia, envía solicitudes a otras partes de las que obtiene los datos reales. No indexa las cadenas de bloques ni mantiene el estado.

Supuestos de seguridad

Nuestra arquitectura de seguridad opera según algunos supuestos clave para una protección óptima. Suponemos:

• El dispositivo del usuario no está rooteado, ni el sistema operativo está desactualizado y es susceptible a vulnerabilidades críticas que podrían otorgarle a un atacante acceso a la memoria del dispositivo.
• El paquete Keychain o Keystore proporciona una protección lo suficientemente fuerte
• El sistema operativo móvil ofrece una sólida zona de pruebas entre los procesos de las aplicaciones, lo que garantiza que la memoria que contiene datos confidenciales, como semillas, se administre correctamente.

Funcionalidad adicional

• La aplicación funciona según el principio de almacenar solo los datos mínimos que necesita para ejecutar la billetera.
• No se utilizan kits de desarrollo de software (SDK) de informes de fallos ni análisis de terceros en el cliente.
  • Con nuestros esfuerzos por no filtrar ningún dato a terceros, no tendría sentido incluir un seguimiento de datos adicional, lo que significa que no encontrará ningún software de análisis ni de informes de fallos en el cliente.
• No se permiten ni implementan actualizaciones inalámbricas (fuera del flujo de actualización habitual de AppStore/Play Store) en el código base.
  • El usuario puede esperar un software compilado que no se puede actualizar sin su consentimiento.
• Lista de tokens y sistema de reputación.
  • Para ayudar a los usuarios a administrar sus tokens, implementamos un sistema de lista y reputación basado en los activos proporcionados por Kraken y otros terceros.
• Spam de NFT
  • Un esfuerzo inicial que planeamos seguir mejorando es la detección de spam y ataques relacionados con spam, donde el spam se archiva automáticamente en la carpeta del usuario.

Auditoría de seguridad externa

La seguridad de nuestra billetera de autocustodia fue evaluada rigurosamente a través de una auditoría realizada por Sendero de bits, una firma de auditoría de seguridad reconocida en la industria. Esta auditoría abarcó un examen detallado de nuestra base de código y arquitectura del cliente, con el objetivo de identificar y abordar posibles vulnerabilidades de seguridad.

Para garantizar la transparencia y brindar información sobre la seguridad de nuestra plataforma, los resultados de esta auditoría están disponibles públicamente. Este acceso abierto permite a los usuarios e interesados ​​revisar los resultados del análisis de seguridad realizado por Trail of Bits. El informe sirve como un recurso importante para comprender las medidas de seguridad que tenemos implementadas y nuestro compromiso de mantener un entorno seguro para nuestros usuarios.

Priorizando la seguridad, la transparencia y el control de los usuarios

Kraken Wallet logra un delicado equilibrio entre conveniencia y protección sólida frente a las limitaciones inherentes de la plataforma. Nuestro enfoque siempre ha sido comenzar con una estructura de billetera interoperable que sea ampliamente reconocida. Esta base sólida prepara el escenario para que podamos innovar y agregar nuevas capacidades, con el objetivo de ofrecer a nuestros usuarios una solución de seguridad de primer nivel en constante evolución para la autocustodia de sus criptoactivos.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://blog.kraken.com/product/kraken-wallet/kraken-wallet-security