Asegurar la autenticidad de las tarjetas mifare, protección contra la clonación

1

Estoy diseñando un flujo de trabajo para emitir y adquirir tarjetas de cupones para un cliente y la tecnología elegida para las tarjetas ha sido mifare desfire.

Tengo mucha experiencia con tarjetas de crédito y queremos que la tecnología sea lo más amigable posible con el POS, por lo que el proceso de adquisición podría ser lo más simple posible para conectarse a los flujos de trabajo de las aplicaciones POS existentes.

Además, el HSM es uno de los que realmente se centran en las tarjetas de crédito, por lo que si quiero mantener los beneficios de seguridad de tener un HSM bloqueado con una gran seguridad, necesito usar la criptografía "estándares de la industria".

La tarjeta está en circuito cerrado. Tengo control total sobre todos los componentes del proceso de emisión y adquisición. Mi ingenua primera idea fue hacer que la tarjeta generara una firma para la transacción, pero mirando la especificación de los comandos de la tarjeta, nada corresponde realmente a esto, no es más que un almacén de datos con comunicación cifrada.

Entonces, la respuesta podría ser "usar el cifrado de canal de Luke", pero este cifrado debe ocurrir entre el POS y el dispositivo, lo que significa que el POS debe hacer una llamada en línea durante la duración del deslizamiento sin contacto (mal móvil) internets, etc.) o el TPV debe conocer las claves de la tarjeta, lo cual no es bueno.

Así que mi pregunta es, ¿realmente lo entendí bien y la única manera de asegurar esto en la adquisición es:

  1. comparte el secreto con la red POS
  2. hacer que el TPV se comporte como un canal para que el host intercambie los mensajes seguros, pero no estoy seguro de que esto sea una opción

¿Me estoy perdiendo algo?

    
pregunta bbozo 01.02.2017 - 14:34
fuente

2 respuestas

0

De hecho, no me faltaba nada, las únicas opciones son:

  1. comparta la clave secreta maestra del esquema de emisión con toda la red POS (una idea ba-ad)
  2. use un HSM del lado del servidor para crear claves de sesión para la comunicación NFC, lo que significa que el POS y el servidor deben intercambiar un ciclo de solicitud / respuesta de API a mitad de pase para que el POS pueda autenticarse con la tarjeta

Aparentemente, Mifare se diseñó como una solución de bajo costo y bajo riesgo, algo que si se rompe le permitiría al atacante obtener menos valor que el esfuerzo de romperlo, y es muy seguro en este rol. / p>

Hay otras tecnologías (por ejemplo, enlace ) que te permiten hacer más seguro & flujos de trabajo más robustos, y vienen con una etiqueta de precio para que coincida.

EDIT al final opté por una API del lado del servidor donde

  1. el componente del servidor tiene acceso a las claves de la tarjeta a través del HSM y
  2. puede responder a la cadena card-challenge con la cadena challenge-response
  3. y en la misma respuesta de API envía la clave de sesión al dispositivo
  4. la clave de sesión está a su vez protegida mediante el mismo tipo de tecnologías que se aseguraría un bloqueo de PIN (claves de sesión, DUKPT, almacenamiento seguro de claves en el dispositivo).

Donde "dispositivo" es el "dispositivo que habla con la tarjeta Mifare". El resultado final parece "suficientemente bueno" porque:

  1. las claves maestras de las tarjetas individuales no se comparten con los dispositivos; la mayoría de las implementaciones dependen de la clave maestra de la tarjeta para compartirlas de alguna manera, y esto no es necesario para mi caso de uso
  2. solo se necesita una llamada a la API para el HSM en la nube para que la comunicación se realice (la mayoría de las otras implementaciones que he visto hacen% de transferencia total co% de% significa 2 a 4 llamadas como mínimo durante el movimiento de deslizar la tarjeta) que es un no-go para mi caso de uso
  3. en el peor de los casos, el atacante puede descubrir la clave de la sesión del intercambio individual, y esto solo si logró romper el mismo tipo de criptografía que protege los bloques de PIN en la industria de PCI

Supongo que este es el punto ideal para lo que necesito.

    
respondido por el bbozo 01.02.2017 - 19:04
fuente
0

DESfire EV1 ahora se considera seguro (posterior a 2008) y no se puede clonar. Cómpralas directamente desde NXP. Las claves secretas no pueden ser rastreadas, ya que nunca dejan la tarjeta. El UID es irrelevante, y establecerlo en forma aleatoria puede confundir incluso a un actor de habilidad media.

Aquí hay un enlace al código para manejar las tarjetas DESfire (aunque en un Teensy 3.2, utilizando el C ++ ligeramente simplificado de Arduino)

enlace: enlace

extracto: Mifare Desfire EV1 Tarjetas En 2009 entró en el mercado la siguiente generación: el Mifare Desfire. Cartas EV1 que se han mejorado una vez más y hasta hoy no se conoce ningún ataque. Por lo tanto, si usa las tarjetas Desfire EV1, no necesita una Cartera de acero inoxidable. Comprar tarjetas Desfire EV1 es más difícil. No hay tantas ofertas y las más baratas requieren que compre cantidades de 50, 100 o incluso 500 tarjetas. Encontré estas dos compañías que también venden cantidades más pequeñas: RyscCorp y Smartcard Focus. También puede hacer un pedido a Smartcard America, que vende a través de eBay, pero su envío es muy caro para otros países. Tenga cuidado con las ofertas falsificadas de China en eBay: no hay garantía de que los clones chinos cumplan con los mismos criterios de seguridad que las tarjetas NXP originales. Comparación con Mifare Classic < - > Desfire Clásico mifare Mifare Desfire EV1 Identificador único 4 bytes UID siempre se puede leer sin cifrado 7 bytes El UID siempre se puede leer sin cifrado en el modo normal, pero requiere la clave maestra PICC en el modo de identificación aleatoria. Almacenamiento EEPROM En una tarjeta con memoria de 1kB: 16 sectores de 4 bloques de 16 bytes cada uno. (Los bloques y sectores tienen tamaño fijo). Hasta 28 aplicaciones de las cuales cada una puede contener hasta 32 archivos de tamaño variable Llaves Cada sector puede protegerse con dos claves (clave A y clave B) con diferentes permisos por clave Cada aplicación se puede proteger con hasta 14 claves diferentes con diferentes permisos por clave Cifrado Propietario (Crypto-1, 48 bit) DES (56 bits), 2K3DES (112 bits), 3K3DES (168 bits), AES (128 bits) Seguridad El cifrado se ha roto en 2008 No se conocen ataques hoy Mientras que las tarjetas Classic son completamente estáticas, las tarjetas Desfire almacenan datos en "archivos" de tamaño dinámico que están contenidos en "aplicaciones". ¿Qué es una aplicación? Una aplicación no es más que un contenedor de archivos. Imagina una tarjeta RFID emitida a los estudiantes de una universidad. Con la misma tarjeta el estudiante puede comer en la cantina y puede estacionar su auto. En este ejemplo, habría dos aplicaciones independientes en la tarjeta: una aplicación de cantina y una aplicación de estacionamiento. El estudiante puede cobrar dinero por el almuerzo y el estacionamiento que se almacena en un archivo en la aplicación correspondiente. Cada aplicación tiene una o varias claves de cifrado (la claves de aplicación) que permiten cambiar el valor almacenado en la aplicación respectiva. Cada clave puede tener solo permiso de lectura, solo permiso de escritura o ambos. Además, la tarjeta tiene otra clave importante: la clave maestra PICC, que es la "clave divina". La clave maestra PICC permite crear y eliminar aplicaciones, asignar claves a cada aplicación o incluso formatear la tarjeta completa. Pero curiosamente, la llave maestra PICC NO puede acceder a los datos almacenados en las aplicaciones. Ni la cantina ni la plataforma de estacionamiento conocen la llave maestra PICC. Solo tienen acceso a su aplicación correspondiente pero no fuera de ella.

    
respondido por el user400344 04.03.2017 - 07:54
fuente

Lea otras preguntas en las etiquetas