paint-brush
Serie de tecnología de mejora de la privacidad de Blockchain: dirección sigilosa (I)por@iotex
5,887 lecturas
5,887 lecturas

Serie de tecnología de mejora de la privacidad de Blockchain: dirección sigilosa (I)

por IoTeX2018/05/15
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Muchas de las cadenas de bloques actuales, incluidas Bitcoin y Ethereum, son libros de contabilidad abiertos y públicos en el sentido de que no hay restricciones a la participación y todos los detalles de las transacciones son visibles en la cadena de bloques. En un libro mayor público, las entidades de transacción solo se identifican por sus direcciones de cadena de bloques, que se derivan de las claves públicas correspondientes. Los libros de contabilidad públicos generalmente se consideran "pseudo-anónimos", lo que significa que una dirección está vinculada a una persona, pero esa persona es desconocida para el público. Sin embargo, al analizar el gráfico de transacciones y combinarlo con otra información, es posible revelar la verdadera identidad del mundo real detrás de una dirección de cadena de bloques, como lo demuestra una investigación reciente. Las personas y las corporaciones prefieren agregar características de mejora de la privacidad a las transacciones de blockchain por varias razones, que incluyen, entre otras, la gestión de problemas relacionados con la aplicación de la ley y la ocultación de información confidencial específica de la empresa.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coins Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Serie de tecnología de mejora de la privacidad de Blockchain: dirección sigilosa (I)
IoTeX HackerNoon profile picture

Muchas de las cadenas de bloques actuales, incluidas Bitcoin y Ethereum, son libros de contabilidad abiertos y públicos en el sentido de que no hay restricciones a la participación y todos los detalles de las transacciones son visibles en la cadena de bloques. En un libro mayor público, las entidades de transacción solo se identifican por sus direcciones de cadena de bloques, que se derivan de las claves públicas correspondientes. Los libros de contabilidad públicos generalmente se consideran "pseudo-anónimos", lo que significa que una dirección está vinculada a una persona, pero esa persona es desconocida para el público. Sin embargo, al analizar el gráfico de transacciones y combinarlo con otra información, es posible revelar la verdadera identidad del mundo real detrás de una dirección de cadena de bloques, como lo demuestra una investigación reciente. Las personas y las corporaciones prefieren agregar características de mejora de la privacidad a las transacciones de blockchain por varias razones, que incluyen, entre otras, la gestión de problemas relacionados con la aplicación de la ley y la ocultación de información confidencial específica de la empresa.

Mecanismos de gestión de claves de direcciones sigilosas

Una dirección sigilosa es una tecnología de mejora de la privacidad para proteger la privacidad de los receptores de criptomonedas. Las direcciones sigilosas requieren que el remitente cree una dirección aleatoria única para cada transacción en nombre del destinatario para que los diferentes pagos realizados al mismo beneficiario no se puedan vincular.

Protocolo Básico de Direcciones Sigilosas (BSAP)

El esquema de dirección sigilosa más básico fue desarrollado por primera vez por un miembro del Foro de Bitcoin llamado 'ByteCoin' en 2011, que se basa en el protocolo Elliptic Curve Diffie-Hellman (ECDH) y funciona de la siguiente manera:

  • El remitente y el receptor tienen pares de claves privadas/públicas ( a , A ) y ( b , B ), respectivamente, donde A = a·G y B = b·G y G es el punto base de un grupo de curvas elípticas.
  • Tanto el remitente como el receptor pueden calcular un secreto compartido c usando el ECDH: c = H(a·b·G) = H(a·B) = H(b·A) , donde H(·) es una función hash criptográfica .
  • El remitente simplemente utiliza c·G como dirección de destino efímera para enviar el pago.
  • El receptor monitorea activamente la cadena de bloques y verifica si se ha enviado alguna transacción a la supuesta dirección de destino c·G . Si tiene, el pago se puede gastar usando la clave privada correspondiente c .

El diseño de BSAP tiene dos problemas principales: i) La dirección de destino efímera se fija entre dos entidades de comunicación. Así, las transacciones entre esas entidades pueden vincularse fácilmente; ii) Tanto el remitente como el receptor pueden calcular la clave privada c . Como resultado, si el receptor no gasta el pago de manera oportuna, el remitente puede cambiar de opinión y recuperar el dinero.

Protocolo mejorado de direcciones ocultas (ISAP)

Para abordar las fallas de diseño en BSAP, Nicolas van Saberhagen detalló un esquema mejorado, llamado ISAP, en el libro blanco de CryptoNote en 2013, que luego fue adaptado por Peter Todd en el protocolo Bitcoin en 2014. ISAP es una extensión de BSAP, que aplica una técnica de derivación de clave aditiva como se describe a continuación:

  • El receptor tiene un par de claves pública/privada ( b , B ), donde B = b·G y G es el punto base de un grupo de curvas elípticas.
  • El remitente genera un par de claves efímeras ( r , R ), donde R = r·G y lo transmite con la transacción.
  • Tanto el remitente como el receptor pueden calcular un secreto compartido c usando ECDH: c = H(r·b·G) = H(r·B) = H(b·R) , donde H(·) es una función hash criptográfica .
  • El remitente utiliza c·G + B como dirección de destino efímero para el envío del pago.
  • El receptor monitorea activamente la cadena de bloques y comprueba si se ha enviado alguna transacción a la supuesta dirección de destino c·G + B. Si es así, el pago se puede gastar usando la clave privada correspondiente c + b . Tenga en cuenta que la clave privada efímera c + b solo puede ser calculada por el receptor.

Si bien ISAP corrigió las fallas de diseño antes mencionadas de BSAP, un nodo de cadena de bloques aún necesita usar su clave de gasto privada b para escanear activamente la cadena de bloques en busca de la supuesta dirección de destino c·G + B , lo cual es contrario a la práctica común de almacenar claves privadas de forma segura. . El uso continuo de la clave de gasto privado aumenta significativamente el riesgo de que se vea comprometida.

Protocolo de direcciones sigilosas de doble clave (DKSAP)

Para eliminar la limitación de uso excesivo de clave de gasto privado de ISAP, un desarrollador conocido como rynomster/sdcoin creó una mejora de doble clave, DKSAP, en 2014 para ShadowSend , una solución de billetera anónima eficiente y descentralizada. El DKSAP se ha implementado en varios sistemas de criptomonedas desde entonces, incluidos Monero , Samourai Wallet y TokenPay , solo por nombrar algunos. El protocolo aprovecha dos pares de claves criptográficas, a saber, un par de "clave de escaneo" y un par de "clave de gasto", y calcula una dirección de pago única por transacción, como se detalla a continuación:

  • El receptor tiene dos pares de claves pública/privada ( s, S ) y ( b , B ), donde S = s·G y B = b·G son 'escanear clave pública' y 'gastar clave pública', respectivamente. Aquí G es el punto base de un grupo de curvas elípticas.
  • El remitente genera un par de claves efímeras ( r , R ), donde R = r·G y lo transmite con la transacción.
  • Tanto el remitente como el receptor pueden calcular un secreto compartido c usando ECDH: c = H(r·s·G) = H(r·S) = H(s·R) , donde H(·) es una función hash criptográfica .
  • El remitente utiliza c·G + B como dirección de destino efímero para el envío del pago.
  • El receptor monitorea activamente la cadena de bloques y verifica si se ha enviado alguna transacción a la supuesta dirección de destino c·G + B. Dependiendo de si la billetera está encriptada, el receptor puede calcular la misma dirección de destino de dos maneras diferentes, es decir, c·G + B = (c + b)·G. Si hay una coincidencia, el pago se puede gastar usando la clave privada correspondiente c + b . Tenga en cuenta que la clave privada efímera c + b solo puede ser calculada por el receptor.

En DKSAP, si existe un auditor o un servidor proxy en el sistema, el receptor puede compartir la 'clave privada de escaneo' y la 'clave pública de gasto' B con el auditor/servidor proxy para que esas entidades puedan escanear la transacción de blockchain en nombre del receptor. Sin embargo, no pueden calcular la clave privada efímera c + b y gastar el pago.

Desafíos para los sistemas de Internet de las cosas (IoT) basados en blockchain

DKSAP proporciona un fuerte anonimato para los receptores de transacciones y les permite recibir pagos no vinculados en la práctica. Sin embargo, este enfoque requiere que los nodos de la cadena de bloques calculen constantemente las supuestas direcciones de destino y encuentren las coincidencias correspondientes en la cadena de bloques. Si bien este proceso funciona bien para computadoras completas, plantea nuevos desafíos para dispositivos IoT con recursos limitados. Entonces, la pregunta es: ¿podemos adaptar DKSAP a los sistemas de IoT basados en blockchain haciendo ciertas compensaciones? Además, las transacciones que utilizan direcciones sigilosas se pueden identificar fácilmente debido a la presencia de una clave efímera, lo que genera cierta pérdida de privacidad. Por lo tanto, otra pregunta es ¿podemos mitigar esta pérdida de privacidad por la presencia de claves efímeras al usar direcciones sigilosas? ” Para saber cómo IoTeX está abordando estos desafíos, ¡manténgase atento a nuestra próxima publicación de blog sobre direcciones sigilosas y sistemas basados en IoT!

Acerca de IoTeX

IoTeX es la infraestructura de cadena de bloques autoescalable y centrada en la privacidad para Internet de las cosas (IoT). El equipo global de IoTeX está compuesto por doctores en criptografía, sistemas distribuidos y aprendizaje automático, ingenieros de primer nivel y constructores de ecosistemas experimentados. IoTeX está desarrollando varias innovaciones internas para impulsar la frontera de blockchain 3.0, incluida una arquitectura blockchain-in-blockchain para computación heterogénea, un mecanismo de consenso Roll-DPoS ultrarrápido y técnicas livianas para preservar la privacidad, para llevar la coordinación de dispositivos autónomos a la masas.






Sitio web: https://iotex.io/ Twitter: https://twitter.com/iotex_io Canal de anuncios de Telegram: https://t.me/iotexchannel Grupo de Telegram: https://t.me/IoTeXGroup Medio: https: //medium.com/@iotex Reddit: https://www.reddit.com/r/IoTeX/