Implementant un Protocol Honeypot d’Adreces a Bitcoin

1. Introducció: L’amenaça dels ordinadors quàntics criptogràficament rellevants (CRQC)

Un Ordinador Quàntic Criptogràficament Rellevant (Cryptographically Relevant Quantum Computer, CRQC) representa un salt generacional en capacitat computacional; concretament, un sistema amb prou cúbits estables  per executar l’algorisme de Shor a una escala suficient per comprometre la infraestructura moderna de criptografia de clau pública. Estimar quan apareixerà un CRQC és difícil a causa d’un problema de “distorsió de la informació”: les empreses tenen incentius per exagerar els seus avenços per atreure capital, mentre que els estats consideren les fites en computació quàntica com a actius estratègics classificats.

Per reduir aquesta incertesa, el Protocol (Bitcoin Honeysegpot Address Protocol, BHAP) estableix una “recompensa quàntica”: un incentiu econòmic dissenyat per incentivar un operador d’un CRQC a revelar les seves capacitats. Mitjançant l’ús d’una corba el·líptica deliberadament afeblida dins d’una adreça Bitcoin Taproot aparentment estàndard, el BHAP actua com un sistema d’alerta primerenca. Si els fons es mouen, això indica que el Problema del Logaritme Discret sobre Corbes El·líptiques (ECDLP) ha estat resolt en una corba de longitud reduïda, proporcionant un avís a la comunitat abans que corbes de producció com secp256k1 es vegin compromeses.

2. La diferència de seguretat: 128 bits versus 96 bits

L’arquitectura del BHAP es basa en la diferència de seguretat entre la corba estàndard de Bitcoin i una corba deliberadament afeblida. Bitcoin utilitza secp256k1, mentre que el protocol BHAP secp192r1 per reduir la barrera quàntica mantenint un nivell de dificultat tècnicament rellevant.

La recerca actual presenta una gran variabilitat en les estimacions del nombre de cúbits necessaris per comprometre una seguretat de 128 bits. Les estimacions de la Universitat de Sussex indiquen que trencar secp256k1 en una finestra de 8 hores requeriria entre 13 i 300 milions de cúbits físics. Webber et al. estimen aproximadament 317 milions de cúbits físics per a un atac d’una hora, reduint-se fins als 13 milions si l’atacant pot permetre’s un temps d’execució de 24 hores. Pel que fa als cúbits lògics, les estimacions oscil·len entre 1.500 i 3.000. En reduir la seguretat de la corba fins als 96 bits, el BHAP estableix un objectiu assolible per a un CRQC que encara es troba diverses generacions tecnològiques per sota del nivell necessari per amenaçar la corba de 128 bits.

3. El protocol distribuït BHAP

El protocol involucra n participants i un coordinador. La implementació utilitza diverses biblioteques de Python: secrets per generar entropia, coincurve i tinyec per a les operacions sobre corbes el·líptiques, cryptography per implementar ECIES i bitcoinutils per construir adreçes Taproot.

S’utilitza la següent convenció de noms:

• ($P_b$, $d_b$): claus (pública, privada) sobre la corba secp256k1.
• ($P_w$, $d_w$): claus (pública, privada) sobre la corba secp192r1.

3.1 Fases 1 i 2: Generació de claus i agregació de claus públiques

Cada participant i utilitza les biblioteques secrets i bitcoinutils per generar una clau privada aleatòria $d_{bi}$ i la seva corresponent clau pública $P_{bi}$ sobre la corba secp256k1.

Aquestes claus es comparteixen amb el coordinador, que les agrega utilitzant la biblioteca coincurve: $P_b = KeyAgg_{i=1}^n(P_{bi})$

Aquesta agregació es basa en la suma de punts sobre corbes el·líptiques.

Nota: El coordinador ha de verificar que $P_b$ no sigui un punt trivial; concretament, ha de comprovar que no correspon ni al Punt de l’Infinit (O) ni al Punt Generador (G). Si s’obté un punt trivial, el protocol s’ha de reiniciar per evitar una clau privada mestra nul·la o compromesa.

3.2 Fase 3: Derivació de la clau afeblida (secp192r1)

El coordinador deriva la clau feble $P_w$ a partir de $P_b$ mitjançant un procés iteratiu de hash. Primer calcula el SHA-256 de $P_b$ i en conserva els primers 24 bytes (192 bits), que coincideixen amb la mida del camp de secp192r1. Aquest valor s’utilitza com a coordenada x candidata. Si no correspon a un punt vàlid (és a dir, no és un residu quadràtic), el coordinador incrementa un comptador i torna a aplicar el hash sobre el resultat anterior.

Quan es troba un punt vàlid mitjançant tinyec, el coordinador comparteix $P_b$, $P_w$ i el nombre d’iteracions de hash. Això permet als participants verificar que $P_w$ s’ha derivat correctament de $P_b$, assegurant que la clau afeblida no ha estat seleccionada arbitràriament.

3.3 Fase 4: Xifrat ECIES de les claus privades

Utilitzant $P_w$ com a clau de xifrat, els participants xifren les seves claus privades $d_{bi}$ mitjançant ECIES. El protocol utilitza AES-CBC com a xifrat simètric.

Nota: S’ha escollit AES-CBC en lloc del més modern AES-GCM per reduir la mida de les dades emmagatzemades a IPFS i dels compromisos enregistrats a la cadena de blocs. Com que s’assumeix un canal de comunicació autenticat entre els participants i el coordinador, l’etiqueta d’autenticació addicional que proporciona AES-GCM es considera innecessària.

La sortida per a cada participant és: $E_i = (P_{bi}, c_i, IV_i, P_{ei}),$on $c_i$ és el text xifrat, $IV_i$ és el vector d’inicialització i $P_{ei}$ és la clau pública efímera generada durant l’intercanvi ECIES.

Per evitar un atac de denegació de servei (DoS) en què un participant maliciós enviï dades incorrectes que impedeixin la reconstrucció final, futures versions del protocol exigiran Proves de Coneixement Zero (Zero-Knowledge Proofs) que demostrin que $c_i$ conté una clau privada $d_{bi}$ vàlida corresponent a $P_{bi}$.

3.4 Fase 5: Compromís amb Taproot i finançament

El coordinador recopila tots els $E_{bi}$ i les dades de derivació de la clau. Tot seguit utilitza Tagged Hashes per generar un compromís criptogràfic de totes les dades del protocol. Aquest hash s’utilitza com a Taproot tweak per transformar $P_b$ en la clau pública modificada: $P_{bt} = P_b + hash_{TapTweak}(P_b || \mathrm{protocol_data}) \cdot G$.

La clau $P_{bt}$ es converteix en l’Adreça parany (HA). La transacció de finançament inclou una sortida OP_RETURN amb un enllaç a IPFS que conté totes les dades del compromís i el codi font de la implementació.

4. El procés de reclamació: un atacant executant l’algorisme de Shor

Un atacant que disposi d’un ordinador quàntic recupera les metadades emmagatzemades a IPFS i segueix el procés següent per reclamar la recompensa:

1. Verificació: Recalcula el tagged hash i el tweak de $P_b$ per comprovar que l’HA coincideix amb les dades publicades i confirmar que no hi ha hagut cap manipulació.
2. Atac quàntic: Executa l’algorisme de Shor per resoldre l’ECDLP sobre la clau pública feble $P_w$, obtenint la clau privada feble $d_w$.
3. Desxifrat: Utilitza $d_w$ per recuperar $P_{ei}$ i $IV_i$ de cada $E_i$ present a les metadades d’IPFS i desxifra ECIES per recuperar totes les claus privades $d_{bi}$.
4. Reconstrucció: agrega totes les claus recuperades per obtenir la clau privada mestra: $d_b = \sum_{i=1}^n d_{bi} \pmod{n}$ (or $d_b = KeyAgg_{i=1}^n(d_{bi})$).
5. Reclamació dels fons: aplica el Taproot tweak sobre $d_b$ per obtenir la clau privada modificada $d_{bt}$, que li permet generar una signatura Schnorr vàlida per gastar els fons de l’HA.

5. Propietats del protocol i anàlisi de seguretat

• Compatibilitat: HA és indistingible d’una adreça P2TR (Pay-to-Taproot) estàndard, garantint una compatibilitat total amb Bitcoin.
• Correcció: si tots els participants proporcionen dades vàlides, qualsevol entitat capaç de trencar secp192r1 podrà recuperar matemàticament $d_{bt}$.
• Robustesa: la clau $d_b$ roman desconeguda mentre almenys un participant sigui honest. Cap participant, inclòs el coordinador, pot accedir als fons sense disposar d’un CRQC o sense la col·laboració de la resta de participants.
• Verificabilitat: totes les fases del protocol —des del procés iteratiu de derivació de $P_b$ fins al Taproot tweak— són auditables públicament a través de les dades publicades a IPFS.

6. Conclusions

El BHAP ofereix una solució pràctica davant la incertesa associada a la computació quàntica. En convertir l’amenaça abstracta que representa un CRQC en un incentiu econòmic tangible, el protocol crea un “canari quàntic” capaç de forçar la revelació de capacitats avançades abans que comprometin la seguretat de Bitcoin.

Les línies futures de recerca se centren en la integració completa de Proves de Coneixement Zero durant la Fase 4 per garantir la integritat del protocol davant participants maliciosos.