Estudio sobre Seguridad en los Pagos Móviles

Estudio sobre
Seguridad en los
Pagos Móviles
Estudio sobre Seguridad en los Pagos Móviles
Contenidos
SUMARIO EJECUTIVO
4
INTRODUCCIÓN
5
1. 2.INTRODUCCIÓN A LA SEGURIDAD
6
2.1 Diferentes tipos de seguridad
2.2 Objetivos de seguridad
2.3 Tipos de medidas de seguridad
6
7
7
SEGURIDAD EN EL PAGO MÓVIL
8
3.1 Almacenamiento de datos seguro
3.2 Vulnerabilidades del ecosistema
8
11
4. SOLUCIONES DE SEGURIDAD HARDWARE Y SOFTWARE EN PAGOS MÓVILES
14
4.1 Elemento seguro y soluciones de HCE 4.2 Marco de evaluación de la seguridad
4.3 Evaluación de la seguridad
14
16
16
5. 18
3.
Sumario
3
Estudio sobre Seguridad en los Pagos Móviles
Sumario Ejecutivo
Los servicios de pago móvil se evalúan para entender el riesgo que tienen. Esta evaluación se usa
para obtener un nivel de riesgo transparente que pueda ser estudiado, asumido y gestionado por las
entidades bancarias.
Con las nuevas formas de implementación de servicios que ofrece la emulación de tarjeta situada en el
host (HCE por sus siglas en inglés), las entidades bancarias se están interesando por sacar servicios más
flexibles en un ecosistema menos complejo. Sin embargo, hay una contrapartida al pasar de las soluciones
de seguridad hardware a las software. Las soluciones situadas en el hardware, como el elemento seguro
a prueba de manipulación (SE por sus siglas en inglés), han sido probadas contra los últimos ataques
del mercado. Las soluciones más recientes que usan la seguridad software, como la HCE, tienen un
nivel seguridad desconocido. Las medidas de seguridad pueden reducir la probabilidad y el impacto de
un ataque con éxito basándose en lo que se sabe actualmente y en la utilización de medidas lógicas y
procedimentales. Sin embargo, la eficiencia de una implementación específica de estas medidas tendrá
que ser verificada y evaluada con el tiempo.
La seguridad de los pagos móviles sin contacto (contactless) se ha garantizado tradicionalmente
mediante un elemento seguro de hardware a prueba de manipulación, inspirado en las tarjetas con
chip y PIN, que controla el nivel de seguridad de las transacciones mediante un proceso bien conocido.
Este sistema requiere que múltiples partes participen unidas, en especial las operadoras de telefonía
móvil cuando el SE es la tarjeta SIM. La HCE hace posible que aplicaciones de pago únicamente de
software puedan acceder a la interfaz contactless sin necesidad de usar un elemento seguro físico.
Algo interesante para a los bancos, interesados en desplegar sus aplicaciones con más flexibilidad.
Sin embargo, sin un elemento seguro, la HCE no proporciona las herramientas para proteger a las
aplicaciones de pago, por lo que son necesarias medidas de seguridad adicionales que reduzcan la
probabilidad y el impacto de un ataque con éxito.
Este estudio explora las vulnerabilidades típicas del sistema de pagos móvil y las medidas de seguridad
que se aplican a soluciones de pago con y sin elemento seguro en hardware, evaluando su impacto en:
•Limitaciones a la seguridad – alcanzar un nivel de riesgo similar
•Complejidad y coste – implementar las medidas de seguridad que se estime necesario
•Usabilidad – impacto en la experiencia del usuario
•Auditabilidad – capacidad de evaluar el nivel de riesgo con un buen nivel de confianza
Se han extraído cuatro conclusiones principales:
•La complejidad de todo el ecosistema puede reducirse con soluciones de seguridad software
sin presencia de un elemento seguro en hardware. Al mismo tiempo, la complejidad se desplaza
hacia las entidades financieras, que cargarán con todas las medidas de seguridad en su back-end,
aplicación y procesos.
•Hay un impacto en el coste con ambas soluciones: La complejidad a la que se enfrenta la entidad
financiera para implementar y gestionar las nuevas medidas de seguridad software, llevará aparejada
costes aún desconocidos; un SE hardware necesita una inversión significativa dentro de una
infraestructura múltiple, con costes distribuidos entre sus partes.
•La usabilidad de una solución software requerirá la provisión de tokens temporales en los
dispositivos, para autorizar transacciones y realizar actualizaciones de seguridad periódicas. Algo
que requieren que el usuario se re-autentique de forma que la solución sea capaz de acceder a
los datos sensibles almacenados en la nube. Un diseño cuidadoso será necesario para preservar la
calidad de la experiencia del usuario.
•La auditabilidad es posible a través de procesos formales en los tests y evaluación de la certificación
y seguridad de las soluciones de SE en hardware. Es difícil poner en práctica procesos similares
para muchas soluciones software no estandarizadas. Por ahora, la evaluación debe realizarse caso a
caso y el nivel de riesgo real se evaluará de forma más fiable cuando se hayan recogido experiencias
suficientes del mercado.
4
Estudio sobre Seguridad en los Pagos Móviles
1. Introducción
A medida que los dispositivos móviles se hacen más prevalentes como
herramientas para pagos y banca, la seguridad de la información
confidencial que se utiliza se hace más importante. Consideraciones
como de qué forma las aplicaciones y las transacciones se aseguran
y entregan y cómo se identifica de forma segura al usuario son
preocupaciones clave del ecosistema móvil de pago. Las soluciones de
pago están siendo evaluadas por la gestión de riesgos de los bancos,
en su investigación para implementar el pago móvil.
Este trabajo de debate, dirigido a las entidades bancarias y escrito en
colaboración con UL, ofrece una visión general informativa y de alto
nivel de la tecnología de seguridad involucrada en la implementación
de las soluciones de pago móviles. Más específicamente, este
documento considera las implicaciones en la seguridad de soluciones
de pago móvil hardware (por ejemplo, el elemento seguro) y software
(por ejemplo, la emulación de tarjeta de host).
El documento describe los objetivos generales, las necesidades y los
tipos de seguridad, centrándose específicamente en los pagos móviles.
Cubre el almacenamiento de datos confidenciales, las medidas de
seguridad móvil y las vulnerabilidades del ecosistema, proporcionando
un marco de evaluación que compara las soluciones de seguridad
hardware y software existentes en el mercado hoy en día.
5
Estudio sobre Seguridad en los Pagos Móviles
2. Introducción a la seguridad
La seguridad se mide a menudo teniendo en cuenta el riesgo y el riesgo
global asociado con los pagos. Este capítulo proporciona una amplia
visión general de los diferentes tipos de seguridad y sus objetivos y
explica las medidas de mitigación de riesgos.
2.1 Diferentes tipos de seguridad
Se puede representar la seguridad como un triángulo cuyas esquinas son: La seguridad física,
la lógica y la procedimental. El nivel general de seguridad lo determina el eslabón más débil.
Seguridad física
La seguridad física se basa en elementos
físicos o de hardware. El objetivo de
la seguridad física es salvaguardar la
información mediante elementos de
hardware a prueba de manipulación, donde
la información confidencial se almacena y
donde se ejecutan operaciones cruciales.
Este punto se analiza en mayor profundidad
en la sección 3.1
Seguridad lógica
La seguridad lógica se basa en las garantías
del software que tiene un sistema. Aunque el
software se ejecuta mediante un hardware,
la seguridad lógica no utiliza elementos del
hardware para proporcionar seguridad. Este
punto se analiza más en profundidad en la
sección 3.1
Seguridad procedimental
La seguridad procedimental o administrativa
se basa en la protección de la información
confidencial mediante procedimientos
dentro de las organizaciones. La seguridad
procedimental protege la confidencialidad,
integridad y/o acceso a la información
mediante distintos procedimientos y
medidas de seguridad propios de cada
organización, que pueden ser implementados
de forma proactiva o reactiva. La seguridad
procedimental es diferente en cada
aplicación y debe verse en cada caso
específicamente.
Triángulo de seguridad
Física
Lógica
6
Figura 1:
0011101110000
110SECURITY1
11011100010111
0000111011010
1101010100001
Procedimental
000110111111101
0001000111100
1111111010101101
Estudio sobre Seguridad en los Pagos Móviles
2.2 Objetivos de seguridad
La seguridad tiene el objetivo general de proteger activos relevantes de amenazas a la
confidencialidad, integridad y disponibilidad a través de medidas seguras.
Activos
Los activos incluyen la información
confidencial del usuario, como el número
de cuenta primario (PAN), las claves de
acceso y los tokens. Estos activos pueden
ser capturados por atacantes como usuarios
fraudulentos, comerciantes fraudulentos y
piratas informáticos.
Amenazas
Un sistema puede ser atacado por diferentes
lugares, conocidos como sus puntos
de vulnerabilidad. Las vulnerabilidades
son atacadas cuando los activos son
considerados como valiosos por el atacante.
Medidas de seguridad
Las medidas de seguridad se pueden aplicar
para mitigar el riesgo de amenaza a un activo
valioso. Se pueden no aplicar las medidas de
seguridad o reducirlas para acelerar la salida
al mercado o reducir costes (en sus fases de
prueba o piloto).
2.3 Tipos de medidas de seguridad
Siempre se evalúa la seguridad de una aplicación para estimar correctamente el nivel de
riesgo general. Esto proporcionará a la entidad bancaria un nivel de riesgo que sea aceptable
y manejable. Las medidas de seguridad son una forma de hacer que el ataque sea complejo y
caro, al tiempo que se reduce el valor y la visibilidad de los activos. Hay dos tipos de medidas
de seguridad para mitigar riesgos:
• Reducir la probabilidad de un ataque exitoso
La probabilidad de un ataque exitoso se
reduce mediante la implementación de
una seguridad robusta y adecuada. Esto
podría hacerse, por ejemplo, mediante el
almacenamiento de datos confidenciales
en lugares a prueba de falsificaciones.
La ocultación de información por
medios criptográficos también hace que
el esfuerzo o coste de un ataque sea
demasiado grande.
• Reducir el impacto de un ataque exitoso
El impacto de un ataque exitoso se reduce
mediante la devaluación de los activos
que se pueden conseguir. Por ejemplo, la
tokenización reduce el impacto ya que los
activos (tokens) tienen un valor limitado
para el atacante. Esta estrategia permite
a las entidades aceptar un menor nivel de
seguridad y mantener un nivel de riesgo
aceptable.
Implementación del mercado: Apple Pay
Apple Pay permite a los usuarios realizar
pagos NFC. La tokenización se usa para
almacenar los datos de la tarjeta de pago.
Además, un código de seguridad dinámico
validará cada transacción. El usuario
confirma la transacción mediante el TouchID.
Principales mecanismos de seguridad:
•SE: almacena el número de cuenta
del dispositivo único y números de
transacción únicos de cada operación.
•Verificación de usuario y hardware:
verificación de usuario mediante TouchID
•Tokenización: el número de cuenta
primario (PAN) tokenizado se guarda en
el dispositivo, se usan números únicos
individuales para cada transacción.
•Criptografía: el número de cuenta
único del dispositivo se guarda
criptográficamente, se generan
criptográficamente números únicos para
un uso.
7
Estudio sobre Seguridad en los Pagos Móviles
3. Seguridad en el pago móvil
Las entidades bancarias trabajan con información de pago
confidencial y los pagos móviles introducen retos de seguridad
adicionales para las entidades.
Las entidades tienen el reto de autentificar
al usuario y a su dispositivo, así como
almacenar de forma segura y local en el
dispositivo móvil el número de cuenta
primaria (PAN), las claves de acceso y los
criptogramas. El nivel general de riesgo
debería seguir siendo manejable para las
entidades cuando implementan la seguridad
de las soluciones hardware o software
de pago móvil. Tiene que considerarse
el impacto en aspectos críticos como la
usabilidad, los costes, la auditabilidad y la
complejidad. Para gestionar los activos las
entidades pueden implementar soluciones de
seguridad hardware o software.
3.1 Almacenamiento de datos seguro
Un factor importante para determinar el nivel de seguridad es donde se generan, procesan y
almacenan los datos confidenciales o credenciales. La seguridad del almacenamiento debería
depender de la sensibilidad de los datos, ya que cada solución tiene un impacto en el riesgo.
Las entidades tienen cuatro alternativas para generar, procesar y almacenar información
confidencial.
Unidad Central de Procesamiento del
host (CPU)
La información confidencial es gestionada
por la aplicación que se ejecuta en el sistema
operativo (SO) del dispositivo móvil. La
protección frente a posibles ataques es baja
ya que el único mecanismo de seguridad
por defecto es el ‘sandboxing’, que separa
programas en ejecución “no verificados”. En
este caso, el SO Android aísla los activos a
nivel del SO.
Almacenamiento seguro en la nube
La información confidencial se gestiona en
un servidor de red en la nube. El dispositivo
móvil tiene que establecer una conexión
segura para obtener esta información. El
usuario debe autenticarse a sí mismo, a la
aplicación y al dispositivo. En soluciones
software, la autenticación de un dispositivo
se resuelve mediante la ocultación de las
claves de usuario con ofuscación de código o
criptografía de
caja blanca.
8
Entorno de ejecución seguro
El entorno de ejecución seguro (TEE) es un
área segura de la CPU de los dispositivos
móviles. El entorno TEE ofrece la ejecución
segura de “aplicaciones de confianza” y
refuerza los derechos de acceso, además
de almacenar la información confidencial.
El TEE ejecuta su propio sistema operativo,
que separa los recursos de seguridad de su
hardware y su software de los del sistema
operativo principal. Asignar información
confidencial al TEE ofrece retos similares a
asignarla a través de un gestor de servicios
de confianza (TSM) o servidor de la
aplicación. El TEE generalmente carece de
la resistencia a la manipulación de un SE
de hardware. Cada fabricante de equipos
ha desarrollado su propia versión de esta
tecnología, como Knox en Samsung (que
utiliza el TrustZone de ARM) y Secure
Enclave de Apple.
Estudio sobre Seguridad en los Pagos Móviles
Medidas de seguridad lógicas para
soluciones de pago móvil
Hay muchas soluciones de seguridad lógicas
vinculadas a las aplicaciones de pago móviles.
Entre ellas:
A. Verificación de usuario y hardware
La autenticación se puede hacer mediante:
• Lo que el usuario sabe: como el nombre de
usuario y contraseña, el PIN, el patrón
• Lo que el usuario tiene: como el identificador
de dispositivo único o el token
• Cómo se comporta el usuario: como la
localización e historial de transacciones
• Lo que el usuario es (identificación
biométrica): como la huella dactilar, o los
reconocimientos de voz y facial
Se pueden combinar múltiples métodos en una
autenticación dual. Por ejemplo, identificadores
de hardware como el IMEI o el ICCID se podrían
usar en conjunto con la autenticación del usuario.
D. Criptografía de caja blanca
El propósito principal de la criptografía de caja
blanca es implementar un gran conjunto de tablas
de búsqueda y codificar sus claves. Todas las
operaciones criptográficas implican una sucesión
de tablas de búsqueda durante una operación
determinada y estas dificultan la posibilidad de
adivinar la clave correcta utilizada durante la
operación. Los activos permanecen seguros ya que
están “ocultos” para el atacante incluso cuando éste
tiene acceso a todos los recursos, ataque conocido
como de “caja blanca”. Mediante la ocultación de
la clave de la aplicación, la distribución se hace
más compleja ya que cada aplicación tiene que ser
definida de forma única por el usuario.
E. Ofuscación
Limitar las transacciones puede reducir el
impacto de una violación de la seguridad.
Algunos ejemplos:
• Pagos de bajo valor y limitación de
transacciones en un plazo determinado
• Permitir sólo las transacciones online para
pagos de proximidad
• Restricciones de localización/país
Las limitaciones a la transacción son aprobadas
por la entidad y almacenadas en el SE o en
el punto de venta, complicando mucho su
modificación por malware.
La ofuscación de código es un método para escribir
deliberadamente el código o partes del código
de una forma que sea difícil de entender. Así, se
dificulta que los hackers reviertan el código de
ingeniería y se ocultan las partes críticas o secretos
de código. Se presenta de diferentes formas:
• Transformaciones abstractas: destruyen la
estructura del módulo, clases, funciones
•Transformaciones de datos: remplaza
las estructuras de datos con nuevas
representaciones
• Transformaciones del control: destruye
formaciones condicionales del tipo si-, cuando-,
o haz• Transformaciones dinámicas: hacen que el
programa cambie durante su ejecución
C. Controles del sistema operativo
F. Tokenización
Las aplicaciones pueden recuperar la configuración
del sistema operativo (OS) para verificar si un
dispositivo está invadido o “arraigado”. El riesgo
de los dispositivos arraigados es que el usuario y
el hacker son capaces de asumir el control de los
procesos y operaciones controladas por el SO y
pueden pasar por alto las garantías de seguridad y
tener acceso al punto de almacenamiento seguro. Un
usuario puede:
• Alterar los identificadores del dispositivo o
aplicación, usados en la verificación del hardware
• Obtener acceso al código de las aplicaciones
donde se almacena información confidencial
• Instalar aplicaciones maliciosas que pueden
llevar a cabo acciones fraudulentas como
ataques al intermediario.
Con la tokenización, la información confidencial se
sustituye por algo menos confidencial: un token. El
valor del activo se reduce drásticamente, haciéndose
menos interesante para un atacante. Los tokens
pueden ser generados y reemplazados fácilmente
sin comprometer el Número de Cuenta Primario
(PAN). Hay dos formas de tokenización:
• Tokenización EMVCo: Una versión tokenizada
del PAN se vincula al usuario y se guarda en un
dispositivo único.
• Clave tokenizada: Se genera un token por cada
uso o serie limitada de usos que el usuario
autentifica antes de establecer una conexión
segura
B. Limitar las transacciones
9
Estudio sobre Seguridad en los Pagos Móviles
MEDIDAS DE SEGURIDAD FÍSICAS PARA
SOLUCIONES DE PAGO MÓVILES
Elemento seguro
El SE en hardware es un elemento a prueba de manipulación en dispositivos móviles y se
presenta como una tarjeta de circuito integrado universal (UICC) o SE incrustado (eSE).
Estos elementos seguros han sido testados contra los métodos de ataque más recientes,
siguiendo los requerimientos de seguridad de organismos de confianza.
Las principales características del SE son:
• Las claves e información confidencial se guardan en el SE
• Se necesita que se ejecute una aplicación segura del SE para procesar la información
confidencial. Las aplicaciones seguras pueden contener información confidencial y la
combinación de sistemas UICC y de pago tiene que estar certificada.
•Cuando la aplicación se ejecuta fuera del entorno del SO del dispositivo, tanto la
aplicación como las claves son más difíciles de alcanzar por el malware.
Implementación del mercado: Softcard
El monedero Softcard, anteriormente
conocido como Isis, es una iniciativa
conjunta de tres operadores móviles
que proporcionan una aplicación de
monedero basada en el SE. El monedero
ofrece pagos de proximidad NFC, así
como tarjetas de fidelización. Una versión
virtualizada de la tarjeta de pago se
guarda en el SIM del dispositivo móvil.
10
Principales mecanismos de seguridad:
•SE: almacenamiento de información
confidencial de pago en un UICC a
prueba de manipulación (SIM)
•Restricciones a las transacciones:
pagos de bajo valor sin PIN móvil,
pagos de alto valor con PIN móvil
•Verificación de usuario y hardware: PIN
móvil para desbloquear la aplicación +
Verificación del ID del dispositivo
Estudio sobre Seguridad en los Pagos Móviles
3.2 Vulnerabilidades del ecosistema
Un análisis pormenorizado de las posibles amenazas y vulnerabilidades del ecosistema
se muestra en la Figura 2. También se ofrecen posibles medidas para mitigar el riesgo de
amenaza. Cada implementación requerirá un análisis individual de riesgos para identificar
vulnerabilidades específicas.
EJEMPLOS DE VULNERABILIDADES DEL ECOSISTEMA:
Sistema situado en la nube
Un ataque con éxito a un sistema situado en la
nube supondría un hackeo, manipulación y/o
divulgación de información confidencial. Las
posibles amenazas para el sistema de pago
de la nube incluyen la interceptación de datos
confidenciales por un atacante que suplante la
identidad, la interceptación de datos mediante
malware y la redirección de los datos de la
aplicación a otro dispositivo móvil. Con estos
métodos un atacante puede obtener los activos
como el usuario y datos de la tarjeta, los valores
del método de verificación de la tarjeta (CVM),
las claves de acceso o incluso el control de la
totalidad de las aplicaciones de pago móvil.
Los mayores desafíos son la autenticación del
acceso seguro del usuario a la nube. Para que
el sistema basado en la nube pueda gestionar
los pagos tokenizados, deben implementarse
los sistemas que gestionan estos tokens, de
forma que se pueda tokenizar y detokenizar la
información confidencial.
Aplicación de pago móvil
Un ataque con éxito a la aplicación de pago
móvil podría resultar en la descompilación
del código fuente, de forma que el atacante
obtiene acceso a todos los activos ocultos en
la aplicación (como autenticadores y claves
criptográficas). La integridad de una aplicación
también puede verse comprometida por la
manipulación de datos y la distribución de
datos confidenciales capturados mediante
aplicaciones clonadas. Otra vulnerabilidad es el
punto de venta móvil, ya que un comerciante
fraudulento puede manipular la aplicación móvil
que controla el punto de venta móvil. Con estos
métodos, un atacante puede obtener activos
como los usuarios y datos de la tarjeta bancaria,
los valores de los sistemas de verificación de
la tarjeta (CVM) y las claves de acceso. Los
mecanismos de seguridad como la criptografía
de caja blanca reducen la probabilidad de
clonación y decompilación de aplicaciones de
pago móvil. El momento de introducción de
datos confidenciales en el SE o del envío de un
token son grandes puntos de vulnerabilidad en
las aplicaciones de pago móviles.
Dispositivo móvil
Los ataques al dispositivo móvil podrían ir
dirigidos a conseguir activos en el propio
dispositivo: el SE, el procesador NFC y el
sistema operativo (SO) del móvil. El SO del
móvil tiene puntos débiles a través del puerto
de depuración o los virus de enraizamiento,
que permiten obtener acceso a la aplicación de
pago móvil. Además, otros mecanismos como
un registrador de pantalla pueden obtener
información clave de acceso del usuario. Las
posibles medidas de seguridad son el PIN
offline, chequeos del SO, criptografía de caja
blanca y un elemento seguro a prueba de
manipulación (TEE) para asegurar el teclado y
la pantalla.
Elemento seguro
El impacto de un ataque al elemento seguro
(SE) es alto, sin embargo, la probabilidad de un
ataque exitoso es muy baja, dado al alto nivel
de seguridad de un elemento seguro a prueba
de manipulación (TEE). El aspecto más crítico
de la seguridad es el control de acceso al SE,
que define el acceso a las aplicaciones móviles.
Se basa en certificados implementados por
el proveedor del servicio, que se usan para
autenticar o registrar la aplicación en el SE.
Punto de venta – Interfaz NFC
La interfaz de un punto de venta NFC podría
sufrir ataques de relé en pagos de bajo valor.
La interfaz NFC puede ser mal utilizada por
un comerciante fraudulento que simule pagos
‘sin PIN’. La manipulación de los datos también
podría venir por parte de un atacante que
recolecte las claves de acceso. El malware
en el procesador NFC es una posibilidad que
permitiría redirigir datos confidenciales. El
impacto de estos ataques puede reducirse con
la implementación de medidas de seguridad
como la tokenización.
11
Mobile Payment Security discussion paper
Mobile Payment Security discussion paper
Amenazas
Amenazas
• Intercepción mediante malware instalado en las aplicaciones
•S
uplantación de identidad: Intercepción de datos de la
aplicación y credenciales de autenticación
• Redirección de datos de la aplicación a otro dispositivo
• Captura del usuario, datos de tarjeta, valores CVM y claves
ECOSISTEMA SOFTWARE Y
HARDWARE CON AMENAZAS Y
POSIBLEs MEDIDAS DE SEGURIDAD
Posibles medidas
Posibles medidas
Entorno de ejecución de confianza
Criptografía de caja blanca (D)
Controles del sistema operativo (C)
Ofuscación (E)
Verificación de usuario y de
hardware (A)
!
Sistema en la nube
Gestión confidencial
Gestión de transacciones
Plataforma de la
aplicación
Plataforma en la nube
Situado en el software
• Manipulación mediante la
descompilación de la aplicación.
El atacante obtiene del usuario,
datos de tarjeta, valores CVM y
claves
• Suplantación de identidad/
Phishing: aplicación falsa/clonada
que captura datos confidenciales
(claves de acceso, mPIN)
• Manipulación por la inyección
de un código malicioso en la
aplicación
Amenazas
Elemento Seguro a prueba de
manipulación
(el TEE, cubre la mayoría de las
amenazas)
Verificación de usuario (A)
Situado en el hardware
Posibles medidas
!
Aplicación
de pago
SIM (UICC)
Entidad bancaria
(Procesador del servidor)
Red de
Pagos
Internet
Amenazas
• Manipulación con control
de acceso al SO y al
SE, accediendo a datos
confidenciales
• Phishing con captura de
datos confidenciales (claves
de acceso, mPIN)
• Interceptación de datos de
aplicación y autenticación.
Posibles medidas
Controles del Sistema Operativo (C)
Criptografía de caja blanca (D)
Ofuscación (E)
Entorno de ejecución seguro (TEE)
Verificación de usuario y de hardware (A)
Verificación de usuario y de hardware (A)
Controles del Sistema Operativo (C)
Entorno de ejecución seguro (TEE)
Ofuscación (E)
Amenazas
• Manipulación mediante el acceso a datos confidenciales por un
puerto de depuración o virus de enraizamiento
• Manipulación mediante la ejecución de un entorno simulado para
encontrar vulnerabilidades
• Captura del usuario, datos de tarjeta, valores CVM y claves
!
Móvil
!
Adquiriente
Aplicación
de pago
móvil
HCE APIs
Controlador
NFC
!
Punto de venta
• La vulnerabilidad del
dispositivo móvil radica en
el malware instalado en el
controlador NFC combinado
con un ataque de relé
• Un comerciante fraudulento
simula un pago de bajo coste
en el que no se necesitan
verificaciones adicionales
• Manipulación mediante la
captura de criptogramas
y claves de acceso para
descubrir la debilidad del
criptograma de acceso
Posibles medidas
Operador Telefonía
Móvil
Operador TSM
Entidad bancaria TSM
Verificación de usuario y de
hardware (A)
Restricciones a las
transacciones (B)
Autenticación o tokens (F)
Estudio sobre Seguridad en los Pagos Móviles
4.Soluciones de seguridad
hardware y software en
pagos móviles
Este capítulo presenta un marco de evaluación para ayudar a
comparar las soluciones de seguridad en pagos móviles hardware
y software. Soluciones típicas tanto software como hardware son
evaluadas en la figura 4.3.
4.1 Elemento seguro y soluciones de HCE
En esta sección se analizan una solución hardware y una software con niveles de seguridad
similares, incluyendo medidas de seguridad relevantes para la mitigación de riesgos.
La figura 4.1 analiza la solución de seguridad hardware basada en un SE. En el ejemplo, una
tarjeta de pago está guardada como tarjeta virtual en el SE. Se asume que:
• Toda la información de las tarjetas de pago se encuentra en y se recupera del SE
• Se pueden permitir pagos de bajo valor con medidas de seguridad reducidas, como ausencia
de PIN móvil
FIGURA 4.1
Solución de seguridad hardware en un elemento seguro
Aspecto de la
seguridad
Solución SE con dos medas de seguridad
Medidas de seguridad
1. Uso de UICC/ eSE
2. Los pagos de alto valor requieren PIN
Tipo de seguridad
Física
Lógica
Mitigación de riesgos
Reduce la probabilidad de un ataque
exitoso
Reduce el impacto de un ataque exitoso
En una solución hardware, la principal seguridad proviene del SE (por ejemplo una UICC).
Para proporcionar aplicaciones seguras y personalizar la aplicación de pago, se establece una
conexión segura con el SE y las entidades bancarias pueden de controlar por completo sus
activos dentro de la UICC a través de los estándares GlobalPlatform. 1
1. Especificaciones de GlobalPlatform. http://www.globalplatform.org/specifications.asp
14
Estudio sobre Seguridad en los Pagos Móviles
La figura 4.2 mira a una solución software en la nube, que se basa en la HCE. En este ejemplo,
los datos de la tarjeta de pago se almacenan en la CPU del servidor host. La aplicación móvil
que se ejecuta en ese servidor gestiona los datos de tarjetas de pago y se conecta a un
sistema de pago situado en la nube para autenticar al usuario y aprobar las transacciones. Los
supuestos para este ejemplo son:
• La tokenización se usa por la aplicación para generar claves. Estas contendrán todos
cualquier dato confidencial utilizado y proporcionarán autentificación de usuario
• La criptografía de caja blanca se usa para proteger los datos confidenciales
• Se activa el PIN offline u online dependiendo de la transacción
Figura 4.2 Solución de seguridad software de HCE
Aspecto de la
seguridad
Solución de HCE con tres medas de seguridad
Medidas de seguridad
1. Criptografía de caja blanca
2. Tokenización
3. Autenticación usuario
Tipo de seguridad
Lógica
Lógica
Lógica
Mitigación de riesgos
Reduce la probabilidad de un
ataque exitoso
Reduce el impacto de un
ataque exitoso
Reduce la probabilidad
de un ataque exitoso
En una solución de seguridad, la conexión con la red se realiza directamente desde la
aplicación a través de NFC. Para habilitar los pagos, el usuario tendrá que autenticarse en la
nube para obtener tokens de pago que le tendrán que ser suministrados de forma segura,
lo que implica un emisor de tokens. La tokenización se utiliza para reducir el impacto de un
ataque exitoso y estos tokens se almacenarán en el teléfono móvil para que el consumidor
pueda hacer los pagos. La solución software implica un menor número de partes implicadas,
pero necesita más medidas de seguridad de software para compensar la falta de un SE,
incluyendo las mencionadas en la figura anterior.
Implementación del mercado: Bankinter
Esta aplicación de pago móvil de software
ofrece transacciones de comercio
electrónico (pagos remotos) y pagos de
HCE en el punto de venta. Las tarjetas de
pago se guardan como tarjetas móviles
virtuales en el dispositivo, al que se
vinculan. No se necesita conectividad
móvil para transacciones NFC, sólo para
la reposición al dispositivo móvil de las
credenciales parcialmente calculadas.
Principales mecanismos de seguridad:
•Tokenización: en forma de creación de
una Tarjeta Virtual Móvil (MVT) en el
dispositivo y tarjetas de un solo uso
• Criptografía: criptograma EMV
•Limitaciones a las transacciones:
limitaciones de tiempo de 60 segundos
para cada tarjeta de uso único
• Validez
•Verificación de usuario y de hardware:
PIN de la Tarjeta Virtual Móvil +
verificación del ID del dispositivo
15
Estudio sobre Seguridad en los Pagos Móviles
Estudio sobre Seguridad en los Pagos Móviles
FIGURA 4.3 MARCO DE EVALUACIÓN
4.2 Marco de evaluación de
la seguridad
Para comparar soluciones, se utiliza un
marco de evaluación de la seguridad basado
en cinco aspectos: seguridad, usabilidad,
costes, auditabilidad y complejidad. Otros
factores, como los medios específicos de la
configuración, el despliegue y la viabilidad
de las medidas de mitigación de riesgos,
no se consideran en este marco, ya que son
específicos de cada implementación.
Marco
Seguridad
Las medidas de seguridad reducen la cantidad de riesgos y esta seguridad
debe evaluarse en cada implementación específica. Dentro del marco, la
estimación del riesgo se realiza de acuerdo con el ecosistema. Sus puntos
de vulnerabilidad y medidas de mitigación de riesgo posibles se comparan
con el impacto del posible fraude. El lugar de almacenamiento de datos
confidenciales es un factor importante para determinar el nivel general de
seguridad. Aquí se evalúa la seguridad factual, ya que la percepción de
seguridad del usuario varía según el mercado y cambiará con el tiempo.
Usabilidad
La usabilidad por lo general va en detrimento de los requisitos de
seguridad y la entidad bancaria tiene que equilibrarlos. Por ejemplo, las
contraseñas adicionales aumentan la seguridad, pero reducen la usabilidad
(la gente tiene que memorizar otra contraseña).
Solución hardware
Solución software
• La estrategia para mitigar el riesgo se centra en la reducción
de la probabilidad de un ataque con éxito. En una aplicación
situada en el hardware los activos de la entidad bancaria y del
usuario son almacenados de forma segura en el SE.
• La seguridad se proporciona mediante un SE a prueba de
manipulación, producido y testado durante más de 10 años.
• El suministro de datos es gestionado y enviado directamente
de forma segura, sin ir a través del SO del dispositivo.
• La seguridad ha sido certificada por proveedores de tarjetas
antes los ataques recientes más conocidos.
• La seguridad de una solución software no coincide con
la seguridad de una solución hardware. La mejora de la
seguridad de una solución software requiere criptografía de
caja blanca y métodos de verificación de usuario, que inciden
en otros aspectos del marco.
• La estrategia para mitigar riesgos se centra principalmente
en la reducción del impacto de un ataque con éxito a través
de la tokenización y limitaciones de transacción (sólo permite
pagos de bajo valor sin PIN), a fin de lograr un nivel de riesgo
global comparable a las soluciones hardware.
• Como se mencionó anteriormente, estas soluciones son un
desarrollo reciente y falta experiencia sobre el terreno para
evaluar plenamente el nivel real de riesgo a largo plazo.
• La usabilidad de una solución hardware es buena, ya que
ofrece la posibilidad de hacer pagos de bajo valor sin PIN y
pagos incluso cuando el dispositivo móvil está apagado.
• Cuando el SE es una UICC (SIM), los usuarios tienen la
posibilidad de portabilidad.
• El dispositivo debe estar encendido para realizar
transacciones.
• La conectividad móvil es necesaria de forma regular para
conectar con el servidor de tokens emplazado en la nube para
reponer tokens.
• La aplicación necesitará actualizaciones periódicas de
software para mantener las medidas de seguridad de software
al día.
• El acceso seguro a la nube requerirá del usuario que se vuelva
a autenticar periódicamente con mecanismos de autenticación
fuerte.
• Transacciones rápidas, como el pago de bucle abierto para
el transporte público, es posible que se queden fuera del
alcance.
• Para el aprovisionamiento seguro y personalización de tarjetas
de pago virtuales en los teléfonos móviles, se necesita que
se involucren partes como los proveedores de TSM y los
operadores móviles podrían cobrar una tasa por el uso de la
UICC como SE.
• El emisor no necesita contratar muchas partes externas, como
TSMs y, operadores móviles o gerentes SE, sin embargo,
otros miembros como un proveedor de servicios de token
u otro que provea/actualice el software de seguridad son
necesarios. Los costes adicionales para la gestión de nuevas
complejidades (ver en este marco el apartado complejidad)
incurrirán en otros costes de magnitud aún desconocida y
específicos de la implementación.
• La aplicación aún tiene que ser suministrada de forma
segura y personalizada con claves o tokens, que pueden ser
elaborados internamente o por una entidad externa.
4.3 Evaluación de la seguridad
El marco de evaluación de la seguridad
presenta una comparación exhaustiva
basada en cinco aspectos: seguridad,
usabilidad, costes, auditabilidad y
complejidad. Una comparación completa
requeriría un análisis completo de
riesgos de ambas implementaciones.
Nótese que en la práctica, la evaluación
del nivel de riesgo de una aplicación de
software tendrá que ser completada con
un período de monitorización operativa
antes de que esté funcionando el proyecto
(certificación, riesgo de las transacciones,
provisión para riesgos financieros). En
su lugar, se ofrece una comparación en
profundidad que tiene en cuenta las
características generales de las soluciones
hardware y software.
Costes
Los costes se ven afectados principalmente por el tamaño del ecosistema,
el nivel de implementación de la seguridad y el tipo de medidas de
seguridad.
• Se necesita una inversión significativa en infraestructura de
varias partes: generalmente el coste de la configuración y
gestión del TSM lo cubre el dueño del SE y la conexión es
cubierta por el usuario.
Auditabilidad
Otro aspecto importante para las entidades bancarias es la auditabilidad
que tiene la solución, sus transacciones y la integridad de las transacciones
que se realicen. Una implementación compleja es más difícil de evaluar.
Complejidad
La complejidad se puede determinar por el número de partes, el tamaño
del ecosistema y el nivel de seguridad deseado.
16
• Es robusto ya que hay un proceso establecido desde hace
muchos años para la prueba, la certificación y la evaluación de
la seguridad formal.
• La auditabilidad no está tan madura como con las soluciones
hardware ya que los procesos formales están siendo
desarrollados.
• Los procesos son deliberadamente oscurecidos o protegidos
criptográficamente, haciendo que sea menos transparente y,
en consecuencia, menos auditable.
• La complejidad de una solución de pago móvil de SE viene
dada por el gran ecosistema y la cantidad de partes externas
involucradas.
• Estas partes tienen que integrar y operar juntas para
lanzar una solución exitosa. Surgen dudas de integración
e interoperabilidad debido a la cantidad de interfaces y la
complejidad de ir sumando entidades bancarias adicionales u
operadores móviles.
• El ecosistema puede tener menos partes, aunque el papel
de los operadores móviles y TSMs es sustituido por los
proveedores del servicio de tokens y gestores de medidas de
seguridad software. La complejidad para la entidad bancaria
puede incrementarse. Los sistemas back-end de la misma,
necesitarán ser adaptados para incorporar una plataforma
de pago en la nube que gestione los pagos móviles y sea
capaz de autenticar a usuarios y pueda soportar este tipo
de transacciones. Por lo tanto, se deben hacer cambios
significativos en el sistema back-end de la entidad.
• Cuando la aplicación incorpora algoritmos criptográficos,
se necesita que otra parte haga llegar las claves o las
actualizaciones de seguridad. Otro ejemplo es la tokenización,
donde se requiere un gestor de tokens.
17
Estudio sobre Seguridad en los Pagos Móviles
5. Sumario
Se pueden obtener niveles similares de riesgo, sin embargo el impacto
en la usabilidad, costes, auditabilidad y complejidad varía, como se
puede comprobar en Figura 5.1.
FIGURA 5.1 RESUMEN COMPARATIVO DEL MARCO DE EVALUACIÓN DE LA SEGURIDAD
Aspecto del marco
18
Impacto
Solución hardware
Solución software
Seguridad
Nivel de seguridad probado y bien
entendido.
Se pueden lograr niveles similares de
seguridad, pero una implementación necesita
tiempo de prueba para evaluar y verificar el
nivel de seguridad.
Usabilidad
La usabilidad es buena. Una vez que el
producto de pago llega al usuario, la
usabilidad está al mismo nivel que una
tarjeta de pago física.
La usabilidad puede estar a un nivel
comparable, pero depende de las medidas
concretas de seguridad software que la
entidad bancaria emplee. Estas medidas
pueden obstaculizar la usabilidad y podrían
añadir factores añadidos de coste y
complejidad a las entidades bancarias.
Costes
La participación de varias partes como
los TSMs y los operadores móviles,
para hacer llegar el producto de pago
de forma segura al usuario, eleva los
costes en este ecosistema de múltiples
miembros.
Para un nivel de seguridad similar, se
requieren medidas de tokenización y
criptografía, lo que añade factores de
coste como el proveedor de servicios de
tokenización y una tarifa para actualizar el
software de seguridad. El back-end de la
entidad bancaria debe adaptarse, lo que
también es un factor de coste.
Auditabilidad
Existen procesos formales.
Proceso formal en desarrollo.
Complejidad
La complejidad recae en distintas
partes del ecosistema.
La complejidad recae en la entidad bancaria.
Estudio sobre Seguridad en los Pagos Móviles
En general, cuando se implementa una
solución de seguridad software mediante la
implementación de medidas de seguridad
lógicas como la tokenización, las limitaciones
a las transacciones y la criptografía de caja
blanca, se puede mantener el riesgo, en
principio, en niveles comparables. Se debería
aplicar una gran variedad de medidas de
seguridad lógicas para compensar la falta de
un SE de hardware.
Para apoyar medidas como el
aprovisionamiento de tokens y las
actualizaciones de la seguridad del software
sería necesaria una autenticación compleja
del usuario para acceder desde el terminal
al almacenamiento seguro en la nube, lo
que afecta a la usabilidad de una solución
software. A pesar de ello, la experiencia
del usuario podría ser mantenida a un nivel
comparable a la de una solución hardware,
dependiendo de la aplicación concreta de las
medidas de seguridad.
La complejidad se desplaza hacia la entidad
bancaria en las soluciones software y
está vinculada a la velocidad de salida al
mercado. Al elegir una solución software,
no hay necesidad de una integración a gran
escala de los miembros del ecosistema.
Sin embargo, se incrementa la complejidad
para la entidad en términos de integración
back-end, lo que unido a la implementación
de las medidas de seguridad hace que se
incremente el tiempo de salida al mercado.
El lanzamiento de las aplicaciones de pago
de HCE es muy reciente. Visa y MasterCard
han sacado requisitos para los pagos en
la nube para los titulares de licencias y
un proceso de prueba y evaluación de
la seguridad se está desarrollando para
certificar este nuevo tipo de solución de
pago móvil. Dicho esto, las respuestas
definitivas sobre el nivel de riesgo llegarán
del trabajo operativo de los pioneros y hasta
entonces los riesgos deberán ser evaluados y
tratados caso a caso.
El coste de lanzar y operar una solución
software podría reducirse por la falta
de dependencia de agentes externos,
sin embargo, costes adicionales para la
entidad bancaria son probables ya que la
complejidad técnica es absorbida por la
entidad. La solución puede desarrollarse
internamente en la empresa o por agentes
externos, como en el caso de un gestor de
servicios de tokenización.
La auditabilidad mediante procesos
formales está presente en el estado,
certificación y evaluación de la seguridad
de las aplicaciones de pago de SE. Para una
solución software este tipo de procesos
están en desarrollo y se determinarán con el
paso del tiempo.
19
Acerca de UL
UL es una compañía global líder en seguridad científica que ha abogado por el
progreso durante 120 años. Sus más de 10.000 profesionales se guían por la misión
de UL de promover entornos de trabajo y vitales seguros para todo el mundo. UL
utiliza la investigación y los estándares para avanzar y satisfacer unas necesidades
de seguridad en constante evolución. Nos asociamos con empresas, fabricantes,
asociaciones comerciales y autoridades reguladoras internacionales para aportar
soluciones a una cadena de suministro global más compleja.
La división de Seguridad en las Transacciones de UL orienta a las empresas de los
sectores móvil, de pagos y de tránsito en el complejo mundo de las transacciones
electrónicas. UL es el líder mundial en garantizar la seguridad, el cumplimiento y la
interoperabilidad global. Ofrece servicios de asesoramiento, prueba y certificación,
evaluaciones de seguridad y herramientas de prueba, durante todo el ciclo de vida:
desde el proceso de desarrollo de su producto o durante la implantación de nuevas
tecnologías. El personal de UL colabora activamente con los agentes del sector
para definir normas y políticas sólidas. Les prestamos servicio a nivel local, mientras
actuamos globalmente. UL está acreditado por organismos de la industria como
Visa, MasterCard, Discover, JCB, American Express, EMVCo, PCI, GCF, ETSI, GSMA,
GlobalPlatform, NFC Forum y muchos otros.
Para más información visite www.UL.com
Acerca de la GSMA
La GSMA representa los intereses de los operadores móviles en todo el mundo.
Abarcando más de 220 países, la GSMA reúne a casi 800 operadores móviles
de todo el mundo y 250 empresas del amplio ecosistema móvil, incluyendo
fabricantes de dispositivos móviles, empresas de software, proveedores de equipos
y compañías de Internet, así como organizaciones de otros sectores de la industria
como el financiero de servicios, el de la salud, los medios, transporte y los servicios
públicos. La GSMA también organiza eventos líderes en el sector como Mobile
World Congress y Mobile Asia Expo.
El programa de Comercio Digital de la GSMA trabaja con operadores móviles,
comerciantes, bancos, redes de pago, operadores de transporte y proveedores de
servicios para apoyar el despliegue de servicios de comercio móvil. Al fomentar el
ecosistema para alentar y facilitar la colaboración, el programa ha colaborado con
el ecosistema móvil para desarrollar directrices y especificaciones para la aplicación
técnica y para construir propuestas de valor para los sectores adyacentes.
Para más información visite www.gsma.com
Oficinas centrales de GSMA
Walbrook, Planta 2, 25 Walbrook,
Londres, EC4N 8AF,
Reino Unido
Tel: +44 (0)207 356 0600
www.gsma.com
©GSMA 2014