{"id":921,"date":"2026-09-08T18:47:46","date_gmt":"2026-09-08T16:47:46","guid":{"rendered":"https:\/\/www.blackhats.es\/wordpress\/?p=921"},"modified":"2026-09-08T20:11:01","modified_gmt":"2026-09-08T18:11:01","slug":"resucitar-un-hsm-de-un-fabricante-desaparecido-manejar-un-spyrus-lynks-series-ii-desde-linux-byte-a-byte","status":"publish","type":"post","link":"https:\/\/www.blackhats.es\/wordpress\/?p=921","title":{"rendered":"Resucitar un HSM de un fabricante desaparecido: manejar un SPYRUS LYNKS Series II desde Linux, byte a byte"},"content":{"rendered":"\r\n
\r\n

Un m\u00f3dulo de seguridad hardware FIPS 140-2 de 2005. Sin driver. Sin middleware. Sin PIN. Un fabricante que ya no existe. Esta es la historia completa de c\u00f3mo consegu\u00ed que generase una clave y firmase un mensaje dentro del chip desde una m\u00e1quina Linux x86-64 moderna, contada al nivel al que realmente trabaj\u00e9: descriptores USB, cabeceras ELF, desensamblado, bloques de comando big-endian, bytes DER y aritm\u00e9tica modular. Al final hay un peque\u00f1o proyecto de c\u00f3digo abierto, hs4l<\/strong>, para que nadie tenga que repetir el viaje.<\/p>\r\n

Dispositivo: <\/b>SPYRUS LYNKS Series II, USB 08df:0a00<\/code>, referencia 3003-F0 (2005), sistema operativo SPYCOS
Validaci\u00f3n: <\/b>FIPS 140-2 nivel 2, certificado NIST CMVP #679
Host: <\/b>Fedora x86-64, kernel 7.1, OpenSSL 3.5, qemu-user ARM de 32 bits
<\/b><\/code><\/div>\r\n

Contenido<\/h3>\r\n
    \r\n
  1. El objeto sobre la mesa<\/a><\/li>\r\n
  2. Todas las puertas cerradas<\/a><\/li>\r\n
  3. El movimiento lateral: \u00bfqui\u00e9n m\u00e1s habla con este chip?<\/a><\/li>\r\n
  4. Leer el firmware<\/a><\/li>\r\n
  5. C\u00f3digo ARM, anfitri\u00f3n x86-64, USB real<\/a><\/li>\r\n
  6. Primer contacto, en el cable<\/a><\/li>\r\n
  7. Apropiarse de la tarjeta: reinicializaci\u00f3n<\/a><\/li>\r\n
  8. El muro: 0x0a<\/code> Execution Failure<\/a><\/li>\r\n
  9. La causa ra\u00edz real, demostrada de tres maneras<\/a><\/li>\r\n
  10. La criptograf\u00eda, byte a byte<\/a><\/li>\r\n
  11. Extra: una compilaci\u00f3n nativa x86-64, con su propio bug<\/a><\/li>\r\n
  12. C\u00f3mo lo prob\u00e9<\/a><\/li>\r\n
  13. Por qu\u00e9 constru\u00ed hs4l y qu\u00e9 contiene<\/a><\/li>\r\n
  14. Descargas y firmas<\/a><\/li>\r\n<\/ol>\r\n\r\n

    1. El objeto sobre la mesa<\/h2>\r\n

    \u00abRA\u00bb, referencia 3003-F0. Dentro hay un m\u00f3dulo criptogr\u00e1fico del linaje Fortezza que ejecuta SPYCOS<\/strong>, el SPYRUS Cryptographic Operating System, validado a FIPS 140-2 nivel 2. Dos roles lo custodian: un Site Security Officer (el oficial criptogr\u00e1fico) y un User. Cada uno tiene una frase PIN de al menos doce caracteres de un alfabeto de 93 s\u00edmbolos. Diez inicios de sesi\u00f3n SSO fallidos consecutivos lo ponen a cero.<\/p>\r\n

    No quer\u00eda lo que hubiera dentro. Quer\u00eda hacerlo m\u00edo<\/em>: borrarlo, fijar mis propios PIN, meterle una clave y hacer que firmase. Es una funci\u00f3n documentada del m\u00f3dulo. Result\u00f3 ser la parte f\u00e1cil. La parte dif\u00edcil era que en 2026 no hay software en la Tierra que hable con \u00e9l, o eso parec\u00eda.<\/p>\r\n

    \"\"<\/a><\/pre>\r\n
    Hay que leer ese descriptor como lo lee el kernel. USB 1.1, full speed, una interfaz, clase 0<\/strong>. No es CCID (clase 0x0b), no es HID, no es almacenamiento masivo. Dos endpoints bulk, uno en cada direcci\u00f3n, paquetes de 64 bytes. Sin cadena de n\u00famero de serie. Es una tuber\u00eda cruda del fabricante: el dispositivo har\u00e1 exactamente lo que le diga un programa que conozca su protocolo privado, y nada m\u00e1s.<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Ning\u00fan driver del kernel reclama la interfaz 0. Nada en la tabla de alias de m\u00f3dulos conoce la cadena \u00abspyrus\u00bb. Conviene recordar esa ausencia de driver: parece una mala noticia y en realidad es el \u00fanico hecho que hizo posible todo lo dem\u00e1s.<\/p>\r\n\r\n
    2. Todas las puertas cerradas<\/h2>\r\n
    \"\"<\/a><\/p>\r\n
    Puerta 1: el fabricante<\/h3>\r\n
    SPYRUS Inc. fue absorbida por otra empresa el 15 de septiembre de 2021. El portal de desarrolladores ha desaparecido a nivel de DNS:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Lo que responde hoy en el dominio antiguo es una p\u00e1gina aparcada detr\u00e1s de un CDN de hosting compartido. La empresa sucesora tiene un formulario de contacto. Lo rellen\u00e9. Nada.<\/p>\r\n
    Puerta 2: el middleware de Windows<\/h3>\r\n
    El token se gestionaba con una aplicaci\u00f3n de Windows llamada En-Sign, con un SDK SPEX+ que proporcionaba un CSP y un m\u00f3dulo PKCS#11. Todo se distribu\u00eda detr\u00e1s de un muro de registro. La Wayback Machine nunca rastre\u00f3 m\u00e1s all\u00e1 de ese muro. archive.org\/details\/Spyrus<\/code> contiene un GIF con el logotipo. El \u00fanico artefacto que sobrevivi\u00f3 en la web p\u00fablica es SCARDLYNKSUSBW.sys<\/code> con su .inf<\/code> y su .cat<\/code>, firmado WHQL en 2005, todav\u00eda en el Microsoft Update Catalog y en sitios agregadores de drivers como un zip de 20 KB. Lo desmont\u00e9. Es un shim de lector<\/em>: hace que Windows presente el token como un lector de tarjetas inteligentes para que otro<\/em> software pueda manejarlo. Por s\u00ed solo no hace nada. Una m\u00e1quina virtual con Windows 7 y paso USB de 08df:0a00<\/code> lleg\u00f3 exactamente hasta \u00ablector presente, ning\u00fan software instalado que entienda la tarjeta\u00bb.<\/p>\r\n
    Puerta 3: Linux<\/h3>\r\n
    El mundo PC\/SC no puede verlo, porque no es un lector CCID:<\/p>\r\n
    \"\"<\/a>\r\n<\/code><\/p>\r\n
    <\/code>Nunca ha existido un driver Linux para el Series II. Nunca ha existido un driver macOS. No hay ning\u00fan m\u00f3dulo PKCS#11 para \u00e9l fuera del SDK perdido.<\/p>\r\n
    Puerta 4: el PIN<\/h3>\r\n
    Doce caracteres como m\u00ednimo de 93 s\u00edmbolos: 9312<\/sup> \u2248 4,2 \u00d7 1023<\/sup>. Diez intentos SSO fallidos ponen la tarjeta a cero. Incluso con un protocolo en la mano, la fuerza bruta no es un plan; es una forma de convertir el token en un pisapapeles de diez en diez intentos. La frase \u00abZeroize Default PIN\u00bb de f\u00e1brica que permite recuperar una tarjeta puesta a cero est\u00e1 en una gu\u00eda de administrador propietaria que no pude encontrar.<\/p>\r\n
    Puerta 5: sondeo a ciegas<\/h3>\r\n
    Con libusb se puede reclamar una interfaz sin driver y escribir bytes arbitrarios en EP1. Lo intent\u00e9. La palabra de estado con la que se responde a cada comando empieza por un byte que parec\u00eda 0x80<\/code>, y m\u00e1s all\u00e1 de eso no ten\u00eda ni formato de trama, ni lista de opcodes, ni regla de checkword. Cada intento devolv\u00eda una respuesta corta que no sab\u00eda interpretar. Hacer fuzzing a ciegas a un m\u00f3dulo FIPS con contador de intentos fallidos no es una afici\u00f3n que recomiende.<\/p>\r\n
    Puerta 6: la gente<\/h3>\r\n
    Pregunt\u00e9 en dos foros. La respuesta m\u00e1s \u00fatil fue comprensiva y correcta: \u00abel software es vapor\u00bb.<\/p>\r\n
    Semanas despu\u00e9s, el balance:<\/strong> un dispositivo que Linux puede enumerar pero con el que no puede hablar, un fabricante que no existe, un middleware que nunca se archiv\u00f3, un espacio de PIN mayor que el n\u00famero de estrellas del universo observable, y un contador de intentos fallidos. Todas las puertas que se me hab\u00edan ocurrido estaban cerradas.<\/div>\r\n\r\n
    3. El movimiento lateral: \u00bfqui\u00e9n m\u00e1s habla con este chip?<\/h2>\r\n
    La pregunta que hab\u00eda estado haciendo era \u00ab\u00bfd\u00f3nde est\u00e1 el software del fabricante?\u00bb. La pregunta correcta era otra: \u00bfqui\u00e9n m\u00e1s, en cualquier sitio, en cualquier sistema operativo, distribuye c\u00f3digo que hable SPYCOS?<\/strong><\/p>\r\n
    Un token DSA validado FIPS de mediados de los 2000 existe por una raz\u00f3n: firmar flujos de datos cuya autenticidad tiene peso legal. El \u00fanico \u00e1mbito que se me ocurr\u00eda donde eso es obligatorio y p\u00fablico es la vigilancia del tratado de prohibici\u00f3n de ensayos nucleares. Las estaciones s\u00edsmicas que alimentan el Sistema Internacional de Vigilancia firman sus datos en el formato CD1.1, con claves hardware, y los digitalizadores que lo hacen los construyen un pu\u00f1ado de fabricantes de sism\u00f3grafos. Uno de ellos documenta, en un manual de usuario del firmware de su digitalizador Platinum, una herramienta de l\u00ednea de comandos llamada spyrus_util<\/code> que inicializa una tarjeta \u00abSpyrus Lynks\u00bb y firma con ella. Sus digitalizadores ejecutan Linux embebido sobre ARM<\/strong>.<\/p>\r\n
    Si esa herramienta exist\u00eda como binario, el protocolo vendr\u00eda con ella. Y exist\u00eda, en un espejo rsync p\u00fablico y an\u00f3nimo que sirve sistemas de ficheros ra\u00edz completos del firmware del digitalizador:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    \u00abctbto-prerelease\u00bb es la Organizaci\u00f3n del Tratado de Prohibici\u00f3n Completa de los Ensayos Nucleares. La corazonada era correcta. Se descarga el sistema de ficheros ra\u00edz ARM, o solo las piezas que necesita la herramienta:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Obs\u00e9rvense las dos bibliotecas que viven en lib\/<\/code> en lugar de en usr\/lib\/<\/code>. Que faltasen me cost\u00f3 una hora m\u00e1s adelante; el cargador din\u00e1mico solo las reporta como ausentes despu\u00e9s de haber encontrado todo lo dem\u00e1s.<\/p>\r\n\r\n
    4. Leer el firmware<\/h2>\r\n
    Antes de ejecutar nada: \u00bfqu\u00e9 es este binario, para qu\u00e9 CPU, y c\u00f3mo llega al hardware?<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    ARM de 32 bits little-endian, EABI versi\u00f3n 5, compilado para el juego de instrucciones ARMv4T, de modo que corre en un n\u00facleo de la clase ARM9TDMI. La ruta del m\u00f3dulo del kernel en el listado, 2.6.36-cm-x270<\/code>, dice que el digitalizador es un m\u00f3dulo CompuLab CM-X270, un Intel PXA270 XScale. El binario se construy\u00f3 con GCC 4.4.4 contra glibc 2.12.2 y no est\u00e1 stripped<\/strong>, con informaci\u00f3n de depuraci\u00f3n DWARF. Ese \u00faltimo detalle vale cien horas de conjeturas:<\/p>\r\n
    \"\"<\/a>\r\n<\/code><\/p>\r\n
    Ahora las dependencias, que dicen c\u00f3mo<\/em> llega un programa al hardware:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Esta es la observaci\u00f3n decisiva de todo el proyecto. libspyrus<\/code> habla con el token a trav\u00e9s de libusb-1.0<\/strong>: enumerar dispositivos, abrir, reclamar la interfaz 0, transferencias bulk. Ni m\u00f3dulo del kernel, ni \/dev\/spyrus0<\/code> (eso solo existe para la variante PCMCIA a trav\u00e9s de spyrus_cs.ko<\/code>). La cadena es spyrus_util \u2192 libspyrus.so.3 \u2192 libusb-1.0 \u2192 ioctls USBDEVFS \u2192 EP1\/EP2<\/code>, enteramente en espacio de usuario. Y una interfaz sin driver en mi anfitri\u00f3n es exactamente lo que libusb quiere: nada que desvincular, nada contra lo que pelear. El kernel del sism\u00f3grafo y mi kernel presentan la misma interfaz usbfs<\/code>. El token no puede distinguir entre un PXA270 en una c\u00e1mara acorazada y un port\u00e1til en Helsinki.<\/p>\r\n
    Las cadenas de la biblioteca me dieron el vocabulario de errores que necesitar\u00eda m\u00e1s tarde:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Y los propios ficheros de integraci\u00f3n del firmware explican c\u00f3mo usa la herramienta el digitalizador, que es la documentaci\u00f3n m\u00e1s barata posible:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Conviene tener presente esa l\u00ednea openssl dsaparam -out ... 1024<\/code>. Es la semilla del \u00fanico bug real de esta historia, y el OpenSSL del firmware es 1.0.2j:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Por \u00faltimo, el mismo paquete distribuye cabeceras GPL-2 en el m\u00f3dulo de bibliotecas cruzadas del espejo. Son lo m\u00e1s parecido a una especificaci\u00f3n del protocolo que existe en p\u00fablico. Los opcodes son doce bits m\u00e1s un indicador de conjunto de comandos de ocho bits:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Obs\u00e9rvese c\u00f3mo funciona una comprobaci\u00f3n de PIN: el anfitri\u00f3n env\u00eda la frase y un desaf\u00edo de 20 bytes, y la tarjeta responde con un par (r, s)<\/code>. El inicio de sesi\u00f3n es una firma DSA sobre un desaf\u00edo. Por eso nada relativo al PIN puede cortocircuitarse desde fuera.<\/p>\r\n\r\n
    5. C\u00f3digo ARM, anfitri\u00f3n x86-64, USB real<\/h2>\r\n
    El binario es ARMv4T. Mi m\u00e1quina es x86-64. qemu-arm-static<\/code> es un emulador en modo usuario: traduce las instrucciones del invitado y pasa las llamadas al sistema<\/em> del invitado al kernel anfitri\u00f3n. Un ioctl(USBDEVFS_BULK)<\/code> emitido por la libusb ARM aterriza en mi nodo de dispositivo real. Sin m\u00e1quina virtual, sin controlador USB virtual, sin demonio. Tres detalles de entorno hacen que funcione:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    La herramienta necesita escribir en tres sitios del anfitri\u00f3n: el nodo de dispositivo USB, un fichero de bloqueo y un directorio de configuraci\u00f3n. La biblioteca toma un bloqueo de uso exclusivo (la cabecera lo llama \u00abthe interprocess right to use the card\u00bb) y lee su configuraci\u00f3n, as\u00ed que antes de nada:<\/p>\r\n
    \"\"<\/a><\/code><\/p>\r\n
    Una versi\u00f3n permanente de esto (un grupo spyrus<\/code>, una regla udev con TAG+=\"uaccess\"<\/code>, una entrada tmpfiles.d<\/code> porque \/var\/lock<\/code> es un tmpfs) es lo que hace el script de configuraci\u00f3n del proyecto; aqu\u00ed muestro las acciones en crudo.<\/p>\r\n\r\n
    6. Primer contacto, en el cable<\/h2>\r\n
    Primero solo lectura. --state<\/code> pide la palabra de estado y nada m\u00e1s. Dos banderas -D<\/code> hacen que la biblioteca vuelque en hexadecimal cada transacci\u00f3n:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    La tarjeta respondi\u00f3. Una palabra de estado de 9 bytes con el bit alto del byte 0 activado, y dos registros que la biblioteca llama SR y PRR. SR = 25 significaba \u00abinicializada, en uso, nada cargado\u00bb. --status<\/code> es el primer bloque de comando real, y aqu\u00ed est\u00e1 todo el formato de trama del protocolo en un solo viaje de ida y vuelta:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Todo es una secuencia de palabras big-endian de 32 bits<\/strong>, sobre un ARM little-endian, sobre un anfitri\u00f3n x86 little-endian; la biblioteca intercambia los bytes a la salida. La cabecera son seis palabras:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
    palabra<\/th>\r\nGet_Status enviado<\/th>\r\nsignificado (le\u00eddo directamente del cable)<\/th>\r\n<\/tr>\r\n
    W0<\/td>\r\n00 00 00 26<\/code><\/td>\r\nopcode; la respuesta pone el byte alto a 0x90<\/code> y devuelve el resto tal cual<\/td>\r\n<\/tr>\r\n
    W1<\/td>\r\n00 00 00 00<\/code><\/td>\r\nreservado<\/td>\r\n<\/tr>\r\n
    W2<\/td>\r\n00 00 00 00<\/code><\/td>\r\ndesplazamiento de la carga \u00fatil de entrada (0 cuando no hay; 0x18<\/code> en caso contrario)<\/td>\r\n<\/tr>\r\n
    W3<\/td>\r\n00 00 00 18<\/code><\/td>\r\nlongitud total del bloque (24 = solo cabecera)<\/td>\r\n<\/tr>\r\n
    W4<\/td>\r\n00 00 00 00<\/code><\/td>\r\nc\u00f3digo de resultado<\/strong>, rellenado por la tarjeta<\/td>\r\n<\/tr>\r\n
    W5<\/td>\r\n00 00 00 00<\/code><\/td>\r\nreservado<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n
    Tras la cabecera, la respuesta lleva struct spyrus_status<\/code>: longitud 0x34<\/code>, despu\u00e9s el n\u00famero de serie de 8 bytes 01 00 00 00 f0 00 18 4f<\/code> (la etiqueta del pl\u00e1stico termina en 00184F), estado 7, modos, personalidad 1, 20 ranuras de clave con sus banderas, 50 ranuras de certificado. El comando de lista de personalidades muestra las etiquetas de las ranuras como 20 cadenas fijas de 32 bytes:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    (Ese listado es de hoy, despu\u00e9s de cargar una clave; en el primer contacto todas las ranuras dec\u00edan Empty.) Una ranura de certificado vac\u00eda responde a un Get_Certificate con texto literal:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Una ranura de certificado ocupa 0x800<\/code> bytes y contiene texto PEM, con finales de l\u00ednea CRLF, rellenado con ceros. Esto importar\u00e1 en la secci\u00f3n 11.<\/p>\r\n\r\n
    7. Apropiarse de la tarjeta: reinicializaci\u00f3n<\/h2>\r\n
    Nunca supe el PIN SSO anterior y nunca lo necesit\u00e9. La inicializaci\u00f3n es una funci\u00f3n documentada de SPYCOS que destruye todas las claves y certificados y fija PIN nuevos. El propio script del fabricante hace exactamente esto en un digitalizador nuevo. Dos banderas importan: --loose<\/code> selecciona el modo que no exige un certificado en cada ranura, y la confirmaci\u00f3n se lee del terminal de control, no de stdin, as\u00ed que canalizar yes<\/code> por una tuber\u00eda solo funciona cuando no hay tty en absoluto.<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    SR pas\u00f3 de 25 a 26. La tarjeta era m\u00eda, con PIN que eleg\u00ed yo (se cambian despu\u00e9s con --change --old-pin --pin<\/code>; la biblioteca impone un m\u00ednimo de 4 caracteres, la regla propia de la tarjeta es 12). Nada de esto elude el modelo de seguridad del m\u00f3dulo: es el camino que sigue un administrador leg\u00edtimo el primer d\u00eda, destruye lo que hubiera, y no toca el motor de PIN.<\/p>\r\n\r\n
    8. El muro: 0x0a<\/code> Execution Failure<\/h2>\r\n
    Entonces intent\u00e9 generar una clave como lo har\u00eda en cualquier m\u00e1quina moderna: crear par\u00e1metros DSA con OpenSSL y entreg\u00e1rselos a la tarjeta.<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Decodifiquemos la petici\u00f3n. W0 = 0x85<\/code> Generate_X. W3 = 0x144<\/code> = 324 bytes en total. Despu\u00e9s la carga \u00fatil de struct spyrus_generate_x_in<\/code>: longitud 0x12c<\/code> = 300, \u00edndice 1, tipo 0x0a<\/code> = DSA, y tres bloques cada uno introducido por una palabra de longitud en bits: P 0x400<\/code> = 1024 bits, Q 0xa0<\/code> = 160 bits, G 0x400<\/code>. La tarjeta devolvi\u00f3 el bloque entero y puso W4 = 0x0000000a<\/code><\/strong>. El viaje de ida y vuelta se complet\u00f3. La trama se acept\u00f3. La tarjeta entendi\u00f3 la petici\u00f3n, lo intent\u00f3 y fall\u00f3.<\/p>\r\n
    Diez es un n\u00famero concreto. Leamos la tabla de errores del binario; la funci\u00f3n es un switch sobre el c\u00f3digo, y el compilador emiti\u00f3 una tabla de saltos, que se ve en ambas arquitecturas:<\/p>\r\n
    \"\"<\/a><\/pre>\r\n
    Recorrer la tabla da la correspondencia, y 0x0a<\/code> cae en una cadena muy concreta:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
    c\u00f3digo<\/th>\r\ncadena<\/th>\r\nc\u00f3digo<\/th>\r\ncadena<\/th>\r\n<\/tr>\r\n
    0x00<\/td>\r\nPassed<\/td>\r\n0x07<\/td>\r\nInvalid Data Size<\/td>\r\n<\/tr>\r\n
    0x01<\/td>\r\nSpyrus command failed<\/td>\r\n0x08<\/td>\r\nInvalid Header<\/td>\r\n<\/tr>\r\n
    0x02<\/td>\r\nCheckword Failure<\/td>\r\n0x09<\/td>\r\nInvalid State<\/td>\r\n<\/tr>\r\n
    0x03<\/td>\r\nInvalid Type Value<\/td>\r\n0x0a<\/strong><\/td>\r\nExecution Failure<\/strong><\/td>\r\n<\/tr>\r\n
    0x04<\/td>\r\nInvalid Mode Value<\/td>\r\n0x0b<\/td>\r\nNo Key Loaded<\/td>\r\n<\/tr>\r\n
    0x05<\/td>\r\nInvalid Key Index<\/td>\r\n0x15<\/td>\r\nNO PQG Loaded<\/td>\r\n<\/tr>\r\n
    0x06<\/td>\r\nInvalid Cert Index<\/td>\r\n\u00a0<\/td>\r\n\u00a0<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n
    No es Invalid Header, as\u00ed que la trama era correcta. No es Invalid State, as\u00ed que la tarjeta estaba lista. No es NO PQG Loaded, as\u00ed que los par\u00e1metros estaban presentes. No es Invalid Data Size. La tarjeta ejecut\u00f3 la operaci\u00f3n y abort\u00f3 dentro de ella. Eso reduce la b\u00fasqueda al contenido<\/em> de los par\u00e1metros.<\/p>\r\n
    Dos pistas falsas, eliminadas en el cable y no por intuici\u00f3n:<\/p>\r\n