Privacidad en la distribución clásica de claves cuánticas mediante zk-SNARKs

Privacidad en la distribuci´ on cl´ asica de claves cu´ anticas mediante zk-SNARKs David Soler, Carlos Dafonte y Francisco N´ ovoa CITIC, Universidade da Coru˜ na, A Coru˜ na Email: {david.soler,carlos.dafonte,fjnovoa}@udc.es M. Fern´ andez-Veiga y A. Fern´ andez Vilas atlanTTic, Universidade de Vigo, Vigo, Spain Email: {mveiga,avilas}@det.uvigo.es Resumen—Los n´ umeros aleatorios de alta entrop´ ıa son una parte esencial de la criptograf´ ıa, y los generadores cu´ anticos de n´ umeros aleatorios (QRNG) son una tecnolog´ ıa emergente que puede proporcionar claves de alta calidad para algoritmos criptogr´ aficos, pero lamentablemente son de dif´ ıcil acceso en la actualidad. Las soluciones existentes de Entrop´ ıa como Servicio requieren que los usuarios conf´ ıen en la autoridad central que distribuye el material de claves, lo que no es permisible en un entorno de alta privacidad. En este trabajo, presentamos un novedoso protocolo de transmisi´ on de claves que permite a los usuarios obtener material criptogr´ afico generado por un QRNG de forma que el servidor no pueda identificar qu´ e usuario recibe cada clave. Esto se consigue con la inclusi´ on de zk-SNARKs, una primitiva criptogr´ afica que permite a los usuarios demostrar el conocimiento de alg´ un valor sin necesidad de revelarlo. Tambi´ en proporcionamos una implementaci´ on del protocolo que demuestra su funcionalidad y rendimiento, utilizando NFC como canal de transmisi´ on de la clave QRNG. Index Terms—QRNG, transmisi´ on de clave, zk-SNARK, protoco de comunicaci´ on, Autenticaci´ on privada, NFC Tipo de contribuci´ on: Investigaci´ on en desarrollo I. INTRODUCCI´ ON Los n´ umeros aleatorios siempre han sido un elemento fundamental en la criptograf´ ıa. Todos los algoritmos criptogr´ aficos, desde los de cifrado sim´ etrico como AES hasta los asim´ etricos como RSA, requieren n´ umeros aleatorios como material de clave o par´ ametros de inicializaci´ on. Las fuentes m´ as comunes de aleatoriedad para fines criptogr´ aficos son los generadores de n´ umeros pseudoaleatorios (PRNG), que son procesos deterministas que se inicializan a partir de una semilla espec´ ıfica. Adem´ as, los PRNG pueden contener vulnerabilidades en sus implementaciones [1], [2] que los hacen vulnerables a ataques. Por ello, los PRNG suelen producir material clave de baja entrop´ ıa, lo que puede comprometer todo el esquema criptogr´ afico en el que se utilizan: no importa lo te´ oricamente seguro que sea un algoritmo de cifrado, podr´ ıa descifrarse f´ acilmente si un atacante consigue obtener la clave secreta aprovechando su generaci´ on insegura. No se trata s´ olo de un problema te´ orico: la generaci´ on de claves de baja entrop´ ıa se ha utilizado como punto de entrada para romper la confidencialidad en sistemas criptogr´ aficos de uso habitual [3], [4], [5]. Los Generadores Cu´ anticos de N´ umeros Aleatorios (QRNG) [6], [7], [8] son un tipo diferente de Generadores de N´ umeros Aleatorios que utilizan el comportamiento intr´ ınsecamente impredecible de las part´ ıculas cu´ anticas como fuente de entrop´ ıa. Por ello, el material clave que generan es de mayor calidad que el generado por un PRNG, y su uso podr´ ıa mejorar la seguridad de los algoritmos criptogr´ aficos actuales. Por desgracia, la tecnolog´ ıa a´ un no est´ a totalmente desarrollada y los QRNG tienen un coste elevado, por lo que no es viable distribuirlos de forma masiva y los usuarios finales tienen un acceso muy limitado a ellos. En contextos que requieran un alto nivel de privacidad, como las comunicaciones privadas, los usuarios se beneficiar´ ıan de tener acceso a claves criptogr´ aficas de alta entrop´ ıa, de tal forma que sea m´ as dif´ ıcil para los atacantes adivinar la clave que se ha utilizado. Adem´ as, facilitar el acceso a este material de claves podr´ ıa animar a los usuarios a tomarse en serio su privacidad y mejorar la seguridad general de sus comunicaciones. El objetivo de este trabajo es proporcionar un m´ etodo para que los usuarios finales obtengan material criptogr´ afico de mayor calidad mediante la definici´ on de un protocolo de transmisi´ on de claves en el que un servidor con acceso al QRNG distribuye claves aleatorias de forma segura a los usuarios que las solicitan. Como parte del proceso, el servidor exigir´ a a los clientes que se autentiquen antes de obtener el material criptogr´ afico generado por el QRNG. Sin embargo, las soluciones existentes de Entrop´ ıa como Servicio (EaaS) [9] requieren que los usuarios conf´ ıen en su servidor de distribuci´ on de claves, ya que este servidor puede rastrear qu´ e claves ha proporcionado a cada usuario. Un servidor malicioso o comprometido podr´ ıa utilizar las claves que ha transmitido para descifrar las comunicaciones de los usuarios o incluso suplantar su identidad. De hecho, el requisito de confiar en el servidor es una preocupaci´ on com´ un en los protocolos de distribuci´ on de claves. Este trabajo pretende dar soluci´ on a ese problema, dise˜ nando un protocolo de transmisi´ on de claves que busca un equilibrio entre exigir autenticaci´ on (es decir, solicitar informaci´ on privada a los usuarios de forma que el acceso quede restringido a aquellos que puedan demostrar su identidad) y proteger la privacidad de los usuarios. Este requisito se consigue con la inclusi´ on de Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARK) como pruebas de autenticaci´ on, una primitiva criptogr´ afica que permite a los usuarios demostrar que conocen alg´ un valor sin necesidad de revelarlo, de forma que cualquier verificador podr´ ıa convencerse de ello. Nuestro protocolo se divide en dos fases principales: en la primera, un usuario realiza la autenticaci´ on y, en la segunda, el usuario solicita la clave QRNG presentando una prueba zk- SNARK. La inclusi´ on de zk-SNARKs nos permite desacoplar claramente las dos fases, de forma que la presentaci´ on de la prueba zk-SNARK en la segunda fase no revela ninguna informaci´ on (ni siquiera al servidor) sobre las credenciales utilizadas en la primera fase. As´ ı, los usuarios pueden demostrar que se han autenticado previamente, de tal forma que el servidor no podr´ ıa distinguir al usuario de cualquier otro JNIC 2024 ISBN:978-84-09-62140-8 374 que haya realizado la autenticaci´ on alguna vez. Esto impide que el servidor de distribuci´ on de claves asocie una clave a un usuario concreto, lo que permitir´ ıa al servidor descifrar cualquier mensaje que utilice esta clave. Nuestro protocolo tambi´ en ofrece protecci´ on contra los ataques de repetici´ on: si un atacante intenta reutilizar la prueba zk-SNARK de otro usuario, el servidor detectar´ a el intento y abortar´ a la ejecuci´ on. Dado que los n´ umeros aleatorios son necesarios en todos los algoritmos criptogr´ aficos habituales, las claves QRNG distribuidas por el protocolo podr´ ıan ser ´ utiles en una amplia gama de aplicaciones. Por ejemplo, en situaciones en las que los usuarios necesiten establecer canales de comunicaci´ on con un alto nivel de confidencialidad, podr´ ıan emplear estos valores aleatorios como material de clave de alta calidad para algoritmos de cifrado sim´ etrico. Otra aplicaci´ on es la autenticaci´ on multifactor: la posesi´ on de un n´ umero aleatorio generado por este protocolo tambi´ en demuestra que su propietario ha realizado la autenticaci´ on con ´ exito, por lo que un servidor podr´ ıa exigir a los usuarios que ejecutaran este protocolo y presentaran el valor generado por el QRNG para proporcionarles acceso. En resumen, nuestro trabajo presenta las siguientes aportaciones: 1. Un Protocolo de Transmisi´ on de Claves para la distribuci´ on de claves QRNG. El protocolo requiere dos interacciones distintas entre clientes y el servidor: una para la autenticaci´ on y otra para la obtenci´ on de la clave QRNG. 2. Un m´ etodo de autenticaci´ on que preserva la privacidad para el Protocolo de Transmisi´ on de Claves. La autenticaci´ on se define de tal forma que es imposible para el servidor rastrear qui´ en recibe cada clave, evitando as´ ı que el servidor esp´ ıe las comunicaciones de los clientes que utilizan estas claves. Esto permite a los usuarios ejecutar el protocolo aunque no conf´ ıen en el servidor que genera las claves. Adem´ as, el protocolo est´ a dise˜ nado para evitar que se puedan falsificar pruebas sin haber realizado la autenticaci´ on, incluyendo protecci´ on contra ataques de repetici´ on. Denominaremos a nuestra propuesta Protocolo de Transmisi´ on de Claves que Preserva la Privacidad o, por sus siglas en ingl´ es, PPKTP. 3. Una implementaci´ on del Protocolo de Transmisi´ on de Claves propuesto. La implementaci´ on simula un caso de uso real, en el que el servidor se encuentra en alg´ un lugar espec´ ıfico al que los usuarios tienen que acudir. Parte de la comunicaci´ on se realiza a trav´ es de NFC y la clave se almacena en el tel´ efono m´ ovil de los usuarios. Se emplean dos librer´ ıas zk-SNARK diferentes para la generaci´ on y validaci´ on de pruebas, y el servidor tiene la opci´ on de utilizar dos QRNG para la generaci´ on de claves. El resto del documento est´ a organizado de la siguiente manera: La Secci´ on II revisar´ a trabajos relacionados y los comparar´ a con nuestra contribuci´ on. La Secci´ on III presentar´ a al lector el fondo t´ ecnico requerido. La Secci´ on IV explicar´ a en detalle todos los pasos involucrados en la ejecuci´ on del protocolo, as´ ı como las entidades que participan en ´ el. La Secci´ on V analizar´ a la implementaci´ on de prueba de concepto de todas las entidades involucradas en el protocolo. Finalmente, la Secci´ on VI concluir´ a este documento y se discutir´ an futuras mejoras. II. TRABAJO RELACIONADO Muchas de las mejoras recientes en fuentes de entrop´ ıa se han centrado en los Distributed Random Beacons (DRB) [15], [16]. En estos esquemas, un grupo de usuarios puede generar un valor aleatorio p´ ublico que puede ser verificado por todos los participantes y otras partes, asegurando que ning´ un usuario haya introducido sesgo en el c´ alculo. Si bien la aleatoriedad p´ ublica verificable es ´ util en m´ ultiples escenarios, todav´ ıa existe la necesidad de fuentes de entrop´ ıa que distribuyan los n´ umeros aleatorios generados de manera privada. Existen varios servicios que proporcionan aleatoriedad de alta entrop´ ıa a pedido, como random.org [17]. NIST ha dise˜ nado una arquitectura para la generaci´ on y distribuci´ on de n´ umeros aleatorios [9], que requiere que los clientes presenten un token de autenticaci´ on. En estos esquemas, el servidor sabe qu´ e cliente est´ a recibiendo cada valor aleatorio, y por lo tanto, cualquier material criptogr´ afico que se genere a trav´ es de ellos. Esto representa un problema de privacidad para los clientes, que quiz´ a no conf´ ıen en el servidor que proporciona la fuente de entrop´ ıa. El objetivo de la autenticaci´ on generalmente entra en conflicto con la privacidad de los usuarios: el servidor de autenticaci´ on puede requerir m´ as informaci´ on de la que el cliente est´ a dispuesto a proporcionar. Las Pruebas de Conocimiento Cero son una familia de herramientas criptogr´ aficas mediante los cuales un demostrador puede demostrar a un verificador que conoce cierta informaci´ on privada sin necesidad de revelarla. Su uso en protocolos de autenticaci´ on permite a los usuarios demostrar su identidad sin revelar informaci´ on sensible sobre s´ ı mismos. En variantes no interactivas de Pruebas de Conocimiento Cero, el usuario que se autentica y el verificador no necesitan establecer comunicaci´ on directamente: en su lugar, el usuario publica una prueba que puede ser verificada m´ as tarde por cualquier otra entidad. Los autores de [10] definen un esquema en el que los usuarios pertenecientes a ciertos dominios de confianza pueden autenticarse entre s´ ı y establecer sesiones de comunicaci´ on. Se define un m´ etodo para registrar nuevos usuarios, pero la defensa contra ataques de repetici´ on es d´ ebil, ya que utiliza marcas de tiempo: no protege contra repeticiones que ocurran en un corto per´ ıodo de tiempo. El esquema definido en [11] permite que las instituciones educativas presenten el diploma de un alumno en una cadena de bloques p´ ublica. Se utiliza una Prueba de Conocimiento Cero personalizada en m´ ultiples ocasiones, como proteger la identidad del alumno o atestiguar sus calificaciones. El protocolo no proporciona ninguna protecci´ on directa contra ataques de repetici´ on, pero repetir una prueba no es suficiente para suplantar a un alumno leg´ ıtimo: un atacante tambi´ en necesitar´ ıa conocer la clave secreta de ese alumno. Entre los algoritmos de Pruebas de Conocimiento Cero, los zk-SNARKs son una alternativa popular que tambi´ en se pueden usar en protocolos de autenticaci´ on. Los autores de [14] proponen un protocolo de autenticaci´ on para entornos de atenci´ on m´ edica en el que un conjunto de clientes prerregistrados se autentican con un zk-SNARK validado con Privacidad en la distribuci´on cl´asica de claves cu´anticas mediante zk-SNARKs 375 Scheme Purpose Authentication Method Client Registration External Infrastructure Replay protection [10] Key Agreement Discrete Logarithm Yes No Timestamp [11] E-learning records Zero Knowledge Proof Yes Yes (Blockchain) Secret key [12] Voting zk-SNARK No Yes (Blockchain) Yes [13] Identity Management zk-SNARK Yes Yes (Blockchain) No [14] Key Agreement zk-SNARK No Yes (Ethereum) Yes Ours Key Transmission zk-SNARK/Merkle Tree Yes No Yes Tabla I COMPARACI ´ ON ENTRE OTROS TRABAJOS QUE UTILIZAN AUTENTICACI´ ON NO INTERACTIVA DE CONOCIMIENTO CERO Y EL PROTOCOLO PROPUESTO. un Smart Contracts con el objetivo de establecer un canal de comunicaci´ on seguro. En [13], se inserta una autoridad de certificaci´ on en el esquema para validar los par´ ametros de los usuarios, que luego pueden proporcionar pruebas. Sin embargo, no presenta defensa contra atacantes que podr´ ıan interceptar la prueba de otro usuario y luego presentarla como propia. En [12], el enfoque se centra en definir un sistema que puede proporcionar Rastreabilidad y Trazabilidad para identificar usuarios malintencionados, mientras protege la privacidad de los usuarios honestos. Dado que los autores orientan su trabajo hacia una aplicaci´ on de votaci´ on, la lista de usuarios autorizados est´ a predefinida y no puede cambiarse. El concepto de Commitments yNullifiers, que se utilizan extensamente en este trabajo, se introduce en [18]. Al igual que en el protocolo propuesto, en ZCash los usuarios pueden crear un Commitment cuando tienen el derecho de realizar una acci´ on y deben publicar un Nullifier para consumirlo, acompa˜ nado de un zk-SNARK que verifica la relaci´ on entre estos hashes. La Tabla I compara el protocolo que proponemos con los trabajos mencionados en esta Secci´ on. Como se muestra, nuestro protocolo es capaz de introducir nuevos usuarios din´ amicamente en el sistema, no requiere infraestructura externa fuera del control del esquema y proporciona protecci´ on contra ataques de repetici´ on. III. FUNDAMENTOS TE´ ORICOS Para conseguir nuestro protocolo PPKTP, necesitaremos desacoplar los pasos de Autenticaci´ on y Solicitud de Clave, de forma que el servidor no pueda asociar a los clientes que realizan el segundo con las credenciales que utilizaron en el primero. Para ello, empleamos la primitiva criptogr´ afica zk- SNARK, que se define formalmente en la Secci´ on III-A. En este trabajo utilizamos zk-SNARKs para demostrar la pertenencia a un conjunto de usuarios v´ alidos. Para acelerar la generaci´ on de pruebas zk-SNARK, el conjunto mencionado se estructura como un ´ arbol Merkle, en el que demostrar la pertenencia a un grupo solo conlleva log2(N)operaciones, donde Nes el n´ umero total de usuarios. Por ´ ultimo, empleamos criptograf´ ıa asim´ etrica para transmitir de forma segura la clave QRNG al usuario en el ´ ultimo paso del protocolo. III-A. zk-SNARKs Los Argumentos de Conocimiento Cero Sucintos No Interactivos (o zk-SNARK, por sus siglas en ingl´ es) son un subconjunto de las pruebas de conocimiento cero no interactivas. Un zk-SNARK se construye a partir de una relaci´ on Rentre una afirmaci´ on p´ ublica xy un testigo privado w. Si la relaci´ on entre wyxse mantiene, entonces (x, w)∈R. De la descripci´ on de Rpuede derivarse un par´ ametro de seguridad λ. Formalmente, un esquema zk-SNARK Πpara una relaci´ on Rse compone de la tupla (Gen,Prove,Verify), definida como sigue: Setup(R)→(pk, vk): Toma una relaci´ on y devuelve el Common Reference String (CRS), que se divide en la Clave de Prueba pk y la Clave de Verificaci´ on vk. Prove(pk, x, w)→π: A partir de pk, un testigo wy una afirmaci´ on x, se genera una prueba π. Verify(vk, x, π)→Accept/Reject: A partir de vk, una prueba πy la correspondiente afirmaci´ on x, se obtiene Accept oReject. En el contexto de este trabajo, un prueba v´ alida se refiere a cualquier (xv, πv)tal que Verify(vk, xv, πv) = Accept. Un esquema zk-SNARK tambi´ en debe cumplir los siguientes requisitos de seguridad [19]: Completeness: La probabilidad Pr "(pk, vk)←Gen(R) π←Prove(pk, x, w) (x, w)∈R :¬Verify(vk, x, π)# es despreciable. Intuitivamente, esto significa que un usuario honesto es capaz de convencer a un verificador de que (x, w)∈R. Knowledge Soundness: Para cada adversario eficiente A, existe un extractor eficiente ExtAcon acceso al estado interno de Atal que la probabilidad Pr "((pk, vk), aux)←Gen(R) (x, π)←A(R, aux, (pk, vk)) w←ExtA(R, aux, (pk, vk)) :(x, w)/∈R∧ Verify(vk, x, π)# es despreciable, donde aux es una entrada auxiliar producida por Gen. Intuitivamente, esto significa que un usuario deshonesto no puede generar una prueba v´ alida si no conoce w. Zero-knowledge: Para cada adversario A que act´ ua como caja negra y (x, w)∈R, existe un simulador Sim((pk, vk), aux, x)tal que se cumple la siguiente igualdad: Pr ((pk, vk), aux)←Gen(R) π←Prove(pk, x, w):A((pk, vk), aux, x, π) = 1  ≈ Pr ((pk, vk), aux)←Gen(R) π←Sim((pk, vk), aux, x):A((pk, vk), aux, x, π) = 1  donde aux es una entrada auxiliar producida por Gen. Intuitivamente, esto significa que un atacante no puede averiguar nada sobre un testigo wa partir de una prueba π, una afirmaci´ on xy un par de claves (pk, vk). D. Soler, C. Dafonte, M. Fern´andez-Veiga, A. Fern´andez Vilas and F. Novoa 376 Weak Simulation-Extractability: Para cada adversario eficiente Acon acceso a un or´ aculo O, existe un extractor eficiente ExtAcon acceso al estado interno de Atal que la probabilidad Pr "((pk, vk), aux)←Gen(R) (x, π)←AO(aux)(R, aux, (pk, vk)) w←ExtA(R, aux, (pk, vk)) : x /∈Q ∧(x, w)/∈R ∧Verify(vk, x, π)# es despreciable, donde aux es una entrada auxiliar producida por Gen y Q es la lista de afirmaciones xisolicitada al or´ aculo. Esto significa que Ano puede generar una prueba v´ alida para un enunciado que no se haya obtenido del or´ aculo. N´ otese que existe una noci´ on m´ as fuerte de Simulation-Extractability que requiere que tanto la sentencia xcomo la prueba πno est´ en incluidas en Q. Sin embargo, para este trabajo s´ olo requerimos la versi´ on d´ ebil de Simulation-Extractability. En la pr´ actica, los esquemas zk-SNARK pueden construirse mediante diferentes t´ ecnicas criptogr´ aficas. Los dise˜ nos m´ as populares, incluido el de Groth16 [20] (que utilizaremos en este trabajo) implican la transformaci´ on de un c´ alculo en un circuito aritm´ etico. El rendimiento de un esquema zk- SNARK, especialmente durante la configuraci´ on y la generaci´ on de pruebas, depende en gran medida del n´ umero de restricciones de este circuito [21], que vienen determinadas por el c´ alculo que se va a verificar. III-B. ´ Arboles Merkle Los ´ arboles Merkle [22] son una estructura de datos en forma de ´ arbol binario. Cada elemento se identifica como hi,j, donde ies el nivel del ´ arbol y jla posici´ on dentro de dicho nivel. Un ´ Arbol Merkle de profundidad ncontiene como m´ aximo l= 2nnodos hoja hn,j que contienen un hash, y los nodos intermedios toman el valor hk,j =H(hk+1,m ∥ hk+1,m+1), donde ∥es el operador de concatenaci´ on, Hes una funci´ on hash y m= 2j. El nodo h0,0se denomina ra´ ız, y su valor est´ a determinado por todos los dem´ as nodos del ´ Arbol. La principal ventaja de los ´ Arboles Merkle es que comprobar si un elemento eexiste dentro de la lista de nodos hoja es solo O(log l), mientras que la misma operaci´ on para una lista ser´ ıa O(l). Para ello, debe proporcionarse una lista de validaci´ on {hn−1,kn−1, hn−2,kn−2, ..., h1,k1}y el nodo ra´ ız h0,0del ´ Arbol Merkle. Si es posible reconstruir la ra´ ız proporcionada a partir de H(e)y la lista de validaci´ on, entonces se demuestra que eest´ a dentro del ´ Arbol de Merkle. Este m´ etodo requiere que la funci´ on hash Hutilizada para construir el ´ Arbol de Merkle sea resistente a colisiones [23]: de lo contrario, un atacante podr´ ıa demostrar que un elemento falso efest´ a dentro del ´ Arbol Merkle cuando no lo est´ a. Para el ´ ambito de este trabajo, se definen las siguientes operaciones para los ´ Arboles Merkle: 1. EmptyTree(n)→T: Inicializa un ´ Arbol Merkle vac´ ıo de profundidad n, con todos sus nodos hoja establecidos aH(0). 2. AddLeaf(T, h)→T′: Recibe un ´ Arbol Merkle Ty un hash hy devuelve un ´ arbol modificado, en el que el nodo cuyo valor es H(0) que est´ e situado m´ as a la izquierda es sustituido por h. Los nodos intermedios y ra´ ız se actualizan en consecuencia. 3. GetRoot(T)→R: Recibe un ´ Arbol Merkle Ty devuelve la ra´ ız h0,0. 4. GetIndexOf(T, h)→index: Recibe un ´ Arbol Merkle Ty un hash hy devuelve ital que hn,i =hpara alg´ un hn,i en el ´ Arbol. 5. ValidationList(T, i)→V al = {hn−1,kn−1, hn−2,kn−2, ..., h1,k1}: Recibe un ´ Arbol Merkle Ty un ´ ındice iy devuelve la lista de validaci´ on necesaria para validar la hoja hn,i. 6. IsLeafOfTree(h, i, V al, R)→true/false: Recibe un hash h, su ´ ındice i, una lista de validaci´ on V al = {hn−1,kn−1, hn−2,kn−2, ..., h1,k1}y una ra´ ız Ry devuelve true si hes la hoja con ´ ındice idel ´ arbol con ra´ ız = R, y false en caso contrario. III-C. Mecanismo de Encapsulaci´ on de Claves Un mecanismo de encapsulaci´ on de claves [24], [25] (o KEM, por sus siglas en ingl´ es) es un m´ etodo de distribuci´ on de claves entre dos partes que utiliza criptograf´ ıa asim´ etrica. El emisor utiliza la clave p´ ublica del receptor para cifrar el material clave de entrada de forma que s´ olo el receptor pueda descifrarlo. Ambas partes deben acordar qu´ e algoritmo de cifrado asim´ etrico se utilizar´ a para la encapsulaci´ on. En el Cifrado H´ ıbrido de Clave P´ ublica [26], el material de clave se introduce posteriormente en una KDF para obtener una clave sim´ etrica. Un KEM se compone de las siguientes operaciones: KeyGen(λ)→(pk, sk): Toma un par´ ametro de seguridad λy genera un par de claves sim´ etricas. Encap(ikm, pk)→c: Cifra una clave de entrada ikm con una clave p´ ublica pk. Decap(c, sk)→km: Descifra un texto cifrado con una clave secreta sk para obtener el material de claves. IV. PROTOCOLO DE TRANSMISI´ ON DE CLAVE QUE PRESERVA LA PRIVACIDAD (PPKTP) IV-A. Visi´ on General El protocolo requiere dos interacciones diferentes entre los Usuarios y el Servidor: la Autenticaci´ on y la Solicitud de Clave. La principal aportaci´ on de nuestro protocolo es la capacidad de desacoplar ambas interacciones, que se consigue mediante el uso de zk-SNARKs: al solicitar una clave, los Usuarios deben demostrar que han realizado previamente la autenticaci´ on. Durante la autenticaci´ on, los Usuarios deben presentar credenciales v´ alidas que certifiquen su identidad, como un certificado digital. Si estas credenciales son correctas, se les permite publicar un Commitment, que el Servidor incluye en una estructura de Commitments v´ alidos (que, por razones de eficiencia, es un ´ Arbol Merkle). As´ ı, un Commitment identifica a un Usuario concreto, porque se publica junto con la informaci´ on de autenticaci´ on. Tambi´ en representa el derecho del Usuario a obtener una clave QRNG en pasos posteriores. Los Usuarios deben generar un Nullifier, que es un valor que est´ a criptogr´ aficamente relacionado con su Commitment: se generan a partir de las mismas entradas, pero s´ olo el Usuario que ha creado ambos sabe que est´ an relacionados. Tambi´ en generan una prueba zk-SNARK que certifica la Privacidad en la distribuci´on cl´asica de claves cu´anticas mediante zk-SNARKs 377 Figura 1. Diagrama del protocolo propuesto. relaci´ on entre el Commitment y el Nullifier, pero sin revelar el valor del primero de ambos. La prueba tambi´ en certifica que el Commitment est´ a dentro de la estructura de Commitments v´ alidos. Para realizar la Solicitud de Clave, los Usuarios env´ ıan el Nullifier y la prueba zk-SNARK antes mencionados al Servidor, que valida dichos valores. Si la prueba es v´ alida, el Servidor (1) sabe que existe un Commitment relacionado con este Nullifier espec´ ıfico dentro de la estructura de Commitments v´ alidos, pero (2) no sabe de cu´ al de todos los Commitments v´ alidos se trata. Cabe destacar que (1) demuestra que el Usuario ha realizado el intercambio de Autenticaci´ on, mientras que (2) garantiza que ni el Servidor ni ninguna otra entidad puedan conocer la identidad del Usuario. Por ´ ultimo, el Servidor almacena el Nullifier para evitar ataques de repetici´ on: cualquier otra Solicitud de Clave que contenga el mismo Nullifier ser´ a rechazada. IV-B. Arquitectura En el protocolo PPKTP participan las siguientes entidades: Usuario (U): ejecuta el protocolo e inicia la comunicaci´ on para ambos Pasos. En el Paso de Autenticaci´ on, los Usuarios deben proporcionar su certificado digital y generar un Commitment. A continuaci´ on, generan un Nullifier y un zk-SNARK vincul´ andolo al Commitment. Servidor de Autenticaci´ on (AS): recibe las solicitudes de autenticaci´ on de los Usuarios. Cuando el certificado de un usuario se valida correctamente, el AS inserta el Commitment proporcionado en el ´ arbol Merkle de Commitment y actualiza los nodos y la ra´ ız necesarios. El AS tambi´ en debe proporcionar una copia del ´ Arbol Merkle a cualquiera que lo solicite. Servidor de Validaci´ on de Pruebas (PVS): recibe pruebas zk-SNARK de los Usuarios y las valida. El PVS almacena la lista de todos los Nullifiers publicados, por lo que rechaza cualquier prueba que vaya acompa˜ nada de un Nullifier que ya haya sido publicado. El PVS necesita informaci´ on sobre el ´ Arbol Merkle para validar las pruebas zk-SNARK, por lo que debe comunicarse con el AS para obtener esta estructura de datos. Es la ´ unica entidad del protocolo que puede acceder al QRNG, que utiliza para generar material de claves para los Usuarios que presenten pruebas zk-SNARK v´ alidas. El AS y el PVS son entidades l´ ogicas, por lo que pueden Name Description crs Common Reference String del esquema zk-SNARK pkcrs Clave de Prueba del esquema zk-SNARK vkcrs Clave de Verificaci´ on del esquema zk-SNARK T´ Arbol Merkle de Commitments Told Lista de anteriores ra´ ıces de T LNLista de Nullifiers ya publicados cert certificado digital del Usuario ck Clave privada de cert Tabla II LISTA DE NOTACI ´ ON DEL PROTOCOLO PROPUESTO. implementarse tanto como uno como dos programas diferentes. Toda la informaci´ on almacenada por el AS y el PVS (es decir, el ´ Arbol Merkle de Commitments y la Lista de Nullifier) est´ a expuesta para que los Usuarios puedan acceder libremente a ella sin comprometer la seguridad del protocolo. La figura 1 muestra un diagrama de la interacci´ on entre el Usuario, el Servidor de Autenticaci´ on y el Servidor de Validaci´ on de Pruebas, tal y como se esboza en IV-A. IV-C. Definici´ on del Protocolo El protocolo PPKTP utiliza como primitivas una funci´ on hash H, un esquema zk-SNARK ZK = (ZK.Setup, ZK.Prove, ZK.Verify), un esquema de ´ Arbol Merkle M = (M.EmptyTree, M.AddLeaf, M.GetRoot, M.GetIndexOf, M.ValidationList, M.IsLeafOfTree) y un KEM K = (K.KeyGen, K.Encap, K.Decap). La Tabla II indica la notaci´ on utilizada para referenciar a los elementos que participan en el protocolo. Inicializaci´ on de par´ ametros:Antes de la ejecuci´ on del protocolo, es necesario inicializar algunos par´ ametros. La operaci´ on que se ejecuta en este paso inicial es: ServerSetup(R, n)→((pkcrs, vkcrs), T, Told, LN): Se inicializan las claves y las estructuras de datos que se utilizar´ an durante la ejecuci´ on del protocolo. Se inicializa el esquema zk-SNARK a partir de su relaci´ on R, y se crea un ´ Arbol Merkle vac´ ıo de profundidad n. La relaci´ on con la que se inicializa el esquema zk-SNARK es la siguiente: R=     (x, w) = ((N, root), (ρ, pk, sk, C, iC, V al)) : C=H(sk ∥ρ), N=H(pk ∥ρ), M.IsLeafOfTree(C, iC, V al, root)      (1) Intuitivamente, la relaci´ on Rdemuestra que el Commitment y el Nullifier se generan a partir de un par de claves (pk, sk) y un valor secreto ρ, que s´ olo conoce el Usuario que cre´ o ambos hashes. Tambi´ en se demuestra que el Commitment est´ a dentro de un ´ Arbol Merkle con ra´ ız root. Esta misma relaci´ on se muestra en la Figura 2. Paso 1: Autenticaci´ on:Para realizar el primer paso del protocolo, un usuario Udebe crear primero un Commit Note, que contiene un valor secreto y un par de claves. A continuaci´ on, debe autenticarse ante el AS. Si lo consigue, el AS a˜ nadir´ a el Commitment CUaT. El Paso de Autenticaci´ on requiere la ejecuci´ on de las siguientes operaciones: UserInit(λ)→note:Ucrea un Commit Note noteUque contiene el valor secreto ρUy un par de claves de cifrado asim´ atrico (pkU, skU). A continuaci´ on, almacena noteU de forma segura. El tama˜ no de estos valores depende del par´ ametro de seguridad λ. D. Soler, C. Dafonte, M. Fern´andez-Veiga, A. Fern´andez Vilas and F. Novoa 378 Figura 2. Diagrama de la relaci´ on entre Commitments y Nullifiers. Auth(cert, ck, note)→(C, σC):Uutiliza noteUpara generar un Commitment CU=H(pkU∥ρ). donde ”∥.es el operador de concatenaci´ on. A continuaci´ on, firma CU con la clave privada de su certificado ckU. Register(cert, C, σC, T, Told)→(true/false, T, Told): El AS comprueba la validez del certificado certUpresentado por U. A continuaci´ on, verifica la firma σUcon la clave p´ ublica de certU. Si es v´ alida, el AS inserta CU en el ´ arbol Merkle T. Cabe destacar que, aunque el m´ etodo de autenticaci´ on del protocolo que presentamos implica el uso de certificados, el Paso de Autenticaci´ on es lo suficientemente flexible como para permitir otros tipos de autenticaci´ on o atestaci´ on. Se podr´ ıan implementar diferentes AS que soliciten otra informaci´ on a U(por ejemplo, contrase˜ nas, datos biom´ etricos, .. .), siempre y cuando inserten CUen Tdespu´ es de una autenticaci´ on exitosa. Paso 2: Generaci´ on de Prueba:Despu´ es de una autenticaci´ on exitosa, el Commitment CUde Use almacena en T. En este Paso, Udemuestra que conoce alg´ un Commitment dentro de Tgenerando una prueba zk-SNARK. Para ello, Udebe descargar primero una copia del ´ Arbol de Merkle del AS. A continuaci´ on, Upuede utilizar el ´ Arbol y noteUpara formar el Testigo zk-SNARK w= (ρU, pkU, skU, CU, iC, V alU), necesario para crear la prueba zk-SNARK. Se ejecuta la siguiente operaci´ on: CreateProof(note, T, pkcrs)→(π, x):Urecalcula su Commitment CUy genera el Nullifier NU, ambos a partir de los valores dentro de noteU. A continuaci´ on, utiliza el esquema zk-SNARK para crear una prueba πU que demuestre que CUest´ a dentro de T (sin revelar qu´ e elemento es) y que CUyNUse generaron a partir del mismo Commit Note. Paso 3: Solicitud de Clave:En este ´ ultimo Paso, U env´ ıa la prueba de que ha realizado con ´ exito el Paso 1 al PVS, que es la ´ unica entidad del protocolo con acceso al QRNG. El mensaje de Ual PVS incluye πUy la afirmaci´ on x= (NU,ra´ ız). Si la informaci´ on proporcionada por Use valida correctamente, el PVS responder´ a a Ucon material de claves generado por el QRNG. Las operaciones realizadas por Uy el PVS en el Paso de Solicitud de Clave son las siguientes: VerifyProof(π, x, T, Told, LN, vkcrs)→ (true/false, LN): El PVS verifica la prueba zk- SNARK πUgenerada por Uen la fase anterior. Tambi´ en comprueba que la ra´ ız rootUque forma parte de la afirmaci´ on zk-SNARK xUse corresponde con la ra´ ız del ´ Arbol Merkle actual o cualquiera de sus versiones pasadas y que el Nullifier NUno se ha presentado todav´ ıa. Si todas las comprobaciones tienen ´ exito, NUse incluye en una lista de ”Nullifiers utilizados”, de forma que no se puede volver a utilizar. DeliverKey(t, pk)→enc: El PVS genera tbytes de material clave con su QRNG y luego lo cifra con la clave p´ ublica pk de U. V. IMPLEMENTACI´ ON Proporcionamos una implementaci´ on de nuestro protocolo para demostrar su aplicabilidad. Representamos un caso de uso real en el que las claves QRNG se transmiten a trav´ es de NFC al dispositivo m´ ovil del usuario, de forma que estas claves podr´ ıan utilizarse para cifrar de forma segura la informaci´ on del usuario dentro de su tel´ efono. Nuestra implementaci´ on se compone de los siguientes elementos: Tres programas en el lenguaje de programaci´ on Java que representan al Usuario, al Servidor de Autenticaci´ on y al Servidor de Validaci´ on de Pruebas. Ambos servidores est´ an ubicados en la misma m´ aquina, y tienen acceso local a sus archivos compartidos. El AS es una API REST implementada con Spring Boot. Dado que los servidores no necesitan mantener ninguna informaci´ on privada, el AS permite a los Usuarios solicitar cualquiera de sus estructuras de datos: el ´ Arbol Merkle, la ista de Nullifiers y la lista de ra´ ıces de antiguos ´ Arboles Merkle. Una librer´ ıa encargada de la implementaci´ on del esquema zk-SNARK, incluyendo la definici´ on de circuitos y la generaci´ on y validaci´ on de pruebas. Un dispositivo QRNG para la generaci´ on del material clave. Un t´ unel NFC para la comunicaci´ on entre el Usuario y el PVS. Para ello, hemos implementado una App Android que emplea el c´ odigo del Usuario y act´ ua como una Smart Card NFC. El PVS tiene acceso a un Lector NFC ACR 122U USB para recibir las peticiones de los Usuarios. V-A. zk-SNARKs Todas las operaciones relacionadas con la generaci´ on y validaci´ on de zk-SNARK en este trabajo se han implementado con dos librer´ ıas diferentes: libsnark [27] y ZoKrates [28], a las que nos referiremos como backends de zk-SNARK. Ambas librer´ ıas requieren definir las sentencias que el zk- SNARK debe probar, que en este protocolo corresponden a las sentencias que se especificaron en la Secci´ on IV. Ambos backends de zk-SNARK requieren un proceso similar para la definici´ on del esquema zk-SNARK. En primer lugar, la relaci´ on R(en este caso, la relaci´ on mostrada en la Ecuaci´ on 1 debe codificarse en el lenguaje espec´ ıfico del backend de zk-SNARK. A continuaci´ on, se compila este c´ odigo y se genera un circuito aritm´ etico que representa el c´ alculo. Para ambos backends de zk-SNARK, los usuarios Privacidad en la distribuci´on cl´asica de claves cu´anticas mediante zk-SNARKs 379 pueden interactuar con el programa compilado a trav´ es de la l´ ınea de comandos. Una vez compilado, se puede generar el Common Reference String (CRS) a partir del circuito aritm´ etico. El CRS est´ a compuesta por la Clave de Prueba y la Clave de Verificaci´ on. Para ejecutar Prove, los usuarios deben proporcionar tanto la Afirmaci´ on x= (ra´ ız, N)y el Testigo w= (ρ, pk, sk, C, iC, V al). Para verificar una prueba π, s´ olo se requiere la Declaraci´ on. Hemos elegido Groth16 [20] como esquema zk-SNARK, ya que consigue los tiempos m´ as r´ apidos de generaci´ on y validaci´ on de pruebas [21]. Adem´ as, satisface todas las propiedades mencionadas en la Secci´ on III-A [29]. V-B. QRNG En este trabajo hemos utilizado dos QRNG diferentes: ”Quantis QNRG USB”de IDQuantique: Este dispositivo es accesible a trav´ es de una interfaz USB, y sus manufacturadores proporcionan una API para m´ ultiples lenguajes de programaci´ on. Su velocidad de generaci´ on de claves es de aproximadamente 4 Mb/s. M´ odulo QRNG del Centro de Supercomputaci´ on de Galicia (CESGA): Este supercomputador tiene infraestructura nativa de QRNG que puede generar hasta 400 Mb/s de material de clave. Se requiere una conexi´ on remota SSH para acceder al dispositivo, lo cual introduce un coste adicional para la obtenci´ on de material de clave. V-C. T´ unel NFC Near Field Communication (NFC) [30], [31], [32], [33] es una tecnolog´ ıa que permite la comunicaci´ on inal´ ambrica entre dos dispositivos f´ ısicamente cercanos: un lector que inicia la comunicaci´ on y una Smart Card que responde a las peticiones del lector. Los mensajes NFC se encapsulan en Application Protocol Data Units (APDUs). NFC se considera m´ as seguro que otras tecnolog´ ıas de comunicaciones inal´ ambricas como Bluetooth debido a su peque˜ na ´ area de transmisi´ on (que impide que atacantes puedan capturar las APDUs) y su r´ apido proceso de inicializaci´ on de la conexi´ on. La mayor´ ıa de dispositivos m´ oviles soportan NFC, e incluyen la capacidad de emular una Smart Card para crear APDUs de manera din´ amica para responder a lectores NFC. Esto hace que NFC sea un m´ etodo c´ omodo para transmitir material de clave a los usuarios de nuestro protocolo, ya que este se almacenar´ ıa en sus tel´ efonos m´ oviles. En nuestra implementaci´ on, toda la comunicaci´ on entre Usuarios y el PVS en el Paso 3 se realiza mediante NFC. El lector NFC del PVS interact´ ua con el tel´ efono m´ ovil de U, que contiene una App que ejecuta nuestro protocolo. Dado que es el lector NFC el que debe iniciar la comunicaci´ on, se requiere un m´ etodo ad hoc para transmitir la prueba zk-SNARK del Usuario al PVS. La Figura 3 muestra el m´ etodo definido para esta transmi- si´ on. El PVS debe primero asegurarse de que el dispositivo m´ ovil de Ucontiene la App espec´ ıfica que ejecuta nuestro protocolo. Si es as´ ı, el PVS pregunta la longitud del mensaje a enviar, y entonces realiza tantas peticiones como sean necesarias para recibir la prueba zk-SNARK completa. La prueba se divide en segmentos para poder encapsularse en APDUs, cuyo tama˜ no est´ a limitado a 255 bytes. a continuaci´ on, el User User Validator Validator (1) App with AID xxxxxx? Yes (2) Length of message? N loop [until all proof sent] (3i) Request Segment i Segment i Validate proof alt [proof valid] (4a) Success, QRNG Key [proof invalid] (4b) Error OK (5) End Transmission OK Figura 3. Diagrama de secuencia del t´ unel NFC. PVS comprueba la validez de la prueba y en caso afirmativo devuelve la clave QRNG. En caso contrario, devuelve un error. Finalmente, el PVS env´ ıa un mensaje de ”Fin de la Transmisi´ on”que se˜ naliza al dispositivo m´ ovil de que puede cerrar la conexi´ on. VI. CONCLUSI´ ON Y TRABAJO FUTURO En este trabajo hemos presentado un Protocolo de Transmisi´ on de Clave que Preserva la Privacidad para distribuir material criptogr´ afico generado por QRNG, en el que se utilizan zk-SNARKs para asegurar que el servidor no puede identificar cu´ al de los usuarios est´ a recibiendo cada clave. Por lo tanto, los usuarios no necesitan confiar en el servidor para solicitar estas claves. El protocolo puede ser utilizado para proporcionar material de clave de alta calidad a usuarios finales, que podr´ an incorporar a su pila de protocolos de comunicaci´ on para aumentar su seguridad. Nuestra implementaci´ on del protocolo demuestra su aplicabilidad a un caso de uso real, en el que las claves generadas por QRNG son enviadas al dispositivo m´ ovil de los usuarios a trav´ es de NFC, utilizando un m´ etodo personalizado para transmitir informaci´ on arbitraria encapsulada en APDUs. En nuestra implementaci´ on utilizamos dos librer´ ıas diferentes de generaci´ on y validaci´ on de zk-SNARKs. Continuaremos con este trabajo proporcionando demostraciones formales de la seguridad de nuestro protocolo y midiendo el rendimiento de nuestra implementaci´ on bajo diferentes par´ ametros. RECONOCIMIENTO Este trabajo est´ a financiado por el Plan Complementario de Comunicaciones Cu´ anticas, Ministerio de Ciencia e Innovaci´ on(MICINN), Plan de Recuperaci´ on NextGeneration, Uni´ on Europea (PRTR-C17.I1, CITIC Ref. 305.2022), y la Xunta D. Soler, C. Dafonte, M. Fern´andez-Veiga, A. Fern´andez Vilas and F. Novoa 380 de Galicia (Agencia Gallega de Innovaci´ on, GAIN, CITIC Ref. 306.2022) D.S. reconoce el apoyo de Xunta de Galicia y de la Uni´ on Europea (European Social Fund - ESF), beca [ED481A-2023-219]. Este trabajo es parte de los proyectos TED2021- 130369B-C31 y TED2021-130492B-C21, financiados por MCIN/AEI/10.13039/501100011033 y por “ERDF A way of making Europe”. Trabajo desarrollado gracias al acceso concedido por el Centro de Supercomputaci´ on de Galicia a la infraestructura basada de tecnolog´ ıas cu´ anticas de la informaci´ on que permita impulsar I+D+I en Galicia. Esta infraestructura fue financiada por la Uni´ on Europea, a trav´ es del FONDO EUROPEO DE DESARROLLO REGIONAL (FEDER), como parte de la respuesta de la Uni´ on Europa a la pandemia de la COVID-19. REFERENCIAS [1] K. Bhattacharjee and S. Das, “A search for good pseudo-random number generators: Survey and empirical studies,” Comput. Sci. Rev., vol. 45, no. C, aug 2022. [2] A. Saini, A. Tsokanos, and R. Kirner, “Quantum randomness in cryptography—a survey of cryptosystems, RNG-based ciphers, and QRNGs,” Information, vol. 13, no. 8, p. 358, 2022. [3] N. Heninger, Z. Durumeric, E. Wustrow, and J. Halderman, “Mining your Ps and Qs: detection of widespread weak keys in network devices,” in 21st USENIX Security Symposium (USENIX Security 12), 08 2012, pp. 35–35. [4] D. Antonioli, N. O. Tippenhauer, and K. B. Rasmussen, “The KNOB is broken: Exploiting low entropy in the encryption key negotiation of bluetooth BR/EDR,” in 28th USENIX Security Symp. (USENIX Security 19), Santa Clara, CA, Aug. 2019, pp. 1047–1061. [5] D. Kaplan, S. Kedmi, R. Hay, and A. Dayan, “Attacking the Linux PRNG on Android: Weaknesses in seeding of entropic pools and low boot-time entropy,” in Proc. of the 8th USENIX Conference on Offensive Technologies, ser. WOOT’14, USA, 2014, p. 14. [6] D. Hurley-Smith and J. Hernandez-Castro, “Quantum leap and crash: Searching and finding bias in quantum random number generators,” ACM Trans. Priv. Secur., vol. 23, no. 3, pp. 1–25, jun 2020. [7] M. Stipˇ cevi´ c, “Quantum random number generators and their use in cryptography,” in 2011 Proceedings of the 34th International Convention MIPRO, 2011, pp. 1474–1479. [8] M. M. Jacak, P. J´ o´ zwiak, J. Niemczuk, and J. E. Jacak, “Quantum generators of random numbers,” Scientific Reports, vol. 11, no. 1, p. 16108, Aug 2021. [9] A. Vassilev and R. Staples, “Entropy as a service: Unlocking cryptography’s full potential,” Computer, vol. 49, no. 9, pp. 98–102, 2016. [10] S. Liu, L. Chen, H. Yu, S. Gao, and H. Fang, “BP-AKAA: Blockchainenforced privacy-preserving authentication and key agreement and access control for iiot,” Journal of Information Security and Applications, vol. 73, p. 103443, 2023. [11] H. An and J. Chen, “Elearnchain: A privacy-preserving consortium blockchain system for e-learning educational records,” Journal of Information Security and Applications, vol. 63, p. 103013, 2021. [12] P. Li, J. Lai, and Y. Wu, “Event-oriented linkable and traceable anonymous authentication and its application to voting,” Journal of Information Security and Applications, vol. 60, p. 102865, 2021. [13] J. Lee, J. Y. Hwang, J. Choi, H. Oh, and J. Kim, “Sims : Self sovereign identity management system with preserving privacy in blockchain,” IACR Cryptol. ePrint Arch., vol. 2019, p. 1241, 2019. [14] D. A. Luong and J. H. Park, “Privacy-preserving blockchain-based healthcare system for iot devices using zk-snark,” IEEE Access, vol. 10, pp. 55 739–55 752, 2022. [15] A. Kavousi, Z. Wang, and P. Jovanovic, “Sok: Public randomness,” Cryptology ePrint Archive, Paper 2023/1121, 2023, https://eprint.iacr. org/2023/1121. [Online]. Available: https://eprint.iacr.org/2023/1121 [16] M. Raikwar and D. Gligoroski, “Sok: Decentralized randomness beacon protocols,” in Australasian Conference on Information Security and Privacy. Springer, 2022, pp. 420–446. [17] M. Haahr, “Random. org: True random number service,” School of Computer Science and Statistics, Trinity College, Dublin, Ireland. Website (http://www. random. org). Accessed, vol. 10, 2010. [18] D. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, “Zcash protocol specification,” GitHub: San Francisco, CA, USA, vol. 4, p. 220, 2016. [19] H. Ko, I. Lee, S. Lee, J. Kim, and H. Oh, “Efficient verifiable image redacting based on zk-snarks,” Cryptology ePrint Archive, Paper 2020/1579, pp. 213–226, 2020. [20] J. Groth, “On the size of pairing-based non-interactive arguments,” in Advances in Cryptology – EUROCRYPT 2016, M. Fischlin and J.-S. Coron, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2016, pp. 305–326. [21] K. Baghery, Z. Pindado, and C. R` afols, “Simulation extractable versions of groth’s zk-snark revisited,” in Cryptology and Network Security, S. Krenn, H. Shulman, and S. Vaudenay, Eds., 2020, pp. 453–461. [22] R. C. Merkle, “A digital signature based on a conventional encryption function,” in Advances in Cryptology — CRYPTO ’87, C. Pomerance, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 1988, pp. 369– 378. [23] C. Coronado, “On the security and the efficiency of the Merkle signature scheme,” IACR Cryptol. ePrint Arch., vol. 2005, p. 192, 2005. [24] M. Campagna and A. Petcher, “Security of hybrid key encapsulation,” Cryptology ePrint Archive, Paper 2020/1364, 2020. [25] R. Barnes, K. Bhargavan, B. Lipp, and C. Wood, “Hybrid public key encryption,” RFC Editor, RFC 9180, 5 2022. [26] J. Alwen, B. Blanchet, E. Hauck, E. Kiltz, B. Lipp, and D. Riepel, “Analysing the hpke standard,” Cryptology ePrint Archive, Paper 2020/1499, 2020. [27] S. Lab, “libsnark: a C++ library for zk-SNARK proofs,” https://github. com/scipr-lab/libsnark, 2020. [28] J. Eberhardt and S. Tai, “Zokrates - scalable privacy-preserving offchain computations,” in 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2018, pp. 1084–1091. [29] K. Baghery, M. Kohlweiss, J. Siim, and M. Volkhov, “Another look at extraction and randomization of groth’s zk-snark,” Cryptology ePrint Archive, Paper 2020/811, 2020. [30] V. Coskun, B. Ozdenizci Kose, and K. Ok, “A survey on near field communication (NFC) technology,” Wireless Personal Communications, vol. 71, 08 2013. [31] E. Haselsteiner and K. Breitfuss, “Security in near field communication (NFC),” Workshop on RFID Security, 01 2006. [32] G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger, “NFC devices: Security and privacy,” in 2008 Third International Conference on Availability, Reliability and Security, 2008, pp. 642–647. [33] M. M. Mahinderjit Singh, K. Adzman, and R. Hassan, “Near field communication (NFC) technology security vulnerabilities and countermeasures,” International Journal of Engineering and Technology, vol. 7, pp. 298–305, 12 2018. Privacidad en la distribuci´on cl´asica de claves cu´anticas mediante zk-SNARKs 381