Prueba de reservas

Auditoría

Aprenda acerca del proceso de auditoría de Kraken

Proceso de auditoría de prueba de reservas de Kraken

Introducción

Este documento proporciona información y orientación sobre el proceso de auditoría de Kraken.

Kraken mantiene todas sus garantías, y realizamos una auditoría independiente y criptográficamente verificada para demostrar a terceros, incluyendo a nuestros clientes, que los fondos de los clientes están en buen estado. La transparencia y las auditorías verificadas de forma independiente son fundamentales para garantizar que las empresas mantengan todas las reservas de los fondos de los clientes. La aplicación de un sistema de prueba de reserva pública es técnicamente posible. Sin embargo, hay importantes factores externos, entre ellos la privacidad del usuario, que deben ser cuidadosamente consideradas en la implementación específica de un esquema de prueba de reserva pública. Creemos que los exchanges y monederos deben crear confianza a través de la transparencia de cuentas y que tenemos la responsabilidad de abordar el deseo de transparencia de la comunidad.

Durante las últimas semanas, Kraken ha desarrollado y completado con éxito una auditoría independiente, criptográficamente verificada, líder en la industria. Estamos orgullosos de presentar este resumen de nuestro proceso a la comunidad global de las criptomonedas. Creemos que la industria del Bitcoin es capaz de proporcionar un nivel de seguridad y responsabilidad que supera a la industria de servicios financieros tradicional, y nuestro objetivo es liderar la carga hacia una transparencia óptima.

Panorama actual

El ímpetu de esta iniciativa es la propuesta de Greg Maxwell para que los exchanges y las monederos demuestren sus reservas de Bitcoin. [1]

Hasta la fecha, las auditorías realizadas por la industria Bitcoin han sido opacas, superficiales y sin una verificación criptográfica verificable y visible al público de forma independiente. Kraken busca proporcionar una prueba de concepto y establecer estándares industriales con una mayor transparencia y responsabilidad desde el ecosistema de la divisa digital que otros puedan aplicar y mejorar.

Calidad del proceso

La propuesta de Maxwell habría requerido que las compañías de bitcoins revelaran todas las direcciones que contienen saldo. Este método daría como resultado el conocimiento público de los monederos de Bitcoin de los exchanges o de los proveedores de monederos, así como las tenencias totales, información que es comercialmente sensible y presenta riesgos de seguridad potenciales para las empresas y los usuarios. Peor aún, daría lugar a un incumplimiento inadmisible de la privacidad del usuario, en el cual terceros podrían rastrear el historial y la trayectoria de las tenencias individuales y la actividad financiera sin causa ni debido proceso.

Nuestro proceso no requiere que revelemos nuestro saldo total, direcciones o claves al público. Al combinar y aprovechar las fortalezas de un auditor confiable y una criptografía verificable públicamente, la auditoría de Kraken representa el equilibrio ideal entre privacidad y transparencia.

Dado que Bitcoin es la criptomoneda dominante, nuestra auditoría inicial cubrirá solo las reservas de Bitcoin. Sin embargo, las auditorías para otros activos serán consideradas para el desarrollo en el futuro.

Resumen del proceso

  • Fase 1: el auditor verifica los fondos de todo el monedero de Kraken

    Kraken le da al auditor todas nuestras direcciones públicas y las firma. El hash de bloque en el momento de la firma es parte del mensaje firmado y se puede utilizar como registro de tiempo para cuando se realizó la firma. Las firmas de esas direcciones públicas se verificarán y el auditor usará la cadena de bloques de bitcoin para extraer la cantidad total disponible en esas direcciones en un momento determinado.

    El código requerido para esta fase fue escrito por Michael Gronager, Director de Operaciones de Payward, y puede ser de código abierto en el futuro en su totalidad. Sin embargo, la mayoría del código ya es de código abierto porque el código está basado en libcoin. [2]

  • Fase 2: el auditor verifica que los saldos de los usuarios de Kraken coinciden con los fondos del monedero de Kraken

    Kraken le da al auditor los saldos de BTC de cada uno de nuestros usuarios y genera un árbol de Merkle. El auditor publicará el hash del nodo raíz para que todos lo vean, y afirmará, si es cierto, que las tenencias totales representadas por el hash raíz se aproximan mucho al valor que ve en nuestro monedero de la cadena de bloques. Este flujo también garantiza que Kraken no oculte nada en ninguno de los nodos que conducen al nodo raíz.

    Para esta fase de la auditoría, el auditor tendrá acceso al código fuente para el programa generador de árboles y al archivo de datos de saldos de cuentas individuales. Kraken lanzó el código C++ para esta fase bajo la licencia MIT: https://github.com/payward/krakendb

  • Fase 3: los usuarios verifican de forma independiente que sus saldos de cuenta se incluyeron en los datos utilizados por el auditor

    Kraken les da a los usuarios la cantidad que informamos al auditor, así como los nodos (y nodos adyacentes) desde su cuenta a la raíz (que coincide con la publicada por el auditor). También revelamos el método hash utilizado para generar el hash para el nodo, de modo que puedan verificar que el nodo representa la cantidad que reclamamos.

    Esto permitirá a los usuarios verificar por sí mismos que su cuenta se incluyó en los datos verificados por el auditor.

Deficiencias

En esta sección, describimos algunas de las deficiencias de esta auditoría. Tenga en cuenta que obviamente no es una lista exhaustiva de debilidades. Sin embargo, debido a que valoramos la transparencia para nuestros usuarios, estamos proporcionando antecedentes informativos sobre deficiencias específicas que hemos identificado hasta el momento en el proceso de la auditoría.

A diferencia de los activos físicos, la información no necesita ser eliminada de la posesión de una persona para ser adquirida por otra. Por lo tanto, Kraken u otra compañía que emplea este método de auditoría no puede probar que las claves privadas no hayan sido duplicadas por un atacante. Tampoco podemos probar que tenemos posesión exclusiva de los fondos auditados. Sólo podemos demostrar que para el momento de la auditoría, éramos uno de los poseedores de las claves privadas.

Probablemente, la auditoría completa no pueda ser realizada bajo pedido, sin previo aviso. Dada la información requerida, estructura de la auditoría y las prácticas estándar de la industria para seguridad de cold storage al momento actual, no es posible realizar una auditoría sorpresa el mismo día. Prevemos una auditoría ‘ligera’ basada en una auditoría completa previa, confiando en firmas generadas previamente, que pueden realizarse con más frecuencia.

El auditor debe ser confiable y competente. La comunidad también debe creer que el auditor valúa su reputación y es técnicamente capaz. Hay varias oportunidades en este proceso de auditoría donde un auditor menos técnico o menos paranoico podría ser engañado por el auditado. También hay oportunidades para que el auditor comprometa intencional o inadvertidamente información confidencial de la compañía y del cliente. Tanto el auditor como el auditado deben considerar quien proporciona al computador, al espacio de auditoría, el blockchain, la conexión a Internet, el router, DNS, etc. Si el objetivo es esconder un fraude de billones de dólares, es de suponer que se haría todo lo posible para comprometer la auditoría.

La auditoría no se renueva continuamente en tiempo real. Es posible que las claves se hayan perdido o se hayan robado fondos desde la última auditoría. La auditoría completa renueva la afirmación que las claves no se hayan perdido, aunque crea una mayor exposición a amenazas porque es necesario utilizar las claves de cold storage para realizar la auditoría.

El auditado puede pedir prestado fondos temporalmente o compartir claves con el verdadero propietario de los fondos para aprobar una auditoría.

El auditor puede coludir con el auditado o sucumbir a sus amenazas.

Encurso

Tenemos la intención de realizar auditorías periódicas de forma continua. Como no hay un auditor universal de confianza, podemos usar un auditor diferente o múltiples auditores cada vez. Esto satisface a aquellos que pueden dudar de las credenciales de un auditor individual en particular.

Futuroscambios y mejoras

Esperamos recibir comentarios de la comunidad que nos ayudarán a nosotros y a otros a mejorar este proceso para futuras auditorías. Como miembros de esta comunidad, también esperamos trabajar con organizaciones de la industria como DATA (www.datauthority.org) para ayudar a desarrollar estándares básicos, herramientas escalables y un manual integral para que otros en la industria realicen auditorías similares.

Referencias

[1] Resumen por Zak Wilcox: https://iwilcox.me.uk/2014/proving-bitcoin-reserves. Queremos agradecer a Greg Maxwell por sus ideas.

[2] libcoin es la transformación de bitcoin en bibliotecas modulares y reutilizables: https://github.com/libcoin/libcoin

Como verificarel balance de su cuenta individual en la auditoría de Kraken

Vea tambien: Proceso de auditoría de prueba de reservas de Kraken.

Estas instrucciones explican cómo verificar criptográficamente el balance de su cuenta en Kraken y su inclusión en la auditoría.

Esta verificación reflejará el balance de Bitcoin (XBT) de su cuenta en el momento de la auditoría.

 

  • Paso 1

    Si aún no ha iniciado sesión, inicie sesión en su cuenta en Kraken.

    Diríjase a https://www.kraken.com/ y asegúrese de que la barra de direcciones de su navegador muestre "https://www.kraken.com/"

  • Paso 2

    Haga clic en "Fondos" -> "Auditoría" -> "Bitcoin (XBT)" a la izquierda.

    Figura 1. Kraken Bitcoin Página de la auditoría

  • Paso 3

    Ver la información sobre su cuenta verificada por el auditor

    • El Tiempo de la auditoría, que es la marca de tiempo utilizada por el auditor.

    • El Código de envío, que es 64 bit salt.

    • La Cantidad de Bitcoins mantenido en su cuenta en el momento de la auditoría. Este es el valor del balance para su cuenta que le proporcionamos al auditor.

    • Notas incluye información del auditor que prueba el hash raíz que se utilizó para la auditoría. También se proporciona un enlace a un informe firmado y detallado.

    • Los Hashes desde el hash de nodo hasta el hash raíz, incluidos los hashes adyacentes. Los valores de hash en su ruta directa se muestran con un asterisco (*) para diferenciarlos del hash de nodo adyacente. Con estos hashes, puede verificar que su nodo se incluyó en la raíz:

    • La primera línea debe coincidir con el valor de hash raíz dado por el auditor.

      Si desea verificar su propio hash de nodo (el último hash con un * en la lista), haga lo siguiente:

      
      sha256(sha256(<c de presentaci> || “:” || <cantidad con el punto decimal eliminado y los primeros eliminados>))</cantidad></c>

      Ese valor debe coincidir con el último valor dado en los hashes.

      Código de ejemplo

      Código de envio: 379377cd8190f9bf

      Cantidad: 0.01500000

      Python

      
      import hashlib; print(hashlib.sha256(hashlib.sha256(b'379377cd8190f9bf:1500000').digest()).hexdigest());
      

      PHP

      
      echo hash('sha256', hash('sha256', '379377cd8190f9bf:1500000', true));
      

      Resultado

      
      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      Puede verificar completamente sus ramas de Merkle haciendo un hash de cada par de hashes (o "tupla"). El formato es:

      
      sha256(left-hash || right-hash)
      

      El resultado debe coincidir con el hash de tupla anterior (o el hash de raíz) con un * en él. Esto se haría para todas las tuplas.

      Con la excepción del hash raíz, todos los hashes se dan como tuplas, representando el hash izquierdo y el hash derecho en ese orden. Se le da un * a los hashes que representan sus nodos directos.

      Código de ejemplo:

      Hashes:

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

      
      import hashlib; print(hashlib.sha256(b'c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'.decode('hex'))).hexdigest();
      

      PHP

      
      echo hash('sha256', hex2bin('c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'));
      

      Resultado

      
      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3