Repositorio Institucional de Documentos

Proyecto Fin de Carrera de Ingenier´ıa en Inform´atica Ataques de relay en NFC con dispositivos Android Jos´e Vila Bausili Director: Ricardo J. Rodr´ıguez Fern´andez Ponente: Jos´e Javier Merseguer Hern´aiz Departamento de Inform´atica e Ingenier´ıa de Sistemas Escuela de Ingenier´ıa y Arquitectura Universidad de Zaragoza Septiembre de 2014 Curso 2013/2014 Agradecimientos A mi familia por aguantarme, mantenerme y quererme. A Arantxa por su paciencia y ´animos, no pocas veces. A Ricardo, el mejor director de proyecto que pod´ıa haber tenido. Y a Jos´e Merseguer, por hacerle trabajar en agosto. GRACIAS. On the Internet, nobody knows you’re a dog. Abraham Lincoln Ataques de relay en NFC con dispositivos Android RESUMEN Las siglas NFC (Near Field Communication) nombran al conjunto de est´andares dise˜nados para establecer una comunicaci´on inal´ambrica punto-a-punto entre dispositivos en proximidad, normalmente de unos pocos cent´ımetros. Dichos est´andares cubren distintos protocolos de comunicaci´on e intercambio de datos y est´an basados en otros est´andares de identificaci´on por radio frecuencia (RFID) como ISO/IEC 14443 o FeliCa. Cada vez encontramos m´as servicios que permiten el pago mediante tarjetas o dispositivos sin contacto mediante tecnolog´ıa NFC; desde el transporte p´ublico hasta aparcamientos, cajeros r´apidos en supermercados o m´aquinas de vending. ¿El principal motivo? La fuerte apuesta de los bancos por esta tecnolog´ıa. Existen numerosos tipos de tarjetas NFC, de mecanismos de seguridad y de ataques a ´estas. Los ataques de relay son una t´ecnica de man-in-the-midle en la que el atacante es capaz de retransmitir un mensaje desde un emisor a un receptor remoto en tiempo real, explotando el supuesto de que la comunicaci´on con una tarjeta NFC implica proximidad f´ısica. Desafortunadamente, la gran mayor´ıa de tarjetas no dispone de ninguna medida ante este vector de ataque ya que la necesidad de hardware especializado “hace”poco realista un ataque pr´actico. Sin embargo, con la irrupci´on de dispositivos m´oviles con chips NFC, este panorama ha cambiado radicalmente. En este trabajo se pretende estudiar la arquitectura NFC en un entorno m´ovil y desarrollar una aplicaci´on llamada NFC Leech que permita realizar un ataque de relay con dispositivos Android a tarjetas NFC (concretamente tarjetas de cr´edito). Se pretende, a su vez, documentar todos los aspectos t´ecnicos de la implementaci´on que hace Android de NFC a partir de las especificaciones, documentaci´on y c´odigo fuente, con el fin de servir de referencia a cualquier trabajo futuro relacionado. ´ Indice ´ Indice de Figuras V ´ Indice de Tablas VII 1. Introducci´on 1 1.1. Objetivo..................................... 1 1.2. Motivaci´on ................................... 2 1.3. Organizaci´on .................................. 2 2. Conocimientos previos 5 2.1. Tecnolog´ıa NFC y familia ISO 14443 . . . . . . . . . . . . . . . . . . . . . 5 2.2. APDUs (ISO 7816-4) y EMV . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Ataques de relay ................................ 11 2.4. EcosistemaAndroid .............................. 12 2.4.1. Dispositivos y software . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2. Desarrollo en Android . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.3. Arquitectura Android . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. An´alisis de NFC en Android 15 3.1. Alternativas y elecci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. NCI ....................................... 18 3.3. Limitaciones: conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. NFC Leech: dise˜no e implementaci´on 21 4.1. Dise˜no...................................... 21 4.2. Implementaci´on................................. 24 4.2.1. Proxy .................................. 24 4.2.2. Mole................................... 25 4.2.3. Canal de retransmisi´on . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. Pruebadeconcepto............................... 29 5. Trabajo relacionado 33 iii ´ INDICE ´ INDICE 6. Conclusi´on y l´ıneas futuras 39 6.1. L´ıneas de investigaci´on futuras . . . . . . . . . . . . . . . . . . . . . . . . 39 Acr´onimos 42 A. Horas de trabajo 45 B. Mensajes de configuraci´on NCI 47 C. Traza de una llamada transceive en Android con NfcA 55 D. Habilitar TRACE LEVEL en servicio NFC 65 D.1. Desbloqueo del terminal m´ovil Nexus 4 . . . . . . . . . . . . . . . . . . . . 65 D.2.Rootv´ıaSuperSU ............................... 66 D.3.FlagsdedebugNFC.............................. 67 E. Kernel Android 73 F. Estructura y ´ordenes APDU 77 G. Mapa de tags y tecnolog´ıas 85 iv ´ Indice de Figuras 2.1. Protocolo de selecci´on y anti-colisi´on ISO 14443-3A. . . . . . . . . . . . . 7 2.2. Pre´ambulo del protocolo de transmisi´on ISO 14443-4. . . . . . . . . . . . 8 2.3. Selecci´on opcional de AID en un canal ISO 14443-4. . . . . . . . . . . . . 10 2.4. Env´ıo de un APDU sobre ISO 14443-4. . . . . . . . . . . . . . . . . . . . . 10 2.5. Escenario de relay en partida de ajedrez postal descrito por Conway. . . . 12 2.6. Arquitectura IPC basada en Binder de Android. . . . . . . . . . . . . . . 14 3.1. Capas de la arquitectura Android. . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Arquitectura NCI: comunicaci´on entre NFCC y DH. . . . . . . . . . . . . 18 4.1. Diagrama de clases general de la aplicaci´on NFC Leech. . . . . . . . . . . 22 4.2. Arquitectura de relay de APDUs en NFC. . . . . . . . . . . . . . . . . . . 24 4.3. Diagrama del elemento Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4. Diagrama del elemento Mole. . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5. Ejemplo de ataque de relay NFC; una tarjeta a N sitios. . . . . . . . . . . 28 4.6. Ejemplo de ataque de relay NFC; botnet de tarjetas de pago. . . . . . . . 29 4.7. Dispositivo Nexus 4; con Android 4.4 y soporte NFC. . . . . . . . . . . . 30 4.8. TPV Ingenico IWL280; GPRS y NFC. . . . . . . . . . . . . . . . . . . . . 30 4.9. Tarjeta de cr´edito NFC del Banco Sabadell. . . . . . . . . . . . . . . . . . 31 4.10. Capturas de pantalla de la aplicaci´on: pantalla principal a la izquierda, y selecci´on de pares mediante WiFi-Direct a la derecha. . . . . . . . . . . . 32 4.11. Captura de pantalla de v´ıdeo demo realizando un ataque de relay con NFCLeech.................................... 32 5.1. Hardware ad-hoc para implementar ataque de relay NFC. ......... 33 5.2. Arquitectura de ataque relay con un punto de venta malicioso. . . . . . . 35 5.3. Arquitectura de ataque relay en comunicaci´on P2P. . . . . . . . . . . . . . 35 5.4. Ataque relay NFC con Nokia y Blackberry. . . . . . . . . . . . . . . . . . 37 A.1. Diagrama de Gantt mostrando el esfuerzo invertido en semanas. . . . . . 45 C.1. Arquitectura de la implementaci´on Tag en la API de Android. . . . . . . . 56 v Secci´on 1.3 1. Introducci´on 4 Cap´ıtulo 2 Conocimientos previos En este cap´ıtulo se definen conceptos b´asicos para la compresi´on de la memoria del trabajo. Dado que se abarcar´an varias tem´aticas distintas y son necesarias bastantes nociones, se pretende dar una introducci´on a las distintas por secciones: empezando con la familia de protocolos y est´andares que utiliza NFC, la explicaci´on de en qu´e consiste un ataque de relay y finalmente se presenta el entorno Android para que el lector se familiarice con la nomenclatura. 2.1. Tecnolog´ıa NFC y familia ISO 14443 La tecnolog´ıa NFC o Near Field Communication, engloba a la familia de est´andares para establecer una comunicaci´on inal´ambrica entre dos dispositivos en proximidad. Dichos est´andares cubren distintos protocolos de comunicaci´on e intercambio de datos y est´an basados en otros est´andares de identificaci´on por radio frecuencia (RFID) como ISO/IEC 14443 o FeliCa. Puesto que FeliCa es utilizado principalmente en Jap´on, esta secci´on se va a centrar en la familia ISO 14443 que es el est´andar en Europa y EEUU. La caracter´ıstica m´as relevante de NFC es la capacidad de los elementos pasivos, una comunicaci´on consta de dos componentes: el PCD (o Proximity Coupling Device), que tiene corriente (elemento activo) y act´ua como lector/escritor, y el PICC (o Proximity Integrated Circuit Card), que es la tarjeta pasiva y cuyo chip se alimenta por inducci´on gracias al campo electromagn´etico que genera el lector (por lo que no necesita una fuente de alimentaci´on interna). Dentro de ISO 14443 se puede distinguir dos tipos de tecnolog´ıas: A y B, que a pesar de trabajar ambas en la frecuencia 13’56 MHz se diferencian en la modulaci´on utilizada, la codificaci´on y los protocolos de inicializaci´on. El est´andar consta de 4 partes: 1. ISO/IEC 14443-1: Describe las caracter´ısticas f´ısicas. 2. ISO/IEC 14443-2: Describe la potencia y se˜nal de la radio frecuencia. 3. ISO/IEC 14443-3: Detalla los algoritmos de inicializaci´on y anti-colisi´on. 5 Secci´on 2.1 2. Conocimientos previos En la Figura 2.1 se puede ver un diagrama del protocolo de selecci´on de una tarjeta, donde en caso de activar varias tarjetas a la vez se realiza un algoritmo de anti-colisi´on. Las ´ordenes REQA,ATQA, etc., son simplemente un conjunto de bytes definidos en la especificaci´on. En resumen, el PCD (o lector) se encuentra haciendo polling enviando ´ordenes REQA al medio hasta que un PICC (o dispositivo pasivo) entra en el campo y es activado, momento en el que responder´a con un ATQA y quedar´a a la espera de ser seleccionado. El PCD ejecutar´a su algoritmo de anti-colisi´on en caso de que se detecten varias tarjetas cercanas en el mismo momento. El algoritmo consiste en ir enviando una m´ascara de bits sobre el identificador de la tarjeta, ya que todas las tarjetas tienen un ID ´unico, de este modo los PICCs cercanos responder´an s´olo si la m´ascara coincide con su ID. En cada iteraci´on se restringir´a m´as la m´ascara hasta que s´olo responda una tarjeta. Finalmente el PICC seleccionado responder´a con un mensaje SAK determinando el tipo de tarjeta que es y los protocolos que soporta. 4. ISO/IEC 14443-4: Protocolo de transmisi´on. En esta parte se define el protocolo de transmisi´on, y como se aprecia en la Figura 2.2, se produce el env´ıo de unas ´ordenes de configuraci´on (RATS yPPS) que definen los par´ametros entre ambas partes para establecer un canal l´ogico de comunicaci´on half-duplex, es decir, donde s´olo puede estar transmitiendo un par a la vez. Dependiendo del SAK recibido, el PCD solicitar´a mediante una orden RATS (Request ATS) los par´ametros de la conexi´on del tag. La respuesta ATS (Answer To Select) contiene por ejemplo los tama˜nos de ventana, los timeouts m´aximos para los mensajes de configuraci´on y el canal, bytes hist´oricos... Opcionalmente el PCD podr´a modificar alg´un par´ametro si la tarjeta soporta PPS. Una vez finalizado queda definido el canal l´ogico sobre el que se enviar´an mensajes APDU. Las tarjetas que cumplen las cuatro partes del est´andar se denominan IsoDep, aunque tambi´en hay algunas que implementan protocolos propietarios y siguen algunas o ninguna parte. Un ejemplo son las tarjetas Mifare Classic, que implementan las dos primeras acorde al est´andar, pero despu´es establecen su propio protocolo de transmisi´on. 6 2. Conocimientos previos Secci´on 2.1 opt loop [UID not complete] [UID complete, PICC compliant to ISO/IEC 14443-4] ref ISO/IEC 14443-4 PICC PCD 2.1: SAK 2: SELECT 1.1: ATQA 1: REQA Figura 2.1: Protocolo de selecci´on y anti-colisi´on ISO 14443-3A. 7 Secci´on 2.1 2. Conocimientos previos [PPS supported] alt opt [Parameter change] ref ISO/IEC 14443-3 PICC PCD 2.1: PPS response 2: PPS request 1.1: ATS 1: RATS Figura 2.2: Pre´ambulo del protocolo de transmisi´on ISO 14443-4. 8 2. Conocimientos previos Secci´on 2.2 2.2. APDUs (ISO 7816-4) y EMV El est´andar ISO 7816 est´a relacionado con las tarjetas inteligentes o smartcards y consta de quince partes o libros. Para este trabajo ser´a de inter´es la parte 4 donde se define la organizaci´on y seguridad de las ´ordenes para intercambiar informaci´on, y que puede ser usada independientemente del medio f´ısico. NFC utiliza los mensajes APDU o Application Protocol Data Unit (especificados en ISO 7816-4), que es la estructura de los mensajes transmitidos sobre el canal half-duplex establecido en base a ISO 14443-4. En las Figuras 2.3 y 2.4 se pueden ver los diagramas de env´ıo de un mensaje APDU entre el PCD y el PICC. Puesto que ISO 7816 define un protocolo orientado a tarjetas inteligentes existe una orden especialmente relevante llamada SELECT. Esta orden permite a un lector seleccionar una aplicaci´on concreta de la tarjeta con la que comunicarse, ya que los chips pueden almacenar y ejecutar distintas aplicaciones. Este proceso es posible gracias a los AID (o Identificadores de Aplicaci´on) que est´an formados por dos partes: RID (o Registered Application Provider Identifier): consta de 5 bytes y est´a registrado por una autoridad registradora. PIX (o Propietary Identifier Extension): permite al proveedor diferenciar entre sus propias aplicaciones dentro de una misma tarjeta. Por otro lado, el est´andar EMV (de Europay, MasterCard y Visa)1define la comunicaci´on entre tarjetas inteligentes y terminales TPV (Terminal Punto de Venta, o POS en ingl´es) o cajeros autom´aticos (ATM) para la autenticaci´on en transacciones de tarjetas de cr´edito y d´ebito. Las ´ordenes EMV utilizan la estructura APDU, que se puede consultar para mayor detalle en el Ap´endice F. 1http://www.emvco.com/specifications.aspx?id=21 9 Secci´on 2.2 2. Conocimientos previos [Explicit Select] ref ISO/IEC 14443-4 opt alt [Error] PICC PCD 2: ISO/IEC 14443-4 DESELECTION 1.1: success 1: SELECT AID Figura 2.3: Selecci´on opcional de AID en un canal ISO 14443-4. ref ISO/IEC 7816-4 PICC PCD 1.1: APDU Command response 1: APDU Command request Figura 2.4: Env´ıo de un APDU sobre ISO 14443-4. 10 2. Conocimientos previos Secci´on 2.3 2.3. Ataques de relay Los ataques de relay son el tema central de este trabajo, de modo que se pretende introducir la idea subyacente y posteriormente presentar el caso concreto en NFC. La primera vez que aparece este concepto fue en [CON76] en el a˜no 1976, donde Conway explica c´omo alguien que no conoce las reglas del ajedrez puede llegar a vencer a un Gran Maestro. El escenario consiste en retar a dos Gran Maestros a una partida postal, es decir por correo, y hacer el relay (retransmisi´on) de los movimientos entre ellos. La ´unica restricci´on es que en una partida deber´a jugar como Blancas y en la otra como Negras. En la Figura 2.5 se muestra el escenario descrito por Conway, donde el caballo blanco representa el Gran Maestro que juega con blancas, y el negro a su rival. Aunque en realidad est´an jugando entre ellos, ambos creen que su rival leg´ıtimo es el se˜nor del sombrero. La aplicaci´on de este ataque en protocolos de desaf´ıo-respuesta, com´unmente usados en transacciones y pagos, fue descrita por primera vez en [DGB87]. Una cronolog´ıa posterior de los estudios relacionados con ataques de relay en NFC se puede consultar en el Cap´ıtulo 5. El caso particular en NFC pretende explotar la confianza del PCD en que el tag leg´ıtimo se encuentra en su proximidad: el atacante se situar´a en medio de la comunicaci´on suplantando al PICC de cara al PCD, y haciendo creer a la tarjeta que es el lector leg´ıtimo. La principal ventaja es que, al igual que el falso jugador de ajedrez, no es necesario conocer el protocolo de aplicaci´on y cualquier medida de seguridad a ese nivel (como el cifrado) resultar´a in´util. La principal limitaci´on de estos ataques es el delay o retraso introducido durante el relay, ya que algunos protocolos poseen restricciones temporales bastante estrictas. 11 Secci´on 2.4 2. Conocimientos previos Figura 2.5: Escenario de relay en partida de ajedrez postal descrito por Conway. 2.4. Ecosistema Android Android es un sistema operativo m´ovil basado en el Kernel de Linux, actualmente desarrollado por Google y que desde 2011 posee la mayor cuota de usuarios del mercado, siendo instalado en m´as dispositivos que Windows, iOS y Mac OS juntos. Como consecuencia en los ´ultimos a˜nos se ha creado todo un ecosistema a su alrededor. En esta secci´on se van a describir algunos conceptos clave para dar a conocer este entorno al lector. 2.4.1. Dispositivos y software La arquitectura hardware principal de Android es ARMv7 de 32 bits (aunque posteriormente se ha dado soporte a otras arquitecturas como x86 o MIPS), pero al ser un sistema utilizado por un conjunto enorme de dispositivos de diferentes fabricantes, con distintos componentes como aceler´ometros, giroscopios, c´amaras, pantallas t´actiles, etc., han ido apareciendo diferentes ramas del sistema mantenidas ya sea por los propios fabricantes o por comunidades de desarrolladores. El repositorio principal y la base del sistema operativo se encuentra en https:// source.android.com y est´a mantenida por el AOSP (Android Open Source Project) que es liderado por Google. Android ha ido evolucionando con los a˜nos, desde el lanzamiento de una versi´on beta en 2007 hasta la ´ultima versi´on 4.4.4 lanzada el 19 de junio de 2014. Normalmente los dos primeros n´umeros indican la versi´on mayor y suelen tener un nombre; la 4.4, por ejemplo, se llama Kitkat. 12 2. Conocimientos previos Secci´on 2.4 A partir de estos lanzamientos los fabricantes suelen lanzar versiones propias o ROMs, que son las im´agenes del sistema que se instalan en el dispositivo con soporte para componentes particulares y drivers propios. Tambi´en existen modificaciones de Android no oficiales que dan la posibilidad al usuario de utilizar funcionalidades y caracter´ısticas especiales, entre las m´as conocidas est´an: CyanogenMod, AOKP, OmniROM o Paranoid Android. Otra parte fundamental del ecosistema Android es su market, tambi´en conocido como Play Store, donde los desarrolladores pueden subir sus aplicaciones y los usuarios instalarlas muy f´acilmente. Hay que mencionar que tambi´en existen markets no oficiales, como AppBrain o GetJar. 2.4.2. Desarrollo en Android El desarrollo en Android es uno de los puntos fuertes del ´exito del sistema, ya que a pesar de soportar dispositivos tan diferentes ofrece un SDK (Software Development Kit) y un framework con APIs de desarrollo muy bien documentadas2e independientes de la plataforma destino. El lenguaje utilizado es Java aunque a bajo nivel no utiliza su m´aquina virtual (JVM), sino Dalvik, una m´aquina virtual especialmente dise˜nada para la arquitectura Android. A la par que las versiones del sistema operativo, la SDK y la API han ido evolucionando y a˜nadiendo nuevas funcionalidades. Para hacer referencia a la versi´on de la API se habla de niveles, y por ejemplo con Android 4.4 se soporta el Nivel de la API 19. El concepto de nivel permite que un dispositivo pueda utilizar los niveles de API inferiores a su versi´on (se mantiene la compatibilidad hacia atr´as), pero no los superiores. Otro elemento clave es el Manifest de una aplicaci´on, un fichero XML donde el desarrollador debe definir los distintos elementos de ´esta, los permisos que va a requerir y los eventos que quiere ser capaz de escuchar. De este modo, cuando una nueva aplicaci´on es instalada el sistema puede leer este fichero y registrarla correctamente. 2.4.3. Arquitectura Android Como se ha visto Android est´a basado en el Kernel de Linux, aunque actualmente poco tiene que ver el uno con el otro. Las principales diferencias son la implementaci´on de IPC (Inter Process Communication) en Android y el ´enfasis puesto en mejorar el consumo para ahorrar bater´ıa (lo que es cr´ıtico en dispositivos m´oviles). Adem´as Android ofrece un entorno aislado (o sandbox) durante la ejecuci´on de aplicaciones para proteger los datos del usuario, junto con un gestor de permisos que permite a una aplicaci´on utilizar los distintos componentes del sistema (ficheros, c´amara, USB, Internet, etc.). A continuaci´on se describe brevemente c´omo implementa Android los servicios del sistema y c´omo permite a las aplicaciones de usuario comunicarse con ´estos. Para aclarar, los servicios del sistema (79 en la versi´on 4.4) implementan la mayor´ıa de las funcionalidades del n´ucleo de Android, muchas de ellas escritas en Java aunque 2https://developer.android.com/preview/setup-sdk.html 13 Secci´on 3.3 3. An´alisis de NFC en Android lectores). Otra limitaci´on a tener en cuenta es el timeout m´aximo permitido ya que cualquier relay va a incluir un retraso en la comunicaci´on, as´ı que dependiendo de la ventana de tiempo ser´a posible utilizar una comunicaci´on con menor o mayor latencia, que puede traducirse en una mayor o menor distancia. En la mayor´ıa de trabajos mencionados en el Cap´ıtulo 5 se aborda este punto, y aunque los tiempos en ISO 14443-3A (parte de anti-colisi´on y selecci´on) son bastante restrictivos, a nivel ISO 14443-4A la ventana de tiempo puede llegar hasta los 5 segundos, tiempo m´as que suficiente para cualquier canal de relay (ya sea sobre 3G, Bluetooth o WiFi). Para m´as detalle se remite al trabajo de [KH14], donde realizan un an´alisis exhaustivo sobre coste de tiempo y timeouts en distintos canales durante un ataque de relay NFC. A pesar de esto, los dispositivos Android con soporte NFC y versi´on mayor que 4.4 brindan las suficientes caracter´ısticas como para llevar a cabo un ataque de relay a nivel de APDUs (sobre ISO 14443-4). Para implementar el Proxy es necesario HCE (API Level 19) para emular la tarjeta, pero la Mole tan s´olo har´a uso de la clase Tag que se encuentra disponible a partir de la API Level 10. Los conceptos de Proxy y Mole se definen en detalle en el siguiente cap´ıtulo. 20 Cap´ıtulo 4 NFC Leech: dise˜no e implementaci´on El objetivo final de este proyecto es implementar un ataque de relay con una aplicaci´on Android en un dispositivo sin modificar. En el cap´ıtulo anterior se han descrito las limitaciones para llevar a cabo dicho ataque. En este cap´ıtulo se van describir el dise˜no e implementaci´on seguidos para desarrollar la aplicaci´on NFC Leech que permitir´a realizar este ataque de relay. En la fase de an´alisis del problema se fij´o primero la restricci´on de utilizar un dispositivo lo m´as gen´erico posible, de este modo la aplicaci´on podr´a ser accesible a usuarios de cualquier perfil t´ecnico, lo que pone de relieve la gravedad: ya no es necesario utilizar hardware especializado o modificar el software de un dispositivo para realizar un ataque de este tipo. Por otro lado, se requiere una aplicaci´on lo m´as modular posible siendo capaz de utilizar distintos canales de comunicaci´on y que adem´as pueda ser f´acilmente integrada con cualquier otro dispositivo, por ejemplo, en un ordenador con lector de tarjetas NFC. Adem´as se quiere que el usuario pueda visualizar todo el proceso y ver los mensajes enviados y recibidos durante la comunicaci´on. La aplicaci´on pretende servir como prueba de concepto para mostrar c´omo se puede llevar a cabo un ataque de relay real a una tarjeta de cr´edito contactless. El c´odigo no va a hacerse p´ublico, pero se facilitar´a a cualquier persona que quiera estudiarlo, siempre que sea con fines acad´emicos o de investigaci´on. 4.1. Dise˜no Para realizar un buen dise˜no que cumpla con las caracter´ısticas deseadas de modularidad e independencia se han utilizado los patrones de dise˜no: Facade yAdapter. El primero permite gestionar y reducir la complejidad de clases y la estructura orientada a callbacks de las APIs de Android, mediante la divisi´on en subsistemas. El segundo sirve para definir interfaces que ser´an implementadas por los dispositivos espec´ıficos o por los distintos canales, solucionando as´ı los problemas de dependencia. 21 Secci´on 4.1 4. NFC Leech: dise˜no e implementaci´on -channel -timeout +state +init() +stop() +onNfcRequest() +onPeerResponse() +onDisconnect() <<Interface>> Proxy ProxyAndroid -logger +Logger() +write() Logger +onMessage() +sendMessage() +list() +connect() +close() <<Interface>> Channel Bluetooth P2P-WiFi -channel +state +onNfcResponse() +onPeerRequest() +init() +onDisconnect() +stop() <<Interface>> Mole +processCommandApdu(commandApdu : byte[], extras : Bundle) : by... +onDeactivated() android.nfc.cardemulation.HostApduService MoleAndroid +close() +connect() +get(tag : Tag) : IsoDep +getHiLayerResposne() : byte[] +getHistoricalBytes() : byte[] +getMaxTransceiveLength() : int +getTag() : Tag +getTimeout() : int +isConnected() : boolean +isExtendedLengthAdpuSupported() : boolean +setTimeout(timeout : int) : void +transceive(data : byte[]) : byte[] android.nfc.tech.IsoDep TCP/IP <<use>> <<use>> <<use>> <<use>> Figura 4.1: Diagrama de clases general de la aplicaci´on NFC Leech. 22 4. NFC Leech: dise˜no e implementaci´on Secci´on 4.1 A continuaci´on, apoy´andose en la Figura 4.1, se especifican los elementos necesarios para la implementaci´on de la aplicaci´on, as´ı como su uso y la interacci´on con el usuario y entre ellos. Para llevar a cabo el ataque, a nivel de hardware son necesarios dos dispositivos: uno que act´ue como Proxy y otro como Mole, cuyos roles se explican m´as adelante. La aplicaci´on implementa ambas funcionalidades y permite al usuario especificar el modo de funcionamiento en cada ejecuci´on. Tambi´en permite seleccionar el canal de comunicaci´on que debe usarse entre: WiFi-Direct, TCP/IP y Bluetooth, utilizando por defecto WiFiDirect. Esto ´ultimo se ha conseguido utilizando el Adapter y un patr´on Factory para la ejecuci´on de actividades, donde Android lanzar´a una u otra en funci´on de la configuraci´on definida, resultando trivial la inclusi´on de otra interfaz de usuario para un canal nuevo. Una vez seleccionados el modo de trabajo y el canal de comunicaci´on, se establece la conexi´on entre ambas partes mediante sockets. A partir de este punto cada terminal trabaja seg´un su rol: Mole El par que act´ua como Mole permanecer´a a la escucha en el canal de relay hasta que llegue una solicitud, en ese momento se comunicar´a con la tarjeta retransmitiendo la orden y enviar´a la respuesta de la tarjeta, de vuelta al canal de relay. Proxy Por otro lado el par que trabaje como Proxy se mantendr´a a la espera de una solicitud por parte del PCD, al recibirla la retransmitir´a por el canal de relay (momento en el que el PCD empieza a consumir su timeout). Una vez llega la respuesta por el canal de relay la retransmitir´a inmediatamente al PCD, concluyendo as´ı el proceso. En la Figura 4.2 se puede ver la arquitectura de un ataque de relay NFC a nivel ISO 7816-4. En la que se ve el proceso descrito anteriormente donde PCD y Proxy establecen un canal l´ogico sobre NFC (ISO 14443-4), al igual que Mole y PICC, y donde Proxy y Mole se mantienen conectados por otro canal (el de relay) para retransmitir los mensajes. Adem´as, para que el usuario pueda ver todo el proceso en su terminal, cada evento debe generar un registro que sea almacenado y mostrado por pantalla. Dicho registro contiene el tipo de evento, su estado y en caso de ser un mensaje el payload (como su representaci´on hexadecimal). Una de las propuestas de trabajo futuro es realizar un procesado de este contenido seg´un la norma ISO/IEC 7816-4 y el est´andar EMV, para mostrar mensajes m´as legibles y servir en los procesos de depuraci´on de protocolos. 23 Secci´on 4.2 4. NFC Leech: dise˜no e implementaci´on ref ISO/IEC 7816-4 ref ISO/IEC 7816-4 PICC Mole Proxy PCD 3.1: APDU Command response 3: APDU Command response 1.1: APDU Command request 2.1: APDU Command response 2: APDU Command Request 1: APDU Command request Figura 4.2: Arquitectura de relay de APDUs en NFC. 4.2. Implementaci´on 4.2.1. Proxy El Proxy es la pieza clave del escenario y como se ha visto es el encargado de utilizar HCE para trabajar en modo pasivo. Android lo implementa con un servicio que extiende la clase HostApduService, como se ha visto en el Cap´ıtulo 3. Adem´as se ha optado por utilizar un servicio gen´erico RelayService corriendo sobre un thread distinto al principal para evitar congelar la interfaz de usuario. La principal raz´on es que el comportamiento de Proxy y Mole es bastante similar en cuanto a escucha de canales y retransmisi´on de informaci´on aunque usen componentes distintos. En la Figura 4.3 se puede ver un diagrama de la soluci´on descrita. Desafortunadamente Java no soporta herencia m´ultiple, por lo que la implementaci´on se complica un poco. El servicio que extiende a HostApduService debe registrarse en el Manifest de la aplicaci´on junto con los AID a los que quiere responder, y ser´a ejecutado ofreciendo su interfaz a trav´es del m´etodo onBind por el servicio NFC del sistema. La soluci´on utilizada, ha sido crear el servicio ProxyService que corre en background durante todo el relay extendiendo la clase RelayService e implementando el listener, permitiendo la comunicaci´on mediante mensajes con el servicio HCE gracias a la capacidad de reflection de Java. Del mismo modo, el servicio se encargar´a de enviar los registros de cada evento a la actividad principal encargada de su gesti´on. Se ha optado por diferenciar entre 2 tipos de eventos: Comandos; son ´ordenes enviadas desde la actividad o el usuario para iniciar o 24 4. NFC Leech: dise˜no e implementaci´on Secci´on 4.2 +handleMessage() : void +launch() : void RelayService +handleMessage() : void +launch() : void ProxyService LogActivity +processCommandApdu(commandApdu : byte []) : byt... sendResponseApdu(responseApdu : byte[]) : void HostApduService +processCommandApdu(commandApdu : byte []) : byt... ProxyAndroid NfcService System User app <re ection> IPC IPC IPC Figura 4.3: Diagrama del elemento Proxy. detener el servicio. Mensajes; llevan el tipo de informaci´on y datos llegado a trav´es de uno de los canales de comunicaci´on. En el Proxy los mensajes podr´an ser solicitudes del PCD que nos llegan v´ıa NFC o respuestas del tag que nos llegan por el canal de relay. Otra parte importante para que funcione es registrar correctamente los AID que usan las tarjetas bancarias, que dependen de la tarjeta y del fabricante, como se vio en el Cap´ıtulo 2. Brevemente, en el caso particular de los TPV, en lugar de almacenar una lista exhaustiva de AIDs1, utilizan uno para una aplicaci´on especial llamada PPSE (Proximity Payment Systems Environment2), que no es m´as que una interfaz que deben implementar las tarjetas de cr´edito que devuelve la lista de AIDs de la aplicaciones instaladas junto con su prioridad. De este modo, el TPV va a enviar normalmente dos ´ordenes SELECT antes de iniciar la transacci´on, el primero al PPSE y el segundo a la aplicaci´on concreta que tenga registrada la tarjeta objetivo. Por este motivo la aplicaci´on desarrollada, NFC Leech, registrar´a el identificador del PPSE junto con todas las aplicaciones de las tarjetas que quiera soportar. 4.2.2. Mole La Mole es la parte encargada de comunicarse con la tarjeta leg´ıtima, es decir, enviar al tag las ´ordenes que le llegan v´ıa relay y retransmitir las respuestas de vuelta. La implementaci´on es muy parecida al Proxy; el servicio MoleService extiende a la clase RelayService, por lo que se trata de nuevo de un servicio que se ejecuta en background en un hilo independiente y que se comunicar´a mediante paso de mensajes con la actividad de gesti´on de eventos. En este caso es necesario utilizar la clase IsoDep que implementa la tecnolog´ıa ISO 14443-4 y, como se vio en el Cap´ıtulo 3, est´a basada en BasicTechnology. Esta cla1Lista de AIDs: https://en.wikipedia.org/wiki/EMV#Application selection 2AID PPSE: 325041592E5359532E4444463031 25 Secci´on 4.2 4. NFC Leech: dise˜no e implementaci´on +handleMessage() : void +launch() : void RelayService +handleMessage() : void +launch() : void ProxyService LogActivity NfcService -tag : IsoDep MoleAndroid System User app IPC IPC Intent Figura 4.4: Diagrama del elemento Mole. se ofrece un m´etodo transceive que permite enviar una orden APDU y devuelve la respuesta del tag, o lanza una excepci´on en caso de error o timeout. En la Figura 4.4 se describen, igual que en la parte anterior, las clases participantes y su interacci´on. De nuevo surge un problema en la implementaci´on en Android y es que el sistema no permite registrar un servicio para recibir los Intents con el Tag, tan s´olo pueden hacerlo aplicaciones corriendo en foreground. Para solucionarlo se ha implementado una actividad invisible, MoleAndroid, que al recibir el Intent simplemente lo reenv´ıa al servicio mediante un mensaje de broadcast y finaliza. 4.2.3. Canal de retransmisi´on El canal de relay o de retransmisi´on es el encargado de enlazar a Proxy y Mole. Para ello se ha implementado una clase que establece un socket y permite a los pares trabajar tanto de cliente como de servidor, independientemente de su rol. El RelayService ser´a el encargado de iniciar dicha conexi´on y gestionar´a los eventos del canal (nuevo mensaje o fin de comunicaci´on). Se ha puesto especial ´enfasis en hacer esta parte de comunicaci´on independiente del medio utilizado, para ello se ha dise˜nado una interfaz Channel, siguiendo el patr´on Adapter, que deber´a ser implementada por los distintos canales. El usuario podr´a elegir en su configuraci´on a trav´es del men´u de opciones de la aplicaci´on principal, qu´e tipo de canal utilizar y, dependiendo de la selecci´on, al iniciar el proceso se lanzar´a una actividad u otra gracias al uso del patr´on Factory. La configuraci´on define WiFi-Direct como canal de comunicaci´on relay por defecto. WiFi-Direct WiFi-Direct es un protocolo que permite a varios dispositivos WiFi conectarse entre s´ı sin necesidad de un punto de acceso. Las principales ventajas de usar 26 4. NFC Leech: dise˜no e implementaci´on Secci´on 4.2 este canal son dos: La primera es que permite establecer una conexi´on entre dos dispositivos de manera r´apida y sin necesidad de configuraci´on, lo que puede resultar cr´ıtico para llevar a cabo un ataque en un momento puntual. La segunda es que Android ofrece una API3Level 14 basada en callbacks bien documentada y f´acil de utilizar, una vez se entiende su funcionamiento global. Las desventajas: Al utilizar WiFi la distancia entre los dispositivos tiene un l´ımite y suele ser alrededor de los 50 metros. Android ofrece una API basada en callbacks, y puede ser bastante complicado integrarla en una aplicaci´on si no se ha trabajado antes con este paradigma. La implementaci´on ofrece al usuario una interfaz simple donde se listan los dispositivos cercanos y permite establecer una conexi´on mediante un simple clic (v´ease captura derecha de la Figura 4.10). TCP/IP En este modo se permite al usuario utilizar un canal ya establecido por el sistema y simplemente introducir una direcci´on IP y un puerto al que conectarse. Este m´etodo permite realizar una comunicaci´on a trav´es de 3G o de una conexi´on WiFi lo que significa que Proxy y Mole pueden estar separados varios kil´ometros mientras el canal tenga una latencia baja. En [KH14] se presentan datos y un an´alisis detallados de distintas latencias en diferentes canales en relaci´on a los l´ımites que se describen a continuaci´on. En la ecuaci´on 4.1 se definen las f´ormulas del Frame Delay Time (FDT), que es el tiempo entre dos frames durante las fases de inicializaci´on y anti-colisi´on. El FDT m´aximo es 86.4 µs. F DT =n·128 + 20 fc (4.1) Durante la configuraci´on del canal se calcula el Frame Waiting Time (FWT), que ser´a el tiempo de espera del PCD para una respuesta. Est´a descrito en la ecuaci´on 4.2 a partir del campo FWI que se define mediante la orden ATS, como se vio en la Secci´on 2.1. El est´andar permite valores entre 302 µs y 4989 ms, un margen muy grande para el relay. Adem´as se define un Waiting Time Extension (o WTX) para que el PICC solicite tiempo extra al PCD durante operaciones computacionalmente costosas, de este modo el timeout puede extenderse ilimitadamente. FWT = 256 ·(16 fc )·2F W I ,0≤FWI ≤14 (4.2) 3https://developer.android.com/guide/topics/connectivity/wifip2p.html 27 Secci´on 4.2 4. NFC Leech: dise˜no e implementaci´on Figura 4.5: Ejemplo de ataque de relay NFC; una tarjeta a N sitios. Tambi´en permite conectar de manera sencilla la aplicaci´on m´ovil con cualquier otro dispositivo conectado a Internet, y gracias a la interfaz Channel se puede implementar un wrapper en Java para enviar y recibir mensajes utilizando el hardware NFC de un dispositivo cualquiera. La desventaja es que requiere una IP p´ublica y m´as tiempo de configuraci´on, pero dependiendo del escenario ser´a una soluci´on adecuada. Un ejemplo puede ser el caso de dejar una tarjeta cerca de un dispositivo fijo que act´ue como Mole y crear un canal de relay desde un m´ovil (Proxy) a ´este, as´ı la tarjeta podr´ıa ser usada por distintas personas desde distintos lugares a la vez. Esto podr´ıa usarse para, entre muchas otras cosas, hacer realmente complicado el rastreo de una tarjeta. En la Figura 4.5 se describe este escenario de ataque. El caso contrario tambi´en puede resultar interesante si se imagina, por ejemplo, un software malicioso que convierte los dispositivos infectados en Proxies NFC. El criminal podr´ıa utilizar un dispositivo como Mole y su botnet para pagar en casi cualquier momento ya que las posibilidades de que al menos un dispositivo infectado este cerca de una tarjeta en un momento dado son bastante altas. En la Figura 4.6 se puede ver el ejemplo de este escenario de ataque. Bluetooth Este canal no se ha llegado a implementar, pero se deja para mejoras futuras. La idea es utilizar otro medio como Bluetooth que de nuevo permite una configuraci´on r´apida y sencilla para dispositivos cercanos (hasta 30 metros), y que adem´as tiene buen soporte por parte de Android. Especialmente a partir de Android 4.3 (API Level 18), que al dar soporte a BLE (Bluetooth Low Energy) puede suponer una mejora considerable en el consumo de bater´ıa, lo que resulta un aspecto cr´ıtico en dispositivos m´oviles. 28 4. NFC Leech: dise˜no e implementaci´on Secci´on 4.3 MOLE BOT MOLE BOT MOLE BOT MOLE BOT MOLE BOT MOLE BOT BOTNET PROXY Figura 4.6: Ejemplo de ataque de relay NFC; botnet de tarjetas de pago. 4.3. Prueba de concepto La aplicaci´on llevada a cabo ha resultado de una complejidad alta ya que ha sido necesaria la interacci´on entre distintos m´odulos y APIs, por lo que el autor ha tenido que aprender a programar en Android. Al final se ha implementado la aplicaci´on llamada NFC Leech, capaz de realizar un ataque de relay NFC con dispositivos Android en un escenario de cobro con una tarjeta de cr´edito contactless. Para llevar a cabo las pruebas se han utilizado: Dos dispositivos m´ovil Android (v´ease la Figura 4.7) con soporte NFC (uno de ellos con versi´on ≥4.4). Un TPV (Terminal Punto de Venta) Ingenico IWL8280, que se muestra en la Figura 4.8, con soporte contactless (la mayor´ıa de comercios los utilizan ya), proporcionando la capacidad de realizar pruebas de pago reales en un entorno controlado. Una tarjeta de cr´edito MasterCard del Banco Sabadell (las tarjeta nuevas de Banco Sabadell, BBVA, Bankia y Santander ya soportan NFC; al lado del chip hay un dibujo de ondas de radiofrecuencia, como se ve en la Figura 4.9), que permite el pago sin contacto para transacciones menores de 20 euros, sin solicitar el c´odigo de seguridad o PIN. 29 5. Trabajo relacionado Phone A (Proxy A realiza el proceso an´alogo). Todos son dispositivos basados en Symbian S40 y utilizan una aplicaci´on Java usando las API del fabricante para comunicaciones NFC peer-to-peer y Bluetooth (para el canal de relay). El experimento les permite hacer un relay completo de una comunicaci´on NFC P2P, y proponen utilizar un tercero de confianza para confirmar la localizaci´on de los dispositivos evitando as´ı el ataque. A partir de aqu´ı se ve la tendencia de que a medida que los fabricantes hacen sus dispositivos m´as accesibles y liberan APIs para el desarrollo de aplicaciones NFC, los m´oviles se convierten en herramientas de ataque tan potentes como cualquier dispositivo especializado. De nuevo el objetivo es distinto del propuesto en este trabajo, pero podr´ıa considerarse otro caso de estudio el trasladar un ataque de relay NFC P2P a Android, ya que todav´ıa no se ha hecho. Mayo de 2010 En [Wei10] se presenta uno de los trabajos m´as completos en seguridad NFC y ataques de relay. En ´el se describen distintas arquitecturas de ataques de relay y sus limitaciones, para finalmente implementar un ataque de relay con un dispositivo Nokia 6121 Classic NFC como Mole, y una placa Beagle Board con Android conectada a un USB NFC (compatible con libnfc1, que s´ı permitir enviar ´ordenes ISO 14443-3A raw) como Proxy. Sin embargo, el relay queda restringido a ISO 14443-4, debido a las limitaciones de tiempo de ISO 14443-3A y a que la API de Nokia s´olo soporta trabajar con APDUs. En cualquier caso el trabajo realizado por Weiss es sobresaliente adem´as de pionero, aunque lamentablemente todav´ıa no resulta posible utilizar tan s´olo dispositivos m´oviles. Febrero de 2012 En [FHM+12] presenta el primer ataque de relay est´andar utilizando tan s´olo dispositivos m´oviles, como ya se hab´ıa vaticinado. Debido a la explosi´on de dispositivos m´oviles con soporte NFC como el Nokia C7, RIM Blackberry 9900/9930 o el Google Nexus S, los fabricantes apuestan por dar m´as libertad a los desarrolladores de aplicaciones con el soporte a emulaci´on de tags v´ıa software. El primer ejemplo es la Blackberry 9900, aunque tambi´en es posible utilizar un Google Nexus S con un firmware modificado2. Adem´as empiezan a aparecer sistemas de pago NFC con dispositivos m´oviles como Google Wallet u Orange QuickTap. Este ataque (v´ease la Figura 5.4), consigue realizar un relay a nivel de APDUs igual que en el trabajo que aqu´ı se presenta, pero se trata de dispositivos concretos con una menor cuota de mercado y, sobretodo, con una dificultad alta para la instalaci´on de aplicaciones, con lo que todav´ıa resulta poco pr´actico. Junio de 2012 Douge Yeager realiza dos commits3,4 en CyanogenMod 9, consiguiendo 1https://code.google.com/p/libnfc/ 2http://www.nfcworld.com/2011/02/13/35913/ 3https://github.com/CyanogenMod/android frameworks base/commit/c80c15bed5b5edffb61eb543e31f0b90eddcdadf 4https://github.com/CyanogenMod/android external libnfc-nxp/commit/34f13082c2e78d1770e98b4ed61f446beeb03d88 36 5. Trabajo relacionado Figura 5.4: Ataque relay NFC con Nokia y Blackberry. as´ı soporte para emulaci´on software de tarjetas en dispositivos Android (con chip de NXP semiconductors). A ra´ız de este trabajo, Eddie Lee presenta en DEFCON 20 [Lee12] la herramienta NFC Proxy, que permite a cualquier persona con un dispositivo m´ovil NFC Android y una versi´on de CyanogenMod +10 instalada realizar ataques de relay de APDUs. En este caso el impacto es mayor y queda clara la aplicaci´on pr´actica y la facilidad con que se puede implementar el ataque, pero sigue siendo necesario utilizar una ROM modificada, lo que restringe la distribuci´on a diferencia de NFC Leech. Octubre de 2013 Desde la modificaci´on de CyanogenMod han hecho falta casi dos a˜nos hasta que Android diera soporte nativo a la emulaci´on por software con el lanzamiento de la versi´on 4.4 (KitKat)5. HCE (Host Card Emulation) permite a los desarrolladores programar aplicaciones m´oviles que act´uen como elemento pasivo a nivel de ISO 14443-4 (IsoDep), emulando tarjetas inteligentes que sigan el est´andar ISO/IEC 7816-4. Sin embargo, HCE sigue teniendo dos limitaciones: Requiere que el lector env´ıe una orden SELECT AID expl´ıcito para seleccionar la aplicaci´on de la tarjeta con la que se quiere comunicar. La aplicaci´on Android debe registrar en su Manifest la lista de AIDs a los que responder. Diciembre de 2013 Johannes Zweng publica en el foro XdaDevelopers un m´odulo [Zwe13] para Xposed que permite redirigir todos los APDUs (u ´ordenes ISO/IEC 7816-4) entrantes a una aplicaci´on concreta. Aunque para usarlo es necesario tener un dispositivo rooteado y el framework instalado. A ra´ız de esto en abril de 2014 aparece en el Play Store una aplicaci´on llamada NFCSpy6que adem´as de utilizar opcionalmente este m´odulo, implementa un relay NFC para observar la comunicaci´on entre una tarjeta y un terminal. ´ Esta es la primera demostraci´on pr´actica de un ataque de relay NFC utilizando s´olo dispositivos Android de serie y su impacto es cr´ıtico, ya que cualquier usuario con un m´ovil Android y soporte NFC puede instalar la aplicaci´on con un simple clic. 5https://developer.android.com/about/versions/kitkat.html 6https://play.google.com/store/apps/details?id=com.sinpo.nfcspy 37 5. Trabajo relacionado NFC Leech implementa el mismo ataque como prueba de concepto, utilizando un dise˜no m´as gen´erico que permita, adem´as de distintos canales de comunicaci´on, una f´acil integraci´on con otros dispositivos para poder llevar a cabo ataques m´as elaborados. Sin embargo a d´ıa de hoy todav´ıa no se ha conseguido llevar a cabo un ataque de relay a nivel ISO 14443-3A con dispositivo Android por defecto. Este trabajo quiere servir de base para explorar las posibles v´ıas que pueden llevar a dar este salto. Tambi´en cabe mencionar que la mayor´ıa de trabajos describe mecanismos de defensa ante los ataques de relay, generalmente mediante protocolos de distance bounding que intentan medir la distancia real entre el lector y tag leg´ıtimo a trav´es de otros canales o de terceros (como GPS). En resumen, las principales ventajas de NFC Leech respecto a los trabajos anteriores son: 1. Utiliza dispositivos m´oviles sin necesidad de hardware adicional. 2. Al ser una aplicaci´on Android que utiliza la API p´ublica, es compatible con cualquier dispositivo comercial que soporte NFC y su instalaci´on y distribuci´on pueden ser extremadamente sencillas gracias a los markets. 3. Gracias a su dise˜no puede ser f´acilmente integrada con otras plataformas para construir escenarios de ataque m´as elaborados. Por contra, la mayor desventaja es que el relay NFC con un dispositivo Android sigue restringido a la tecnolog´ıa IsoDep, lo que limita su uso en tarjetas que sigan protocolos propietarios. 38 Cap´ıtulo 6 Conclusi´on y l´ıneas futuras En este ´ultimo cap´ıtulo se presentan los resultados y conclusiones del proyecto, as´ı como sus implicaciones. Adem´as, se plantean posibles l´ıneas futuras de trabajo. A lo largo de este trabajo se ha realizado un an´alisis de la implementaci´on NFC en Android obteniendo sus posibilidades y limitaciones para llevar a cabo ataques de relay o retransmisi´on sobre NFC. Adem´as se ha conseguido implementar exitosamente la aplicaci´on NFC Leech haciendo posible realizar el ataque en un escenario real de pago con tarjetas de cr´edito. La tendencia actual parece indicar que las aplicaciones m´oviles y el pago con ´estas v´ıa NFC va a crecer en los pr´oximos a˜nos y, al igual que con sus predecesores, se van a convertir en un objetivo para las mafias del fraude y la industria del software malicioso. Habi´endose demostrado que no hacen falta grandes recursos ni hardware especializado para llevar a cabo un ataque, el problema resulta todav´ıa m´as cr´ıtico. De hecho, puede que en los pr´oximos meses algunos de los escenarios de ataque que se han presentado aqu´ı acaben convirti´endose en realidad. Por este motivo hay que insistir y recordar que los nuevos sistemas o tecnolog´ıas no pueden sacrificar su seguridad, aunque como en este caso aporten mayor comodidad a los usuarios para realizar peque˜nos pagos. Con este proyecto se pretende poner de relieve el problema de las tarjetas NFC y, en la medida de lo posible, alertar a usuarios y consumidores para evitar posibles da˜nos. Es necesario recordar que a pesar de que los fabricantes pueden implantar medidas de seguridad a d´ıa de hoy, el problema radica en que ´estos y las entidades bancarias ya han realizado una inversi´on y hasta que no obtengan un retorno, seguramente se tenga que convivir con este defecto. 6.1. L´ıneas de investigaci´on futuras Debido a la diversidad de temas estudiados y aprendidos para llevar a cabo este trabajo, en algunos puntos no se ha podido profundizar tanto como al autor le hubiera gustado. Por ese motivo en este apartado se enumeran las posibles l´ıneas de investigaci´on futuras que podr´ıa ser interesante llevar a cabo. 39 Secci´on 6.1 6. Conclusi´on y l´ıneas futuras Posibilidades de configuraci´on con NCI: Investigar las posibilidades de configuraci´on del NFCC a trav´es de la NCI. De este modo podr´ıan extenderse las capacidades del dispositivo m´ovil sin m´as necesidad que un dispositivo con permisos de super-usuario, aunque posiblemente har´ıa falta realizar ingenier´ıa inversa. Custom firmware:Modificar el firmware del NFCC. Esta soluci´on es la m´as radical y ser´ıa completamente dependiente del hardware, pero realizar ingenier´ıa inversa y modificar el binario ser´ıa la manera de conseguir mayor control sobre el dispositivo. El objetivo deber´ıa centrarse en la parte de interfaces que se explic´o en el Cap´ıtulo 3 para conseguir que el dispositivo pueda enviar ´ordenes directamente sobre ISO 14443-3. Con esta soluci´on se podr´ıa intentar emular protocolos propietarios y, tal vez, dar soporte a los dispositivos con chip BCM para tarjetas Mifare, que nativamente no est´an soportadas. Librer´ıa Java para NFC Relay:En el desarrollo de la aplicaci´on se puso especial inter´es en un dise˜no modular, otra l´ınea interesante ser´ıa mejorar dichas interfaces Java y ofrecer una peque˜na librer´ıa que permita la integraci´on de aplicaciones relay NFC independientemente del dispositivo (ya sean Androids con una ROM modificada, PCs, etc.). Procesamiento de mensajes APDU: Aunque la aplicaci´on desarrollada muestra el contenido de los mensajes (´ordenes y respuestas) entre el PCD y el tag, ser´ıa interesante llevar a cabo un procesamiento de los mensajes y mostrar al usuario informaci´on m´as legible que facilite, por ejemplo, la comprensi´on de ´ordenes EMV y la f´acil depuraci´on de aplicaciones NFC. An´alisis de seguridad de aplicaciones bancarias NFC: Los bancos espa˜noles est´an lanzando versiones de prueba de sus monederos digitales, con lo que ser´ıa interesante realizar un estudio comparativo de las distintas implementaciones y vulnerabilidades en ´estas. Vectores de explotaci´on y software malicioso: Inspecci´on y an´alisis de muestras de software malicioso para dispositivos m´oviles, viendo su uso de las caracter´ısticas NFC, as´ı como la documentaci´on de posibles ataques todav´ıa no explotados. 40 Acr´onimos AID Application Identifier. AOSP Android Open Source Project. APDU Application Protocol Data Unit. API Application Programming Interface. ATM Automated Teller Machine. ATQ Answer to Request. ATS Answer To Select. BLE Bluetooth Low Energy. CRC Cyclic Redundancy Check. DH Device Host. EMV Europay, MasterCard y Visa. HCE Host Card Emulation. IEC International Electrotechnical Comission. IPC Inter Process Communication. ISO International Organization for Standardization. JVM Java Virtual Machine. NCI NFC Controller Interface. NFC Near Field Communication. NFCC NFC Controller. 41 Siglas Siglas NFCEE NFC Execution Environment. P2P Peer-to-Peer. PCD Proximity Coupling Device. PFC Proyecto de Fin de Carrear. PICC Proximity Integrated Circuit Card. PIX Propietary Identifier Extension. POS Point of Sale. PPS Protocol and Parameter Selection. PPSE Proximity Payment Systems Environment. RATS Request ATS. RF Radio Frequency. RFID Radio Frequency IDentification. RID Registered Application Provider Identifier. ROM Read-Only Memory. SDK Software Kit Development. TPV Terminal Punto de Venta. 42 Bibliograf´ıa [CON76] J. H. CONWAY. On Numbers and Games. Academic Press, 1976. [DGB87] Yvo Desmedt, Claude Goutier, and Samy Bengio. Special Uses and Abuses of the Fiat-Shamir Passport Protocol. In CRYPTO, pages 21–39, 1987. [DM07] Saar Drimer and Steven J. Murdoch. Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks. In Proceedings of 16th USENIX Security Symposium on USENIX Security Symposium, SS’07, pages 7:1–7:16, Berkeley, CA, USA, 2007. USENIX Association. [FHM+12] Lishoy Francis, Gerhard Hancke, Keith Mayes, Konstantinos Markantonakis, and Information Security Group. Practical Relay Attack on Contactless Transactions by Using NFC Mobile Phones. IACR Cryptology ePrint Archive, 2012. [FHMM10] Lishoy Francis, Gerhard Hancke, Keith Mayes, and Konstantinos Markantonakis. Practical NFC Peer-to-Peer Relay Attack Using Mobile Phones. In SiddikaBerna Ors Yalcin, editor, Radio Frequency Identification: Security and Privacy Issues, volume 6370 of Lecture Notes in Computer Science, pages 35– 49. Springer Berlin Heidelberg, 2010. [For] NFC Forum. NFC Forum Technical Specifications. Available at http:// nfc-forum.org/our-work/specifications-and-application-documents/ specifications/nfc-forum-technical-specifications/. [Goo14] Google. Android developers, 01 2014. http://developer.android.com/ reference/. [Han05] Gerhard Hancke. A practical relay attack on ISO 14443 proximity cards. Technical report, 2005. [How08] HowToWired. Make a Faraday Cage Wallet, 2008. [ISO10a] Identification cards – Contactless integrated circuit cards – Proximity cards. Part 2: Radio frequency power and signal interface, 2010. Available at http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ detail_ics.htm?csnumber=39693. 43 BIBLIOGRAF´ IA BIBLIOGRAF´ IA [ISO10b] Identification cards – Contactless integrated circuit cards – Proximity cards. Part 4: Transmission protocol, 2010. Available at http://www.iso.org/iso/ iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50648. [ISO11] Identification cards – Contactless integrated circuit cards – Proximity cards. Part 3: Initialization and anticollision, 2011. Available at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_ detail.htm?csnumber=50942. [ISO13] Identification cards – Contactless integrated circuit cards – Proximity cards. Part 1: Physical characteristics, 2013. Available at http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ detail_ics.htm?csnumber=39693. [KH14] Thomas Korak and Michael Hutter. On the Power of Active Relay Attacks using Custom-Made Proxies. In IEEE, editor, 2014 IEEE International Conference on RFID (IEEE RFID) (IEEE RFID 2014), 2014. in press. [KW05] Ziv Kfir and Avishai Wool. Picking Virtual Pockets using Relay Attacks on Contactless Smartcard Systems. IACR Cryptology ePrint Archive, 2005:52, 2005. [Lee12] Eddie Lee. NFC Hacking: The easy way. 2012. [Sem11] NXP Semiconductors. Mifare classic 1k - mainstream contactless smart card ic for fast and easy solution development, 2011. [Wei10] Michael Weiß. Performing Relay Attacks on ISO 14443 Contactless Smart Cards using NFC Mobile Equipment. Master’s thesis, Technische Universit¨at M¨unchen, May 2010. [Zwe13] Johannes Zweng. Xposed Module NFC AID Re-Routing - https://github.com/johnzweng/XposedModifyAidRouting, October 2013. 44 Ap´endice A Horas de trabajo Para el control del tiempo se utiliz´o una hoja de c´alculo, se puede ver el tiempo dedicado en la Figura A.1 en forma de diagrama de Gantt. La primera fase es el an´alisis y estudio del entorno en el campo de la seguridad RFID, necesario para poder decidir el alcance del proyecto. Una vez completo se llev´o a cabo la parte m´as costosa: la fase de investigaci´on y formaci´on, donde se requer´ıan una gran cantidad de conocimientos previos al tener que lidiar con un conjunto muy amplio de tecnolog´ıas y especificaciones. Una vez llevado a cabo el an´alisis y definidos los objetivos se aprendieron las nociones de programaci´on en Android necesarias para desarrollar la aplicaci´on NFC Leech. Los dos ´ultimos meses se realiz´o el desarrollo de la aplicaci´on y la elaboraci´on de la memoria, junto con las pruebas en un escenario real con un TPV y una tarjeta de cr´edito contactless. Al final de estos seis meses, se ha estimado un coste aproximado de 550 horas de trabajo entre las distintas fases de este proyecto. Lo que sobrepasa un poco la estimaci´on inicial, pero que ha sido necesario dada la extensi´on de los conocimientos previos necesarios. Figura A.1: Diagrama de Gantt mostrando el esfuerzo invertido en semanas. 45 B. Mensajes de configuraci´on NCI RFU 0x86-0x9F Reserved for Proprietary Use Reserved 0xA0-0xFE Reserved for Extension RFU 0xFF 52 B. Mensajes de configuraci´on NCI Tabla B.4: C´odigos de estado. Extra´ıdo de la “NCI Technical Specification”del NFC Forum. Status code Description Generic Status Codes 0x00 STATUS OK 0x01 STATUS REJECTED 0x03 STATUS FAILED 0x04 STATUS NOT INITIALIZED 0x05 STATUS SYNTAX ERROR 0x06 STATUS SEMANTIC ERROR 0x07-0x08 RFU 0x09 STATUS INVALID PARAM 0x0A STATUS MESSAGE SIZE EXCEEDED 0x0B-0x10 RFU 0x11 STATUS OK 1 BIT 0x12 STATUS OK 2 BIT 0x13 STATUS OK 3 BIT 0x14 STATUS OK 4 BIT 0x15 STATUS OK 5 BIT 0x16 STATUS OK 6 BIT 0x17 STATUS OK 7 BIT 0x18-0x9F RFU RF Discovery Specific Status Codes 0xA0 DISCOVERY ALREADY STARTED 0xA1 DISCOVERY TARGET ACTIVATION FAILED 0xA2 DISCOVERY TEAR DOWN 0xA30xAF RFU RF Interface Specific Status Codes 0x02 RF FRAME CORRUPTED 0xB0 RF TRANSMISSION ERROR 0xB1 RF PROTOCOL ERROR 0xB2 RF TIMEOUT ERROR 0xB3 RF UNEXPECTED DATA 0xB4-0xBF RFU NFCEE Interface Specific Status Codes 0xC0 NFCEE INTERFACE ACTIVATION FAILED 0xC1 NFCEE TRANSMISSION ERROR 0xC2 NFCEE PROTOCOL ERROR 0xC3 NFCEE TIMEOUT ERROR 0xC4-0xDF RFU Proprietary Status Codes 0xE0-0xFF For proprietary use 53 B. Mensajes de configuraci´on NCI 54 Ap´endice C Traza de una llamada transceive en Android con NfcA En este apartado se detalla la implementaci´on a trav´es de las distintas llamadas que se ejecutan en Android a partir del m´etodo transceive de un tag con tecnolog´ıa NfcA. De este modo el lector podr´a sumergirse en el c´odigo de bajo nivel con mayor facilidad, ya que conseguir´a una visi´on global del proceso. La clase Tag es la base que expone la API para comunicarse con una tarjeta cercana. Tiene un campo INfcTag mTagService de tipo IBinder (una interfaz a un objeto remoto en Android), que es usado por la clase BasicTechnology sobre la que se implementan todas las tecnolog´ıas del siguiente modo: C´odigo C.1: Tag.java byte [ ] t r a n s c e i v e ( byte [ ] data , boolean raw ) { ... mTag . g etT agS erv ice ( ) . t r a n s c e i v e (mTag . g et Serv ic eH and le ( ) , data , raw ) ; ... } Nota: El booleano raw es ignorado en la implementaci´on de libnfc-nci, mientras que en libnfc-nxp la utilizan para el env´ıo de ´ordenes a las tarjetas Mifare Classic. De modo que al llamar a transceive en realidad se realiza una invocaci´on remota mediante IPC (la propia clase INfcTag es autogenerada a partir de un fichero AIDL1, cuya implementaci´on se encuentra en la clase TagService de NfcService.java2que es el servicio NFC del sistema. La Figura C.1 describe la implementaci´on descrita. TagService mantiene un objecto TagEndpoint que referencia a la tarjeta remota, dicha clase es tan s´olo una interfaz en DeviceHost.java3y su implementaci´on va a 1https://android.googlesource.com/platform/frameworks/base/+/android4.4.1 r1.0.1/core/java/android/nfc/INfcTag.aidl 2https://android.googlesource.com/platform/packages/apps/Nfc/+/android4.4.1 r1.0.1/src/com/android/nfc/NfcService.java 3https://android.googlesource.com/platform/packages/apps/Nfc/+/android4.4.1 r1.0.1/src/com/android/nfc/DeviceHost.java 55 C. Traza de una llamada transceive en Android con NfcA NfcService.java Tag.java INfcTag.java - mTagService DeviceHost.java TagService extends INfcTag.Stub Interface TagEndpoint - transceive NativeNfcTag.cpp - NFA_sendRawFrame JNI InfcTag . transceive - tag NativeNfcTag.java NativeNfcTag implements TagEndpoint - doTransceive nativeNfcTag_doTransceive User App Application framework Library Figura C.1: Arquitectura de la implementaci´on Tag en la API de Android. depender del fabricante, seg´un use libnfc-nxp olibnfc-nci. En nuestro caso, encontramos la implementaci´on en NativeNfcTag.java que va a utilizar JNI para llamar al m´etodo doNative implementando en NativeNfcTag.cpp. A partir de aqu´ı se entra en otro nivel, donde se puede ver el predicado de la funci´on en C++: C´odigo C.2: NativeNfcTag.cpp static jbyteArray nativeNfcTag doTransceive ( JNIEnv∗e , j o bj ec t , jbyteArray data , jbool e an raw , j int Arr ay statusTargetLost ) ; Tras comprobar el estado de la tarjeta y definir un timeout se invoca a la funci´on NFA SendRawFrame, pasando el buffer con el payload original. Este proceso se repite a lo largo de varios niveles descendiendo por los distintos m´odulos. Al tener varios hilos y capas, la librer´ıa libnfc-nci implementa un mecanismo de colas de eventos y paso de mensajes fiable llamado GKI (General Kernal Interface) 4, que sirve de abstracci´on entre capas permitiendo una mayor independencia entre m´odulos. B´asicamente cada tarea tiene un buffer (o buz´on de entrada) de mensajes, estos mensajes ser´an procesados seg´un su campo de evento y as´ı el payload ir´a avanzando hasta el NFCC. Esta arquitectura facilita la gesti´on as´ıncrona del proceso. C´odigo C.3: Traza de una operaci´on transceive. D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 2 7( 0 x1b ) by te s , e r r n o=0 c oun t =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p buf=0x 74f865ec , count =1, l ength =27 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74f86bd0 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 I / NfcNciHal ( 87 0) : n f c h a l d m s e t n f c w a k e ( ) ASSERT D/USERIAL LINUX( 870) : UPIO Set : i o c t l , s t a t e=0 D/USERIAL LINUX( 870) : UPIO Set : i o c t l , old s t a t e =1, i n s e r t de lay f o r 20 ms 4https://android.googlesource.com/platform/external/libnfc-nci/+/master/src/gki/ 56 C. Traza de una llamada transceive en Android con NfcA D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =26 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n =26 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 4 (IDLE )−>5 (OPEN) I /BrcmNfcNfa ( 870 ) : n f c n c i f p r o c a c t i v a t e : 2 3 0 , mode : 0 x00 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4004 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : DISCOVERY ( 1 ) , ev e nt : ACTIVATED NTF( 5 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70 ) : n f a d m d i s c n e w s t a t e ( ) : o l d s t a t e : DISCOVERY ( 1 ) , n ew s t ate : POLL ACTIVE ( 4 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 870) : n f a d m d i s c n o t i f y a c t i v a t i o n ( ) : tech n mode : 0 x0 , proto : 0 x2 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c g e t d i s c m a s k ( ) : t ech n mode : 0 x0 , p r o t o c o l : 0 x2 , dis c m as k : 0 x2 I / BrcmNfcNfa ( 870) : a c t i v a t e d p r o t o c o l : 0 x2 , a ct iv at e d h a nd le : 0 x1 I /BrcmNfcNfa ( 870 ) : n f a d m p o l l d i s c c b a c k ( ) : eve nt : 0 x01 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW ACTIVATE NTF EVT ( 0 x601 ) , f l a g s : 00000001 I /BrcmNfcNfa ( 870) : n f a r w a c t i v a t e n t f I /BrcmNfcNfa ( 8 70) : RW SetActivatedTagType p r o t o c o l : 2 , t ec h no l og y : 0 , SAK: 0 I / BrcmNfcNfa ( 870) : n f a d m n o t i f y a c t i v a t i o n s t a t u s ( ) : s ta t u s : 0 x0 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 5 D/ BrcmNfcJni ( 870) : nf aCon ne ctio nCall back : NFA ACTIVATED EVT: g I s S e l e c t i n g R f I n t e r f a c e =0, s I s D i s a b l i n g =0 D/ BrcmNfcJni ( 870) : NfcTag : : s e t A c t i v a t i o n S t a t e : s t a t e =2 D/ BrcmNfcJni ( 87 0) : p n5 4 4I n te r op I sB u sy : 0 D/ BrcmNfcJni ( 8 70 ) : NfcTag : : IsSameKovio : e n t e r D/ BrcmNfcJni ( 87 0) : NfcTag : : d i s c o v e r T e c h n o l o g i e s ( a c t i v a t i o n ) : e nt er D/ BrcmNfcJni ( 87 0) : NfcTag : : d i s c o v e r T e c h n o l o g i e s ( a c t i v a t i o n ) : ind ex =0; t ec h =1; h andle =1; n f c type=2 D/ BrcmNfcJni ( 87 0) : NfcTag : : d i s c o v e r T e c h n o l o g i e s ( a c t i v a t i o n ) : ind ex =1; t ec h =9; h andle =1; n f c type=2 D/ BrcmNfcJni ( 87 0) : NfcTag : : d i s c o v e r T e c h n o l o g i e s ( a c t i v a t i o n ) : e x i t D/ BrcmNfcJni ( 8 70 ) : NfcTag : : c r ea te N at i ve Nf c Ta g : e n t e r D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 1 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 2 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 3 : i n de x =0; r f t ec h params mode=0 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 3 : t e ch A D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 3 : i n de x =1; r f t ec h params mode=0 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 3 : t e ch A D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 4 : i n de x=0 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 4 : T2T ; t e c h A D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 4 : i n de x=1 D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 4 : T2T ; t e c h A D/ BrcmNfcJni ( 87 0) : NfcTag : : f il l Na t iv eN f cT a gM em b er s 5 : t e ch A D/ BrcmNfcJni ( 8 70) : NfcTag : : c rea teNa tiv eNfc Tag : try n o t i f y n f c s e r v i c e D/ audio hw prima ry ( 17 5) : o u t s e t p a r a m e t e r s : e nt er : u s ec ase ( 1 : low−latency−pl ayb ac k ) k v p a i r s : r o u t i n g =2 D/ NativeNfcTag ( 870) : Connect to a tech with a d i f f e r e n t handle D/ BrcmNfcJni ( 87 0) : n at iv eN fc Ta g do Ha nd leR ec on ne ct : t a r g e tH a n d le = 0 D/ BrcmNfcJni ( 87 0) : n at iv eNf cT ag d oC on nec t : t a r ge t H a n dl e = 0 D/ BrcmNfcJni ( 870) : nativeNfcTag doConnect ( ) Nfc type = 2 , do not hin g f o r non ISO DEP D/ BrcmNfcJni ( 870) : nativeNfcTag doConnect : e x i t 0 x0 D/BrcmNfcJni( 870) : nativeNfcTag doIsIsoDepNdefFormatable D/ BrcmNfcJni ( 870) : NfcTag : : i s M i f a r e U l t r a l i g h t : r eturn=1 D/ BrcmNfcJni ( 8 70 ) : n at iv e Nf c Ta g d o Is Nd e fF or m at ab l e : i s f o r m a t t a b l e=1 D/ BrcmNfcJni ( 8 70 ) : n at iv eN fcTa g do Re co nn ec t : e n t e r D/ BrcmNfcJni ( 8 70 ) : r e S e l e c t : e n t e r ; r f i n t f = 1 , c u r r e n t i n t f = 1 D/ BrcmNfcJni ( 87 0) : r e S e l e c t : d e a c t i v a t e to s l e e p I /BrcmNfcNfa ( 8 70) : NFA Deactivate ( ) : s le ep m od e : 1 D/ BrcmNfcJni ( 870) : NfcTag : : crea teNat ive NfcTa g : e x i t I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x1 I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0113 I / BrcmNfcNfa ( 87 0) : n f a d m e v t h d l r e ve nt : NFA DM API DEACTIVATE EVT ( 0 x13 ) I /BrcmNfcNfa ( 8 70) : n f a d m a c t d e a c t i v a t e ( ) D/ audio hw primary ( 175) : s e l e c t d e v i c e s : o ut s n d d e v i ce ( 2 : s pe ake r ) i n s n d d e v i c e ( 0 : ) D/ACDB−LOADER( 1 75) : ACDB −>send afe cal I /BrcmNfcNfa ( 870) : n f a d m r f d e a c t i v a t e ( ) d e a c t i v a t e t y p e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE CMD ( 6 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70) : NFC Deactivate 5 (OPEN) d e a c t i v a t e t y p e : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 5 (OPEN)−>6 (CLOSING) I / BrcmNfcNfa ( 870) : a c t p r o t o c o l 2 c r e d i t s : 1/1 D/ NfcAdaptation ( 870) : NfcAdaptation : : HalWrite D/ N fcNciHal ( 87 0) : HaiWri te : e n t e r ; l e n =4 I / NfcNciHal ( 87 0) : HAL NfcWrite ( ) D/ NfcNciHal ( 870) : HaiWrite : e x i t 0 I / N fcNc iHal ( 87 0) : n f c h a l m a i n s e n d m e s s a g e ( ) l s : 0 x10 I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 0 I / NfcNciHal ( 870) : p buf−>l e n : 4 D/USERIAL LINUX( 870) : USERIAL Write : (5 byt e s ) D/USERIAL LINUX( 870) : USERIAL Write l en = 5 , r e t = 5 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t a r t t i m e r 74 df0 b5c I /BrcmNfcNfa ( 870) : ptim tim er s t a r t I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x61 57 C. Traza de una llamada transceive en Android con NfcA D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 5 (0 x5 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f86bc8 , count =1, l ength=5 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f8 71 ac , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 6 (0 x6 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f871a4 , count =1, l ength=6 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f86 14 4 , l e n = 280 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =4 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=4 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =5 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=5 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d rsp g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 6 (CLOSING)−>4 (IDLE) I / BrcmNfcNfa ( 8 70 ) : r w t 2 t c o n n c b a c k : c on n i d =0 , e vt =24578 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4005 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE RSP ( 7 ) d i s c f l a g s : 0x61 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x41 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 4 (IDLE )−>4 (IDLE ) I / BrcmNfcNfa ( 87 0) : n f a d m d i s c d a t a c b a c k ( ) I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4005 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE NTF ( 8 ) d i s c f l a g s : 0x41 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 d f0b5 c I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 870) : n f a d m d i s c n o t i f y d e a c t i v a t i o n ( ) : a c t i v a t e d h an dl e=1 I /BrcmNfcNfa ( 870 ) : n f a d m p o l l d i s c c b a c k ( ) : eve nt : 0 x02 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW DEACTIVATE NTF EVT ( 0 x602 ) , f l a g s : 00000021 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 6 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : NFA DEACTIVATED EVT Type : 1 , g I s T ag D e a c t i va t i n g : 1 D/ BrcmNfcJni ( 87 0) : NfcTag : : s e t D e a c t i v a t i o n S t a t e : s t a t e =1 I /BrcmNfcNfa ( 8 70 ) : n f a d m d i s c n e w s t a t e ( ) : o l d s t a t e : POLL ACTIVE ( 4 ) , n e w s t at e : W4 HOST SELECT ( 3 ) d i s c f l a g s : 0 x1 D/ BrcmNfcJni ( 870) : r e S e l e c t : s e l e c t i n t e r f a c e 1 I /BrcmNfcNfa ( 870) : NFA Select ( ) : r f d i s c i d : 0 x1 , pr o t o c o l : 0 x2 , r f i n t e r f a c e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0111 I / BrcmNfcNfa ( 87 0) : n f a d m e v t h d l r e ve nt : NFA DM API SELECT EVT (0 x11 ) I /BrcmNfcNfa ( 870) : n f a d m a c t s e l e c t ( ) I /BrcmNfcNfa ( 870) : n f a d m d i s c s e l e c t ( ) r f d i s c i d : 0 x1 , p ro to co l : 0 x2 , r f i n t e r f a c e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : SELECT CMD( 3 ) d i s c f l a g s : 0 x11 D/ NfcAdaptation ( 870) : NfcAdaptation : : HalWrite D/ N fcNciHal ( 87 0) : HaiWri te : e n t e r ; l e n =6 I / NfcNciHal ( 87 0) : HAL NfcWrite ( ) I / N fcNc iHal ( 87 0) : n f c h a l m a i n s e n d m e s s a g e ( ) l s : 0 x10 I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 0 I / NfcNciHal ( 870) : p buf−>l e n : 6 D/USERIAL LINUX( 870) : USERIAL Write : (7 byt e s ) D/ NfcNciHal ( 870) : HaiWrite : e x i t 0 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0 x11 D/USERIAL LINUX( 870) : USERIAL Write l en = 7 , r e t = 7 I /BrcmNfcNfa ( 87 0) : ptim t imer sto p D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 5 (0 x5 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f8 613c , count =1, l ength=5 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f86 72 0 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =4 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=4 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d rsp g id : 1 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4003 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : SELECT RSP ( 4 ) d i s c f l a g s : 0 x11 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 3 D/ BrcmNfcJni ( 87 0) : n fa Con nec tio nC all bac k : NFA SELECT RESULT EVT: s t a t u s = 0 , g I s S e l e c t i n g R f I n t e r f a c e = 1 , s I s D i s a b l i n g =0 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0x1 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 2 7( 0 x1b ) by te s , e r r n o=0 c oun t =280 , n=1, t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f86718 , count =1, l ength =27 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f86 97 8 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) 58 C. Traza de una llamada transceive en Android con NfcA I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =26 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n =26 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 4 (IDLE )−>5 (OPEN) I /BrcmNfcNfa ( 870 ) : n f c n c i f p r o c a c t i v a t e : 2 3 0 , mode : 0 x00 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4004 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : ACTIVATED NTF ( 5 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70 ) : n f a d m d i s c n e w s t a t e ( ) : o l d s t a t e : W4 HOST SELECT ( 3 ) , n e w s t ate : POLL ACTIVE ( 4 ) d i s c f l a g s : 0 x1 I /BrcmNfcNfa ( 870) : n f a d m d i s c n o t i f y a c t i v a t i o n ( ) : tech n mode : 0 x0 , proto : 0 x2 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c g e t d i s c m a s k ( ) : t ech n mode : 0 x0 , p r o t o c o l : 0 x2 , dis c m as k : 0 x2 I / BrcmNfcNfa ( 870) : a c t i v a t e d p r o t o c o l : 0 x2 , a ct iv at e d h a nd le : 0 x1 I /BrcmNfcNfa ( 870 ) : n f a d m p o l l d i s c c b a c k ( ) : eve nt : 0 x01 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW ACTIVATE NTF EVT ( 0 x601 ) , f l a g s : 00000001 I /BrcmNfcNfa ( 870) : n f a r w a c t i v a t e n t f I /BrcmNfcNfa ( 8 70) : RW SetActivatedTagType p r o t o c o l : 2 , t ec h no l og y : 0 , SAK: 0 I / BrcmNfcNfa ( 870) : n f a d m n o t i f y a c t i v a t i o n s t a t u s ( ) : s ta t u s : 0 x0 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 5 D/ BrcmNfcJni ( 870) : nf aCon ne ctio nCall back : NFA ACTIVATED EVT: g I s S e l e c t i n g R f I n t e r f a c e =1, s I s D i s a b l i n g =0 D/ BrcmNfcJni ( 870) : NfcTag : : s e t A c t i v a t i o n S t a t e : s t a t e =2 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x1 D/ BrcmNfcJni ( 870) : r e S e l e c t : s e l e c t completed ; sConnectOk=1 D/ BrcmNfcJni ( 870) : r e S e l e c t : e x i t ; s ta tu s=0 D/ BrcmNfcJni ( 870) : na tiveNfcTag doR econnect : e x i t 0x0 D/ BrcmNfcJni ( 8 70 ) : na tiveNfcTag doCh eck Ndef : e n t e r D/ BrcmNfcJni ( 87 0) : n ati veN fcTa g doC hec kNd ef : t r y NFA RwDetectNDef I /BrcmNfcNfa ( 87 0) : NFA RwDetectNDef I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0600 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW OP REQUEST EVT (0 x600 ) , f l a g s : 00000021 I /BrcmNfcNfa ( 8 70) : n f a r w h a n d l e o p r e q : op=0x00 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) I /BrcmNfcNfa ( 870) : n f a r w d e t e c t n d e f I /BrcmNfcNfa ( 870) : RW SENT [ ] : 0 x30 CMD I /BrcmNfcNfa ( 870) : n f c n c i f s e n d d a t a : 0 , num buff : 1 qc : 0 D/ NfcAdaptation ( 870) : NfcAdaptation : : HalWrite D/ N fcNciHal ( 87 0) : HaiWri te : e n t e r ; l e n =5 I / NfcNciHal ( 87 0) : HAL NfcWrite ( ) D/ NfcNciHal ( 870) : HaiWrite : e x i t 0 I / N fcNc iHal ( 87 0) : n f c h a l m a i n s e n d m e s s a g e ( ) l s : 0 x0 I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 0 D/USERIAL LINUX( 870) : USERIAL Write : (6 byt e s ) I /BrcmNfcNfa ( 8 70) : r w t 2 t r e a d Sent Command f o r Blo ck : 0 D/USERIAL LINUX( 870) : USERIAL Write l en = 6 , r e t = 6 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 7 (0 x7 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f86970 , count =1, l ength=7 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f8 64 c8 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =6 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=6 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 0 I /BrcmNfcNfa ( 870) : n c i p r o c c o r e n t f opcode : 0 x6 I /BrcmNfcNfa ( 870) : n f c n c i f s e n d d a t a : 0 , num buff : 1 qc : 0 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 2 1( 0 x15 ) b yt es , e r r n o=0 c oun t =280 , n=1, ti me ou t=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f8 64c0 , count =1, l ength =21 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f 8 6 5 f 4 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =20 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n =20 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d data I /BrcmNfcNfa ( 870) : n f c n c i f p r o c d a t a 0 x000011 I /BrcmNfcNfa ( 870) : n f c n c i f p r o c d a t a l en : 1 7 I / BrcmNfcNfa ( 8 70 ) : r w t 2 t c o n n c b a c k : c on n i d =0 , e vt =24579 I /BrcmNfcNfa ( 870) : RW RECV [ ] : 0 x30 RSP I /BrcmNfcNfa ( 8 70) : r w t 2 t p r o c d a t a S t at e : 5 co n n i d : 0 e ve nt : 24579 l e n : 16 data [ 0 ] : 0 x04 I /BrcmNfcNfa ( 870) : NDEF D e tection f a i l e d ! , CC [ 0 ] : 0 x00 , CC [ 1 ] : 0x00 , CC [ 3 ] : 0 x00 I /BrcmNfcNfa ( 87 0) : nfa r w c back : event=0x43 I /BrcmNfcNfa ( 870) : NDEF Detection completed : c u r s i z e =0, max s ize =46, f l a g s =0x34 I /BrcmNfcNfa ( 8 70) : n f a d m a c t c o n n c b a c k n o t i f y ( ) : e ve nt : 0 x8 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 8 D/ BrcmNfcJni ( 87 0) : n faC onn ect ion Cal lba ck : NFA NDEF DETECT EVT: s t a t u s = 0 x3 , p r o t o c o l = 2 , max s i ze = 46 , c u r s i z e = 0 , f l a g s = 0 x34 D/ BrcmNfcJni ( 870) : nativeNf cTag doCheckN defResult : f l a g n def support ed D/ BrcmNfcJni ( 8 70 ) : n at iv eN fc Ta g d oCh ec kN de fR es ul t : f l a g f o r m a t t a b l e I /BrcmNfcNfa ( 870) : RW T2T s t a t e changed:<TLV DETECT>−> <IDLE> 59 C. Traza de una llamada transceive en Android con NfcA D/ BrcmNfcJni ( 87 0) : nativeNfcTag doCheckNdef : e x i t ; s t a t u s =0x3 D/ Nati ve NfcTag ( 8 70 ) : Check NDEF F a i l e d −s t a t u s = 3 D/ BrcmNfcJni ( 87 0) : n at iv eN fc Ta g do Ha nd leR ec on ne ct : t a r g e tH a n d le = 1 D/ BrcmNfcJni ( 87 0) : n at iv eNf cT ag d oC on nec t : t a r ge t H a n dl e = 1 D/ BrcmNfcJni ( 870) : nativeNfcTag doConnect ( ) Nfc type = 2 , do not hin g f o r non ISO DEP D/ BrcmNfcJni ( 870) : nativeNfcTag doConnect : e x i t 0 x0 D/ BrcmNfcJni ( 8 70 ) : na tiveNfcTag doCh eck Ndef : e n t e r D/ BrcmNfcJni ( 87 0) : n ati veN fcTa g doC hec kNd ef : t r y NFA RwDetectNDef I /BrcmNfcNfa ( 87 0) : NFA RwDetectNDef I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0600 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW OP REQUEST EVT (0 x600 ) , f l a g s : 00000021 I /BrcmNfcNfa ( 8 70) : n f a r w h a n d l e o p r e q : op=0x00 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) I /BrcmNfcNfa ( 870) : n f a r w d e t e c t n d e f I/BrcmNfcNfa( 870) : RW T2tLocateTlv −I n v a l i d NDEF Magic Number ! , CC [ 0 ] : 0 x00 , CC [ 1 ] : 0 x00 , CC [ 3 ] : 0 x00 I /BrcmNfcNfa ( 8 70) : n f a d m a c t c o n n c b a c k n o t i f y ( ) : e ve nt : 0 x8 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 8 D/ BrcmNfcJni ( 87 0) : n faC onn ect ion Cal lba ck : NFA NDEF DETECT EVT: s t a t u s = 0 x3 , p r o t o c o l = 0 , max s i ze = 0 , c u r s i z e = 0 , f l a g s = 0x8 D/ BrcmNfcJni ( 870) : nativeNf cTag doCheckN defResult : f l a g a l l unknown D/ BrcmNfcJni ( 87 0) : nativeNfcTag doCheckNdef : e x i t ; s t a t u s =0x3 D/ Nati ve NfcTag ( 8 70 ) : Check NDEF F a i l e d −s t a t u s = 3 D/ BrcmNfcJni ( 8 70 ) : n at iv eN fcTa g do Re co nn ec t : e n t e r D/ BrcmNfcJni ( 8 70 ) : r e S e l e c t : e n t e r ; r f i n t f = 1 , c u r r e n t i n t f = 1 D/ BrcmNfcJni ( 87 0) : r e S e l e c t : d e a c t i v a t e to s l e e p I /BrcmNfcNfa ( 8 70) : NFA Deactivate ( ) : s le ep m od e : 1 I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0113 I / BrcmNfcNfa ( 87 0) : n f a d m e v t h d l r e ve nt : NFA DM API DEACTIVATE EVT ( 0 x13 ) I /BrcmNfcNfa ( 8 70) : n f a d m a c t d e a c t i v a t e ( ) I /BrcmNfcNfa ( 870) : n f a d m r f d e a c t i v a t e ( ) d e a c t i v a t e t y p e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE CMD ( 6 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70) : NFC Deactivate 5 (OPEN) d e a c t i v a t e t y p e : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 5 (OPEN)−>6 (CLOSING) I / BrcmNfcNfa ( 870) : a c t p r o t o c o l 2 c r e d i t s : 1/1 D/ NfcAdaptation ( 870) : NfcAdaptation : : HalWrite D/ N fcNciHal ( 87 0) : HaiWri te : e n t e r ; l e n =4 I / NfcNciHal ( 87 0) : HAL NfcWrite ( ) D/ NfcNciHal ( 870) : HaiWrite : e x i t 0 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t a r t t i m e r 74 df0 b5c I /BrcmNfcNfa ( 870) : ptim tim er s t a r t I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x61 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) I / N fcNc iHal ( 87 0) : n f c h a l m a i n s e n d m e s s a g e ( ) l s : 0 x10 I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 0 I / NfcNciHal ( 870) : p buf−>l e n : 4 D/USERIAL LINUX( 870) : USERIAL Write : (5 byt e s ) D/USERIAL LINUX( 870) : doWriteDelay ( ) d el ay 1 ms D/USERIAL LINUX( 870) : USERIAL Write l en = 5 , r e t = 5 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 5 (0 x5 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f865 ec , count =1, l en gth=5 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74f86bd0 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =4 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=4 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d rsp g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 6 (CLOSING)−>4 (IDLE) I / BrcmNfcNfa ( 8 70 ) : r w t 2 t c o n n c b a c k : c on n i d =0 , e vt =24578 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4005 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE RSP ( 7 ) d i s c f l a g s : 0x61 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x41 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 6 (0 x6 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f86bc8 , count =1, l ength=6 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f8 71 ac , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =5 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=5 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 4 (IDLE )−>4 (IDLE ) I / BrcmNfcNfa ( 87 0) : n f a d m d i s c d a t a c b a c k ( ) I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4005 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : POLL ACTIVE ( 4 ) , e v en t : DEACTIVATE NTF ( 8 ) d i s c f l a g s : 0x41 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 d f0b5 c I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 870) : n f a d m d i s c n o t i f y d e a c t i v a t i o n ( ) : a c t i v a t e d h an dl e=1 60 C. Traza de una llamada transceive en Android con NfcA I /BrcmNfcNfa ( 870 ) : n f a d m p o l l d i s c c b a c k ( ) : eve nt : 0 x02 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW DEACTIVATE NTF EVT ( 0 x602 ) , f l a g s : 00000021 I /BrcmNfcNfa ( 870) : n f a s y s p t i m s t o p t i m e r 74 df45 e4 I /BrcmNfcNfa ( 87 0) : ptim t imer sto p I / BrcmNfcNfa ( 8 70 ) : Stopped p r e s e n c e c he ck t i me r ( i f s t a r t e d ) D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 6 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : NFA DEACTIVATED EVT Type : 1 , g I s T ag D e a c t i va t i n g : 1 D/ BrcmNfcJni ( 87 0) : NfcTag : : s e t D e a c t i v a t i o n S t a t e : s t a t e =1 D/ BrcmNfcJni ( 870) : r e S e l e c t : s e l e c t i n t e r f a c e 1 I /BrcmNfcNfa ( 870) : NFA Select ( ) : r f d i s c i d : 0 x1 , pr o t o c o l : 0 x2 , r f i n t e r f a c e : 0 x1 I /BrcmNfcNfa ( 870) : NFA Select ( ) : r f d i s c i d : 0 x1 , pr o t o c o l : 0 x2 , r f i n t e r f a c e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70 ) : NFA g ot e ve nt 0 x0111 I / BrcmNfcNfa ( 87 0) : n f a d m e v t h d l r e ve nt : NFA DM API SELECT EVT (0 x11 ) I /BrcmNfcNfa ( 870) : n f a d m a c t s e l e c t ( ) I /BrcmNfcNfa ( 870) : n f a d m d i s c s e l e c t ( ) r f d i s c i d : 0 x1 , p ro to co l : 0 x2 , r f i n t e r f a c e : 0 x1 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : SELECT CMD( 3 ) d i s c f l a g s : 0 x11 D/ NfcAdaptation ( 870) : NfcAdaptation : : HalWrite D/ N fcNciHal ( 87 0) : HaiWri te : e n t e r ; l e n =6 I / NfcNciHal ( 87 0) : HAL NfcWrite ( ) D/ NfcNciHal ( 870) : HaiWrite : e x i t 0 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0 x11 I / N fcNc iHal ( 87 0) : n f c h a l m a i n s e n d m e s s a g e ( ) l s : 0 x10 I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 0 I / NfcNciHal ( 870) : p buf−>l e n : 6 D/USERIAL LINUX( 870) : USERIAL Write : (7 byt e s ) D/USERIAL LINUX( 870) : doWriteDelay ( ) d el ay 2 ms D/USERIAL LINUX( 870) : USERIAL Write l en = 7 , r e t = 7 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 5 (0 x5 ) b yte s , e r rn o =0 co unt =280 , n=1 , t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f871a4 , count =1, l ength=5 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f86 14 4 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =4 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n=4 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d rsp g id : 1 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4003 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : SELECT RSP ( 4 ) d i s c f l a g s : 0 x11 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 3 D/ BrcmNfcJni ( 87 0) : n fa Con nec tio nC all bac k : NFA SELECT RESULT EVT: s t a t u s = 0 , g I s S e l e c t i n g R f I n t e r f a c e = 1 , s I s D i s a b l i n g =0 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : W4 HOST SELECT ( 3 ) , d i s c f l a g s : 0x1 D/USERIAL LINUX( 8 70 ) : my read : r e t u r n 2 7( 0 x1b ) by te s , e r r n o=0 c oun t =280 , n=1, t im eo ut=−1 D/USERIAL LINUX( 870) : u s e r i a l r e a d t h r e a d ( ) : enqueued p b uf=0x74f8 613c , count =1, l ength =27 D/USERIAL LINUX( 8 70 ) : my read : e nte r , pbuf =74 f86 72 0 , l e n = 280 I / NfcNciHal ( 87 0) : n f c h a l n c i p r e p r o c r x n c i m s g ( ) I / NfcNciHal ( 87 0) : n fc h al dm p ow er m ode e xe cut e ( ) e vent = 1 D/ N fcNciHal ( 87 0) : BroadcomHalDataCallback : e n t e r ; l e n =26 D/ N fcA dap tat ion ( 87 0) : N fcA dap tation : : H al DeviceC on textD at aC all ba ck : l e n =26 I /BrcmNfcNfa ( 8 70) : NFC r e c e i v e d n t f g id : 1 I /BrcmNfcNfa ( 870) : n f c s e t s t a t e 4 (IDLE )−>5 (OPEN) I /BrcmNfcNfa ( 870 ) : n f c n c i f p r o c a c t i v a t e : 2 3 0 , mode : 0 x00 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c d i s c o v e r y c b a c k ( ) : eve nt : 0 x4004 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : s t a t e : W4 HOST SELECT ( 3 ) , ev e nt : ACTIVATED NTF ( 5 ) d i s c f l a g s : 0x1 I /BrcmNfcNfa ( 8 70 ) : n f a d m d i s c n e w s t a t e ( ) : o l d s t a t e : W4 HOST SELECT ( 3 ) , n e w s t ate : POLL ACTIVE ( 4 ) d i s c f l a g s : 0 x1 I /BrcmNfcNfa ( 870) : n f a d m d i s c n o t i f y a c t i v a t i o n ( ) : tech n mode : 0 x0 , proto : 0 x2 I /BrcmNfcNfa ( 8 70) : n f a d m d i s c g e t d i s c m a s k ( ) : t ech n mode : 0 x0 , p r o t o c o l : 0 x2 , dis c m as k : 0 x2 I / BrcmNfcNfa ( 870) : a c t i v a t e d p r o t o c o l : 0 x2 , a ct iv at e d h a nd le : 0 x1 I /BrcmNfcNfa ( 870 ) : n f a d m p o l l d i s c c b a c k ( ) : eve nt : 0 x01 I /BrcmNfcNfa ( 8 70 ) : n f a r w h a n d l e e v e n t e ve nt : NFA RW ACTIVATE NTF EVT ( 0 x601 ) , f l a g s : 00000001 I /BrcmNfcNfa ( 870) : n f a r w a c t i v a t e n t f I /BrcmNfcNfa ( 8 70) : RW SetActivatedTagType p r o t o c o l : 2 , t ec h no l og y : 0 , SAK: 0 I / BrcmNfcNfa ( 870) : n f a d m n o t i f y a c t i v a t i o n s t a t u s ( ) : s ta t u s : 0 x0 D/ BrcmNfcJni ( 87 0) : n f aC o n ne c t io n C al l b a ck : e ve nt= 5 D/ BrcmNfcJni ( 870) : nf aCon ne ctio nCall back : NFA ACTIVATED EVT: g I s S e l e c t i n g R f I n t e r f a c e =1, s I s D i s a b l i n g =0 D/ BrcmNfcJni ( 870) : NfcTag : : s e t A c t i v a t i o n S t a t e : s t a t e =2 I / BrcmNfcNfa ( 8 70) : n f a d m d i s c s m e x e c u t e ( ) : new s t a t e : POLL ACTIVE ( 4 ) , d i s c f l a g s : 0 x1 D/ BrcmNfcJni ( 870) : r e S e l e c t : s e l e c t completed ; sConnectOk=1 D/ BrcmNfcJni ( 870) : r e S e l e c t : e x i t ; s ta tu s=0 D/ BrcmNfcJni ( 870) : na tiveNfcTag doR econnect : e x i t 0x0 D/ BrcmNfcJni ( 8 70 ) : n at i veN f cT a g d o Tr a ns c e iv e : e n t e r ; raw =0; t im eo ut = 618 I /BrcmNfcNfa ( 8 70) : NFA SendRawFrame ( ) d a t a l e n : 2 I /BrcmNfcNfa ( 87 0) : NFA got e vent 0x010C I / BrcmNfcNfa ( 87 0) : n f a d m e v t h d l r e ve nt : NFA DM API RAW FRAME EVT ( 0 x0c ) I /BrcmNfcNfa ( 8 70) : n f a d m a ct s e nd r a w f rame ( ) 61 Secci´on D.3 D. Habilitar TRACE LEVEL en servicio NFC # byte [ 1 ] i s the param i d i t sh ou ld be s e t to B9 . # by te [ 2 ] i s t he l e n g t h o f t he LPTD p ar a me te rs # byte [ 3 ] i n d i c a t e s i f LPTD i s en abl ed # i f s e t t o 0 , LPTD w i l l be d i s a b l e d ( par am eter s w i l l s t i l l be s ent ) . # byte [4−n ] ar e the LPTD par amete rs . # By d e faul t , LPTD i s enabled and d e f a u l t s e t t i n g s a re used . # See n f c h a l d m c f g . c f o r d e f a u l t s LPTD CFG={23:B9:21:01:02:FF:FF:04:A0:0F:40:00:80:02:02:10:00:00:00:31:0E :30:00:00:00:00:00:00:00:00:00:00:00:00:00:00} ############################################################################### # S ta rt u p C o n f i g u r a t i o n ( 100 b yt e s maximum) # # For the 0xCA parameter , byte [ 9 ] ( marked by ’AA’ ) i s f o r UICC0 , and byte [ 1 0 ] ( marked by BB) i s # f o r UICC1 . The v a l u e s a r e d e f i n e d as : # 0 : UICCx o nly suppor t s ISO DEP i n low power mode . # 2 : UICCx o nly suppor t s Mif are i n low power mode . # 3 : UICCx s upports both ISO DEP and M ifar e in low power mode . # # AA BB NFA DM START UP CFG={2E :CB: 0 1 : 0 1 : A5 : 0 1 : 0 1 :CA: 1 4 : 0 0 : 0 0 : 0 0 : 0 0 : 0 6 : E8 :03:00:00:00:00:00:00:00:00:00:00:00:00:00:80:01:01:C2:08:61:40:82:04:40:4B:4C:00:B5 : 0 3 : 0 1 : 0 2 : FF} ############################################################################### # S ta rt u p Vendor S p e c i f i c C o n f i g u r a t i o n ( 10 0 b yt e s maximum) ; # byte [ 0 ] TLV t o t a l l e n = 0x5 # byte [ 1 ] NCI MTS CMD|NCI GID PROP = 0 x 2f # byte [ 2 ] NCI MSG FRAME LOG = 0x9 # byte [ 3 ] 2 # by te [ 4 ] 0=tu rn o f f RF frame l o g g i n g ; 1=t urn on # by te [ 5 ] 0=tu rn o f f SWP frame l o g g i n g ; 1=tu rn on # NFA DM START UP VSC CFG={05:2F: 0 9 : 0 2 : 0 1 : 0 1 } ############################################################################### # Antenna C o n f i g u r a t i o n −This data i s used when s e t t i n g 0xC8 c o nf i g item # a t s t a r t u p ( b e f o r e d i s c o v e r y i s s t a r t e d ) . I f not used , no v al u e i s s e n t . # # The s e t t i n g s f o r t h i s v alue a re documented here : # h tt p : / / wcgbu . broadcom . com/wpan/PM/ P r o j e c t %20Document %20L i b ra r y /bcm20791B0/ # Design /Doc/PHY%20r e g i s t e r %20s e t t i n g s /BCM20791−B2−1027−02 PHY Recommended Reg Settings . x l s x # This document i s maintained by Paul Forshaw . # # The v a l u e s marked as ?? s h ou ld be tweaked p er ant enna o r c ust omer / app : #{20:C8: 1E : 0 6 : ? ? : 0 0 : ? ? : ? ? : ? ? : 0 0 : ? ? : 2 4 : 0 0 : 1 C: 0 0 : 7 5 : 0 0 : 7 7 : 0 0 : 7 6 : 0 0 : 1C: 0 0 : 0 3 : 0 0 : 0A :00:??:01:00:00:40:04} # a r r ay [ 0 ] = 0 x20 i s l e n g t h o f t he p ayl oa d from a r r ay [ 1 ] to t he end # a rray [ 1 ] = 0xC8 i s PREINIT DSP CFG PREINIT DSP CFG={20:C8: 1E: 0 6 : 1 F : 0 0 : 0A: 0 3 : 3 0 : 0 0 : 0 4 : 2 4 : 0 0 : 1C: 0 0 : 7 5 : 0 0 : 7 7 : 0 0 : 7 6 : 0 0 : 1 C: 0 0 : 0 3 : 0 0 : 0A : 0 0 : 4C: 0 1 : 0 0 : 0 0 : 4 0 : 0 4 } ############################################################################### # C onfi gu re c r y s t a l frequen cy when i n t e r n a l LPO can ’ t d et e ct the f r e q uency . #XTAL FREQUENCY=0 ############################################################################### # Use Nexus S NXP RC work to a l l ow our stack / firmware t o work with a r e t a i l # Nexus S t hat causes IOP i s s u e s . Note , t h i s w i l l not p ass conformance and # sho uld be removed f o r produ ct ion . USE NXP P2P RC WORKAROUND=1 ############################################################################### # C on fi gu re the d e f a u l t D es tin ati on Gate used by HCI ( the d e f a u l t i s 4 , which # i s the ETSI loopback gat e . #NFA HCI DEFAULT DEST GATE=0x04 ############################################################################### # Overrid e the s tack d e f a u l t f o r NFA EE MAX EE SUPPORTED s e t i n n f c t a r g e t . h . # The v al ue i s s e t t o 3 by d e f a u l t as i t assumes we w i l l d i s c o v e r 0xF2 , # 0xF3 , and 0xF4 . I f a plat fo rm w i l l exc lu de and SE , t h i s value can be reduced # s o t ha t t he s ta ck w i l l not w ait any l o n g e r than n e c e s s a r y . #NFA MAX EE SUPPORTED=3 ############################################################################### # C on fi gu re the s i n g l e d e f a u l t SE to use . The d e f a u l t i s t o use the f i r s t # SE t h at i s d e t e c t e d by th e s t a c k . Thi s v a l ue might be us ed when t he phone # s u ppo r t s m u l t i p l e SE ( e . g . 0xF3 and 0xF4 ) but you want t o f o r c e i t t o u se # one o f them ( e . g . 0xF4 ) . ACTIVE SE=0xF4 ############################################################################### # C o n fi g u re th e d e f a u l t NfcA/ IsoDep t e c h o l o g y and p r o t o c o l r o u t e . Can be # e i t h e r a s ec u re element ( e . g . 0xF4 ) or the hos t (0 x00 ) 68 D. Habilitar TRACE LEVEL en servicio NFC Secci´on D.3 DEFAULT ISODEP ROUTE=0x00 ############################################################################### # C onfi g ure the NFC Extras t o open and use a s t a t i c p ipe . I f the valu e i s # not s e t or s e t to 0 , then the d e f a u l t i s use a dynamic p ip e based on a # d e s t i n a t i o n gate ( s ee NFA HCI DEFAULT DEST GATE) . Note t here i s a v alu e # f o r each UICC ( where F3=”UICC0” and F4=”UICC1”) #NFA HCI STATIC PIPE ID F3=0x70 NFA HCI STATIC PIPE ID F4=0x71 ############################################################################### # When d i s c o n n e c t i n g from Oberthur s e c u r e element , perf orm a warm−r e s e t of # the s e c ure element to d e s e l e c t the appl e t . # The d e f a u l t hex valu e o f the command i s 0x3 . I f t h i s v a r i a b l e i s und efined , # then t h i s f e a t u r e i s not used . OBERTHUR WARM RESET COMMAND=0x03 ############################################################################### # Force UICC t o only l i s t e n to the f o l l o w i n g technol ogy ( s ) . # The b i t s a r e d e f i n e d a s tNFA TECHNOLOGY MASK i n n f a a p i . h . # D e f a u l t i s NFA TECHNOLOGY MASK A |NFA TECHNOLOGY MASK B. UICC LISTEN TECH MASK=0x01 ############################################################################### # Allow UICC to be powered o f f i f t h e r e i s no t r a f f i c . # Timeout i s i n ms . I f s e t t o 0 , then UICC w i l l not be powered o f f . #UICC IDLE TIMEOUT=30000 ############################################################################### # AID f o r Empty S e l e c t command # I f s p e c i f i e d , t h i s AID w i l l be s u bs t i t ut e d when an Empty SELECT command i s # d e t e c t e d . The f i r s t b yte i s th e l e n g t h o f th e AID . Maximum l e n g t h i s 1 6 . AID FOR EMPTY SELECT={08:A0 : 0 0 : 0 0 : 0 1 : 5 1 : 0 0 : 0 0 : 0 0 } ############################################################################### # Force tag p o l l i n g f o r the f o l l o w i n g techno logy ( s ) . # The b i t s a r e d e f i n e d a s tNFA TECHNOLOGY MASK i n n f a a p i . h . # D e f a u l t i s NFA TECHNOLOGY MASK A |NFA TECHNOLOGY MASK B | # NFA TECHNOLOGY MASK F |NFA TECHNOLOGY MASK ISO15693 | # NFA TECHNOLOGY MASK B PRIME |NFA TECHNOLOGY MASK A ACTIVE | # NFA TECHNOLOGY MASK F ACTIVE. # # Notable b i t s : # NFA TECHNOLOGY MASK KOVIO 0x20 # NFA TECHNOLOGY MASK A ACTIVE 0x40 # NFA TECHNOLOGY MASK F ACTIVE 0 x80 POLLING TECH MASK=0xFF ############################################################################### # Force P2P to o nly l i s t e n f o r the f o l l o w i n g t ec hno logy ( s ) . # The b i t s a r e d e f i n e d a s tNFA TECHNOLOGY MASK i n n f a a p i . h . # D e f a u l t i s NFA TECHNOLOGY MASK A |NFA TECHNOLOGY MASK F | # NFA TECHNOLOGY MASK A ACTIVE |NFA TECHNOLOGY MASK F ACTIVE P2P LISTEN TECH MASK=0xC5 ############################################################################### # Maximum Number o f C r e d i t s t o be a l l ow e d by t he NFCC # This valu e o v e r r i d e s what the NFCC s p e c i f i c e s a l l o w i n g th e host to have # t he c o n t r o l to work−around t r a n s p o r t l i m i t a t i o n s . I f t h i s v a lu e does # not e x i s t or i s s e t to 0 , the NFCC w i l l provid e the number o f c r e d i t s . #MAX RF DATA CREDITS=1 ############################################################################### # This s e t t i n g al l o ws you to d i s a b l e r e g i s t e r i n g the T4t V i r tu a l SE that c a u s e s # t he NFCC to send PPSE r e q u e s t s to t he DH. # The d e f a u l t s e t t i n g i s enabled ( i . e . T4t V i rt u a l SE i s r e g i s t e r e d ) . #REGISTER VIRTUAL SE=1 ############################################################################### # When s c r ee n i s turned o f f , s p e c i f y t he d e s i r e d power s t a t e o f th e c o n t r o l l e r . # 0 : power−off−s l e e p s t a t e ; DEFAULT # 1 : f u l l −power s t a t e # 2 : scre en −o f f card−emu lat ion (CE4/CE3/CE1 modes a r e used ) #SCREEN OFF POWER STATE=0 ############################################################################### # Firmware patch f i l e # I f the v al ue i s not s e t then patch download i s d i s a b l e d . FW PATCH=”/ vendor / fi rmwa re / bcm2079x firmware . ncd ” ############################################################################### # Firmware pre−patch f i l e ( s e n t b e f o r e the above patch f i l e ) # I f the valu e i s not s e t then pre−patch i s not used . 69 Secci´on D.3 D. Habilitar TRACE LEVEL en servicio NFC FW PRE PATCH=”/vendor / firmware / bcm2079x pre firmwar e . ncd ” ############################################################################### # Firmware patch format # 1 = HCD # 2 = NCD ( d e f a u l t ) #NFA CONFIG FORMAT=2 ############################################################################### # SPD Debug mode # I f s et to 1 , any f a i l u r e o f downloading a patch w i l l t r i g g e r a hard−stop #SPD DEBUG=0 ############################################################################### # SPD Max Retry Count # The number o f a ttempts to download a patch b e f o r e g i v i n g up ( d e f u a l t i s 3) . # Note , t h i s r e s e t s a f t e r a power−cycle . #SPD MAX RETRY COUNT=3 ############################################################################### # t r a n s p o r t d r i v e r # # TRANSPORT DRIVER=<d r i v e r > # # where <d r i v e r >can be , f o r example : # ”/dev / ttyS ” (UART) # ”/dev / bcmi2cnf c ” ( I2C ) # ”hwtun” (HW Tunnel ) # ”/dev / bcmspin fc ” ( SPI ) # ”/ dev / btusb0 ” (BT USB) TRANSPORT DRIVER=”/dev/bcm2079x−i 2 c ” ############################################################################### # power c o n t r o l d r i v e r # S p e c i f y a k e r n e l d r i v e r t ha t s uppo rt i o c t l commands to c o n t r o l NFC EN and # NFC WAKE gpio s i g n a l s . # # POWER CONTRL DRIVER=<d r i v e r > # where <d r i v e r >can be , f o r example : # ”/ dev / nfcpowe r ” # ”/dev / bcmi2cnf c ” ( I2C ) # ”/dev / bcmspin fc ” ( SPI ) # i 2 c and s p i d r i v e r may be used t o c o n t r o l NFC EN and NFC WAKE s i g n a l POWER CONTROL DRIVER=”/dev/bcm2079x−i 2 c ” ############################################################################### # I2C t r a n s p o r t d r i v e r o p t i o n s # Mako does not support 10−b i t I2C a d d r e s s e s # Revert to 7−b i t a dd ress BCMI2CNFC ADDRESS=0x77 ############################################################################### # I2C t r a n s p o r t d r i v e r t r y t o r ea d m u l t i p l e p a c ke t s in read ( ) i f da ta i s a v a i l a b l e # remove the comment below to enabl e t h i s f e a t u r e #READ MULTIPLE PACKETS=1 ############################################################################### # SPI t r a n s p o r t d r i v e r o p t i o n s #SPI NEGOTIATION={0A: F0 : 0 0 : 0 1 : 0 0 : 0 0 : 0 0 : FF: FF : 0 0 : 0 0 } ############################################################################### # UART t r a n s p o r t d r i v e r o p t i o n s # # PORT= 1 , 2 , 3 , . . . # BAUD=115200 , 19200 , 9 600 , 4800 , # DATABITS=8, 7 , 6 , 5 # PARITY=”even ” |”odd” |” none ” # STOPBITS=”0” |”1” |”1.5” |”2” #UART PORT=2 #UART BAUD=115200 #UART DATABITS=8 #UART PARITY=”none ” #UART STOPBITS=”1” ############################################################################### # I n s e r t a d e la y i n m i cr o se c on d s pe r b yte a f t e r a w r i t e t o NFCC. # a f t e r w r i t i n g a b l oc k o f data t o the NFCC, d ela y t h i s an amopunt o f time b e f o r e # w r it in g next b lo ck of data . the d el ay i s c a l c u l a t e d as below # NFC WRITE DELAY ∗( number o f byte w rit t en ) / 1000 m i l l i s e c o n d s # e . g . a f t e r 259 b ytes i s wri tten , delay (259 ∗20 / 10 00) 5 ms b e f o r e nex t w r i te NFC WRITE DELAY=20 70 D. Habilitar TRACE LEVEL en servicio NFC Secci´on D.3 ############################################################################### # D ef ault p o l l duratio n ( i n ms) # The d e f u a l t i s 500ms i f not s e t ( s ee n f c t a r g e t . h ) #NFA DM DISC DURATION POLL=333 Este fichero, es le´ıdo cada vez que se inicia el servicio NFC y permite realizar algunos cambios interesantes sin necesidad de recompilar la librer´ıa, lo que ahorra bastante trabajo. Uno de los cambios que se llevo a cabo fue el del par´ametro APPL TRACE LEVEL, poniendo el valor a 0x05 se consigue que toda la librer´ıa muestre mensajes de depuraci´on facilitando la traza de la ejecuci´on. Si bien es cierto, que para modificar el fichero surgen algunos problemas: 1. El fichero se encuentra en /etc que es un enlace simb´olico a /system/etc y por defecto es una partici´on montada como s´olo lectura (si se mira el fichero fstab.mako o/proc/mounts se encuentra la opci´on ro, por lo que es necesario desmontarla y volverla a montar (desde una shell root): mount −o remount rw /system Una vez hecho ya se puede escribir en la partici´on. 2. La shell de Android no tiene muchos programas como vi,ed ogrep, con que editar un fichero se puede convertir en una tarea dif´ıcil, la soluci´on es pasar el fichero a nuestro PC, editarlo c´omodamente y volver a cargarlo: adb p ul l / etc / l ib n fc −brcm . conf . adb push li b n f c −brcm . conf . e d it / etc / li b n f c −brcm . conf 3. Pero da un error porque la orden push no tiene permisos root para escribir en /etc, la soluci´on es copiarlo temporalmente a /sdcard donde si se tiene permiso y posteriormente moverlo: adb push li b n f c −brcm . conf . edi t / sdcard /. Y desde una consola con permisos de superusuario (mv fallar´ıa al ser una referencia cross-device): cp / sdcard / l i bn fc −brcm . conf . ed i t / etc / l ib n fc −brcm . conf && rm / sdcard / l i bn f c −brcm . conf Otra opci´on, por poder hacer las cosas “de otra forma¸consiste en usar cat y redireccionar la salida: cat / sdcard / l i bn fc −brcm . conf . e di t >/ etc / li b nf c −brcm . conf Ahora tan s´olo hay que reiniciar el servicio NFC y conectar el dispositivo por USB para ejecutar la orden adb logcat y empezar a ver los registros. En las pruebas se obtuvieron trazas del inicio y la parada del servicio (donde se comprob´o, apoy´andose en el c´odigo fuente, que el fichero de configuraci´on era cargado, junto con el firmware y las comprobaciones de actualizaciones, adem´as de ver las notificaciones 71 Secci´on D.3 D. Habilitar TRACE LEVEL en servicio NFC y mensajes de configuraci´on desde el DH al NFCC), tambi´en se obtuvieron trazas de las transacciones de lectura y escritura de un tag remoto as´ı como del proceso de discovery. Las trazas resultaron de gran ayuda para la comprensi´on de la implementaci´on de la NCI. 72 Ap´endice E Kernel Android Durante el desarrollo de este proyecto se han comprobado los requisitos y factibilidad para compilar y distribuir un m´odulo para el Kernel, en caso de que fuera necesario intervenir el sistema a ese nivel. Aqu´ı se documentan los distintos Kernels de Android y como compilar un m´odulo para uno espec´ıfico, para finalmente determinar algunas ventajas y desventajas. Android est´a basado en el Kernel de Linux, aunque a estas alturas poco tiene que ver uno con el otro. Entre otras cosas ha sido modificado para implementar IPC (Inter Process Communication) y ahorrar bater´ıa, permite tambi´en ejecutar las aplicaciones en un entorno aislado, etc. Sin embargo, aunque est´an basados en el mismo, los distintos fabricantes utilizan distintas ramas con soporte para su hardware espec´ıfico, por lo que a la hora de compilar un m´odulo nuevo es necesario trabajar con la rama correspondiente al Kernel utilizado en el dispositivo destino. Como casi todo en Android, el c´odigo fuente es libre y se puede encontrar en el git https://android.googlesource.com/device/lge/mako-kernel/ (las URLs son de la forma “device/<vendor>/<name>”), adem´as en la documentaci´on se encuentran la Tabla E.1 se pueden ver las principales ramas. En el caso de Nexus 4, dispositivo con el que se han hecho las pruebas, el codename es mako con que es necesario clonar el repositorio: $ g i t c lon e https :// android . g oog le sou rce . com/ ke rn el /msm. g i t d es tino Una vez descargado se va a compilar el Kernel, para ello es necesario el Android Toolchain para compilar para la plataforma deseada (arm, x86 o mips), ya que otra de las caracter´ısticas de Android es que puede correr en diferentes arquitecturas, de modo que se debe descargarse la versi´on adecuada para la m´aquina host y a˜nadir la ruta al PATH. El siguiente paso ser´a compilar: export ARCH=arm export SUBARCH=arm export CROSS COMPILE=arm−linux−androideabi− make mako defconfig make 73 E. Kernel Android Device Binary location Source Build config hammerhead device/lge/hammerhead-kernel kernel/msm hammerhead defconfig flo device/asus/flo-kernel/kernel kernel/msm flo defconfig deb device/asus/flo-kernel/kernel kernel/msm flo defconfig manta device/samsung/manta/kernel kernel/exynos manta defconfig mako device/lge/mako-kernel/kernel kernel/msm mako defconfig grouper device/asus/grouper/kernel kernel/tegra tegra3 android defconfig tilapia device/asus/grouper/kernel kernel/tegra tegra3 android defconfig maguro device/samsung/tuna/kernel kernel/omap tuna defconfig toro device/samsung/tuna/kernel kernel/omap tuna defconfig panda device/ti/panda/kernel kernel/omap panda defconfig stingray device/moto/wingray/kernel kernel/tegra stingray defconfig wingray device/moto/wingray/kernel kernel/tegra stingray defconfig crespo device/samsung/crespo/kernel kernel/samsung herring defconfig crespo4g device/samsung/crespo/kernel kernel/samsung herring defconfig Tabla E.1: Nombres y localizaci´on de los principales kernels Android. Es necesario definir las variables de la arquitectura destino y el prefijo del toolchain, y en el ejemplo se utiliza la configuraci´on por defecto, pero es posible muchos par´ametros. Una vez se ha compilado el Kernel, la forma m´as sencilla es compilar el m´odulo solo: 1. Se crea un directorio con los ficheros fuentes del Kernel. 2. Se crea un Makefile para compilar el m´odulo linkeando con el Kernel: KERNEL DIR=<r ut a d e l ke r n e l > obj−m := <objecto salida> PWD := $ ( s h e l l pwd) de f au l t : $ (MAKE) ARCH=arm CROSS COMPILE=arm−linux−androideabi− −C $ (KERNEL DIR) SUBDIRS=$ (PWD) modules clean : $ (MAKE) −C $ (KERNEL DIR) SUBDIRS=$ (PWD) c lea n 3. Se ejecuta el make. Y si todo ha ido bien aparecer´a el m´odulo modulo.ko que podr´a cargarse con la orden insmod. Aunque tambi´en ser´ıa posible a˜nadir el m´odulo al directorio de m´odulos y modificar el Makefile para llevar a cabo una compilaci´on est´atica. Por desgracia, la mayor´ıa de versiones, incluida ´esta, por defecto no incluyen soporte para m´odulos (para ello es necesario recompilar con el flag CONFIG MODULES=y). Lo que significa que para que alguien utilice un m´odulo necesita recompilar el Kernel, ya sea con el flag y despu´es cargando el m´odulo o con el m´odulo est´atico, en cualquier caso es un proceso poco usable, y al igual que utilizar una ROM modificada rompe el requisito de utilizar software lo m´as gen´erico posible. En cualquier caso para probar el m´odulo, habr´ıa que seguir los siguientes pasos: 74 E. Kernel Android 1. Compilar un Kernel con soporte para m´odulos, flashear el tel´efono con la nueva imagen y cargar el m´odulo: make bootimage fastboot f l a s h boot zImage . img fastboot reboot adb push module . ko / sdcard /. adb s h e l l su insmod / sdcard /module . ko 2. Compilar el Kernel y en lugar de flashear, usar fastboot para cargar la nueva imagen s´olo una vez, subir el m´odulo y cargarlo: make bootimage fastboot boot zImage . img fastboot reboot adb push module . ko / sdcard /. adb s h e l l su insmod / sdcard /module . ko 3. Lanzar el Kernel con el emulador de Android y cargar el m´odulo. make bootimage emulator −avd foo −kern el zImage . img adb push module . ko / sdcard /. adb s h e l l su insmod / sdcard /module . ko La segunda opci´on seguramente sea la m´as pr´actica y permite probar correctamente cuando se trata con elementos dif´ıciles de emular, pero en muchas ocasiones puede ser peligroso hacer pruebas sobre el Kernel en un dispositivo por lo que emular es la soluci´on m´as adecuada. En Android, la rama de Kernels preparada para soportar emulaci´on es Goldfish, por lo que ser´a necesario compilar con ese Kernel los m´odulos que se quieran emular. 75 E. Kernel Android 76 Ap´endice F Estructura y ´ordenes APDU 77 F. Estructura y ´ordenes APDU 84 Ap´endice G Mapa de tags y tecnolog´ıas 85 ISO 14443 A-4 Type 4 Tag Mifare UL 48 bytes (NXP) • NTAG203 (144 bytes) (NXP) • my-d NFC my-d Move (Infineon) • Kovio 2Kb RFID (Kovio) Type 2 Tag Topaz BCM20203 96/512 Bytes (Broadcom) Type 1 Tag ISO 14443 B-4 ISO 15693 part 3 FeliCa Lite RC-S965 (Sony) Type 3 Tag Type 6 Tag Physical ISO 14443 A-1 ISO 14443 B-1 RF Initialization Anticollision Protocol Activation Protocol Mifare 1K/4K & mini (NXP) ISO 14443 A-3 SLE 66 CL (Infineon) • SmartMx - JCop (NXP) Tag Types or NDEF Transport MicroPass (Inside) • Vault IC Tag (Inside) • 16RF (STM) • SLE66CL (Infineon) ISO 14443 A-2 ISO 14443 B-3 ISO 15693-1 ISO 14443 B-2 ISO 15693-2 iClass 2KS/32KS secure (HID) Generic RFID Tag • ICODE (NXP) • Tag-it (TI) • LR xx (ST) FeliCa RC-880 RC-885 RC-860 (Sony) ISO 18092 = ECMA 340 = NFCIP1 ISO 7816-4 (File APDU) Applicative Protocol NFC Standards, Products and Specifications Version 1.9 [email protected] Copyright © 2008-2012 Inside Secure Type A Type B Type V = RFID Type C = Type F Transport Cards • Calypso Applicative Layer NFC Forum NDEF Message Handling (RTD Smart Poster, Generic Control,…) Standards Examples of Product Specifications Open NFC and the Open NFC logo are trademarks or registered trademarks of Inside Secure. iCLASS and the HID logo are trademarks or registered trademarks of HID Corporation. Other brand, product and company names mentioned herein may be trademarks, registered trademarks or trade names of their respective owners. This document is licensed under the Creative Commons Attribution 3.0 license (http://creativecommons.org/licenses/by/3.0/). You may use the content of this document in any way that is consistent with this license and if you give proper attribution (http://www.open-nfc.org/wp/license_information/). Cryptography Crypto 1 proprietary (mandatory) Prop. Crypto 3DES Bluetooth & WI-FI Pairing Mifare DESFire D40 / EV1 2K/4K/8K (NXP) LLCP (peer 2 peer) Type 3 protocol JIS X 6319-4 3DES or AES JIS X 6319-4 = SNEP (NFC Forum) Mifare UL C (144 bytes) (NXP) 3DES Jewel (innovision Legacy product) Mifare Plus 2K/4K S/X (NXP) Crypto 1 proprietary or AES Type 7 Tag (with NXP crypto) B’ = GTML (Innovatron) Proprietary Specifications rely on proprietary mapping, not 100% compliant with the specification after formatting after formatting after formatting after formatting after formatting specific application specific application after formatting specific application V-Card or Calendar Exchanges Browser or Smart Poster Applications Content Transfer (after pairing) Examples of applications using NFC Tags www.open-nfc.org Kovio Tag (128 bit ID) (Kovio) NXP Type V for I-Code Android NPP (Google) after formatting