Qué puede ver y qué no puede ver el relay de SSP
SSP es una cartera de dos dispositivos. Tu extensión de navegador guarda una clave, tu teléfono guarda la otra, y ninguno puede mover fondos por su cuenta. Pero esos dos dispositivos tienen que hablar entre sí, y lo hacen a través de un servidor que gestionamos nosotros y que llamamos el relay.
Ese servidor es el lugar evidente para plantear una pregunta incómoda: si todo pasa por una infraestructura que opera la empresa de la cartera, ¿qué ve exactamente esa empresa?
Es una pregunta justa y merece una respuesta concreta en lugar de una tranquilizadora. Así que esto es lo que hay realmente en el código.
El relay no puede firmar nada
Empecemos por lo que más importa.
El relay nunca recibe una clave privada. Ni cifrada, ni fragmentada, ni de ninguna forma. La clave de tu cartera se queda en tu extensión de navegador y la clave de la aplicación se queda en tu teléfono; lo único que cruza la red son claves públicas, datos sin firmar y firmas que ya se hicieron en tus dispositivos.
Esto no es un compromiso de política, es un compromiso estructural. El multifirma dos de dos exige ambas firmas para mover fondos, y el relay no posee ninguna de las dos claves. Un relay completamente malicioso —el nuestro, comprometido, o sustituido por un atacante— sigue sin poder producir una transacción válida, porque producirla exige secretos que nunca se le enviaron.
Esa es la garantía. Todo lo que sigue trata de lo que el relay sí maneja, un conjunto más estrecho pero genuinamente no vacío.
Qué pasa por ahí, y durante cuánto tiempo
El relay guarda cuatro clases de registro. Dos de ellas se borran solas.
Datos de sincronización, cuando emparejas tus dos dispositivos. Llevan la cadena, tu identidad de cartera, la clave pública extendida de la aplicación, la identidad WK resultante, los nonces públicos, la dirección generada y el xpub de recuperación con su firma.
Datos de acción, cuando estás firmando algo. Llevan la cadena, la ruta de derivación, tu identidad WK, el tipo de acción, la carga útil misma y los UTXO pertinentes.
Ambas colecciones tienen en MongoDB un índice TTL fijado en expireAfterSeconds: 900. Quince minutos. La base de datos borra el registro pase lo que pase: no es una tarea de limpieza que alguien deba acordarse de ejecutar, ni una promesa en una política de privacidad. Es un índice, impuesto por la propia base de datos.
Tokens de notificación push, para que tu teléfono pueda despertarse cuando haya algo que aprobar. Estos persisten, porque un token de notificación que caducara cada quince minutos sería inútil.
El xpub de recuperación, uno por identidad, sin caducidad alguna. Es deliberado y el código lo dice: existe para que la cartera pueda recuperarlo cuando lo necesite, y no solo durante los breves lapsos en que ambas aplicaciones estén despiertas a la vez.
La parte sobre la que deberíamos ser francos
Mira otra vez esa carga de sincronización. Contiene una clave pública extendida.
Un xpub no es una clave de gasto y no puede autorizar una transacción. Pero no es nada trivial. A partir del xpub de una cuenta se puede derivar cada dirección que esa cuenta llegará a usar, lo que significa que quien lo tenga puede observar todo el saldo y el historial de transacciones de esa cadena. Es acceso de lectura a tu vida financiera en esa cuenta: justo el enlace que la privacidad en cadena depende de evitar.
La carga de acción es igual de real. Mientras firmas, el relay maneja la transacción sin firmar: adónde va el dinero, cuánto y desde qué salidas.
Así que el resumen honesto no es «el relay no ve nada». Es:
El relay no puede gastar tu dinero, y durante quince minutos seguidos puede ver qué estás haciendo con él.
La ventana de quince minutos es la mitigación, y es significativa: acota cuánto historial puede acumularse en un solo sitio. Pero durante esa ventana los datos están ahí, y preferimos decirlo con claridad antes que dejar que «no custodio» haga un trabajo retórico que no se ha ganado.
El principio de diseño que vale la pena tomar prestado
Hay un comentario en el servicio de recuperación que capta la arquitectura mejor que cualquier diagrama:
la cartera verifica esa firma contra la clave pública de identidad que ella misma deriva, de modo que este almacén no es de confianza.
El xpub de recuperación se guarda junto a una firma separada que SSP Key hizo sobre él. Cuando la cartera lo recupera, deriva de forma independiente la clave pública de identidad y comprueba la firma por sí misma. Si el relay devolviera un xpub distinto —por compromiso, por un fallo o por sustitución deliberada—, la firma no verificaría y la cartera lo rechazaría.
El software que depende del relay lo trata como una tubería no confiable. Esa es la manera correcta de construir sobre infraestructura propia, porque significa que un error de tu servidor no se convierte en problema de tus usuarios. Es también el patrón que hay que buscar al evaluar cualquier cartera: no «¿prometen portarse bien?», sino «¿qué pasa si su servidor se porta mal?».
Qué podría hacer realmente un relay hostil
Conviene ser concreto sobre el modelo de amenaza real.
Podría observar. Dentro de la ventana TTL, tu xpub y tu transacción pendiente. Eso es una exposición de privacidad, no un riesgo de robo.
Podría censurar. Negarse a pasar mensajes entre tus dispositivos, lo que te impediría firmar nuevas transacciones por el camino habitual. Molesto y perturbador, y no lo mismo que perder algo. Tus claves siguen siendo tuyas, tus fondos siguen en la cadena, y existen rutas de recuperación precisamente porque el relay podría no estar.
Podría mentir, y fracasar casi siempre. Sustituir un xpub de recuperación queda desbaratado por la comprobación de firma descrita arriba. Por eso importa esa verificación.
No puede firmar. Sin clave, sin firma, sin transacción.
El peor caso realista es vigilancia y disrupción, no pérdida. Es una posición apreciablemente mejor que la de un servicio custodio, donde el peor caso equivalente es que el dinero ya no está. No equivale a «nadie puede ver nada», y confundir ambas cosas es como la gente acaba con una imagen falsa de su propia privacidad.
Qué puedes hacer con las partes visibles
Entiende qué expone el emparejamiento. Sincronizar una cadena significa que un xpub de esa cadena transita por el relay. Ese es el coste de que el diseño de dos dispositivos funcione siquiera.
Recuerda que la ventana es corta, no nula. Quince minutos por acción es un límite, no una ausencia.
Trata el xpub de recuperación como permanente. Se guarda sin caducidad por diseño, y es material de clave pública con una firma verificable adjunta, pero es duradero, y conviene saberlo en vez de descubrirlo.
Juzga la arquitectura, no la promesa. La pregunta útil sobre el servidor de cualquier cartera no es si la empresa promete discreción. Es si el software se daría cuenta de que el servidor mintió. El nuestro comprueba firmas en lugar de confiar en respuestas, y puedes leerlo en el código en vez de creernos.
Lo que más nos gustaría que se entendiera es la forma del intercambio. Una cartera de dos dispositivos necesita un canal de coordinación, y un canal de coordinación es un sitio donde se acumulan metadatos. Lo hemos acotado con caducidad impuesta por la base de datos y hemos diseñado los clientes para que desconfíen del servidor, pero la versión honesta es que el relay ve cosas reales, brevemente, y ninguna arquitectura cuidadosa hace que ese número sea cero.
