Análisis de riesgos de la tecnología NFC en Android

El NFC Near Field Communication, (comunicación mediante campo cercano) tiende a considerarse como una tecnología pasiva (inerte); de forma que actúa exclusivamente cuando decidimos activarla y acercar el móvil a otro dispositivo. Y que mientras tanto, no hace absolutamente nada. Esta idea es en parte correcta, pero omite ciertos aspectos que merecen revisarse más detalladamente.

La mayoría de los escenarios de riesgo que se describirán a continuación, requieren de una proximidad física real, infraestructura específica o que el dispositivo tenga algún tipo de malware instalado previamente. Pero también hay matices importantes sobre el funcionamiento del chip NFC los cuales conviene conocer antes de decidir cuándo tiene sentido mantener el NFC activo y cuándo no.

NFC a nivel físico

El estándar NFC opera a 13,56 MHz y, según la especificación del NFC Forum, y tiene un alcance máximo teórico de 20 centímetros. En condiciones reales y con las antenas integradas en un móvil convencional, la distancia operativa suele limitarse a unos 4 cm.

El estándar define tres modos de operación que Android implementa de forma bastante diferente entre sí.

Modo lectura/escritura. El dispositivo actúa como lector activo: emite un campo electromagnético para alimentar y comunicarse con etiquetas NFC pasivas ( las tarjetas de transporte físicas, carteles informativos, etiquetas de producto, etcétera). Es el modo más intuitivo y el que más solemos asociar al NFC.

Modo peer-to-peer (emparejamiento). Dos dispositivos activos intercambian datos directamente. Fue la base de Android Beam, la función de intercambio por NFC que Google introdujo en Android 2.3 y eliminó en Android 10. Hoy está prácticamente en desuso dado que tanto Bluetooth como Wi-Fi Direct ofrecen mayores velocidades y alcance para los mismos casos de uso.

Modo emulación de tarjeta (Card Emulation). El móvil se comporta como una tarjeta sin contacto ante un lector externo. Es el modo utilizado por Google Pay, abonos de transporte digitales y las tarjetas de acceso virtuales. Siendo el que merece más atención desde el punto de vista de privacidad y la seguridad.

Qué ocurre cuando nadie está usando el NFC

El chip NFC no emite un campo electromagnético de forma continua cuando está en reposo. Necesita detectar el campo de un lector externo para activarse y responder. En ese sentido, el chip no anuncia su presencia en el entorno ni emite datos al aire.

Las complicaciones aparecen en el modo de emulación de tarjeta, y específicamente en su variante por software: HCE (Host Card Emulation, emulación de tarjeta por software), disponible desde Android 4.4 KitKat. Con HCE no hay un elemento de seguridad hardware independiente que gestione la comunicación; es el propio sistema Android quien recibe y responde al lector externo. Esta arquitectura, si bien es mucho más flexible, vincula su comportamiento directamente al estado en que se encuentre la pantalla de nuestro móvil en cada momento.

El sistema distingue tres estados con consecuencias diferentes:

1. Pantalla apagada. Por defecto, los servicios HCE no responden con la pantalla apagada. Pero cada aplicación que implementa HCE puede declarar en su configuración la necesita -o no- que la pantalla esté encendida para funcionar. Algunas aplicaciones de transporte público, para facilitar el paso por torniquetes sin sacar el móvil del bolsillo, están configuradas para responder también en este estado.
2. Pantalla bloqueada pero encendida. Es el estado más frecuente cuando el dispositivo va en el bolsillo. En esta situación, los servicios HCE suelen estar activos. Un lector externo puede iniciar la comunicación con el dispositivo sin que el usuario autorice nada en ese momento concreto.
3. Dispositivo desbloqueado. Funcionalidad completa. El usuario puede ver lo que ocurre y, si la aplicación lo implementa, confirmar o cancelar la operación.

La clave, y por tanto los posibles riesgos, radica en que estos comportamientos no son homogéneos para todos los dispositivos ni para todas las aplicaciones: depende de lo que cada aplicación haya declarado en su manifest de Android, algo que como usuarios es prácticamente imposible de saber con certeza.

HCE: el enrutamiento por AID

Cuando una aplicación implementa HCE: un servicio de pago, un abono de transporte, una tarjeta de acceso virtual, registra en el sistema un AID (Application Identifier, identificador de aplicación), definido mediante el estándar ISO/IEC 7816-4. Es el identificador que los lectores NFC usan para dirigir la comunicación al servicio correcto entre todos los que tengamos instalados en el dispositivo.

Cuando un lector cercano emite un campo, Android intercepta la solicitud, consulta qué app tiene registrado el AID correspondiente y le cede la comunicación. Todo esto ocurre antes de que aparezca cualquier interfaz visible para el usuario.

Lo que se intercambia en esa fase preliminar depende del protocolo específico. En el caso de pagos sin contacto, los datos de la tarjeta real (número de cuenta, CVV) no viajan en texto plano. El esquema está tokenizado: tanto Google Pay, cuya infraestructura de pago gestiona Google Play Services, como Visa y Mastercard sustituyen el número de tarjeta real por un token de un solo uso y generado específicamente para esa transacción. Si un atacante interceptara dicho token, no le serviría para nada fuera del contexto de ésa operación en concreto.

Ahora bien, un lector externo, aunque no complete la transacción, sí obtiene cierta información en el intercambio; el AID del servicio activo, que revela qué tipo de aplicación está registrada en el dispositivo y algunos metadatos del protocolo de comunicación. No es información suficiente para robar dinero, pero sí para inferir, por ejemplo, qué entidad bancaria usa el dispositivo o qué sistema de transporte público tiene configurado.

HCE vs Secure Element

Si bien HCE, como el mecanismo de emulación de tarjeta en Android, es la opción más extendida; existe una alternativa a nivel hardware que cambia por completo el modelo de seguridad: se trata de eSE (embedded Secure Element, elemento de seguridad embebido).

La diferencia fundamental es el aislamiento que ofrece. Con HCE, cuando un lector externo activa el campo electromagnético:

1. El controlador NFC del dispositivo demodula la señal.
2. Extrae los comandos de la aplicación y los reenvía al procesador principal.
3. Android los recibe, identifica qué servicio tiene registrado para ese AID y genera la respuesta.

Toda la operación ocurre dentro del sistema operativo, en la misma capa que ejecuta el resto de las aplicaciones.

Con eSE, hay un chip dedicado e independiente (fabricado por empresas como NXP Semiconductors) que gestiona las operaciones criptográficas y el almacenamiento de credenciales de forma completamente aislada del sistema operativo.

Android solo actúa como canal de transporte; los datos sensibles nunca quedan expuestos en la capa de del sistema operativo.

Esto puede conllevar implicaciones directas. Algunos bancos y sistemas de pago, pueden llegar a exigir eSE para ciertas funciones como la emisión de tarjetas virtuales de alta seguridad y con ello rechazar dispositivos que solo incorporen HCE. La razón es que eSE mantiene las credenciales protegidas incluso si el sistema operativo estuviera comprometido, algo que HCE no puede garantizar del mismo modo.

En el ecosistema Android actual, los dispositivos Google Pixel (desde el Pixel 6) incorporan el chip de seguridad Titan M2, que incluye funcionalidad de eSE y gestiona, entre otras cosas, las operaciones criptográficas de Google Wallet en esos modelos. Los Samsung Galaxy de gama alta (desde la serie S21) cuentan con Knox Vault, la implementación de Samsung de un entorno de ejecución aislado con eSE integrado, que es lo que sustenta Samsung Wallet; su propio sistema de pago (antes Samsung Pay).

En la práctica, no hay ninguna diferencia en cuanto a la experiencia de usuario; pero sí en función de nuestro nivel de amenaza. Un ataque que comprometiera el sistema operativo podría, en teoría, afectar a servicios HCE; no así a un eSE correctamente implementado, cuyas claves criptográficas nunca salen del chip. Vendría a ser la misma diferencia que separa un gestor de contraseñas vía software de una llave física de seguridad.

El caso del transporte público

Los abonos para transporte público en terminales Android son el ejemplo paradigmático del comportamiento con pantalla bloqueada en la práctica. Sistemas como el de Transport for London o el más reciente (Enero de 2026) de la Comunidad de Madrid con Mi Tarjeta Transporte usan HCE configurado de forma que responda con el dispositivo bloqueado. De otra forma, el usuario tendría que desbloquear el móvil cada vez que pasa por un torniquete con la consiguiente merma en la comodidad que aporta dicha solución.

El lector del torniquete inicia la comunicación, Android responde con el servicio HCE correspondiente y la validación se completa. El usuario no ha hecho nada de forma activa; el dispositivo desde el bolsillo, ha respondido por sí solo.

Éste comportamiento es idéntico al de las tarjetas físicas sin contacto desde el punto de vista del protocolo. La diferencia es que una tarjeta física lleva únicamente los datos del abono; mientras que un móvil contiene la totalidad de servicios HCE que tenga registrados.

Rastreo de proximidad mediante NFC

Es menos conocido que el rastreo por Bluetooth, pero técnicamente posible en entornos con una infraestructura destinada para ello. Un lector NFC estático (en una entrada, en un punto de venta, en el pasillo de un centro comercial) puede registrar qué dispositivos pasan cerca si llevan algún servicio HCE activo que responda a su solicitud de selección de AID.

Lo que queda registrado en ese intercambio es, en el mejor de los casos para quien opera el lector, el AID del servicio y los metadatos del protocolo. El estándar NFC no expone ningún identificador único del dispositivo en esas comunicaciones. Pero si el mismo dispositivo pasa repetidamente por el mismo lector, el patrón de AID puede usarse de facto como un identificador indirecto.

Este escenario no es un riesgo genérico en la calle. Requiere de una infraestructura y configurada específicamente con ese fin, y está acotado a entornos donde los operadores tienen capacidad y motivación para desplegarla: aeropuertos, estadios, grandes superficies con sistemas de analítica de afluencia.

Riesgos documentados

Sin NFC activo

Cuando el NFC está desactivado desde los ajustes rápidos del sistema, el riesgo específico de NFC es nulo. El chip no responde a campos externos y no puede usarse como vector de ataque. Es el único escenario de protección completa frente a todos los ataques descritos en esta sección.

Pese a ello, algunos fabricantes mantienen ciertas funciones de bajo nivel activas independientemente del ajuste del usuario; el emparejamiento con wearables propietarios es el ejemplo más habitual. Si bien no puede decirse que sea un comportamiento mayoritario, puede merecer la pena verificarlo en cada modelo concreto si así lo estimamos en función de nuestro «nivel de amenaza».

Con NFC activo

Los riesgos documentados se agrupan en tres categorías con naturaleza diferente.

Etiquetas NFC manipuladas en el entorno físico

Una etiqueta NFC colocada en un cartel, una superficie o un producto puede estar programada para ejecutar una acción al aproximar el dispositivo: abrir una URL, iniciar una descarga, lanzar una llamada. El riesgo real depende de la versión de Android y de qué acciones el sistema permite ejecutar sin confirmación explícita del usuario. En versiones recientes de Android, el sistema solicita confirmación para las acciones más sensibles.

El requisito fundamental es que el usuario tiene que acercar activamente el dispositivo a menos de 4 cm de la etiqueta. No ocurre de forma pasiva.

Vulnerabilidades de la pila NFC sin interacción del usuario

Estas son las más relevantes desde un punto de vista técnico, porque no requieren ninguna acción por parte del usuario; solo que el dispositivo esté en proximidad física con un atacante.

CVE-2020-0348 afectó a Android 11: un fallo en la pila NFC permitía a un atacante con proximidad física acceder a información sensible sin interacción del usuario. Parcheado en el boletín de seguridad de noviembre de 2020.

CVE-2025-48539 parcheado en el boletín de seguridad de septiembre de 2025, es considerado como el más grave dado que habilitaba la ejecución remota de código en el componente System, sin interacción del usuario y explotable desde proximidad física (el boletín lo describe como proximal/adjacent), lo que abarca interfaces como NFC, Bluetooth o Wi-Fi Direct. Afecta a Android 13, 14, 15 y 16. No hay indicación confirmada de explotación activa antes del parche; el boletín sí documenta explotación activa en otros dos CVE (CVE-2025-38352 y CVE-2025-48543), pero no en este. Los dispositivos sin las actualizaciones de seguridad aplicadas siguen estando expuestos.

Android Beam (Android 8.0–9) permitía, en determinadas condiciones, transferir e instalar aplicaciones vía NFC sin mostrar el aviso de seguridad habitual. El problema quedó resuelto en Android 10 con la eliminación completa del servicio.

En todos los casos, los dispositivos sin las actualizaciones de seguridad más recientes son los más expuestos.

Ataques de retransmisión NFC (relay attacks) mediante malware NGate

Documentado en activo desde finales de 2023, este es el ataque con mayor alcance práctico de los que se conocen públicamente.

El atacante convence a la víctima de instalar una aplicación maliciosa mediante phishing o ingeniería social, habitualmente haciéndose pasar por la app de un banco. Una vez instalada la aplicación, ésta se vale de NFCGate (herramienta de investigación desarrollada en la Universidad Técnica de Darmstadt) para retransmitir en tiempo real los datos NFC de las tarjetas de pago físicas de la víctima al dispositivo del atacante.

En marzo de 2024, la policía checa detuvo a un sospechoso vinculado a ataques de este tipo (el caso está documentado en el análisis de ESET Research sobre NGate). Según la telemetría de ESET, en el primer semestre de 2025 los ataques de este tipo se multiplicaron por 35 respecto al semestre anterior.

El punto importante es que éste ataque, no explota ninguna vulnerabilidad del protocolo NFC. Se vale de ingeniería social para conseguir que la víctima instale el malware. NFC es el canal de extracción, no el vector de entrada.

Distancias máximas verificadas

La protección física que ofrece la escasa distancia de funcionamiento del NFC es la mejor defensa frente ataques de lectura pasiva directa. No así cuando se utiliza el propio dispositivo de la víctima como intermediario.

Qué controla Android y qué controla el usuario

Activar y desactivar NFC desde los ajustes rápidos. Cuando se desactiva el NFC desde el panel de notificaciones, automáticamente deja de responder a cualquier mensaje externo manteniendo inaccesibles todos los servicios HCE. La excepción la constituyen todas aquellas funciones propietarias que los distintos fabricantes puedan llevar a implementar fuera del stack NFC estándar.

Pago sin contacto predeterminado. Android muestra qué aplicación está configurada en cada momento como servicio predeterminado para pagos. Solo una aplicación puede estar activa para una categoría de AID determinada; si hay conflicto, el sistema prioriza la que estuviera configurada como predeterminada. Desde esta misma pantalla es posible revisar qué aplicaciones tienen servicios HCE registrados en el sistema.

Comportamiento con pantalla bloqueada. Lo que la interfaz de Android no expone de forma clara es si cada servicio HCE está configurado para responder o no con el dispositivo bloqueado. Eso depende de lo que cada aplicación haya declarado en su manifest, y no siempre está documentado de forma sencilla y accesible .

«Requerir desbloqueo para NFC», disponible en Android 15. Esta opción impide que los servicios HCE respondan a lectores externos hasta que el dispositivo haya sido desbloqueado. Es la medida más segura para quien quiera limitar el comportamiento con pantalla bloqueada sin renunciar completamente al NFC. El «inconveniente» es que, por ejemplo, el abono de transporte digital deja de funcionar si previamente no hemos desbloqueado el móvil. La disponibilidad de esta opción en cada dispositivo concreto depende del fabricante y de la versión de Android instalada.

Qué tiene sentido evaluar

No hay una configuración correcta universal; depende del uso real que cada persona haga del NFC. Pero sí hay algunas consideraciones que conviene tener presentes.

Si bien el impacto del NFC en la batería es prácticamente nulo, desactivarlo cuando no se usa elimina por completo la exposición a posibles ataques. Si los únicos casos de uso son esporádicos: leer una etiqueta puntualmente o hacer un pago ocasional, mantenerlo siempre activo no aporta nada.

Revisar qué apps tienen servicios HCE registrados es muy útil para entender qué está activo en el dispositivo. La ruta más usual en Android: Ajustes -> Conexiones -> NFC -> Pago sin contacto. Si aparecen servicios de aplicaciones que ya no se usan o se instalaron sin una intención específica, es recomendable desinstalarlas o revocar el servicio.

Mantener el dispositivo actualizado con todos los parches de seguridad, es, con diferencia, la mejor medida preventiva. Las vulnerabilidades documentadas más graves afectan a dispositivos no actualizados convenientemente.

Por último, conviene tener claro que «NFC desactivado» en el panel rápido, no siempre equivale a que el procedador permanezca completamente inactivo en todos los dispositivos.

Referencias y recursos