Prototipado de un dispositivo de auditoría autónomo para tarjetas RFID

i Equation Chapter 1 Section 1 Prototipado de un dispositivo de auditoría autónomo para tarjetas RFID Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Dpto. Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Álvaro Galdón Rus Tutor: Hipólito Guzmán Miranda Sevilla, 2020 ii iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Prototipado de un dispositivo de auditoría autónomo para tarjetas RFID Autor: Álvaro Galdón Rus Tutor: Hipólito Guzmán Miranda Profesor titular Dpto. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 iv Trabajo Fin de Grado: Prototipado de un dispositivo de auditoría autónomo para tarjetas RFID v Autor: Álvaro Galdón Rus Tutor: Hipólito Guzmán Miranda El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal vi vii A mi familia, gracias a la cual he llegado hasta aquí. A mis amigos, por los buenos momentos juntos. viii ix Resumen Este trabajo busca profundizar en la seguridad de un sistema real mediado por tecnología RFID. Dicha tecnología es cada día más empleada en control de acceso, identificación y pagos sin contacto, adquiriendo una relevancia muy destacable en nuestra sociedad actual. De cara a estudiar una implementación real, vamos a tratar con el sistema MIFARE Classic® del fabricante NXP, cuyo uso es el más común a nivel andaluz. Para ello haremos un repaso por el hardware disponible en el mercado y finalmente construiremos un dispositivo parcialmente autónomo, que nos permita leer y escribir utilizando las herramientas de código abierto disponibles en Internet, comentando sus limitaciones. Gracias a la biblioteca libnfc, capaz de comunicarse a bajo nivel con el chip NXP PN532 del lector que habíamos elegido, hemos implementado un ataque práctico que nos permite acceder al contenido cifrado de varias tarjetas. También podemos editarlas, tras interpretar adecuadamente la estructura de datos que contienen dentro. Los resultados que hemos observado confirman que estas tarjetas son vulnerables a ataques “Darkside”, “Nested” y “Hard-nested” (incluso en tarjetas más modernas). Además, la política de seguridad en cuanto a bases de datos de apoyo suele ser escasa en algunos entornos desplegados, y que el ataque se puede realizar con un presupuesto ajustado. Al final comentaremos también algunas contramedidas aplicables, y de hecho ya desplegadas, en otras redes de transporte. xvi 1 1 INTRODUCCIÓN a tecnología de pago sin contacto (o contactless) está cada día más presente en nuestras vidas. De cara al usuario, la comodidad y rapidez de uso es indiscutible respecto a otros medios de pago anteriores. Pero su despliegue es todavía más interesante de cara a los proveedores de servicios, ya que las nuevas tarjetas permiten más flexibilidad a la hora de almacenar información. Un ejemplo de ello es, de cara a la optimización de redes de transporte urbano, la mayor agilidad de pago al descongestionar los puntos de acceso al vehículo, reduciendo la necesidad de atención de conductores durante el acceso de los usuarios a un autobús. Los proveedores también podrían estimar con gran fiabilidad los recorridos de los usuarios dentro de una red de metro, así como crear planes de transbordo o tarifarios de gran complejidad sin precedentes. Asimismo, la emisión de tarjetas reutilizables beneficia al medio ambiente al no generarse residuos por abono o por viaje, especialmente en las redes de transporte de gran tamaño. Otra ventaja adicional es que, al ser las tarjetas de mayor valor que un billete impreso, dichas tarjetas pueden ser cobradas al usuario a modo de fianza, reduciendo el coste destinado impresión de títulos de transporte. Por todos esos motivos, no es de extrañar que esta tecnología haya tenido una acogida casi unánime en muchos sectores. Las tarjetas MIFARE Classic® fueron desarrolladas por la compañía Philips Semiconductors (ahora conocida como NXP Semiconductors) en el año 1994. Londres fue las primeras ciudades en sumarse a esta nueva iniciativa, creando la Oyster card allá por el año 2003, posteriormente permitiendo también el uso de tarjetas bancarias sin contacto, y haciendo obligatorio su uso para toda su red de transporte. De manera similar, en Hong Kong se creó la Octopus card. Dichas tarjetas llegaron al Metro de Sevilla en 2007 y se implantaron en todos los consorcios de transporte andaluces sucesivamente, ampliándose su uso también como medio de pago para Cercanías Renfe. También pueden ser utilizadas en los servicios de transporte urbano de TUSSAM y otras entidades locales. Pero esta escalada meteórica y todas estas ventajas aquí descritas ocultaban un contra, y es que en 2008 fue publicado un artículo académico (del que hablaremos más adelante) que descubría el algoritmo de cifrado empleado en dichas tarjetas MIFARE, un secreto guardado celosamente por el fabricante hasta entonces, en un intento de “seguridad por oscuridad”. Una vez descrito, quedaron patentes sus vulnerabilidades. Se han realizado varios intentos de mejorar el cifrado de las tarjetas Classic, con el objetivo de mantener la retrocompatibilidad con sistemas ya instalados. Posteriores trabajos han demostrado la inseguridad intrínseca del algoritmo de cifrado CRYPTO1, haciendo el reemplazo de los sistemas inevitable. En este trabajo voy a comentar la evolución del estado del arte y la construcción de un dispositivo para ayudar a la auditoría de estas tarjetas. L 2 3 2 OBJETIVO Y METODOLOGÍA DEL PROYECTO on el propósito de averiguar qué estrategia de seguridad siguen las tarjetas sin contacto empleadas en un campo donde hayan tenido una acogida positiva, vamos a proceder a definir qué buscamos con este trabajo y la metodología que vamos a seguir para alcanzar nuestro objetivo. 2.1 Propósito del trabajo Nuestro principal objetivo es construir un dispositivo autónomo que nos reduzca la dependencia de un ordenador, cuyo fin último nos permita analizar la seguridad de un caso de uso real (en “producción”) mediado por tarjetas sin contacto, donde la confianza en los datos contenidos en el soporte en poder del usuario sea crucial. Dado que los sistemas bancarios suelen tener un gran enfoque hacia la seguridad, consideramos más prometedor estudiar la implementación de estos nuevos soportes en un entorno de uso reciente y aparentemente más laxo. Es por ello por lo que hemos elegido un campo como el transporte de pasajeros, donde multitud de administraciones tratan, regionalmente, de gestionar el modelo de servicio público como más oportunamente consideran. Como este trabajo se realiza en Sevilla, pusimos nuestras miradas en los Consorcios de Transporte Metropolitano (CMT) de Andalucía, dado que algunos medios [1] han puesto en duda ocasionalmente la seguridad de los sistemas desplegados en nuestra comunidad. Hace algunos años le fue sustraída a una persona de nuestro entorno una de esas tarjetas, situación que aprovechamos para contactar con el CTM del Área de Sevilla. Mediante llamada telefónica, se nos confirmó que era imposible bloquear una tarjeta no nominativa, pese a tener referencias del número impreso en su anverso. ¿Indicios de que no hay una base de datos detrás? 2.2 Metodología En primer lugar, vamos a partir del estudio del “estado del arte”, donde enumeraremos y comentaremos los principales avances que se hicieron en el ataque sobre las tarjetas MIFARE Classic®, así como sus limitaciones. El punto de partida más sencillo por el que empezar nuestra auditoría de seguridad, sería hacer un ataque offline con el medio que tengamos a nuestro alcance, la tarjeta de transporte. Para analizarla necesitamos un dispositivo con un lector. Existe hardware tanto comercial como desarrollado por aficionados para realizar la tarea, abarcando desde radio definida por software hasta hardware open source. Debido a la orientación generalista de estas soluciones dado el amplio rango de aplicación que presentan, y especialmente su alto precio, consideraremos construir un dispositivo más especializado, así como adecuar las herramientas disponibles a nuestras necesidades específicas. Hemos observado que la suite de software con posibilidades más prometedoras es nfc-tools, de código fuente abierto y disponible de manera gratuita en Internet. Sobre ella se basan algunas herramientas de explotación de vulnerabilidades, como explicaremos más adelante. Una vez diseñado nuestro dispositivo, continuaremos con la instalación y configuración del software para hacerlo funcionar. En este momento deberíamos poder obtener un primer volcado de la información contenida en la memoria interna. Además, mientras hacemos ingeniería inversa de la memoria de la tarjeta, haremos las optimizaciones necesarias y desarrollaremos nuestras propias utilidades con el objetivo de mejorar las prestaciones del ataque. C 4 2.2.1 Tipo de pruebas a realizar La prueba inicial es, partiendo de algún método existente en el estado del arte, volcar el contenido interno de la tarjeta sin que los posibles sistemas de seguridad que están implementados consigan impedirlo. En segundo lugar, comprobar que podemos dar sentido a dicha información. Posteriormente podríamos intentar alterar los contenidos de la tarjeta y observar qué ocurre. Para las pruebas conseguimos una clave real de lectura, gracias a las capacidades de un dispositivo Proxmark 3 clónico, prestado puntualmente. Hablaremos de él en una sección posterior. La clave de lectura es usada en todos los lectores y tarjetas auténticos, de tal manera que cualquier dispositivo pueda acceder a su información de manera universal, y sin acceso a una base de datos centralizada, sin importar su situación geográfica o capacidades de comunicación. Dicha clave tiene también permisos de decremento, lo que permite reducir el saldo sin poner en riesgo las claves de escritura, que son únicas para cada tarjeta. A modo de inciso, y llegados a este punto, un lector astuto podría pensar que el requerimiento de una clave de partida es un obstáculo importante para la realización de la auditoría. Nada más lejos de la realidad, puesto que existen tanto ataques offline (criptoanalizando la tarjeta) como online (interceptando la comunicación entre un lector público sin vigilancia y una tarjeta normal) fácilmente realizables, aunque requieren un equipamiento más complejo. Realizar un estudio previo para extraer la información secreta relevante nos permite reducir el coste de nuestra implementación de manera importante, insertando dicha información ofuscada en cualquier dispositivo a modo de blob programático (básicamente un código que la genere sin que sea evidente su funcionamiento). Durante el proceso de investigación vamos a experimentar con las posibilidades que nos ofrecen las diversas herramientas a nuestra disposición y comprobaremos también otros ejemplos de tarjetas que pudiéramos considerar representativos, pasando a comentar sus diferencias. 2.2.2 Presentación de resultados Algunas consideraciones a la hora de presentar los resultados que vayamos obteniendo durante la realización de las pruebas: • Se irá mostrando la salida de las operaciones realizadas. • Se ilustrará visualmente en la medida de lo posible. • En caso de acceso satisfactorio a la información protegida: o Se enumerarán las áreas de interés identificadas en la memoria interna. o Se ocultará la información particularmente sensible, especialmente offsets y claves. o Se ocultará la información única de la tarjeta, o que pueda permitir su identificación. • Con respecto a las tarjetas adicionales, se seleccionará y comentará la información de interés. • A modo de conclusión, se valorarán las causas de los resultados obtenidos y, si procediera, cómo se podría haber mejorado en base a las acciones de los diferentes actores implicados en la seguridad. Con esta preparación previa, ahora estaríamos en condiciones de realizar las pruebas, obtener los resultados y elaborar las conclusiones. 5 3 ESTUDIO DEL ESTADO DEL ARTE ntes de proceder con la auditoría, vamos a analizar las vulnerabilidades previamente descubiertas con un breve resumen del proceso seguido por los autores para descubrirlas. Recomiendo encarecidamente leer la bibliografía citada a tal efecto, por motivos didácticos e históricos, que puede ser de gran interés para un lector iniciándose en procedimientos de auditoría de seguridad. 3.1 Introducción a la seguridad en RFID ¿Tiene sentido hablar de seguridad en RFID? Dado que el objetivo del estándar RFID es servir como un medio de identificación sin contacto, uno de los pilares fundamentales para su éxito es la capacidad de comprobar que, efectivamente, podemos confiar en la información valiosa o única que entregamos al portador de la tarjeta. Dicha información, que con alta probabilidad estaríamos utilizando posteriormente, nos interesa que no sea falsificable ni replicable. Podemos partir de la adecuación de la cadena de custodia física, que se podría asegurar más o menos con medios biométricos (por ejemplo, una huella dactilar asociada, contra un atacante con medios convencionales) o una clave secreta. Podríamos pensar en RFID como un medio similar a WiFi en cuanto a intercambio de información sensible, pero de alcance considerablemente más limitado, donde pretendemos proteger los datos intercambiados del acceso no autorizado por terceros. No deberíamos dejar de considerar algunos ataques clásicos o transversales: • Denegación de servicio: Mediante interferencias electromagnéticas o colisiones de tramas. • Escucha y repetición: Copiando el protocolo entre lector y usuario, para posteriormente imitarlo. • Intermediario: Se intercepta la comunicación y se altera la información al vuelo. • Clonado: Sin intervenir la comunicación, somos capaces de hacer una réplica exacta de la etiqueta. • Análisis de potencia: El consumo del sistema cambia al verificar la información fraudulenta. • Ingeniería inversa: Desvelando la información confidencial estudiando su comportamiento aparente. • Ingeniería social: La obtención indirecta de detalles sobre el funcionamiento a través de personas. Numerosos investigadores han utilizado estos métodos genéricos para degradar progresivamente la (aparente) seguridad de las etiquetas RFID. La implementación de protocolos propietario, que no han sido validados por la comunidad de criptoanalistas o matemáticos, suele ser también el origen de la gran mayoría de agujeros de seguridad. Esto se debe a la asimetría entre los recursos humanos disponibles (en cuanto a conocimientos, experiencia y tiempo) disponibles para anticiparse a hipotéticas debilidades. Un sistema capaz de resistir el escrutinio público tampoco es inquebrantable, pero al menos se puede alcanzar un consenso de ser matemáticamente seguro y revisión de implementación suficientemente cuidadosa. Alcanzar este grado de robustez razonable evitaría ataques medianamente bien preparados, limitando su utilidad en cuanto a información potencialmente comprometida o haciéndolo impráctico salvo para esfuerzos con presupuestos multimillonarios por parte de gobiernos u organizaciones similares. En la siguiente sección vamos a exponer paso a paso las diferentes técnicas utilizadas por orden cronológico para comprometer la seguridad del primer modelo de uso masivo como es MIFARE Classic®. A 6 3.2 Artículos y conferencias relacionados con vulnerabilidades de MIFARE Classic® 3.2.1 Mifare: Little Security, Despite Obscurity Así fue llamada la conferencia pionera [2] que Nohl y Plötz presentaron en 2007. En ella se exponían las características básicas de seguridad algoritmo CRYPTO1 empleado por estas tarjetas, a partir de un análisis de una foto microscópica del chip. A destacar, la baja complejidad del algoritmo utilizado (¡sólo 48 bits!) y el generador de números aleatorios (¡16 bits!) e implementación de un ataque básico por fuerza bruta en alrededor de una semana. Este artículo es un claro ejemplo de cómo la seguridad por oscuridad es una mala decisión para proteger la seguridad de un dispositivo. Puede suponer una dificultad añadida de cara a una investigación inicial, pero lamentablemente, se suele usar como una cortina de humo ante una gestión inadecuada de la implementación de seguridad real en un sistema. Al final el hacker persistente siempre encuentra una forma de iluminar el camino que está buscando. 3.2.2 A Practical Attack on the MIFARE Classic En este estudio [3] que Koning Gans, Hoepman y Garcia elaboraron en 2008, se exponían las debilidades detalladas del algoritmo y del débil generador de números pseudo-aleatorios integrado en el IC. Según los autores, la plataforma “deja de ser segura en unos pocos minutos”. Esto permitía leer todos los sectores sin necesidad de conocer las claves, conociendo el contenido de un bloque. En este caso la descripción se asemeja a un ataque “known plaintext”. Dado que las operaciones matemáticas que utiliza CRYPTO1 son bastante sencillas, conociendo el texto plano y el resultado cifrado, se puede inferir el estado del módulo criptográfico y predecir el comportamiento de este en el futuro. 3.2.3 Dismantling MIFARE Classic Esta vez, Garcia et al. demuestran en [4] varios ataques online sobre el protocolo de autenticación sobre un lector auténtico. En este caso se obtienen las claves en cuestión de segundos, con el inconveniente de requerir acceso a un lector real que se comunique con la tarjeta. Aquí parece que el algoritmo utilizado tampoco es útil protegiendo frente a ataques “man-in-the-middle”. La captura del handshake deja desprotegida la comunicación. Este método puede parecer bastante complicado de realizar en la práctica, pero hay que tener en cuenta que el hardware requerido es, actualmente, lo suficientemente pequeño como para llevarlo dentro de una billetera modificada y pasar la tarjeta por un lector auténtico. 3.2.4 Wirelessly Pickpocketing a Mifare Classic Card Garcia et al. [5] demuestran el primer ataque offline, gracias a un estudio matemático del algoritmo CRYPTO1. Gracias a la poca complejidad del generador de números pseudo-aleatorios, es posible predecir el estado de los registros del módulo criptográfico tras una petición de autenticación exitosa, puesto que podemos “conectarnos” a un sector de la tarjeta y ejecutar algunos comandos de autenticación antes de proporcionar la clave necesaria para manipular la información que contienen. La desventaja de este ataque es que requiere el conocimiento previo de una clave de cualquier sector, y a partir de ahí se calcula una tabla con vectores de distancias y se hacen pruebas. Este ataque sería conocido como “Nested authentication attack”. Será uno de los más utilizados y el más fácil de implementar por nosotros debido a la laxitud de la temporización necesaria. 7 3.2.5 The Dark Side of Security by Obscurity En 2009 se descubre el segundo ataque offline importante. Gracias a Courtois, N.T. [6], que se pregunta sobre la ética de exponer este fallo, dado que cualquier tarjeta es atacable rápidamente sin necesidad de lector. Este ataque sería reconocido entre los entusiastas como “DarkSide” y permite obtener la clave de cualquier sector sin ningún conocimiento previo. En nuestra opinión, este ataque supondría un punto de inflexión, ya que su ejecución exitosa deja de depender del acceso a ningún tipo de infraestructura real del sistema donde se use la tarjeta. Ahora tendríamos todo lo necesario a nuestro alcance para investigar tarjetas sin necesidad de exponernos presencialmente, sea cual sea el objetivo del atacante. 3.3 Intentos de NXP para solucionar los problemas de seguridad Alrededor de 2011 empezaron a aparecer unas nuevas tarjetas no vulnerables a los ataques previamente descritos. El fabricante mejoró el generador de números pseudo-aleatorios para dificultar seriamente la obtención de claves offline, en un intento de mantener la retrocompatibilidad con sistemas ya en funcionamiento y mejorar la ya dañada reputación de MIFARE Classic®. Parece ser que su distribución ha sido lenta y gradual, con poca tasa de reemplazo de tarjetas anteriormente existentes. 3.3.1 Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards Finalmente, en 2015, Carlo Meijer y Roel Verdult descubrieron en este artículo [7] todas las vulnerabilidades restantes de CRYPTO1 y dejaron completamente en evidencia que era imposible hacer seguro un sistema que fuera compatible con la implementación previa. Llegando a la siguiente conclusión: “We strongly advice system integrators to migrate away from MIFARE Classic compatible systems and start using strong and cryptographically secure systems. There are many alternative contactless smart cards that support well-studied cryptographic algorithms and formally verified authentication protocols. However, system integrators which are absolutely unable to upgrade their infrastructure could temporarily consider the following palliating countermeasures: i. Deploy hardened cards and diversify all keys. – Requires the adversary to perform a different attack prior to ours, involving either eavesdropping or communication with a reader. This has to take place in a controlled environment, risking camera detection. ii. Perform authenticity and integrity checks in the backoffice on a regular basis to detect fraudulent transaction.” Carlo Meijer y Roel Verdult, 2015 En nuestra opinión, aquí se hizo un trabajo matemático excelente para reducir el tamaño de la búsqueda por fuerza bruta a un espacio razonable, aprovechando las débiles propiedades del algoritmo. La implementación de los cálculos descritos en un ataque, comúnmente llamado “Hardnested authentication attack”, en la FPGA de Proxmark 3 (herramienta que veremos a continuación), dejó rápidamente desprotegidos muchos sistemas que confiaban en las nuevas tarjetas hardened. 3.4 Herramientas de hardware existentes: Proxmark 3 Según se explica en su web [8], Proxmark 3 es una plataforma creada por Jonathan Westhues, con el objetivo de “facilitar la investigación de sistemas RFID”. Por motivos de precisión y potencia, utiliza un FPGA para el procesado de la lógica de comunicación importante. El dispositivo, cuya última revisión es la RDV4, se considera open hardware, pero su coste podría considerarse un poco elevado para un aficionado (en torno a 339€ a fecha de consulta) [9]. 8 Figura 3-1. Proxmark 3 original. Conectado a una antena adecuada y recibiendo comandos desde un ordenador, este dispositivo (o una de sus variantes o clones) es lo que se ha usado para la implementación y ejecución de la mayoría de algoritmos de ataque previamente expuestos. 3.5 Herramientas de software existentes: nfc-tools Las utilidades que vamos a describir a continuación están englobadas dentro de la suite de código abierto nfc-tools, publicada en GitHub bajo licencia LGPL en su versión 3. Dicha licencia permite software derivado que respete la misma licencia (o una equivalente), pero además el uso del código enlazado o como módulo externo en aplicaciones propietarias, siempre que se compartan los cambios particulares realizados al código fuente original. Hemos seleccionado las herramientas que consideramos más relevantes para nuestro propósito: • Platform independent Near Field Communication (NFC) library (libnfc): Biblioteca de comunicación que incluye procedimientos y drivers para diferentes chipsets. • Mifare Classic Offline Cracker (mfoc): Implementación del ataque “Nested authentication attack” (sección 3.2.4), que permite obtener la clave de varios sectores a partir de una conocida. • MiFare Classic Universal toolKit (mfcuk): Implementación del ataque “DarkSide” (sección 3.2.5), en este caso permite obtener una clave sin tener ninguna previa gracias a la debilidad del generador de números pseudo-aleatorios. • miLazyCracker: Implementación del ataque “hardnested” (sección 3.3.1) para el lector USB SCL3711. Requiere un procesador bastante potente para los cálculos matemáticos involucrados. • nfc-eventd: Demonio de monitorización de cambio de estado de las tarjetas en el lector. • libfreefare: API para la manipulación de tarjetas sobre libnfc. • libndef: Biblioteca para manejar mensajes NDEF (NFC Data Exchange Format). • nfcutils: Utilidad lsnfc para mostrar información sobre la tarjeta expuesta en el lector. 9 3.6 Conclusiones del estado del arte Habiendo revisado los artículos y herramientas anteriores, vamos a analizar por qué pueden no adaptarse completamente al cometido de nuestro trabajo. 3.6.1 Limitaciones de las vulnerabilidades y software existente En principio, las vulnerabilidades descubiertas abarcan todos los aspectos genéricos del cifrado y las comunicaciones de y con la tarjeta. El único aspecto que no es analizable trata sobre lo relacionado con la infraestructura de soporte del sistema. En general, una base de datos que comprobara en el backend las operaciones realizadas en el frontend limitaría mucho las posibilidades de realizar alteraciones válidas en las tarjetas. Hablaremos de las limitaciones del software, que consisten principalmente en lo genéricamente diseñado que está para ser flexible en cualquier aplicación. Por otro lado, no siempre tiene una compatibilidad universal tampoco: En el caso de miLazyCracker, podemos observar en su descripción cómo sólo es compatible con un lector USB concreto, conectado a un ordenador. En el caso de Proxmark el software escrito para esta herramienta sólo puede ser utilizado en esa plataforma, teniendo en consideración que cuenta con un FPGA para realizar muchas operaciones específicas de manera eficiente. Además, consideramos que estas herramientas pueden carecer de algunas optimizaciones, planificadas o no, que sería interesante implementar, como por ejemplo la búsqueda de claves para un sector concreto en el caso de mfoc. Tampoco hay nada específico para la edición y exploración de los volcados de las tarjetas. Ninguna de estas utilidades nos va a ayudar tampoco con la organización interna de la memoria de ninguna tarjeta, ya que es un formato dependiente del arbitrio del desarrollador del sistema RFID y relacionado con las necesidades del cliente. Así que tendremos que analizar la distribución de la memoria y crear nuestras propias herramientas de edición. Será necesario, por lo tanto, adaptar un programa o script exclusivamente para las tarjetas del Consorcio de Transportes de Andalucía. 3.6.2 Limitaciones de la plataforma hardware Estamos de acuerdo en que Proxmark 3 es muy funcional, no vemos limitaciones prácticas ya que es una herramienta muy específica que ha contado con numerosas revisiones a lo largo de los años. Pero su mayor fortaleza sería su mayor debilidad en nuestro caso, ya que también proporciona muchas características que realmente no vamos a utilizar, repercutiendo en el elevado coste de esta (339€ como ya se mencionó previamente). Creemos que en este aspecto hay amplio margen de mejora para nuestro caso de uso. Es por ello por lo que pretendemos diseñar un dispositivo propio que, no siendo tan potente y variado, nos sirva para nuestro propósito a una fracción de coste de un Proxmark, manteniendo la adaptabilidad a las particularidades de nuestro proyecto. 16 4.4 Consideraciones sobre el diagrama modular de Intel® Galileo Gen2 En la siguiente figura quedan reflejadas las relaciones de interconexión entre los periféricos que componen la placa de desarrollo. Nótese que estamos utilizando la versión Gen2, que tiene algunas diferencias de pines y periféricos sobre la original, además de voltaje de alimentación de 7-15V en vez de 5V. Es importante tener esto en cuenta porque puede que aplicaciones muy específicas que corren sobre Linux en vez de sobre el emulador de Arduino interno no sean compatibles entre ambas versiones. Para la integración de los componentes que utilizamos en nuestro dispositivo hemos considerado con especial importancia las siguientes pautas: • Seleccionar el nivel de salida digital a 3.3V o 5V (el módulo NFC y LCD soportan ambos). • Algunos GPIO son multifunción y requieren activar las señales adecuadas para el MUX. • En base a nuestra experiencia, el método de conexión del módulo NFC más fiable es UART. • Podemos conectar la pantalla LCD y el teclado en cualquier GPIO, lo definimos por software. Figura 4-8. Diagrama modular de Intel® Galileo Gen2. 17 4.5 Configuración de Intel® Galileo 4.5.1 Instalando la imagen del sistema operativo La imagen de Linux que vamos a utilizar pertenece a la distribución Yocto. La imagen adecuada se podría obtener de las descargas disponibles en la web de Intel, o siguiendo las instrucciones del proyecto. En nuestro caso usaremos la imagen “3.8.7-yocto-standard” que guardaremos en la tarjeta microSD, e insertaremos en la ranura correspondiente. Conectamos un cable a nuestro router en el puerto Ethernet provisto. Galileo se conectará automáticamente por DHCP, por lo que la manera más fácil de configurarlo es añadirlo a la tabla estática de nuestro router. Podremos conectarnos a él mediante la IP que obtenga, puerto 22 con usuario “root” y sin contraseña. Nos mostrará la siguiente información: Figura 4-9. Información de la imagen instalada. 4.5.2 Instalación de libnfc Las herramientas de código abierto que vamos a utilizar corresponden a la suite nfc-tools, cuyo componente principal que proporciona las bibliotecas y controladores necesarios se llama libnfc. Podemos obtenerla clonando el repositorio de GitHub con “git clone https://github.com/nfc-tools/libnfc.git” o simplemente descargar la última versión 1.7.1 desde el apartado de releases. Teniendo en cuenta que el instalador de paquetes de Yocto se llama opkg, podemos ejecutar los siguientes comandos: opkg install autoconf libtool autoreconf -vis ./configure --with-drivers=pn532_uart --sysconfdir=/etc --prefix=/usr make install Instalaremos los controladores UART para el módulo PN532 (que recordemos que es el IC de nuestro lector), en contraposición a SPI o I2C, ya que tras varias pruebas los otros modos no parecían funcionar correctamente en nuestro hardware, o implicarían una configuración más compleja. Para que los GPIO de Galileo estén en modo UART hay que cambiar la configuración de algunos pines de uso múltiple, para ello tendremos que ajustar adecuadamente el pin 45 en “/sys/class/gpio” como se muestra en la siguiente figura: Figura 4-10. Configuración de GPIO 45. 18 Con ello activamos el modo manual en un pin, poniendo la salida a nivel alto, de tal forma que se active un dispositivo de selección de función, que controla el modo del pin que proporciona el UART. En principio tendremos que ejecutar estos comandos cada vez que se reinicie nuestra Galileo, aunque posteriormente automatizaremos este procedimiento. También necesitaremos configurar el archivo “/etc/nfc/libnfc.conf” con los siguientes parámetros: device.name = "Itead_PN532_UART" device.connstring = pn532_uart:/dev/ttyS0 El objetivo no es más que hacer que el controlador de la biblioteca sepa dónde se encuentra el lector RFID que queremos que utilice, indicando la ubicación adecuada del puerto UART de Galileo, apuntando al dispositivo “dev” correspondiente. Probemos ejecutando las utilidades que habíamos instalado, primero sin tarjeta en el lector, para asegurarnos de que la comunicación entre el lector y la placa se desarrolla sin problemas. Figura 4-11. Las herramientas nfc-list y nfc-mfclassic instaladas. Ahora podremos comprobar si podemos detectar una tarjeta en el lector: Figura 4-12. Tarjeta detectada en el lector. ¡Estupendo! Podemos comprobar la UID única de la tarjeta (tampoco nos podemos fiar, en Internet se venden tarjetas sin UID para suplantarlo), la cual es legible sin necesidad de autenticación. Ahora usaremos la herramienta nfc-mfclassic para leer y escribir tarjetas, que podremos probar en tarjetas cuyas claves conozcamos. En este punto podríamos fabricar un sistema de control de acceso con tarjeta, por ejemplo, pero para hacer la auditoría necesitaremos instalar algo más. 4.5.3 Las utilidades mfcuk, mfoc y miLazyCracker Las herramientas mfcuk y mfoc implementan los ataques “DarkSide” (sección 3.2.5) y “Nested authentication attack” (sección 3.2.4), respectivamente. Para instalarlas las descargamos con “wget” o “git clone” y ejecutamos los siguientes comandos: autoreconf -vis ./configure make 19 Haciendo algunas pruebas con mfcuk quizás no parezca funcionar adecuadamente, ya que queda en una búsqueda continua sin encontrar nada. ¿Cómo podríamos solucionarlo? Bueno, realmente no lo necesitamos, ya que disponemos de una clave previamente. Recientemente se implementó el ataque “Hardnested”, para tarjetas hardened sin necesidad de un Proxmark 3 en miLazyCracker y en una rama alternativa de mfoc. En caso de intentar compilarlo en Galileo, tendremos algunos problemas con el código ensamblador inline para AMD64 o SSE, según la versión, ya que nuestro procesador Intel® Quark X1000 es de 32 bits y, de hecho, tampoco incluye juegos de instrucciones para manejar vectores como MMX o SSE. Tampoco importa mucho, el rendimiento sería simplemente insuficiente [13]. 4.5.4 Configuración de la pantalla y del teclado De cara a implementar la pantalla, nuestra primera idea fue la de instalar un controlador que la manejase. Existe, de hecho, un módulo para el kernel de Linux que lo implementa. No obstante, teníamos ciertas limitaciones en cuanto a memoria para realizar las operaciones de instalación necesarias. Así que, tras reflexionar un poco sobre una posible solución, llegamos a la conclusión de que era posible manejarla en shellscript dividiendo el problema en diversas capas de abstracción, desde la capa física (control de bits) hasta la capa de aplicación (envío de mensajes). El datasheet del IC HD44780 [14] explicaba claramente cómo activar los pines para mostrar mensajes, siguiendo las tablas de caracteres proporcionadas para ello. El modo de transmisión elegido fue el de 4 bits, porque simplificaba notoriamente el conexionado. La única diferencia a nivel de software es enviar la información de los caracteres en dos partes con una línea de control. Para el teclado procedemos de manera similar, haciendo polling de lectura cuando nuestro programa requiere una entrada y hasta que las combinaciones adecuadas de pines han sido activadas por una pulsación del teclado. Como es evidente por la sencillez del teclado, evitaremos pulsar varios botones a la vez para no confundir al algoritmo de muestreo y decodificación. Figura 4-13. Pruebas con la pantalla digital. 20 4.6 Ventajas y limitaciones de nuestra plataforma Con una inversión de sólo 22€ (lector, pantalla, teclado, carcasa), teniendo en cuenta que las placas Galileo fueron proporcionadas a modo de muestras gratuitas por Intel (y la microSD reutilizada), cumplimos sobradamente el requisito de reducir el coste del hardware de auditoría. Nos permite instalar GNU/Linux, compilar nuestras herramientas y mejorarlas de manera sencilla. Gracias a estar utilizando el IC modelo PN532 de NXP, también mantenemos compatibilidad tanto con las tarjetas MIFARE Classic®, como con libnfc. La herramienta mfoc, principal en nuestro caso, funcionará correctamente, aunque algo lenta, como veremos posteriormente. En cuanto a los inconvenientes, podríamos destacar la aparente imposibilidad para hacer funcionar mfcuk. El ataque hardnested de miLazyCracker también estará fuera de nuestro alcance, pero considerando que en el momento de diseño de nuestro dispositivo esas tarjetas eran muy poco comunes (y que de hecho esta herramienta no existía aún), nos parecen suficientes las prestaciones obtenidas. Para sortear estos problemas, en principio el primero lo podemos paliar consiguiendo previamente alguna clave obtenida de otro modo. En cuanto a las tarjetas hardened, siempre podríamos utilizar para nuestras pruebas las tarjetas antiguas, que siguen siendo igual de válidas en la actualidad. No hemos tenido demasiados problemas para encontrarlas. Figura 4-14. Dispositivo ensamblado. 21 5 MEJORAS Y OPTIMIZACIÓN DEL SOFTWARE n este capítulo procederemos a preparar el software necesario para el funcionamiento de nuestras pruebas. Se comentarán con especial atención algunos aspectos particulares y problemas encontrados durante las etapas de desarrollo, explicando las soluciones encontradas. El siguiente paso sería mejorar los scripts para reducir la intervención manual al mínimo. Por último, investigar cómo reducir el tiempo empleado en volcar la información relevante de la tarjeta. Serán necesarias varias estrategias para evitar la pérdida de tiempo en cálculos innecesarios. 5.1 Motivación de las mejoras La principal vía de ejecución de las pruebas iniciales será mediante la obtención de volcados de la memoria interna de la tarjeta. En un principio las utilidades mfoc y nfc-mfclassic nos permiten volcar una tarjeta entera o leerla y escribirla por sectores, respectivamente. Su utilización requiere de bastante intervención manual, demandando también ser metódico en la gestión de los archivos generados para no sobrescribir información que queremos mantener, o localizar fácilmente los archivos adecuados que queremos modificar. Tampoco cuentan con parámetros concretos de edición. Por este motivo, lo primero que haríamos sería “envolver” estas utilidades en uno o varios scripts sobre los que delegar algunos procedimientos. 5.2 Automatización Escribir todos los comandos requeridos para hacer las configuraciones y alteraciones necesarias era bastante tedioso, así que la primera mejora que se aplicó fue la creación de varios scripts para automatizar tareas. El código de estos se puede encontrar en el anexo, al final de este documento. Su funcionalidad se describe a continuación. 5.2.1 recarga.sh El script central que automatiza la alteración de la estructura de memoria para las tarjetas andaluzas. Fue creado en paralelo al estudio de la memoria interna de la tarjeta, según íbamos descubriendo cómo modificar ciertos parámetros de la mejor forma posible. Sólo hay que llamar a “/opt/utils/recarga.sh <importe>”: • Inicializa los pines. • Comprueba que hay tarjeta en el lector, en cuyo caso lee el UID para ver si existe en la base de datos. • Si existe, usa las claves guardadas para volcarla con mfoc; si no, intenta el ataque y guarda las claves. • Llama xxd para obtener información del volcado. Consideraciones: o Si un número empieza por “0”, ¡Bash lo considera octal! o Hay que tener cuidado con el endianness (orden de las palabras de la memoria). • Se hace un respaldo del volcado anterior, por si acaso estropeamos algo. • Se genera una cadena hexadecimal con los nuevos datos, y se inserta en el volcado. • Se graban los datos en la tarjeta, sólo los sectores relevantes. E 22 5.2.2 lcd.sh Consta de tres partes: inicialización de pines, funciones de abstracción y ejemplos de uso. Como curiosidad, se han añadido unos comandos sleep para solucionar algunos bugs relacionados con la sincronización digital de los canales. Las funciones de una capa de abstracción superior llaman a las inferiores, facilitando así enormemente la partición del problema, de la siguiente manera: • status(): Lee los valores de las líneas conectadas con la pantalla. Fundamentalmente depuración. • lcdpin(): Ajusta el valor de un pin concreto. • sendNibb(): Ajusta los pines para medio octeto y manda la señal de activación. • sendByte(): Envía dos medios octetos. • sendChar(): Limpia la pantalla, separa la cadena especificada en caracteres y muestra el texto. • cleanLcd(): Limpia la pantalla y resetea el cursor al comienzo. • firstLine(): Mueve el cursor a la primera línea. • secondLine(): Mueve el cursor a la segunda línea. Figura 5-1. Pantalla LCD mostrando el progreso. 5.2.3 keypad.sh Lee el estado de los pines asignados al teclado matricial, decodifica la tecla pulsada según la posición, y devuelve el valor. El teclado consta de ocho líneas, y el escaneado se produce activando a nivel alto consecutivamente los cuatro pines de salida de Galileo. La lectura de los pines pulsados se realiza en cada una de las cuatro entradas, de tal forma que, si el botón produce contacto, la entrada detecte un nivel alto. Consideramos importante ajustar la frecuencia de muestreo y la posibilidad de añadir algún método de debouncing para equilibrar los parámetros de latencia percibida y fiabilidad. 23 5.2.4 uart.sh Inicializa el puerto UART, ya que el puerto GPIO 45 tiene varias funciones asignadas. La línea “export” marca el puerto 45 para su modificación. La línea “out” cambia la dirección a salida. La línea “value” asignado a “1” marca el nivel alto del pin. Este archivo es llamado por recarga.sh antes de hacer ninguna operación, pero sólo una vez. Esto es posible usando la característica de creación de un archivo volátil en “/var/volatile”, como si fuera una variable, para comprobar el estado de llamadas previas. 5.3 Optimización de las prestaciones de ataque En un principio, el volcado de una tarjeta completa tardaba alrededor de 8-12h con la potencia de nuestra CPU. Todo esto para cada vez que quisiéramos modificar algo en alguna tarjeta. De cara a reducir los tiempos a una cantidad más razonable, valoramos la posibilidad de implementar algunas mejoras: • Creación de una base de datos de claves, recordando las tarjetas previamente atacadas. • Análisis de los bits de permisos para reducir las claves que necesitemos (y que no tenemos). • Reducción de los sectores a atacar a los mínimos indispensables (reducción a menos de 1h). El primer punto se abordaría dentro de los scripts de automatización previamente descritos, como parte de la gestión de los ficheros, ordenándolos en el sistema de archivos. El segundo parte de la sospecha de que algunas modificaciones se podían leer, y escribir de nuevo, utilizando la clave A no única; se describirá en la próxima sección. Con respecto al último punto, la herramienta mfoc no permitía seleccionar sectores concretos para atacar, pero dicha funcionalidad estaba planificada en la ayuda del programa. El código fuente de la herramienta está escrito en C, así que no resultó complejo añadir / modificar las líneas necesarias tras una revisión cuidadosa de cómo funcionaba el código. Por lo tanto, fue enviado el Pull Request número 43 (y 44), habilitando la opción “-s” por línea de comandos para especificar un sector, al proyecto original en GitHub, de cara a aportar nuestro granito de arena al proyecto. También se han enviado algunas otras mejoras menores y propuestas de solución de bugs. 5.4 La utilidad MiFaRe para (des)codificar los bits de acceso A la hora de emprender el análisis de permisos, en primer lugar, nos dirigimos al datasheet de la tarjeta [10]. Podemos observar que la información sobre los permisos alojada en los bits de acceso es simple, pero la codificación es un poco compleja desde el punto de vista de un humano. Comprobar estos bits a mano requería una inspección minuciosa, ya que los bits cuentan con redundancia (y varias negaciones de bits), describiendo qué claves y de qué manera afectan a cada posición de memoria. Investigando un poco, tuvimos conocimiento de una utilidad fantástica, que cuenta con interfaz gráfica y es muy intuitiva. Se trata de “MiFaRe – Access Conditions Calculator”, la cual fue de gran ayuda a la hora de decodificar cómodamente los números hexadecimales. Actualmente existen también algunas utilidades online para hacer la misma tarea, aunque nosotros consideramos suficiente esta. 24 Figura 5-2. Captura de la utilidad MiFaRe. Escribiendo los bits de acceso en la caja de texto provista, y pulsando sobre el botón “< Decode”, podremos comprobar el significado de dichos bits de manera rápida y precisa. De la misma manera podríamos hacer la operación inversa y utilizarla para configurar una tarjeta para un sistema que vayamos a diseñar nosotros. La información sobre las implicaciones de cada modo de funcionamiento se indica en el datasheet, aunque como regla general se suele utilizar la clave A para leer y decrementar, y la clave B para escribir e incrementar datos, o para cambiar las claves y los propios bits de condiciones de acceso. La idea de que las claves funcionen así es una configuración de seguridad basada en anillos de confianza, donde en teoría podríamos distribuir las claves de lectura libremente para consultar el saldo en aplicaciones móviles o decrementarlo, en caso de ser requerido por lectores de entidades externas. Las claves de escritura las protegeríamos nosotros para que ninguno de esos usuarios tuviera permiso de modificar los contenidos de manera negativa a nuestros intereses. 25 6 AUDITORÍA DE SEGURIDAD na vez desarrollado el dispositivo y optimizado el software, el siguiente paso fue investigar cómo estaban distribuidos los datos internos para saber la manera más conveniente de leerlos. Vamos a probar también algunas otras tarjetas no pertenecientes al Consorcio de Transportes de Andalucía. 6.1 Vista previa funcional Repasemos la situación de los elementos que componen nuestro dispositivo de auditoría. Los distintos componentes de hardware quedarían situados así, integrados en la carcasa y con una cercanía suficiente entre la tarjeta y el lector. Nuestro dispositivo estaría listo para leer y escribir. En nuestro dispositivo ensamblado, el lector NFC se encuentra colocado en la parte inferior de la carcasa, debajo del teclado, por lo que la tarjeta la tendríamos que aproximar a esa zona para que fuera detectada. Es importante que la carcasa no sea metálica, o bloquearíamos la inducción electromagnética que la espira del lector provoca en la antena espiral de la etiqueta. U Figura 6-1. Disposición esquemática de los elementos que integran el sistema. 32 6.7 Contramedidas posibles De cara a fortalecer el sistema RFID analizado, existen dos métodos más o menos fiables para implementar contramedidas que eliminen completamente las vulnerabilidades encontradas, o al menos limiten su impacto: A través de una base de datos en el backend que compruebe todas las transacciones o bien reforzar el cifrado de las tarjetas utilizadas. En el primer caso, se presenta el inconveniente de que todos los lectores deberían estar conectados a una red. Para el segundo quizás los dispositivos no cuenten con la potencia adecuada para implementar los cifrados recomendados (AES) o que permitan la lectura de nuevos modelos de tarjeta (por ejemplo, al ser diferente el protocolo de comunicación). Otra posibilidad sería cotejar las transacciones en diferido, pero dada la cantidad de entidades y transportes diferentes que utilizan estos medios, pensamos que es complicado. En cualquier caso, ya sea por renovación de equipos o mejora de los protocolos de intercambio de datos, suponemos que la implementación de cualquier contramedida es una situación inconveniente tras una implantación tan intensa de los sistemas ya existentes. Sea como fuere, la mayoría de usuarios tampoco tienen los conocimientos técnicos necesarios, bastante complejos, y habría que valorar el balance entre coste de renovación y pérdida de beneficios a causa de la falsificación de los datos. 33 7 CONCLUSIONES Y TRABAJOS FUTUROS e ha prototipado un sistema de auditoría de bajo coste, compatible con herramientas de código abierto, con el objetivo de explorar la seguridad de una aplicación real masiva de tecnologías RFID. Hemos podido demostrar con ello que, al menos una red de transporte de ámbito andaluz es insegura a los ataques existentes, y concretamente a los que hemos podido implementar en nuestro dispositivo. Para finalizar, nos gustaría comentar las conclusiones que hemos obtenido y las causas, considerando algunas fechas relevantes en las que se produjeron los avances y despliegues. También enumeraremos hacia dónde se podría expandir este proyecto con algunas ideas que hemos ido considerando a medida que avanzaba. No obstante, como veremos, no tendrá mucho sentido seguir invirtiendo esfuerzos al estar el sistema actual en proceso de sustitución progresiva. 7.1 Conclusiones Sin duda el mayor riesgo que asumió Philips Semiconductors (ahora NXP) fue confiar la seguridad de su algoritmo de cifrado, al desconocimiento público del mismo. La manera moderna de proceder hubiera sido exponerlo a escrutinio abierto, o mejor todavía si cabe, utilizar un algoritmo ya probado. Con respecto a la implementación del sistema en la red de pagos del Consocio de Transportes de Andalucía, nuestro sistema de auditoría permite la alteración exitosa del contenido de las tarjetas. El despliegue fue anterior al descubrimiento de la mayoría de vulnerabilidades. No quedaba mucha alternativa salvo haber cambiado las tarjetas por su versión hardened, y a la vez todas las contraseñas de todos los consorcios de manera sincronizada. Adicionalmente, vigilar todos los lectores para evitar escuchas con herramientas sniffer, algo imposible de hacer y con poco futuro a medio plazo. Una base de datos hubiera sido también difícil de mantener con tantos medios de transporte y administraciones involucradas en “modo lectura” (clave A). Pero no todo iban a ser problemas para el transporte andaluz. Hace dos años, en 2017, se mencionó [17] una partida de presupuesto de 9 millones de euros para reemplazar los lectores y tarjetas con la tecnología MIFARE DESFire® EV2, que según parece se desplegará este año. Como podemos apreciar en este documento comparativo [15], el cifrado de dichas tarjetas es 3DES / AES de 112-128 bits, este último especial estándar en la industria en cuanto a seguridad se refiere. Al menos, será seguro mientras no encuentren un ataque side-channel (como le pasó a DESFire [18]), una puerta trasera, o se descubra un fallo de implementación. Pero mientras tanto, podemos afirmar que la nueva protección es matemáticamente segura. 7.2 Trabajos futuros • Implementar una aplicación móvil que permita el control remoto del dispositivo sin necesidad de línea de comandos, de esta manera se agilizaría el proceso de conexión y facilitaría la introducción de parámetros de funcionamiento. • La limitación de potencia de procesado supone un problema. En su día, respecto a una Raspberry Pi de primera generación se podría decir que Galileo era ligeramente más potente. No obstante, hasta la aparición del ataque contra tarjetas hardened la potencia de Intel® Quark X1000 era suficiente. • Migración de plataforma a Raspberry Pi, cuya versión 4 acaba de salir al mercado recientemente, con grandes mejoras de capacidad de memoria y una CPU más potente (también de 64 bits, aunque Raspbian sea sólo de 32). Nos gustaría recordar que la elección de Intel® Galileo se hizo en 2014. S 34 • Estuvimos pensando la posibilidad de dividir el sistema de manera distribuida, de tal forma que un servidor más potente recibiera paquetes de procesado para calcular el bitslicing con multihilo, capacidades de 64 bits y juego de instrucciones AVX. Desafortunadamente la CPU del equipo que utilizamos actualmente no soporta AVX, por lo que el rendimiento de miLazyCracker sería inferior. • Cambiar de paradigma: Con la reciente escalada de núcleos de estos últimos años, un lector USB en un ordenador portátil podría ser suficiente para intentar un ataque hardnested sin renunciar en exceso a la portabilidad. • Probar Proxmark 3 en profundidad, ya que todos los avances en la materia se realizan sobre dicha plataforma primero. A pesar de su elevado coste, existen alternativas clónicas más baratas. 35 REFERENCIAS BIBLIOGRÁFICAS [1] C. Rodríguez, «Polizones 2.0 en el tranvía y el autobús,» El Mundo, 29 Feb 2016. [En línea]. Available: https://www.elmundo.es/andalucia/sevilla/2016/02/29/56cf548346163ff3728b4663.html. [Último acceso: 2019]. [2] K. Nohl y H. Plötz, «Mifare: Little Security, Despite Obscurity,» de 24th Chaos Communication Congress, 2007. [3] G. d. K. Gans, J.-H. Hoepman y F. D. Garcia, «A Practical Attack on the MIFARE Classic,» 2008. [En línea]. Available: https://arxiv.org/abs/0803.2285. [4] F. D. Garcia, G. d. K. Gans y R. Muijrers, «Dismantling MIFARE Classic,» de Computer Security - ESORICS 2008 (13th European Symposium on Research in Computer Security, Malaga, Spain), 2008, pp. 97-114. [5] F. D. Garcia, P. v. Rossum y R. Verdult, «Wirelessly Pickpocketing a Mifare Classic Card,» de 30th IEEE Symposium on Security and Privacy 2009, 2009. [6] N. T. Courtois, «THE DARK SIDE OF SECURITY BY OBSCURITY - and Cloning MiFare Classic Rail and Building Passes, Anywhere, Anytime,» de Proceedings of the International Conference on Security and Cryptography - Volume 1: SECRYPT, 2009. [7] C. Meijer y R. Verdult, «Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards,» de 22nd ACM Conference on Computer and Communications Security, 2015. [8] Proxmark, «Proxmark 3 - Device Background,» [En línea]. Available: https://proxmark.com/. [Último acceso: 2019]. [9] Lab401, «The Proxmark 3 is the ultimate RFID platform for pentesters and researchers.,» Proxmark 3 RDV4.01, [En línea]. Available: https://lab401.com/collections/hardware/products/proxmark-3-rdv4. [Último acceso: 2019]. [10] NXP Semiconductors, «Product data sheet,» NXP MIFARE Classic EV1 1K - Mainstream contactless smart card IC for fast and easy solution development, 2018. [En línea]. Available: https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf. [11] Intel Corporation, «Discontinued Maker & Innovator Products,» Developer Zone, 2017. [En línea]. Available: https://software.intel.com/en-us/iot/hardware/discontinued. [Último acceso: 2019]. [12] ITEAD Intelligent Systems Co.Ltd., «itead.cc,» 2014. [En línea]. Available: https://www.itead.cc/iteadpn532-nfc-module.html. [Último acceso: 2019]. [13] S. Decrock, «Cracking Mifare Classic NFC cards using the hardnested attack,» May 2019. [En línea]. Available: https://medium.com/@decrocksam/cracking-mifare-classic-nfc-cards-using-the-hardnested- 36 attack-506aab3ea305. [Último acceso: 2019]. [14] Hitachi, Ltd., «SpakFun Electronics,» 1998. [En línea]. Available: https://www.sparkfun.com/datasheets/LCD/HD44780.pdf. [Último acceso: 2019]. [15] NXP Semiconductors Austria GmbH, «MIFARE® contactless tag IC family overview,» 2019. [En línea]. Available: https://www.mifare.net/wp-content/uploads/2015/02/MIFARE-Product-Family-Basic- Decision-Chart-2017.pdf. [16] National Institute of Standards and Technology, «GUIDANCE ON TDEA BLOCK CIPHERS,» 2017. [En línea]. Available: https://csrc.nist.gov/CSRC/media/Publications/Shared/documents/itlbulletin/itlbul2017-11.pdf. [Último acceso: 2019]. [17] Consorcio de Transporte Metropolitano - Área de Sevilla, «La Red de Consorcios de Transportes inicia la mejora tecnológica de sus tarjetas con una inversión de 9 millones de euros,» 04 Sep 2017. [En línea]. Available: http://www.consorciotransportessevilla.com/contenido_ctas.php?contenido=4011&id=1190&tipo=1. [Último acceso: 2019]. [18] D. Oswald y C. Paar, «Breaking Mifare DESFire MF3ICD40: Power Analysis and Templates in the Real World,» de Cryptographic Hardware and Embedded Systems, Nara, 2011. 37 ANEXO: CÓDIGO DEL DISPOSITIVO apturas del código de la aplicación. Tenga en cuenta que los datos sensibles (como por ejemplo ciertos offsets) han sido sombreados del código. No obstante, puede hacerse una idea del funcionamiento y de la lógica de la aplicación sin mayor problema. Los archivos son los descritos en la sección 5.2 y las modificaciones de mfoc descritas en la sección 5.3. ◼ lcd.sh C 38 39 ◼ recarga.sh 40 41 ◼ uart.sh