ECDSA (algoritmo de firma digital de curva elíptica)

¿Qué es ECDSA?

ECDSA son las siglas de Elliptic Curve Digital Signature Algorithm (algoritmo de firma digital de curva elíptica).Es un algoritmo criptográfico de clave pública que utiliza matemáticas de curvas elípticas para crear y verificar firmas digitales.Las wallets de criptomonedas utilizan ECDSA para demostrar que una transacción ha sido autorizada por el titular de una clave privada determinada.La clave privada crea la firma, mientras que la clave pública correspondiente permite a los nodos de la blockchain verificarla.No es necesario revelar la clave privada durante la verificación.Una firma ECDSA válida también demuestra que los datos de la transacción firmada no se han modificado desde que se creó la firma.

La versión actual del Estándar de Firma Digital del NIST incluye ECDSA como técnica de firma digital aprobada para las aplicaciones criptográficas federales contempladas.

ECDSA es un algoritmo, no una blockchain, una wallet, una criptomoneda, un método de cifrado ni una curva elíptica.Una implementación completa también necesita una curva seleccionada, parámetros de dominio, una función hash, un método de generación de claves privadas, una codificación de firmas y reglas de formato de mensajes.

Por qué se utiliza ECDSA en las criptomonedas

Una red de criptomonedas descentralizada debe verificar la autorización de gasto sin depender de una base de datos central de cuentas.ECDSA permite que cada usuario controle una cuenta o salida gastable mediante una clave privada secreta.Cuando el usuario quiere transferir criptoactivos, la wallet construye una transacción y firma los datos de transacción necesarios.Los demás participantes de la red verifican la firma con la clave pública y las reglas de validación del protocolo.Con los supuestos actuales de la computación clásica, es extremadamente difícil falsificar una firma generada correctamente sin la clave privada.Esto permite a los nodos de blockchain rechazar transferencias no autorizadas y, al mismo tiempo, propagar transacciones válidas por una red pública.En comparación con algunos sistemas de clave pública más antiguos con niveles de seguridad clásica similares, ECDSA también genera claves y firmas relativamente compactas.Las firmas compactas son importantes porque cada byte adicional puede aumentar el ancho de banda de la red, el almacenamiento de la blockchain y los costes de transacción.

ECDSA es un algoritmo de firma, no de cifrado

ECDSA demuestra la autorización y la integridad del mensaje, pero no oculta los datos firmados.La mayoría de las transacciones públicas de criptomonedas siguen siendo visibles para los participantes de la blockchain, aunque incluyan firmas ECDSA.Una firma no cifra la dirección de destino, el importe transferido, la comisión de transacción ni las instrucciones de un contrato inteligente.El cifrado transforma información legible en texto cifrado que requiere una clave de descifrado.En cambio, ECDSA genera una prueba matemática de que una clave privada ha autorizado un mensaje específico.La privacidad debe proporcionarse mediante técnicas criptográficas, diseños de protocolo o controles de aplicación independientes.

Fundamentos de las curvas elípticas

ECDSA opera dentro de un grupo matemático formado por puntos de una curva elíptica sobre un campo finito.

Una forma habitual de la curva se expresa como

, y todos los cálculos de coordenadas se realizan mediante aritmética modular.

Los parámetros de dominio de la curva definen el campo, los coeficientes de la curva, el punto generador, el orden del generador y el cofactor.

El punto generador suele representarse como

.

El orden del generador suele representarse como

.

Las implementaciones seguras utilizan parámetros estandarizados y analizados minuciosamente, en lugar de inventar una curva nueva para una aplicación concreta.

La recomendación del NIST sobre parámetros de dominio de curvas elípticas documenta las curvas aprobadas para las aplicaciones contempladas en esa norma.

Claves privadas y claves públicas

Una clave privada ECDSA es un entero secreto que suele representarse como

.

El valor debe seleccionarse dentro del rango válido entre 1 y

.

La clave pública se calcula mediante multiplicación escalar en una curva elíptica.

La relación suele expresarse como

.

Calcular

a partir de y es eficiente.

Se considera computacionalmente inviable recuperar

a partir de en una curva segura con una clave generada correctamente.

Esta relación unidireccional se basa en la dificultad del problema del logaritmo discreto en curvas elípticas.Cualquiera que obtenga la clave privada puede generar firmas válidas y normalmente controlar los criptoactivos asociados.

¿Qué es secp256k1?

secp256k1 es la curva elíptica más asociada a ECDSA en el ámbito de las criptomonedas.Se utiliza para las firmas tradicionales de transacciones de Bitcoin y las firmas de cuentas de propiedad externa de Ethereum.

La ecuación de la curva es

sobre un campo primo grande.

El tamaño del campo y el orden del grupo de la curva son cercanos a 256 bits.Su nivel de seguridad clásica estimado suele describirse como de aproximadamente 128 bits frente a ataques genéricos de logaritmo discreto.secp256k1 es distinta de NIST P-256, aunque ambas se describen habitualmente como curvas elípticas de 256 bits.Las claves y firmas creadas para una curva no se pueden verificar simplemente con la otra.

El proyecto libsecp256k1, cuyo mantenimiento sigue activo, proporciona funciones optimizadas de firma y verificación ECDSA, generación de claves, análisis sintáctico y recuperación de claves públicas para secp256k1.

Cómo se crea una firma ECDSA

El proceso de firma comienza con una clave privada, un mensaje, una función hash criptográfica y los parámetros de la curva seleccionada.El mensaje se procesa conforme a las reglas exactas de serialización del protocolo de la criptomoneda.

El mensaje serializado se somete a una función hash para generar un resumen que suele representarse como

.

El firmante selecciona un valor secreto para cada firma, denominado nonce y representado habitualmente como

.

El nonce debe ser un entero válido distinto de cero y menor que el orden de la curva.

El firmante calcula el punto de la curva

.

El primer valor de la firma,

, se obtiene de la coordenada x de y se reduce módulo .

Si

es igual a cero, el firmante debe seleccionar otro nonce.

El segundo valor de la firma se calcula como

.

Si

es igual a cero, el firmante también debe seleccionar otro nonce.

La firma ECDSA resultante es el par

, aunque una criptomoneda puede añadir información de codificación o recuperación.

Cómo se verifica una firma ECDSA

El verificador comienza con el mensaje, la firma, la clave pública, los parámetros de la curva y las reglas de hash requeridas.

El verificador rechaza la firma si

o queda fuera del rango válido.

El verificador calcula

.

A continuación, calcula

y .

El verificador calcula el punto de la curva

.

La firma no es válida si

es el punto en el infinito.

La firma es válida cuando la coordenada x de

, reducida módulo , es igual a .

Esta relación se cumple porque la ecuación de firma conecta el resumen del mensaje, el nonce, la clave privada y la clave pública.La verificación no revela la clave privada ni el nonce de firma.

Qué demuestra una firma ECDSA

Una firma ECDSA válida demuestra que alguien con control de la clave privada correspondiente firmó los datos especificados.También permite al verificador detectar cambios en el mensaje firmado.La firma no demuestra por sí sola la identidad legal del firmante.Una clave pública solo queda vinculada a una persona u organización mediante pruebas adicionales, un registro, comunicaciones o el historial de transacciones.Las firmas generadas con una clave privada robada son matemáticamente indistinguibles de las que crea el titular original.Los nodos de blockchain validan la criptografía; no determinan si el firmante actuó voluntariamente.Un usuario que firma una transacción maliciosa ha creado, aun así, una firma válida.

El papel fundamental del nonce ECDSA

El nonce de firma

es uno de los elementos más sensibles para la seguridad de ECDSA.

Nunca debe reutilizarse para mensajes distintos bajo la misma clave privada.Si dos firmas utilizan el mismo nonce, sus ecuaciones contienen suficiente información relacionada para calcular el nonce y recuperar la clave privada.En ese caso, el atacante no necesita resolver el problema del logaritmo discreto en curvas elípticas.Los nonces parcialmente predecibles, sesgados o filtrados también pueden revelar una clave si se observan suficientes firmas.Los fallos de nonce han provocado compromisos reales de claves criptográficas, incluso cuando la curva elíptica elegida seguía siendo segura desde el punto de vista matemático.El término nonce significa «valor usado una vez», aunque en ECDSA también debe mantenerse secreto y ser único.

ECDSA determinista

ECDSA determinista genera el nonce de firma a partir de la clave privada y el resumen del mensaje, en lugar de solicitar un nuevo valor aleatorio para cada firma.

El procedimiento de firma determinista RFC 6979 define un método muy utilizado basado en una construcción hash con clave.

Con el mismo procedimiento determinista, la misma clave privada y el mismo mensaje suelen generar el mismo nonce y la misma firma.Esto reduce la dependencia de la calidad de un generador de números aleatorios independiente en cada operación de firma.La firma determinista no hace que una generación débil de claves privadas sea segura.La clave privada original sigue requiriendo una entropía sólida.Las implementaciones deterministas también deben resistir ataques de temporización, ataques por fallos, filtraciones de memoria y un procesamiento incorrecto de mensajes.Algunas implementaciones añaden aleatoriedad adicional a la generación determinista del nonce para protegerse contra determinadas condiciones de fallo o ataques de canal lateral.

Por qué es importante el hash

ECDSA normalmente firma un resumen criptográfico, en lugar de procesar directamente un mensaje de tamaño arbitrario.El protocolo de la blockchain define exactamente qué campos de la transacción se incluyen y cómo se serializan antes de aplicarles la función hash.La modificación de un campo firmado debería generar un resumen distinto e invalidar la firma anterior.Distintas criptomonedas pueden utilizar funciones hash y reglas de compromiso de transacciones diferentes aunque utilicen la misma curva ECDSA.Por tanto, el mismo mensaje legible puede producir firmas distintas en aplicaciones diferentes.Los desarrolladores no deben inventar reglas de serialización informales, porque una codificación ambigua puede hacer que dos sistemas interpreten de manera distinta los mismos bytes firmados.Los protocolos seguros también utilizan separación de dominios para impedir que una firma creada con una finalidad autorice otra distinta.

Codificación de firmas ECDSA

La firma ECDSA matemática contiene dos enteros,

y .

El software debe codificar estos enteros en bytes antes de transmitirlos o almacenarlos.Un método habitual utiliza las Reglas de Codificación Distinguida, conocidas como DER.DER representa los valores como enteros codificados dentro de una secuencia estructurada.La longitud resultante de la firma puede variar, porque los enteros positivos a veces requieren un byte cero inicial.

Otros sistemas de criptomonedas utilizan codificaciones compactas de longitud fija, con 32 bytes para

y 32 bytes para .

Una firma matemáticamente válida puede rechazarse si su codificación en bytes incumple el formato canónico del protocolo.

Bitcoin y ECDSA

Bitcoin utiliza tradicionalmente ECDSA sobre secp256k1 para autorizar el gasto de muchas salidas de transacción.La wallet firma un resumen específico de la transacción, determinado por las reglas aplicables del script y del hash de firma.Los nodos de Bitcoin verifican la clave pública, la firma, las condiciones del script y los demás requisitos de consenso.La firma por sí sola no demuestra que la entrada tenga valor suficiente ni que la transacción cumpla todas las reglas del protocolo.

La especificación BIP 66 de Bitcoin introdujo la codificación DER estricta como requisito de consenso para las firmas ECDSA evaluadas por las operaciones de script contempladas.

Este cambio redujo las diferencias entre analizadores y evitó que el comportamiento de consenso dependiera de reglas de análisis sintáctico de terceros sujetas a cambios.El gasto Taproot de Bitcoin utiliza firmas Schnorr definidas por BIP 340, en lugar de ECDSA, para su nueva vía de firma.Los tipos de salida tradicionales basados en ECDSA siguen existiendo y se pueden gastar.

Por qué es importante el análisis estricto de firmas

El software de consenso debe coincidir no solo en la ecuación de la firma, sino también en las secuencias de bytes que se consideran firmas válidas.Si un nodo acepta una codificación inusual y otro la rechaza, los nodos pueden discrepar sobre la validez de una transacción o bloque.Esta discrepancia puede dividir la visión de la blockchain entre los nodos de la red.El análisis estricto elimina las codificaciones alternativas que representan los mismos valores matemáticos.Una implementación de criptomoneda debe especificar con precisión los signos de los enteros, los ceros iniciales, las longitudes, los rangos y los datos finales.La criptografía crítica para el consenso requiere que todas las versiones de software y lenguajes de programación coincidan a nivel de bytes.

Ethereum y ECDSA

Las cuentas de propiedad externa de Ethereum utilizan ECDSA sobre secp256k1 para autorizar transacciones.El emisor firma un resumen de la transacción que incluye campos como el nonce, el destinatario, el valor, los datos, los parámetros de comisión y el tipo de transacción.

Las firmas de Ethereum contienen los valores

y , además de información para recuperar la clave pública.

En descripciones antiguas, el valor de recuperación suele denominarse

, mientras que las transacciones tipadas más recientes suelen representarlo como un valor de paridad y.

La información de recuperación permite al software derivar la clave pública candidata a partir de la firma y el resumen del mensaje.A continuación, se puede derivar la dirección de la cuenta y compararla con el emisor declarado.

El cambio de protocolo EIP-2 rechaza las firmas de transacciones ordinarias cuyo valor

sea superior a la mitad del orden de la curva secp256k1.

Protección contra repetición de transacciones en Ethereum

Una firma válida puede resultar peligrosa si la misma transacción firmada se acepta en más de un entorno blockchain.

El diseño de protección contra repetición EIP-155 de Ethereum incluye un identificador de cadena en el proceso de firma de la transacción.

Esto vincula la autorización a un contexto de cadena determinado.Las transacciones tipadas modernas de Ethereum también incluyen el tipo de transacción y campos específicos de la cadena en los datos comprometidos.Las aplicaciones que solicitan firmas off-chain siguen necesitando separación de dominios, nonces, reglas de caducidad e identificadores de contrato propios.Una firma ECDSA válida nunca debe considerarse segura sin comprender el mensaje exacto y el dominio que abarca.

Recuperación de claves públicas

La verificación ECDSA estándar presupone que el verificador ya conoce la clave pública.ECDSA recuperable añade una pequeña cantidad de información que ayuda a identificar la clave pública asociada a una firma y un mensaje.Varios puntos candidatos de la curva pueden satisfacer parte de la ecuación de firma, por lo que el identificador de recuperación señala el candidato previsto.Esta función puede reducir la necesidad de transmitir la clave pública completa en algunos formatos de transacción.La recuperación de claves públicas no revela la clave privada.

El módulo opcional de recuperación de libsecp256k1 admite firmas secp256k1 recuperables en las aplicaciones adecuadas.

Las aplicaciones deben seguir validando la clave recuperada, los rangos de la firma, el formato del mensaje y el dominio.

Maleabilidad de las firmas ECDSA

ECDSA tiene una forma matemática inherente de maleabilidad de firmas.

Si

es válido para un mensaje y una clave pública, también lo es según la ecuación básica de verificación.

Un tercero puede crear la firma alternativa sin conocer la clave privada.Esto no permite al atacante firmar un mensaje distinto ni gastar activos adicionales.Puede cambiar el identificador de una transacción cuando este incluye los bytes de la firma.

Los protocolos reducen este problema aceptando una sola forma canónica, normalmente la firma con el valor

más bajo.

La canonicalización también facilita comparar y almacenar las firmas de forma coherente.

Firmas low-S

Una regla low-

exige que no sea superior a la mitad del orden de la curva.

Cuando el firmante calcula un valor más alto, puede sustituirlo por

.

El valor transformado sigue siendo matemáticamente válido y queda dentro del rango inferior aceptado.Ethereum aplica esta regla a las firmas de transacciones ordinarias mediante EIP-2.

El software de Bitcoin suele generar firmas ECDSA normalizadas low-

, aunque el tratamiento exacto en materia de consenso y políticas depende del contexto de gasto.

Los desarrolladores deben seguir las reglas precisas del protocolo de destino, en lugar de dar por hecho que todos los sistemas ECDSA aceptan la misma forma.

ECDSA frente a firmas Schnorr

ECDSA y Schnorr son algoritmos de firma distintos que pueden utilizar la misma curva elíptica secp256k1.Las firmas Schnorr tienen una estructura lineal más sencilla que facilita construcciones eficientes de multifirma y agregación.ECDSA básico no ofrece las mismas propiedades de agregación lineal de forma directa.

La especificación BIP 340 de Bitcoin define firmas Schnorr de 64 bytes sobre secp256k1.

BIP 340 también explica la maleabilidad inherente de ECDSA y los supuestos de seguridad más complejos utilizados en el análisis formal de ECDSA.La introducción de Schnorr no significa que las firmas ECDSA existentes hayan dejado de ser válidas o puedan falsificarse en la práctica.Proporciona otro diseño de firma con propiedades útiles para nuevas funciones de protocolo.

ECDSA frente a EdDSA

EdDSA es una familia de firmas distinta, basada en las matemáticas de curvas Edwards.Ed25519 es una instancia habitual de EdDSA.EdDSA se diseñó dando importancia a la firma determinista y a un comportamiento de implementación simplificado.Una clave Ed25519 no se puede utilizar como clave ECDSA secp256k1 sin un diseño de conversión independiente; intentar convertirla sin más no es seguro.Los tamaños de firma, los formatos de clave pública, la aritmética de curvas, los procedimientos de hash y las reglas de validación son distintos.Un sistema compatible con ambos algoritmos debe especificar claramente qué esquema corresponde a cada clave y firma.

ECDSA frente a firmas BLS

Las firmas BLS utilizan curvas elípticas aptas para emparejamientos y tienen propiedades matemáticas distintas de las de ECDSA.Pueden admitir la agregación compacta de muchas firmas conforme a reglas de seguridad definidas.Los validadores de Ethereum utilizan firmas BLS para las tareas de consenso de Proof of Stake, mientras que las cuentas de propiedad externa ordinarias de Ethereum utilizan ECDSA secp256k1.Por tanto, una clave de validador no es intercambiable con una clave de cuenta de ejecución.La agregación BLS puede reducir la cantidad de datos cuando muchos participantes firman mensajes relacionados, pero requiere operaciones de emparejamiento y reglas de validación distintas.

ECDSA y las wallets multifirma

Un script de blockchain puede exigir varias firmas ECDSA independientes para poder gastar activos.Se trata de un diseño multifirma tradicional, ya que cada firmante requerido crea una firma independiente.ECDSA de umbral utiliza un protocolo interactivo más complejo en el que varios participantes generan conjuntamente una única firma ECDSA de apariencia normal.Durante una operación correcta, ningún participante necesita reconstruir la clave privada completa.El diseño de ECDSA de umbral es complejo porque los participantes deben coordinar la generación de nonces y resistir conductas maliciosas.Un protocolo de umbral defectuoso puede exponer la clave privada compartida aunque el algoritmo ECDSA básico sea seguro.Los sistemas de producción deben utilizar protocolos bien revisados, en lugar de inventar ecuaciones de firma multipartitas propias.

Hardware wallets y ECDSA

Una hardware wallet puede generar y almacenar una clave privada ECDSA en un dispositivo específico.El dispositivo recibe los datos de la transacción, muestra los detalles disponibles y crea internamente una firma tras la aprobación del usuario.La clave privada debe permanecer dentro del entorno protegido.Este aislamiento reduce la exposición directa al malware de un teléfono u ordenador conectado.Una hardware wallet no puede hacer que una transacción maliciosa sea segura si el usuario aprueba datos engañosos.La presentación segura de la transacción, la integridad del firmware, la protección de la frase de recuperación y la seguridad de la cadena de suministro siguen siendo esenciales.La resistencia a ataques de canal lateral y por fallos también es importante, ya que las mediciones físicas o los errores inducidos pueden revelar valores secretos de firma.

Ataques de canal lateral

Un ataque de canal lateral extrae información del comportamiento físico de una implementación ECDSA.Entre las posibles señales se encuentran el tiempo de ejecución, el consumo eléctrico, las emisiones electromagnéticas, el acceso a la caché y los patrones de memoria.Las bifurcaciones o búsquedas en tablas que dependen de datos secretos pueden revelar información sobre la clave privada o el nonce.Las implementaciones de tiempo constante intentan que los patrones de operación observables sean independientes de los valores secretos.El proyecto libsecp256k1 actual documenta un comportamiento de tiempo constante y acceso constante a memoria para la firma y la generación de claves públicas.El código de tiempo constante reduce riesgos importantes, pero no aborda todos los ataques físicos, de compilador, hardware o sistema operativo.

Ataques por fallos

Un ataque por fallos provoca deliberadamente un error mientras un dispositivo genera una firma ECDSA.El atacante puede manipular el voltaje, la frecuencia de reloj, la temperatura, la memoria o el flujo de cálculo.En algunas implementaciones, una firma defectuosa puede revelar suficiente información matemática para recuperar una clave privada.Los dispositivos de firma de alta seguridad pueden verificar internamente la firma generada antes de publicarla.También pueden utilizar cálculos redundantes, sensores de fallos, chips reforzados y mensajes de error restringidos.La posesión física de un dispositivo de firma siempre debe considerarse un evento de seguridad relevante.

Claves públicas y puntos de curva no válidos

Un verificador ECDSA no debe aceptar a ciegas cualquier cadena de bytes como clave pública.La implementación puede tener que confirmar que la codificación es válida y que el punto pertenece a la curva esperada.Debe rechazar el punto en el infinito y realizar las comprobaciones de subgrupo necesarias.El uso de un punto no válido controlado por un atacante en operaciones con claves secretas puede facilitar ataques de curva no válida o de subgrupo pequeño.Los requisitos exactos de validación dependen de la curva, el protocolo y la operación.Las bibliotecas criptográficas revisadas gestionan estos detalles con más seguridad que las implementaciones personalizadas e informales.

Generación de claves privadas

Una clave privada ECDSA debe generarse a partir de una fuente de entropía criptográficamente segura.Las frases elegidas por una persona, fechas de nacimiento, citas, dígitos repetidos y funciones aleatorias corrientes no son seguras.La clave también debe estar dentro del rango de escalares válido para la curva seleccionada.Que un valor parezca tener 256 bits no significa que se haya generado una clave privada segura.Las wallets suelen derivar muchas claves ECDSA de una semilla maestra mediante un proceso de derivación determinista jerárquica.Quien obtenga esa semilla maestra podría recrear todas las cuentas derivadas.La seguridad de ECDSA no puede compensar una frase de recuperación expuesta o predecible.

ECDSA y las direcciones de wallet

Una clave pública no siempre es lo mismo que una dirección de criptomoneda.Las direcciones de Bitcoin suelen codificar un hash o una condición de script relacionada con información de la clave pública.Las direcciones de Ethereum se derivan de parte del hash de una clave pública secp256k1 sin comprimir.El formato de la dirección puede incorporar identificadores de red e información para detectar errores.Una wallet puede mostrar varias direcciones derivadas de una semilla maestra mediante distintas rutas de derivación.Los usuarios no deben asumir que conocer una dirección revela la clave pública completa en todos los estados del protocolo.Conocer una clave pública tampoco hace que recuperar una clave privada mediante métodos clásicos sea viable en la práctica, siempre que la clave y la curva sean seguras.

Firma de transacciones frente a firma de mensajes

Una firma de transacción autoriza una operación de blockchain conforme a las reglas definidas por el protocolo.Una firma de mensaje puede demostrar el control de una clave sin enviar directamente una transacción de blockchain.Las solicitudes de inicio de sesión en wallets, las aprobaciones de tokens, las órdenes, los votos de gobernanza y los mensajes de autorización pueden utilizar firmas ECDSA.Las firmas off-chain también pueden autorizar acciones de valor si posteriormente un contrato inteligente o un servicio las envía.Una solicitud descrita como inicio de sesión puede ser peligrosa si los datos firmados realmente conceden permiso para transferir activos.Siempre que sea posible, las wallets deben mostrar el dominio de firma, el contrato, la cadena, el nonce, la caducidad y la acción en lenguaje comprensible.Los usuarios deben rechazar firmas que contengan datos no explicados o permisos inesperados.

Ataques de repetición

Un ataque de repetición reutiliza una firma válida en otro contexto donde el firmante no pretendía que se aplicara.El atacante no falsifica la firma.Aprovecha que el mensaje no está vinculado de forma suficiente a su contexto.Los mensajes firmados seguros incluyen valores como el identificador de cadena, el nonce de cuenta, la dirección del contrato, el dominio de la aplicación, el tipo de operación y la fecha de caducidad.Un nonce de un solo uso impide utilizar repetidamente la misma autorización en una aplicación.Los desarrolladores deben comprobar que el nonce solo se consume tras una acción autorizada realizada correctamente.

Errores de implementación

Los fallos de ECDSA suelen deberse a errores de implementación o de gestión de claves, no a una solución directa del problema del logaritmo discreto en curvas elípticas.Entre los fallos habituales figuran la reutilización de nonces, los números aleatorios sesgados, la aceptación de claves no válidas, el hash incorrecto, la serialización ambigua, la falta de comprobaciones de rango y el análisis inseguro de firmas.Otros fallos se relacionan con canales laterales, ataques por fallos, registros de depuración expuestos, dependencias comprometidas y filtraciones de memoria.Los desarrolladores deben utilizar bibliotecas mantenidas, con pruebas exhaustivas y un modelo de seguridad claro.El código criptográfico debe revisarse por separado del código normal de las aplicaciones, porque un pequeño error puede exponer todos los activos protegidos por una clave.

Por qué es peligroso crear código ECDSA propio

Las fórmulas de ECDSA pueden parecer lo bastante sencillas como para implementarlas en un programa breve.La seguridad en producción requiere mucho más que reproducir las ecuaciones de firma y verificación.La implementación debe realizar operaciones escalares de tiempo constante, inversiones seguras, reducciones modulares correctas, análisis estricto, validación de puntos y gestión segura de la memoria.También debe gestionar correctamente casos excepcionales, como los valores cero y los puntos no válidos.Un programa que supere varias pruebas normales de firma aún puede filtrar su clave privada por el tiempo de ejecución o por un sesgo del nonce.Los desarrolladores deben utilizar bibliotecas consolidadas y vectores de prueba oficiales, en lugar de adaptar código de tutoriales para la custodia de criptomonedas.

Nivel de seguridad de ECDSA

La seguridad de ECDSA depende de la solidez de la curva y de la función hash, la entropía de la clave privada, la generación del nonce y la implementación.Una curva elíptica segura de 256 bits suele asociarse a unos 128 bits de seguridad clásica.Esto no significa que un atacante tenga una probabilidad entre 128 de adivinar la clave.Describe un coste computacional aproximado según los modelos de ataque pertinentes.La función hash también debe ofrecer una resistencia adecuada a colisiones y preimágenes conforme a los objetivos de seguridad del protocolo.Unos controles operativos débiles pueden reducir la seguridad práctica muy por debajo del nivel matemático.

ECDSA y la computación cuántica

No se considera que ECDSA sea seguro frente a un ordenador cuántico tolerante a fallos lo bastante potente.El algoritmo de Shor podría resolver el problema del logaritmo discreto en curvas elípticas y recuperar una clave privada a partir de su clave pública.Actualmente no se conoce ningún ordenador cuántico público que pueda romper ECDSA secp256k1 de tamaño completo a escala práctica para las criptomonedas.Los sistemas blockchain de larga duración siguen necesitando planes de migración, porque las actualizaciones de protocolo, los cambios de wallet y el traslado de fondos inactivos pueden tardar años.Si se desarrollara hardware cuántico criptográficamente relevante, las claves públicas ya expuestas on-chain podrían convertirse en objetivos prioritarios.Las afirmaciones sin fundamento que sostienen que el ECDSA actual ya se ha roto deben tratarse con cautela.

Alternativas de firma poscuánticas

Las firmas digitales poscuánticas se basan en problemas matemáticos que se cree que resisten tanto a los ordenadores clásicos como a los cuánticos de gran capacidad.

En agosto de 2024, el NIST finalizó la norma FIPS 204 para ML-DSA y la norma FIPS 205 para SLH-DSA.

Estos sistemas de firma tienen tamaños de clave y firma, costes computacionales y requisitos de implementación distintos de los de ECDSA.Sustituir ECDSA en una blockchain no es tan sencillo como cambiar una biblioteca de wallet.La migración puede afectar a los formatos de dirección, los tamaños de transacción, las hardware wallets, los contratos inteligentes, la validación de la red, la recuperación de cuentas y los fondos inactivos.Algunos protocolos pueden utilizar autorización híbrida durante la transición y exigir tanto una firma ECDSA existente como una firma poscuántica.

Cómo deben utilizar ECDSA los desarrolladores de forma segura

Los desarrolladores deben utilizar exactamente la curva, la función hash, el formato del mensaje y la codificación de firma que requiera el protocolo de destino.Las claves privadas deben proceder de un proceso criptográficamente seguro de generación o derivación.Los nonces de firma deben utilizar un método determinista revisado o un diseño de aleatoriedad segura con una protección equivalente.Las bibliotecas deben realizar el análisis estricto de firmas, las comprobaciones del rango de escalares, la validación de claves públicas y la canonicalización que exija el protocolo.Las operaciones con claves secretas deben utilizar implementaciones de tiempo constante.Las aplicaciones deben incluir separación de dominios, protección contra repetición, una presentación clara de las transacciones y una gestión adecuada de nonces.

Las suites de pruebas deben incluir firmas no válidas, formas con valor

alto, codificaciones mal formadas, valores cero, mensajes alterados, redes incorrectas e intentos de reutilizar autorizaciones.

Los sistemas de alto valor deben someterse a auditorías criptográficas y de implementación independientes.

Cómo pueden proteger los usuarios cripto las claves ECDSA

Los usuarios deben crear wallets con software fiable o hardware de firma específico.Las frases de recuperación y las claves privadas deben permanecer offline y nunca compartirse con agentes de soporte ni sitios web.Antes de firmar, deben comprobar los detalles de la transacción en una pantalla de confianza.Los usuarios deben verificar la dirección de destino, la red, el importe, la comisión, el contrato y el alcance de los permisos.Los activos de gran valor pueden protegerse mediante políticas multifirma, copias de seguridad distribuidas, aislamiento de hardware y wallets independientes para gastar.No se debe importar una misma frase de recuperación en aplicaciones innecesarias.En muchos sistemas blockchain, una firma válida constituye una prueba irreversible de autorización, por lo que prevenir el problema es más fiable que intentar recuperarse después.

Errores habituales relacionados con ECDSA

Un error habitual es suponer que ECDSA cifra las transacciones de criptomonedas.Otro es tratar la clave pública como si siempre fuera idéntica a la dirección de wallet.Un tercer error es reutilizar el mismo nonce de firma para dos mensajes.Un cuarto error es generar claves privadas o nonces mediante una función aleatoria corriente.Un quinto error es aceptar firmas no canónicas o mal formadas sin un análisis estricto.

Un sexto error es olvidar que tanto

como pueden satisfacer la ecuación básica de ECDSA.

Un séptimo error es firmar datos sin comprobar la red, el dominio, el nonce y la fecha de caducidad.Un octavo error es utilizar una misma clave privada en aplicaciones y blockchains no relacionadas.Un noveno error es escribir código de curvas elípticas propio para wallets de producción sin una revisión experta.Un décimo error es asumir que una firma válida demuestra que una transacción es segura, justa o deseada por el titular original de la clave.

Preguntas frecuentes

¿Qué significan las siglas ECDSA?

ECDSA son las siglas de Elliptic Curve Digital Signature Algorithm (algoritmo de firma digital de curva elíptica).

¿Para qué se utiliza ECDSA en las criptomonedas?

Se utiliza para generar y verificar firmas que autorizan transacciones de blockchain y otras acciones de wallet.

¿ECDSA cifra las transacciones?

No. ECDSA demuestra la autorización y la integridad, pero no oculta los datos habituales de una blockchain pública.

¿Qué es una clave privada ECDSA?

Es un entero secreto que se utiliza para crear firmas y derivar la clave pública correspondiente.

¿Qué es una clave pública ECDSA?

Es un punto de curva elíptica derivado de la clave privada y utilizado para verificar firmas.

¿Qué curva utiliza Bitcoin para ECDSA?

Bitcoin utiliza la curva elíptica secp256k1 para sus firmas de transacciones ECDSA tradicionales.

¿Qué curva utiliza Ethereum para las firmas de cuentas?

Las cuentas de propiedad externa de Ethereum utilizan ECDSA sobre secp256k1.

¿Qué son r y s en ECDSA?

Son los dos componentes enteros de una firma ECDSA.

¿Qué es el nonce de ECDSA?

Es un escalar secreto utilizado una sola vez durante la generación de cada firma.

¿Por qué nunca debe reutilizarse el nonce ECDSA?

La reutilización del nonce en mensajes diferentes puede permitir que un observador calcule la clave privada.

¿Qué es ECDSA determinista?

Es un método de firma que deriva el nonce de la clave privada y del resumen del mensaje mediante un proceso definido, como RFC 6979.

¿ECDSA determinista elimina la necesidad de aleatoriedad?

No. La clave privada original sigue necesitando una entropía sólida y las implementaciones deben protegerse contra fallos y canales laterales.

¿Qué es la maleabilidad de las firmas ECDSA?

Es la propiedad por la que tanto

como pueden ser válidos para el mismo mensaje y la misma clave pública.

¿Qué es una firma low-S?

Es una firma ECDSA canónica cuyo valor

no supera la mitad del orden de la curva.

¿Qué es la codificación DER?

DER es una codificación binaria estructurada que se utiliza habitualmente para representar los enteros

y de una firma ECDSA.

¿Una firma ECDSA puede revelar la clave privada?

Una firma generada correctamente no debería revelarla, pero la reutilización de nonces, los nonces sesgados, los canales laterales y los errores de implementación pueden exponer la clave.

¿ECDSA permite recuperar una clave privada perdida?

No. Las firmas y las claves públicas no ofrecen un método práctico para recuperar una clave privada segura que se haya perdido.

¿Se puede falsificar una firma ECDSA?

Se considera computacionalmente inviable falsificarla cuando se utilizan parámetros, claves, nonces, hashes e implementaciones seguros.

¿ECDSA es lo mismo que ECC?

No. ECC es la familia general de la criptografía de curvas elípticas, mientras que ECDSA es uno de los algoritmos de firma digital de esa familia.

¿ECDSA es lo mismo que Schnorr?

No. Son algoritmos de firma diferentes, aunque ambos utilicen secp256k1.

¿Taproot utiliza ECDSA?

La nueva vía de firma de Taproot utiliza firmas Schnorr BIP 340 en lugar de ECDSA.

¿Los contratos inteligentes pueden verificar firmas ECDSA?

Sí. Muchos entornos blockchain proporcionan operaciones nativas o bibliotecas para verificar firmas ECDSA secp256k1.

¿Una firma ECDSA válida demuestra la identidad legal?

No. Demuestra el control de una clave privada, salvo que existan pruebas independientes que vinculen esa clave con una identidad legal.

¿Una firma válida garantiza que una transacción es segura?

No. Un usuario puede firmar válidamente una transferencia maliciosa, una autorización ilimitada, una orden engañosa o una acción peligrosa de un contrato inteligente.

¿Un ordenador cuántico puede romper ECDSA?

Un ordenador cuántico tolerante a fallos lo bastante potente podría romper ECDSA, pero actualmente no se conoce ningún sistema público capaz de hacerlo a escala de las criptomonedas.

¿ECDSA sigue siendo seguro hoy?

ECDSA, implementado correctamente y con claves y nonces seguros, sigue resistiendo los ataques clásicos prácticos conocidos.

Conclusión

ECDSA es un algoritmo fundamental de firma digital que se utiliza para autorizar transacciones de criptomonedas sin exponer las claves privadas.

Combina un escalar privado, una clave pública de curva elíptica, el resumen de un mensaje y un nonce secreto de firma para generar los valores de firma

y .

Los nodos de blockchain verifican matemáticamente esos valores antes de aceptar una acción firmada.Bitcoin utiliza tradicionalmente ECDSA sobre secp256k1, mientras que las cuentas de propiedad externa de Ethereum utilizan la misma curva con información de firma recuperable.

La codificación estricta, las reglas low-

, los identificadores de cadena, los dominios de mensaje y la protección contra repetición contribuyen a que ECDSA sea más seguro en los protocolos de criptomonedas.

Su mayor debilidad práctica no es el problema matemático central de la curva elíptica, sino una implementación o gestión de claves incorrecta.La reutilización de nonces, la aleatoriedad débil, la exposición de frases de recuperación, los canales laterales, la gestión de puntos no válidos y las solicitudes de firma poco claras pueden invalidar unas matemáticas que, por lo demás, son sólidas.Los desarrolladores deben utilizar bibliotecas revisadas, procedimientos deterministas para los nonces, operaciones de tiempo constante, validación estricta y especificaciones precisas del protocolo.Los usuarios deben proteger el material de recuperación y verificar cada transacción o mensaje en una pantalla de firma de confianza.ECDSA sigue siendo seguro frente a los ataques clásicos prácticos conocidos cuando se implementa correctamente, aunque los sistemas de criptomonedas de larga duración deben prepararse para migrar a tecnologías de firma poscuántica.