¿Es insegura la creación de una aplicación de pago NFC sin un elemento seguro como Apple Pay?

Question

¿Es insegura la creación de una aplicación de pago NFC sin un elemento seguro como Apple Pay?

#1 de lxgr (1 votos)

3

Supongamos que trabajo para un banco y me piden que escriba una aplicación de pago NFC para el iPhone 6 o Android pero no use Apple Pay. Para enviar simplemente los detalles de la tarjeta de crédito al lector a través de NFC.

Ahora, suponga que no estoy almacenando los detalles de la tarjeta de crédito utilizando un hash one-one que la compañía de tarjetas de crédito en el otro extremo coincidirá para validar el pago. Suponga que simplemente le estoy dando los detalles de la tarjeta de crédito al lector, de una manera similar a la de un asistente de tienda que escribe manualmente los números de la tarjeta de crédito en el lector cuando falla la banda magnética.

Para hacer eso: tengo que almacenar los datos de la tarjeta de crédito, ya sea sin cifrar o de manera bidireccional cifrada en el iPhone o Android.

Si lo guardo como no cifrado en el iPhone o Android, entonces cualquier otra aplicación podría leer los datos y potencialmente enviarlos para un uso indebido. (De forma similar a como funciona FileApp ).

Si lo guardo como cifrado en el iPhone o Android, entonces tiene que ser un cifrado bidireccional, y luego cualquier otra aplicación que use ese mecanismo de cifrado puede leer los datos del teléfono. (Es decir, puede obtener el mecanismo de cifrado mediante ingeniería inversa LLVM bytecode de mi aplicación).

Mi pregunta es: ¿Es inseguro crear una aplicación de pago NFC sin un elemento seguro como Apple Pay para iPhone o Android?

iphone file-encryption payment-gateway

pregunta hawkeye 24.09.2014 - 01:16

fuente

1 respuesta

Lea otras preguntas en las etiquetas iphone file-encryption payment-gateway

¿Cuál es el punto de las puertas de enlace de correo electrónico seguras? ¿Es normal que un procedimiento de pago solicite la activación de cookies de terceros?

score 1 · Accepted Answer

La información almacenada en un teléfono que usa HCE para pagos sin contacto probablemente esté limitada de alguna manera (tiempo, uso o ambos).

Tome Google Wallet (la versión HCE): Google indica que

Necesitarás estar conectado a Internet para desbloquear la aplicación con tu PIN de seguridad de 4 dígitos y tocar y pagar en las tiendas. Sin embargo, si establece el tiempo de espera de su PIN en la configuración de la aplicación, puede estar desconectado hasta 24 horas y seguir tocando y pagando sin estar conectado a Internet.

Esto suena como si los datos dinámicos por transacción que crea el teléfono para cada transacción solo sean válidos por un tiempo limitado. Idealmente, las claves / secretos utilizados se reemplazarán cada vez que el teléfono pueda conectarse a Google Wallet.

Algunos teléfonos Android también admiten un almacén de claves respaldado por hardware , que permite crear una clave RSA dentro de una parte protegida del sistema; el sistema operativo solo permitirá que los usuarios de la API realicen operaciones de clave privada, pero nunca revelarán la clave en sí. Esto podría presumiblemente usarse para emular el comportamiento de un elemento seguro dedicado (no sé si los formatos de clave utilizados son compatibles con la especificación EMV. Sin embargo, los elementos físicos seguros también tienen la ventaja de que pueden conectarse directamente a la NFC interfaz del teléfono y detectar si se están comunicando con un lector NFC real o con un software en el procesador de la aplicación).

Por supuesto, si el atacante puede controlar completamente el teléfono (p. ej., explotando algún error de seguridad en el marco de Android o en el kernel de Linux, que ambos han ocurrido antes), podría ser posible copiarlo (o retransmitirlo) en tiempo real) todos los datos necesarios para autenticarse en los servidores de Wallet y rastrear el PIN del usuario mientras se ingresa. Esto (con suerte) lo detectaría el operador de HCE (por ejemplo, buscando solicitudes simultáneas que usen las mismas credenciales de diferentes ubicaciones de red).

Nota: interpreté tu requisito de "no usar Apple Pay" como "no usar un elemento seguro como lo hace Apple Pay", ya que parece poco probable que Apple permita aplicaciones de pago sin contacto de la competencia en iOS (Actualmente no hay ninguna API NFC, e incluso si lo fueran, dudo mucho que las aplicaciones de pago NFC puedan distribuirse en la App Store). Las aplicaciones de Android, por otro lado, no podrían utilizar Apple Pay por razones obvias.