Firmas digitales y autorización de transacciones

Qué autoriza una firma

Una firma digital es un valor criptográfico creado sobre un mensaje especificado mediante una clave privada y un algoritmo de firma. Otros participantes pueden verificar la firma con respecto al mensaje y su clave pública correspondiente. En una transacción de cadena de bloques, el mensaje suele representar un cambio previsto conforme a las reglas de la red: transferir valor, llamar a un programa o satisfacer condiciones asociadas a una salida existente. Los bytes exactos incluidos en ese mensaje determinan qué se autoriza y qué no. Una firma no significa «Estoy de acuerdo con todo»; se verifica con respecto a una declaración definida con precisión, incluso si el software se la presenta a quien firma mediante un resumen breve y comprensible.

Firmar y difundir son eventos distintos. Un dispositivo o una aplicación puede construir una transacción, solicitar una firma y solo entonces enviar los bytes firmados a un nodo de la red. Por lo tanto, una firma puede existir antes de que la transacción sea visible en un explorador de bloques. Una vez enviada, la red aún verifica su validez y el cumplimiento de otras reglas, y su inclusión no es automática. Los estudiantes deben distinguir entre preparación, firma, envío, validación e inclusión. Los mecanismos de consenso del Módulo 2 rigen cómo las transacciones aceptadas pasan a formar parte de un historial compartido; no son, por sí mismos, el acto criptográfico de firmar.

Un mensaje debe ser inequívoco

Serialización y campos que se pueden firmar

La serialización convierte información estructurada en una representación exacta en bytes. Una aplicación podría mostrar un destinatario, un importe, una comisión y el nombre de una red, pero la verificación de la firma se aplica a bytes definidos según las reglas de codificación de un protocolo. Cambiar un campo firmado después de crear la firma normalmente hace que la verificación falle. Algunos protocolos autorizan deliberadamente un subconjunto especificado de campos mediante modos de firma que modifican qué partes quedan cubiertas. Por consiguiente, un analista no debe suponer que toda firma compromete a todas las partes del contexto que se muestran. La pregunta técnica pertinente es: ¿a qué campos quedó vinculada realmente esta modalidad de firma en particular?

Una transacción de estilo Bitcoin consume salidas de transacciones anteriores que aún no se han gastado y propone nuevas salidas. El hash de firma aplicable se compromete con la información de la transacción conforme a las reglas y los indicadores de tipo de hash. Una transacción de estilo Ethereum suele incluir campos como destino, valor, datos, nonce y parámetros de comisión, y utiliza una codificación de transacción apropiada para la firma. Una transacción de Solana firma un mensaje serializado que contiene instrucciones, información de cuentas y un hash de bloque reciente u otra alternativa permitida. Aunque sus estructuras sean diferentes, las tres se basan en el mismo principio: los verificadores deben comprobar el mismo mensaje previsto que se firmó.

Autorizar una transacción no es lo mismo que ejecutarla

Una firma válida es necesaria para muchos tipos de transacciones, pero no basta para que se produzca un cambio de estado exitoso. Una transacción propuesta podría tener un contador de secuencia no válido, un saldo insuficiente, un hash de bloque reciente vencido, una condición de gasto incumplida o un error de ejecución del contrato. En los sistemas basados en cuentas, la firma puede ser válida incluso si la ejecución falla y se cobra una comisión de procesamiento. En otros casos, es posible que la transacción ni siquiera llegue a la cadena. Por lo tanto, para explicar una transferencia disputada se necesitan al menos dos preguntas: ¿se autorizó correctamente el mensaje conforme a las reglas de la red y qué resultado produjo realmente la ejecución o liquidación en la red?

La autorización también puede involucrar más de una clave. Una regla de gasto puede exigir varias firmas, imponer condiciones temporales o utilizar la lógica de un programa. Una cuenta de contrato inteligente puede validar instrucciones según su código en lugar de depender de una única cuenta convencional controlada externamente. Estos sistemas no deben describirse como libres de firmas simplemente porque no aparezca una firma de cuenta ordinaria en el mismo campo. La lección general es que las reglas de autorización pertenecen al protocolo o al programa y deben interpretarse en contexto. La gobernanza y los controles de custodia son temas distintos que se abordan más adelante en el curso.

Repetición y vinculación al contexto

Un ataque de repetición ocurre cuando se reutilizan datos firmados válidos en un contexto en el que no se pretendía que autorizaran otra acción. El diseño de las transacciones puede reducir el riesgo de repetición mediante identificadores específicos de la red, contadores de secuencia, datos de vencimiento u otro contexto firmado. Ethereum Improvement Proposal (EIP) 155, Protección sencilla contra ataques de repetición, introdujo datos que identifican la cadena en la estructura de firma de las transacciones Ethereum heredadas pertinentes. Los formatos de transacción modernos también incorporan reglas de contexto de cadena, pero las implementaciones varían. El principio general es sencillo: los verificadores deben saber no solo si una firma es matemáticamente válida, sino también si es válida para esta red, este tipo de transacción y este uso.

Solicitudes de firma y comprensión humana

Una interfaz de usuario puede mostrar «Aprobar» o «Firmar», aunque las acciones subyacentes tengan consecuencias técnicas diferentes. Por ejemplo, en los contratos de tokens de Ethereum, una aprobación de asignación puede permitir que otra cuenta o contrato mueva tokens más adelante, dentro de las reglas del contrato, mientras que una transferencia simple de un activo nativo es una transacción directa. La firma de un mensaje fuera de la cadena puede autorizar una acción posterior si un servicio o contrato reconoce ese mensaje firmado. Ni la palabra «firma» ni la ausencia de un movimiento inmediato de tokens demuestran que la solicitud sea inocua. En un curso de fundamentos, los revisores deben aprender a preguntar qué capacidad específica se concede y si su alcance tiene límites de tiempo o de importe, o si puede revocarse según el diseño pertinente.

Algoritmos y evidencia de firmas

NIST FIPS 186-5, Estándar de firma digital, especifica técnicas que incluyen ECDSA y EdDSA. Bitcoin Improvement Proposal 340 especifica un esquema de firma Schnorr sobre secp256k1 para el entorno Taproot de Bitcoin. Las implementaciones de la red determinan con precisión cómo se aplican y codifican estos algoritmos. No basta con identificar una firma como «ECDSA» sin verificar el formato real del mensaje, la curva, las reglas de verificación y la versión del protocolo. Los sistemas también pueden usar hashes criptográficos antes de firmar o durante el proceso de firma; aplicar un hash al mensaje y firmarlo son operaciones relacionadas, pero no son la misma operación.

Cómo debe documentar un revisor una acción firmada

1. Registre la red, el tipo de transacción y el identificador exacto de la transacción o los datos serializados, cuando estén disponibles.
2. Identifique qué representan los campos que se muestran para quien firma, el destino, el contrato, el importe, la comisión y los datos.
3. Confirme el alcance de la firma y el contexto de secuencia o de protección contra repetición aplicable.
4. Distinga entre la validez de la firma, el estado de la transacción, el resultado de la ejecución y la autorización organizacional.

Este método evita dos errores opuestos. El primero es tratar una transacción exitosa como prueba de que una persona nombrada la aprobó con conocimiento de causa. El segundo es tratar una firma válida como prueba de que la transacción necesariamente tuvo éxito. La evidencia técnica puede respaldar una investigación, pero la atribución y la intención jurídica dependen de hechos que normalmente no quedan registrados en una cadena de bloques. Si a un analista solo se le presentan capturas de pantalla, lo más prudente es recuperar los registros de cadena correspondientes de forma independiente antes de asentar una conclusión. El siguiente módulo abordará aspectos prácticos del almacenamiento de claves y la organización de la custodia, no los mecanismos matemáticos tratados aquí.

Enfoque del examen: Identifique las cinco etapas de una transacción firmada típica, explique por qué son importantes los bytes exactos que se firman y la protección contra repetición, y distinga una firma válida de una ejecución exitosa, una inclusión confirmada y una aprobación organizacional. Sepa que las firmas pueden cubrir alcances diferentes según las reglas del protocolo.