Comparativa · Alta frecuencia
Las dos familias trabajan a 13,56 MHz y caben en el mismo formato de tarjeta, pero pertenecen a generaciones distintas de diseño. La diferencia decisiva no es la capacidad, sino el modelo criptográfico y quién controla las claves.
Cifrado propietario heredado
Autenticación AES
Sectores frente a ficheros
La marca el lector
MIFARE Classic organiza la memoria en sectores protegidos por un cifrado propietario roto públicamente desde 2008, por lo que su contenido no debe considerarse secreto. DESFire organiza la memoria en aplicaciones y ficheros con autenticación AES y sigue siendo apropiado para credenciales donde el dato importa. Cambiar de una a otra no es sustituir tarjetas: exige lectores y software que soporten la segunda.
La tabla recoge las diferencias que pesan en una decisión de compra. Ninguna fila describe una regla universal: el comportamiento final depende del lector instalado y del software que interpreta el dato.
| Criterio | MIFARE Classic | DESFire |
|---|---|---|
| Organización | Sectores y bloques de tamaño fijo | Aplicaciones y ficheros de tamaño definido por el proyecto |
| Criptografía | Algoritmo propietario heredado, comprometido públicamente | AES de 128 bits; las versiones anteriores admitían además 3DES |
| Confidencialidad del dato | No debe asumirse | Razonable si las claves se gestionan correctamente |
| Protocolo | Comunicación propietaria sobre ISO/IEC 14443-3 | ISO/IEC 14443-4, con intercambio de órdenes normalizado |
| Gestión de claves | Dos claves por sector, habitualmente estáticas | Jerarquía por aplicación, con diversificación por tarjeta |
| Uso razonable hoy | Identificación por número en instalaciones ya montadas | Credenciales nuevas, multiaplicación y datos con valor |
| Coste unitario | Menor | Mayor, y justificado solo si el sistema lo aprovecha |
Existe una instalación en funcionamiento, los lectores no admiten otra cosa y el sistema únicamente utiliza el número de la tarjeta como referencia contra una base de datos. En ese escenario el nivel de protección real lo aporta la infraestructura, no la credencial, y sustituir el soporte no mejora nada por sí mismo.
Se despliega un sistema nuevo, la credencial debe almacenar datos con valor —saldo, permisos, identidad—, conviven varias aplicaciones sobre la misma tarjeta, o el pliego exige autenticación demostrable. También cuando el ciclo de vida previsto es largo y no interesa repetir la migración a medio plazo.
Se pretende conservar los lectores actuales y ganar seguridad al mismo tiempo. Rara vez es posible: si el lector solo sabe leer un número, cualquier tarjeta que le presente ese número será aceptada, independientemente de la criptografía que la tarjeta soporte.
La debilidad de Classic es pública y bien documentada desde 2008: la comunidad académica publicó ataques prácticos sobre su algoritmo propietario y desde entonces existen herramientas accesibles que los implementan. La consecuencia operativa no es que toda instalación deba sustituirse mañana, sino que el contenido de la tarjeta no puede considerarse un secreto y que la seguridad debe apoyarse en el sistema: comprobación contra un servidor, revocación rápida, registro de accesos y control físico.
En sentido contrario, elegir DESFire no produce seguridad de forma automática. Una instalación que lee el identificador de una tarjeta DESFire sin ejecutar la autenticación queda exactamente igual de expuesta que una instalación con Classic, porque ese identificador es legible sin claves. La protección aparece cuando el lector autentica, cuando las claves no son las de fábrica y cuando cada tarjeta deriva las suyas propias. Si esas tres condiciones no se cumplen, se está pagando una arquitectura que no se utiliza.
Por eso la pregunta correcta no es qué tarjeta es mejor, sino qué hace exactamente el lector instalado en el momento de la lectura. Esa información la tiene el integrador o el fabricante del software de accesos, y determina por completo qué margen de decisión existe sobre la credencial.
Una comparación sirve para reducir alternativas, no para cerrar una especificación. Estos pasos convierten la decisión en algo comprobable antes de comprometer un lote.
Documente qué dato consume hoy el sistema: número, sector o operación autenticada.
Pida al integrador la lista de tecnologías que el lector instalado admite.
Compruebe si las claves en uso son las de fábrica.
Pruebe una muestra en el lector real antes de cerrar el lote.
Defina la política de revocación antes de elegir la tarjeta.
Cómo comparar arquitecturas por memoria, autenticación y gestión de claves.
Arquitectura de memoria, nivel de seguridad, codificación y personalización.
Cómo encaja la decisión en una política con perfiles, emisión y revocación.
Envíe fotografías, medidas y contexto para confirmar frecuencia, formato de datos y referencia de reposición.
Cantidad, personalización, plazo y criterio de aceptación para convertir la especificación en un lote.
Siguiente paso