Multigrado: una revolución incompleta

Humo Negro y Estado de la Compresion del Motor Diesel (Junio 2019).

Anonim

el autor está involucrado en el proyecto Ethereum. El autor no tiene ninguna relación con BitGo, Bitrated, Codius o CryptoCorp.

Actualización: Ben Davenport de Bitgo ha respondido, diciendo que ya tienen una API para admitir el uso de su servicio como oráculo puro de CryptoCorp y que pronto intentan proporcionar una extensión de navegador. Los felicito por su respuesta rápida y dedicación a las buenas prácticas de seguridad. GreenAddress también proporciona una API que permite que las aplicaciones se conecten a sus servicios.

Después de varios años de mejorar la infraestructura y la tecnología, parece que las tecnologías de carteras de múltiples firmas finalmente están avanzando en el mundo de Bitcoin. Greenaddress. it y BitGo se han convertido en los principales contendientes en el espacio, y este último ha recaudado recientemente $ 12 millones en fondos de capital de riesgo y se jacta de que almacena más de $ 100 millones en BTC. La creciente aparición de multisig es muy bienvenida en el ecosistema de Bitcoin, ya que se conocen los beneficios y los componentes del protocolo de Bitcoin han estado disponibles durante casi dos años y ahora los consumidores de la corriente principal pueden comenzar a dar sus frutos. Los beneficios particulares de multigrado incluyen aplicaciones de custodia de consumidor-comerciante, permitiendo un mercado abierto y libre para que los árbitros hagan el comercio de Bitcoin relativamente seguro y libre de fraude en áreas donde tales protecciones son necesarias, así como el caso de uso personal de carteras de ahorro. proteger a los usuarios de la pérdida o el compromiso de cualquiera de sus claves privadas.

En un momento en que la protección del consumidor surgió como preocupación, con las inminentes regulaciones de BitLicense que imponen un gran nivel de restricción a las empresas de criptomonedas, multisig ofrece además una promesa como alternativa a un enfoque centrado en la regulación para la protección del consumidor - en lugar de tratar de estar absolutamente seguros de que cada negocio individual es confiable, podemos configurar sistemas para eliminar al máximo los puntos únicos de falla y confiar principalmente en la seguridad en los números. Sin embargo, a pesar de ser una tecnología potencialmente revolucionaria como multigrado, también existe el riesgo de ser sobrevalorado y tergiversado, ya que algunas empresas pueden tratar de reclamar el beneficio de marca de tener sus direcciones con un "3" sin tomar el esfuerzo de ser realmente confianza. -gratis. El objetivo de este artículo será definir un concepto de "buen multigrado": tecnologías que eliminen la necesidad de confianza en los individuos y promuevan la protección del consumidor, y "mal juego múltiple", el mero teatro de seguridad criptoeconómico, y traten de determinar la línea divisoria. entre los dos.

The Client Side Revolution

Antes de llegar al multigrado real, primero debemos diseccionar una tecnología particular que está siendo utilizada por varias compañías para mejorar la seguridad y reducir la necesidad de confianza: el lado del cliente Aplicación Web.Antes de que la aplicación web del lado del cliente se afianzara, había dos paradigmas dominantes en los clientes de Bitcoin. Primero, están los clientes de escritorio, programas que descarga directamente a su computadora. El beneficio de los clientes de escritorio es que los usuarios tienen las claves privadas en sus propias máquinas, por lo que no es necesario confiar en terceros para almacenar los fondos. Sin embargo, esto tiene un costo de usabilidad: el usuario necesita descargar una aplicación. En segundo lugar, están las carteras web del lado del servidor, donde un tercero tiene los bitcoins para usted y le da acceso a cómodamente depositar y retirar utilizando una cuenta similar a una cuenta de Google o Facebook sin descargar ningún software. Esto tiene un alto grado de usabilidad, pero a costa de requerir confianza.

Las aplicaciones web del lado del cliente son una elegante tercera solución: aunque el acceso al sitio web todavía se realiza mediante una aplicación web, sin inconvenientes de descarga del software requerido, las claves privadas se almacenan y las transacciones se firman en el lado del cliente dentro de la web navegador usando Javascript. Por lo tanto, aunque la aplicación tiene el mismo nivel de conveniencia que la interfaz web proporcionada por una billetera confiable del lado del servidor, el servidor no tiene acceso a sus claves privadas y usted lo hace, lo que parece ser lo mejor de ambos mundos. La billetera del cliente más popular en este momento es probablemente blockchain. información

Ahora, evaluemos los méritos de este paradigma. El Javascript del lado del cliente ciertamente no está exento de críticas; incluso hay un artículo completo de Matasano titulado "JavaScript Criptografía Considerado Dañino". Aunque la pieza es bastante extrema en su negación de absolutamente cualquier beneficio de la criptografía basada en el navegador del lado del cliente, sí tiene puntos válidos, en particular, que cuando descargas el navegador Javascript todavía confías en la fuente. Es decir, si blockchain. información o un empleado deshonesto de blockchain. Si la información lo deseaba, o si un gobierno los extorsionaba, simplemente podrían enviarle un código de navegador que tomaría su clave privada y firmaría una transacción enviando todos sus fondos a su dirección, y nunca sabría la diferencia hasta que sea demasiado tarde. Ahora, si se lleva este argumento al extremo, se puede argumentar que incluso con un cliente descargable es posible distribuir una versión que robe sus claves privadas, pero intuitivamente parece obvio que esto es mucho menos problema en ese caso: particularmente porque solo está descargando el software una vez.

Entonces, ¿en qué medida confía en el proveedor de software en cada caso? Analicemos qué sucedería para que se produzca un exploit exitoso en cada caso:

  • Cliente de escritorio, creado a partir de la fuente : el proveedor o un atacante que pirateó los sistemas del proveedor necesitarían enviar un parche en el repositorio del cliente en Github incluyendo una puerta trasera, y necesitaría descargar el cliente antes de que alguien dentro o fuera de la organización escaneara el código fuente y notara
  • Cliente de escritorio, binario (la opción que usan las personas normales) ): el proveedor, o un atacante que pirateó los sistemas del proveedor, necesitaría compilar y publicar una versión del cliente, incluida una puerta trasera, y necesitaría descargar antes de que alguien dentro de la organización detecte la mala conducta (es demasiado difícil de descompilar) binarios para detectar puertas traseras hasta que sea demasiado tarde en la mayoría de los casos, por lo que tendría que ser interno, aunque a largo plazo una vez que se encuentra un exploit es posible aislarlo)
  • Aplicación web del navegador del lado del cliente - un atacante necesidad de deslizar rápidamente una versión del cliente, incluida una puerta trasera en la red de entrega de contenido, y solo todos aquellos que inician sesión entre esa hora y la hora en que se desconecta la versión maliciosa son vulnerables
  • Aplicación web del navegador del lado del servidor - un atacante necesitaría acceder a la billetera fría del sitio, en cuyo punto la cuenta de cada usuario estaría comprometida

Por lo tanto, podemos ver una jerarquía de seguridad, donde cuanto más abajo estás menos seguro estás y cuanto más necesito confiarUna distinción particular es la diferencia entre un atacante a corto y a largo plazo: ¿es la compañía la que es mala o simplemente alguien salta a sus servidores a través de algún exploit durante unos minutos u horas antes de darse cuenta? Contra atacantes a largo plazo, solo descargar versiones anteriores directamente de un repositorio de código abierto puede ayudarte; Contra los atacantes a corto plazo, las aplicaciones de escritorio binarias funcionan razonablemente bien, e incluso las aplicaciones web del navegador del lado del cliente pueden limitar la tragedia a un pequeño número de usuarios.

En general, sin embargo, existe una división fundamental entre los casos de escritorio y los casos del navegador: en los dos primeros, si un atacante obtiene acceso durante un corto período de tiempo, si la seguridad está configurada correctamente, eso no es un problema en absoluto, porque el problema se puede corregir a tiempo, pero en los últimos casos sí lo es. Por lo tanto, las aplicaciones basadas en el navegador del lado del cliente proporcionan solo una ganancia parcial de seguridad sobre las billeteras basadas en servidor.

¿Cómo se puede solucionar el problema? El enfoque más simple es pasar de las páginas web del lado del cliente a las extensiones del navegador. Esto resuelve el problema casi por completo; desde una perspectiva de seguridad, una extensión de navegador es casi exactamente equivalente a una aplicación de escritorio ejecutada dentro de un entorno interpretado como Java o Python. Sin embargo, esto tiene el costo de agregar un paso adicional: el usuario debe descargar una extensión de navegador en lugar de simplemente confiar en el servidor, y por esta razón, incluso si sitios como blockchain. la información ofrece una versión segura de la extensión del navegador de la mayoría de las personas que todavía usan el sitio web.

Tenga en cuenta que todo lo anterior ciertamente no es una acusación contra el navegador del lado del cliente Javascript; todo lo que dice es que el navegador del lado del cliente Javascript no es mucho más seguro o sin confianza que el enfoque en el que el servidor guarda todo su dinero. Hay razones más que la seguridad y la confianza para escribir una aplicación de criptomoneda de Javascript del navegador del lado del cliente; la más grande es la conveniencia, ya que cuanto más se hace en el navegador, menos infraestructura necesita usted como desarrollador de la aplicación para administrarse usted mismo. La aplicación web weba usa Javascript para el cliente por esta razón exacta (conveniencia de desarrollo y robustez contra ataques de denegación de servicio); por supuesto, confías en Ethereum cuando usas la aplicación, pero eso no es un problema porque confías en que Ethereum desarrolle la plataforma de todos modos. Por lo tanto, si admitimos que confiamos en proveedores como blockchain. información, podemos decir que su uso de la criptografía del lado del cliente es legítimo. Sin embargo, para proveedores multigrado, la historia es completamente diferente …

The Fused Multisig Wallet

La discusión previa sobre la seguridad del lado del cliente es importante porque atrae la atención sobre un ingrediente importante, ya veces olvidado, de la seguridad cuando se trata de protocolos criptográficos: la seguridad del código fuente en sí. Aunque un protocolo criptográfico como Bitcoin puede ser teóricamente libre de confianza, en realidad casi todos no son técnicamente competentes para evaluar la totalidad del código por sí mismos.Los tipos de exploits inteligentes desarrollados en el concurso Underhanded C muestran bastante bien lo difícil que es asegurarse de que un software esté completamente libre de ataques; por lo tanto, como resultado, para casi todos, excepto el autor original de los protocolos de un programa, todavía se requiere una cierta cantidad de confianza.

En el caso de multisig, lo que estamos tratando de hacer es eliminar explícitamente la necesidad de confiar en cualquier entidad individual. En general, hay dos formas en que se implementa multigrado. El primero llamaremos 2 de 2 extendidos. El concepto básico de 2 de 2 es simple. El usuario posee una clave, tal vez a través de una autorización de compra derivada de contraseña, o una clave generada aleatoriamente encriptada en el almacenamiento del navegador o en una aplicación del lado del cliente, y el servidor conserva otra clave. Cuando el usuario desea firmar una transacción, inicia sesión en la billetera de su computadora y luego genera una transacción enviando fondos desde su dirección al destino deseado y lo firma con su clave privada. Luego, la transacción se envía al servidor. El servidor luego realiza un control de detección de fraude; por ejemplo, puede enviar un código de confirmación al número de teléfono del usuario y pedirle al usuario que lo escriba. Si tiene éxito, el servidor firma la transacción y la envía.

Por defecto, sin embargo, este esquema es frágil. Si su computadora está hackeada, o si olvida su contraseña, entonces pierde el acceso a la billetera y el servidor no puede hacer nada al respecto. De manera similar, si la compañía que mantiene el servidor sufre un accidente o se daña o desaparece, usted pierde el acceso. La extensión a 2 de 2 es el parche para este problema. Básicamente, cada vez que su cliente produce una nueva transacción, en realidad produce dos transacciones: una enviando los fondos según lo deseado y luego otra enviando los fondos restantes después de que la primera se haya completado a alguna dirección de respaldo controlada por usted. El servidor firma ambas transacciones, pero publica solo la primera; la segunda se le devuelve para que pueda recuperar sus fondos incluso si el servidor desaparece. Tenga en cuenta que la dirección es 2 de 2, por lo que el servidor no tiene forma de invalidar esa transacción sin su consentimiento. Un punto en particular a tener en cuenta es que el servidor debe ser la primera entidad que firma las transacciones, no el segundo; de lo contrario, el servidor puede firmar maliciosamente solo la primera transacción y no la segunda y luego desaparecer, dejando al usuario permanentemente en el limbo.

El segundo esquema es simple 2 de 3. Hay tres claves: su clave, la clave del servidor y una clave de respaldo que usted tiene en una ubicación segura fuera de línea. Al igual que arriba, usted firma, el servidor envía un código de confirmación a su teléfono, usted proporciona el código en su computadora y el servidor firma; Eso es todo al respecto. Si pierde su contraseña, puede usar su clave de respaldo y la clave del servidor para enviar una transacción a una nueva billetera; si usted o el servidor son pirateados, el atacante todavía tiene solo 1 de 3, y si el servidor es malicioso o desaparece, solo tienen 1 de 3 y usted tiene 2 de 3. Se aplica una lógica similar para el caso 2 de 2, excepto que los casos que implican la pérdida de su clave o la desaparición del servidor se manejan mediante la aplicación de la transacción de emergencia.Por lo tanto, tenemos dos protocolos ligeramente diferentes pero en muchos sentidos equivalentes para crear una configuración multigrado sin punto único de falla …

… hasta que comencemos a pensar en el código del software. Una popular billetera de billetes múltiples, BitGo, actualmente se presenta principalmente como una aplicación web Javascript para el cliente; por lo tanto, podemos analizar BitGo usando el mismo análisis que usamos para analizar blockchain. información (nota: no estoy escogiendo BitGo específicamente, es simplemente una de las alternativas más destacadas y bien financiadas, otras alternativas generalmente funcionan exactamente de la misma manera). Si un atacante toma el control de los servidores de BitGo, entonces tienen la capacidad de comenzar a alimentar a los usuarios con una aplicación web defectuosa. Además, si un atacante toma el control de los servidores de BitGo, también pueden aplicar la segunda firma. Por lo tanto, BitGo sigue siendo un punto único de falla.

Ahora bien, uno podría argumentar razonablemente que (1) BitGo es una compañía confiable y por lo tanto no es probable que actúen maliciosamente ellos mismos y (2) la presencia de multisig significa que el atacante tiene que piratear BitGo de dos maneras y no uno. Sin embargo, esto no pasa por alto el punto principal, que es que una billetera centralizada del lado del servidor puede obtener las mismas garantías sin la complejidad de tener las llaves de la tienda del usuario simplemente agregando una capa adicional de multisig o compartición secreta a su billetera fría. Por lo tanto, este tipo de configuración de billetera multisig del lado del cliente se puede considerar como un teatro de seguridad criptoeconómico. Esto no quiere decir que BitGo no sea seguro; en comparación con la mayoría de las alternativas, es una buena opción. Más bien, esto simplemente dice que el aspecto "multigrado" no proporciona precisamente la garantía de seguridad que algunas personas creen que sí.

La razón filosófica por la que es tan problemático combinar el navegador Javascript y multigrado es que los proveedores de billetera multigrado de Javascript basados ​​en navegador, y también muchos proveedores basados ​​en escritorio, están configurando un protocolo que es inmune a cualquier punto único de falla de un protocolo punto de vista, pero inmediatamente están sacrificando esa ventaja en realidad al jugar dos roles en el protocolo al mismo tiempo: el cliente y el servidor. El problema parece fundamental, y dado lo crucial que es el cliente para cualquier interacción quizás incluso no resuelta; como vimos anteriormente, no importa cómo descargue una pieza de software, a menos que tenga tiempo de revisar correctamente cada línea de código que está confiando en el proveedor. A primera vista, parece que no hay forma de evitar este problema. Sin embargo, como veremos ahora, la hay, y la solución una vez más yace en el multigrado, esta vez hecho bien.

Multisig Unfused

La implementación multigrado en la vida real que creo que mejor ejemplifica mi visión de la forma correcta de hacer las cosas es la que está construyendo CryptoCorp. El enfoque de CryptoCorp para multigramos es fundamentalmente diferente: en lugar de tratar de tomar la ruta de Paypal (en realidad, la ruta de la mayoría de las empresas pre-cripto) para tratar la interfaz y el proveedor de seguridad como parte del mismo paquete, CryptoCorp generaliza y abstrae el rol del interfaz y hace que su núcleo ofrezca solo el proveedor de seguridad.Es decir, CryptoCorp está gastando la mayor parte de sus recursos desarrollando específicamente características y algoritmos avanzados para su servidor de Oracle de firma, y ​​permite que cualquier otro proveedor de billetera se integre con ellos para proporcionar una interfaz compatible. En la conferencia Texas Bitcoin en marzo, CryptoCorp mostró un prototipo funcional de una billetera Electrum modificada; ahora, están trabajando con más de diez proveedores de billetera para ayudar a integrar el soporte para su servidor.

Por supuesto, una pregunta es, ¿qué tiene de especial el servidor de CryptoCorp? Una aplicación para realizar una verificación telefónica de segundo factor con Google Authenticator y firmar transacciones se puede escribir en NodeJS en unos pocos días; Incluso lo hice yo mismo. Donde brilla CryptoCorp está en los algoritmos avanzados que usa para filtrar entre transacciones fraudulentas. ¿Solo pagando $ 3 por un café? El oráculo CryptoCorp ni siquiera se molesta en pedir confirmación. ¿Pagar $ 500 por una computadora portátil? Puede ser un poco más estricto. $ 50, 000 por un automóvil? Prepárese para algo muy cercano a la verificación KYC. A menos que se sepa que la dirección del destinatario pertenece al BitPremier bien establecido, en cuyo caso podría enviar la transacción con menos complicaciones simplemente porque sabe que siempre puede solicitar un reembolso si comete un error, y si el destinatario dirección ha sido vinculada a un sindicato de hackers, podría solicitar verificación incluso a $ 3.

Entonces, ¿por qué el enfoque de CryptoCorp es el mejor? De mi crítica anterior al enfoque habitual de multigrado, la respuesta es obvia: la entidad que construye el oráculo y la entidad que mantiene el software están completamente separadas. De hecho, con CryptoCorp puede estar realmente seguro incluso si su software resulta completamente controlado por un atacante. Puede usar herramientas independientes para verificar que las direcciones que está viendo son legítimas (y no falsas multisigs donde todas las claves están realmente controladas por el atacante), el cliente no puede enviar transacciones unilateralmente, y si el cliente intenta un ataque más sutil como cambiando los resultados en la transacción o cambiando los montos, entonces el oráculo captará eso. Por lo tanto, en realidad no existe un único punto de falla, y la promesa de confianza de la criptomoneda finalmente se logra.

Es importante tener en cuenta que Cryptocorp no es la única empresa que está haciendo las cosas de esta manera generalizada y altamente modular. Codius, la plataforma de contrato inteligente basada en oráculo de Ripple, aborda el problema exactamente de la misma manera, y desde el punto de vista de la protección al consumidor también lo está Bitrated, con su mercado abierto de compradores, vendedores y árbitros, aunque Bitrated todavía se queda corto por siendo una aplicación web basada en navegador y no una aplicación del lado del cliente o una extensión del navegador, o mejor aún un protocolo con múltiples implementaciones compatibles.

Cultura empresarial amigable con la descentralización

El camino para hacer que todas las empresas de criptografía se parezcan más a CryptoCorp, Codius o Bitrated, y menos a PayPal, será largo.En la comunidad de negocios tecnológicos, existe una fuerte presión a favor de crear un ecosistema final en lugar de un componente único y construir un "foso" para hacer su producto indispensable para sus usuarios, ideales que son exactamente lo opuesto a los principios. de comoditización, generalización y separación de preocupaciones que son tan importantes para un ecosistema descentralizado robusto. Las ganancias corporativas aumentan enormemente si tiene una posición segura y un monopolio, y sin embargo, en el terreno de las aplicaciones de criptomonedas seguras que son modulares y fácilmente reemplazables es el nombre del juego.

Sin embargo, debemos señalar que CryptoCorp ha logrado superar esta barrera, superando el estigma de ser "solo un oráculo de firma" por ser un oráculo de firma realmente bueno y las carteras con las que CryptoCorp trabaja también han hecho exactamente lo mismo. Incluso los intercambios, quizás el último negocio de productos básicos con cientos de intercambios en todo el mundo, todavía logran diferenciarse. En el caso del arbitraje en servicios como Bitrated, los árbitros pueden elegir especializarse en diferentes industrias, seguir diferentes normas comerciales (por ej., Estándares aceptables de calidad del producto, la medida en que los consumidores deben leer los acuerdos de compra, etc.) y tener un buen -modelos de riesgo optimizados que les permiten cobrar tarifas más bajas.

Además, tal vez ejecutar un oráculo de varias vistas no necesita ser un negocio; al igual que los servidores DNS, la tarea simplemente puede ser convertida en una mercancía y hecha por una combinación de compañías más grandes, grupos de investigación sin fines de lucro y aficionados. Tal situación será posiblemente preferible, ya que cada entidad que ejecuta cada nodo tendrá una fuente de ingresos independiente estable y mucha más reputación que perder, por lo que podemos esperar que los oráculos desaparezcan y se engañen con mucha menos frecuencia. Pero, en última instancia, si la comunidad exige una verdadera descentralización, el mercado se configurará de algún modo para proporcionarla; lo único que queda es un esfuerzo organizado para completar el cambio.