Estudio sobre

Seguridad en los
Pagos Mviles

Estudio sobre Seguridad en los Pagos Mviles

Contenidos
SUMARIO EJECUTIVO

INTRODUCCIN

1.

2. INTRODUCCIN A LA SEGURIDAD

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 MVIL

3.1 Almacenamiento de datos seguro

3.2 Vulnerabilidades del ecosistema

8
11

4. SOLUCIONES DE SEGURIDAD HARDWARE Y SOFTWARE EN PAGOS MVILES

14

4.1 Elemento seguro y soluciones de HCE

4.2 Marco de evaluacin de la seguridad
4.3 Evaluacin de la seguridad

14
16
16

5.

18

3.

Sumario

Estudio sobre Seguridad en los Pagos Mviles

Sumario Ejecutivo
Los servicios de pago mvil se evalan para entender el riesgo que tienen. Esta evaluacin 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 implementacin de servicios que ofrece la emulacin de tarjeta situada en el
host (HCE por sus siglas en ingls), las entidades bancarias se estn interesando por sacar servicios ms
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 manipulacin (SE por sus siglas en ingls), han sido probadas contra los ltimos ataques
del mercado. Las soluciones ms 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 basndose en lo que se sabe actualmente y en la utilizacin de medidas lgicas y
procedimentales. Sin embargo, la eficiencia de una implementacin especfica de estas medidas tendr
que ser verificada y evaluada con el tiempo.
La seguridad de los pagos mviles sin contacto (contactless) se ha garantizado tradicionalmente
mediante un elemento seguro de hardware a prueba de manipulacin, 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 mltiples partes participen unidas, en especial las operadoras de telefona
mvil 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 fsico.
Algo interesante para a los bancos, interesados en desplegar sus aplicaciones con ms 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 tpicas del sistema de pagos mvil 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 extrado 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 cargarn con todas las medidas de seguridad en su back-end,
aplicacin 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 an desconocidos; un SE hardware necesita una inversin significativa dentro de una
infraestructura mltiple, con costes distribuidos entre sus partes.
La usabilidad de una solucin software requerir la provisin de tokens temporales en los
dispositivos, para autorizar transacciones y realizar actualizaciones de seguridad peridicas. Algo
que requieren que el usuario se re-autentique de forma que la solucin sea capaz de acceder a
los datos sensibles almacenados en la nube. Un diseo cuidadoso ser necesario para preservar la
calidad de la experiencia del usuario.
La auditabilidad es posible a travs de procesos formales en los tests y evaluacin de la certificacin
y seguridad de las soluciones de SE en hardware. Es difcil poner en prctica procesos similares
para muchas soluciones software no estandarizadas. Por ahora, la evaluacin debe realizarse caso a
caso y el nivel de riesgo real se evaluar de forma ms fiable cuando se hayan recogido experiencias
suficientes del mercado.

Estudio sobre Seguridad en los Pagos Mviles

1. Introduccin
A medida que los dispositivos mviles se hacen ms prevalentes como
herramientas para pagos y banca, la seguridad de la informacin
confidencial que se utiliza se hace ms importante. Consideraciones
como de qu forma las aplicaciones y las transacciones se aseguran
y entregan y cmo se identifica de forma segura al usuario son
preocupaciones clave del ecosistema mvil de pago. Las soluciones de
pago estn siendo evaluadas por la gestin de riesgos de los bancos,
en su investigacin para implementar el pago mvil.
Este trabajo de debate, dirigido a las entidades bancarias y escrito en
colaboracin con UL, ofrece una visin general informativa y de alto
nivel de la tecnologa de seguridad involucrada en la implementacin
de las soluciones de pago mviles. Ms especficamente, este
documento considera las implicaciones en la seguridad de soluciones
de pago mvil hardware (por ejemplo, el elemento seguro) y software
(por ejemplo, la emulacin de tarjeta de host).
El documento describe los objetivos generales, las necesidades y los
tipos de seguridad, centrndose especficamente en los pagos mviles.
Cubre el almacenamiento de datos confidenciales, las medidas de
seguridad mvil y las vulnerabilidades del ecosistema, proporcionando
un marco de evaluacin que compara las soluciones de seguridad
hardware y software existentes en el mercado hoy en da.

Estudio sobre Seguridad en los Pagos Mviles

2. Introduccin a la seguridad
La seguridad se mide a menudo teniendo en cuenta el riesgo y el riesgo
global asociado con los pagos. Este captulo proporciona una amplia
visin general de los diferentes tipos de seguridad y sus objetivos y
explica las medidas de mitigacin de riesgos.

2.1 Diferentes tipos de seguridad

Se puede representar la seguridad como un tringulo cuyas esquinas son: La seguridad fsica,
la lgica y la procedimental. El nivel general de seguridad lo determina el eslabn ms dbil.

Seguridad fsica
La seguridad fsica se basa en elementos
fsicos o de hardware. El objetivo de
la seguridad fsica es salvaguardar la
informacin mediante elementos de
hardware a prueba de manipulacin, donde
la informacin confidencial se almacena y
donde se ejecutan operaciones cruciales.
Este punto se analiza en mayor profundidad
en la seccin 3.1
Seguridad lgica
La seguridad lgica se basa en las garantas
del software que tiene un sistema. Aunque el
software se ejecuta mediante un hardware,
la seguridad lgica no utiliza elementos del
hardware para proporcionar seguridad. Este

punto se analiza ms en profundidad en la

seccin 3.1
Seguridad procedimental
La seguridad procedimental o administrativa
se basa en la proteccin de la informacin
confidencial mediante procedimientos
dentro de las organizaciones. La seguridad
procedimental protege la confidencialidad,
integridad y/o acceso a la informacin
mediante distintos procedimientos y
medidas de seguridad propios de cada
organizacin, que pueden ser implementados
de forma proactiva o reactiva. La seguridad
procedimental es diferente en cada
aplicacin y debe verse en cada caso
especficamente.

Tringulo de seguridad

Fsica

Lgica

Figura 1:

0011101110000
110SECURITY1
11011100010111
0000111011010
1101010100001
Procedimental
000110111111101
0001000111100
1111111010101101

Estudio sobre Seguridad en los Pagos Mviles

2.2 Objetivos de seguridad

La seguridad tiene el objetivo general de proteger activos relevantes de amenazas a la
confidencialidad, integridad y disponibilidad a travs de medidas seguras.
Activos
Los activos incluyen la informacin
confidencial del usuario, como el nmero
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 informticos.
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 evala la seguridad de una aplicacin 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 implementacin de
una seguridad robusta y adecuada. Esto
podra hacerse, por ejemplo, mediante el
almacenamiento de datos confidenciales
en lugares a prueba de falsificaciones.
La ocultacin de informacin por
medios criptogrficos tambin 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 devaluacin de los activos
que se pueden conseguir. Por ejemplo, la
tokenizacin 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.

Implementacin del mercado: Apple Pay

Apple Pay permite a los usuarios realizar
pagos NFC. La tokenizacin se usa para
almacenar los datos de la tarjeta de pago.
Adems, un cdigo de seguridad dinmico
validar cada transaccin. El usuario
confirma la transaccin mediante el TouchID.
Principales mecanismos de seguridad:
SE: almacena el nmero de cuenta
del dispositivo nico y nmeros de
transaccin nicos de cada operacin.

Verificacin de usuario y hardware:

verificacin de usuario mediante TouchID
Tokenizacin: el nmero de cuenta
primario (PAN) tokenizado se guarda en
el dispositivo, se usan nmeros nicos
individuales para cada transaccin.
Criptografa: el nmero de cuenta
nico del dispositivo se guarda
criptogrficamente, se generan
criptogrficamente nmeros nicos para
un uso.

Estudio sobre Seguridad en los Pagos Mviles

3. Seguridad en el pago mvil

Las entidades bancarias trabajan con informacin de pago
confidencial y los pagos mviles 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 mvil el nmero de cuenta
primaria (PAN), las claves de acceso y los
criptogramas. El nivel general de riesgo
debera seguir siendo manejable para las
entidades cuando implementan la seguridad

de las soluciones hardware o software

de pago mvil. Tiene que considerarse
el impacto en aspectos crticos 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 debera
depender de la sensibilidad de los datos, ya que cada solucin tiene un impacto en el riesgo.
Las entidades tienen cuatro alternativas para generar, procesar y almacenar informacin
confidencial.
Unidad Central de Procesamiento del
host (CPU)
La informacin confidencial es gestionada
por la aplicacin que se ejecuta en el sistema
operativo (SO) del dispositivo mvil. La
proteccin frente a posibles ataques es baja
ya que el nico mecanismo de seguridad
por defecto es el sandboxing, que separa
programas en ejecucin no verificados. En
este caso, el SO Android asla los activos a
nivel del SO.
Almacenamiento seguro en la nube
La informacin confidencial se gestiona en
un servidor de red en la nube. El dispositivo
mvil tiene que establecer una conexin
segura para obtener esta informacin. El
usuario debe autenticarse a s mismo, a la
aplicacin y al dispositivo. En soluciones
software, la autenticacin de un dispositivo
se resuelve mediante la ocultacin de las
claves de usuario con ofuscacin de cdigo o
criptografa de
caja blanca.

Entorno de ejecucin seguro

El entorno de ejecucin seguro (TEE) es un
rea segura de la CPU de los dispositivos
mviles. El entorno TEE ofrece la ejecucin
segura de aplicaciones de confianza y
refuerza los derechos de acceso, adems
de almacenar la informacin 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 informacin
confidencial al TEE ofrece retos similares a
asignarla a travs de un gestor de servicios
de confianza (TSM) o servidor de la
aplicacin. El TEE generalmente carece de
la resistencia a la manipulacin de un SE
de hardware. Cada fabricante de equipos
ha desarrollado su propia versin de esta
tecnologa, como Knox en Samsung (que
utiliza el TrustZone de ARM) y Secure
Enclave de Apple.

Estudio sobre Seguridad en los Pagos Mviles

Medidas de seguridad lgicas para

soluciones de pago mvil
Hay muchas soluciones de seguridad lgicas
vinculadas a las aplicaciones de pago mviles.
Entre ellas:
A. Verificacin de usuario y hardware
La autenticacin se puede hacer mediante:
Lo que el usuario sabe: como el nombre de
usuario y contrasea, el PIN, el patrn
Lo que el usuario tiene: como el identificador
de dispositivo nico o el token
Cmo se comporta el usuario: como la
localizacin e historial de transacciones
Lo que el usuario es (identificacin
biomtrica): como la huella dactilar, o los
reconocimientos de voz y facial
Se pueden combinar mltiples mtodos en una
autenticacin dual. Por ejemplo, identificadores
de hardware como el IMEI o el ICCID se podran
usar en conjunto con la autenticacin del usuario.

D. Criptografa de caja blanca

El propsito principal de la criptografa de caja
blanca es implementar un gran conjunto de tablas
de bsqueda y codificar sus claves. Todas las
operaciones criptogrficas implican una sucesin
de tablas de bsqueda durante una operacin
determinada y estas dificultan la posibilidad de
adivinar la clave correcta utilizada durante la
operacin. Los activos permanecen seguros ya que
estn ocultos para el atacante incluso cuando ste
tiene acceso a todos los recursos, ataque conocido
como de caja blanca. Mediante la ocultacin de
la clave de la aplicacin, la distribucin se hace
ms compleja ya que cada aplicacin tiene que ser
definida de forma nica por el usuario.
E. Ofuscacin

Limitar las transacciones puede reducir el

impacto de una violacin de la seguridad.
Algunos ejemplos:
Pagos de bajo valor y limitacin de
transacciones en un plazo determinado
Permitir slo las transacciones online para
pagos de proximidad
Restricciones de localizacin/pas
Las limitaciones a la transaccin son aprobadas
por la entidad y almacenadas en el SE o en
el punto de venta, complicando mucho su
modificacin por malware.

La ofuscacin de cdigo es un mtodo para escribir

deliberadamente el cdigo o partes del cdigo
de una forma que sea difcil de entender. As, se
dificulta que los hackers reviertan el cdigo de
ingeniera y se ocultan las partes crticas o secretos
de cdigo. Se presenta de diferentes formas:
Transformaciones abstractas: destruyen la
estructura del mdulo, 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 dinmicas: hacen que el
programa cambie durante su ejecucin

C. Controles del sistema operativo

F. Tokenizacin

Las aplicaciones pueden recuperar la configuracin

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 garantas de seguridad y
tener acceso al punto de almacenamiento seguro. Un
usuario puede:
Alterar los identificadores del dispositivo o
aplicacin, usados en la verificacin del hardware
Obtener acceso al cdigo de las aplicaciones
donde se almacena informacin confidencial
Instalar aplicaciones maliciosas que pueden
llevar a cabo acciones fraudulentas como
ataques al intermediario.

Con la tokenizacin, la informacin confidencial se

sustituye por algo menos confidencial: un token. El
valor del activo se reduce drsticamente, hacindose
menos interesante para un atacante. Los tokens
pueden ser generados y reemplazados fcilmente
sin comprometer el Nmero de Cuenta Primario
(PAN). Hay dos formas de tokenizacin:
Tokenizacin EMVCo: Una versin 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 conexin
segura

B. Limitar las transacciones

Estudio sobre Seguridad en los Pagos Mviles

MEDIDAS DE SEGURIDAD FSICAS PARA

SOLUCIONES DE PAGO MVILES
Elemento seguro
El SE en hardware es un elemento a prueba de manipulacin en dispositivos mviles y se
presenta como una tarjeta de circuito integrado universal (UICC) o SE incrustado (eSE).
Estos elementos seguros han sido testados contra los mtodos de ataque ms recientes,
siguiendo los requerimientos de seguridad de organismos de confianza.
Las principales caractersticas del SE son:
Las claves e informacin confidencial se guardan en el SE
Se necesita que se ejecute una aplicacin segura del SE para procesar la informacin
confidencial. Las aplicaciones seguras pueden contener informacin confidencial y la
combinacin de sistemas UICC y de pago tiene que estar certificada.
Cuando la aplicacin se ejecuta fuera del entorno del SO del dispositivo, tanto la
aplicacin como las claves son ms difciles de alcanzar por el malware.


Implementacin del mercado: Softcard

El monedero Softcard, anteriormente
conocido como Isis, es una iniciativa
conjunta de tres operadores mviles
que proporcionan una aplicacin de
monedero basada en el SE. El monedero
ofrece pagos de proximidad NFC, as
como tarjetas de fidelizacin. Una versin
virtualizada de la tarjeta de pago se
guarda en el SIM del dispositivo mvil.

10

Principales mecanismos de seguridad:

SE: almacenamiento de informacin
confidencial de pago en un UICC a
prueba de manipulacin (SIM)
Restricciones a las transacciones:
pagos de bajo valor sin PIN mvil,
pagos de alto valor con PIN mvil
Verificacin de usuario y hardware: PIN
mvil para desbloquear la aplicacin +
Verificacin del ID del dispositivo

Estudio sobre Seguridad en los Pagos Mviles

3.2 Vulnerabilidades del ecosistema

Un anlisis pormenorizado de las posibles amenazas y vulnerabilidades del ecosistema
se muestra en la Figura 2. Tambin se ofrecen posibles medidas para mitigar el riesgo de
amenaza. Cada implementacin requerir un anlisis individual de riesgos para identificar
vulnerabilidades especficas.
EJEMPLOS DE VULNERABILIDADES DEL ECOSISTEMA:
Sistema situado en la nube
Un ataque con xito a un sistema situado en la
nube supondra un hackeo, manipulacin y/o
divulgacin de informacin confidencial. Las
posibles amenazas para el sistema de pago
de la nube incluyen la interceptacin de datos
confidenciales por un atacante que suplante la
identidad, la interceptacin de datos mediante
malware y la redireccin de los datos de la
aplicacin a otro dispositivo mvil. Con estos
mtodos un atacante puede obtener los activos
como el usuario y datos de la tarjeta, los valores
del mtodo de verificacin de la tarjeta (CVM),
las claves de acceso o incluso el control de la
totalidad de las aplicaciones de pago mvil.
Los mayores desafos son la autenticacin 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
informacin confidencial.
Aplicacin de pago mvil
Un ataque con xito a la aplicacin de pago
mvil podra resultar en la descompilacin
del cdigo fuente, de forma que el atacante
obtiene acceso a todos los activos ocultos en
la aplicacin (como autenticadores y claves
criptogrficas). La integridad de una aplicacin
tambin puede verse comprometida por la
manipulacin de datos y la distribucin de
datos confidenciales capturados mediante
aplicaciones clonadas. Otra vulnerabilidad es el
punto de venta mvil, ya que un comerciante
fraudulento puede manipular la aplicacin mvil
que controla el punto de venta mvil. Con estos
mtodos, un atacante puede obtener activos
como los usuarios y datos de la tarjeta bancaria,
los valores de los sistemas de verificacin de
la tarjeta (CVM) y las claves de acceso. Los
mecanismos de seguridad como la criptografa
de caja blanca reducen la probabilidad de
clonacin y decompilacin de aplicaciones de
pago mvil. El momento de introduccin de
datos confidenciales en el SE o del envo de un

token son grandes puntos de vulnerabilidad en

las aplicaciones de pago mviles.
Dispositivo mvil
Los ataques al dispositivo mvil podran ir
dirigidos a conseguir activos en el propio
dispositivo: el SE, el procesador NFC y el
sistema operativo (SO) del mvil. El SO del
mvil tiene puntos dbiles a travs del puerto
de depuracin o los virus de enraizamiento,
que permiten obtener acceso a la aplicacin de
pago mvil. Adems, otros mecanismos como
un registrador de pantalla pueden obtener
informacin clave de acceso del usuario. Las
posibles medidas de seguridad son el PIN
offline, chequeos del SO, criptografa de caja
blanca y un elemento seguro a prueba de
manipulacin (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 manipulacin (TEE). El aspecto ms crtico
de la seguridad es el control de acceso al SE,
que define el acceso a las aplicaciones mviles.
Se basa en certificados implementados por
el proveedor del servicio, que se usan para
autenticar o registrar la aplicacin en el SE.
Punto de venta Interfaz NFC
La interfaz de un punto de venta NFC podra
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 manipulacin de los datos tambin
podra venir por parte de un atacante que
recolecte las claves de acceso. El malware
en el procesador NFC es una posibilidad que
permitira redirigir datos confidenciales. El
impacto de estos ataques puede reducirse con
la implementacin de medidas de seguridad
como la tokenizacin.

11

Mobile Payment Security discussion paper

Mobile Payment Security discussion paper

Amenazas
Amenazas
Intercepcin mediante malware instalado en las aplicaciones
S
 uplantacin de identidad: Intercepcin de datos de la
aplicacin y credenciales de autenticacin
Redireccin de datos de la aplicacin 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 ejecucin de confianza
Criptografa de caja blanca (D)
Controles del sistema operativo (C)
Ofuscacin (E)
Verificacin de usuario y de
hardware (A)

Sistema en la nube

Gestin confidencial

Gestin de transacciones

Plataforma de la
aplicacin

Plataforma en la nube

Situado en el software

Manipulacin mediante la
descompilacin de la aplicacin.
El atacante obtiene del usuario,
datos de tarjeta, valores CVM y
claves
Suplantacin de identidad/
Phishing: aplicacin falsa/clonada
que captura datos confidenciales
(claves de acceso, mPIN)
Manipulacin por la inyeccin
de un cdigo malicioso en la
aplicacin

Amenazas

Elemento Seguro a prueba de

manipulacin
(el TEE, cubre la mayora de las
amenazas)
Verificacin de usuario (A)

Situado en el hardware

Posibles medidas

!
Aplicacin
de pago
SIM (UICC)

Entidad bancaria
(Procesador del servidor)

Red de
Pagos

Internet

Amenazas
Manipulacin con control
de acceso al SO y al
SE, accediendo a datos
confidenciales
Phishing con captura de
datos confidenciales (claves
de acceso, mPIN)
Interceptacin de datos de
aplicacin y autenticacin.

Posibles medidas
Controles del Sistema Operativo (C)
Criptografa de caja blanca (D)
Ofuscacin (E)
Entorno de ejecucin seguro (TEE)
Verificacin de usuario y de hardware (A)

Verificacin de usuario y de hardware (A)

Controles del Sistema Operativo (C)
Entorno de ejecucin seguro (TEE)
Ofuscacin (E)

Amenazas

Manipulacin mediante el acceso a datos confidenciales por un

puerto de depuracin o virus de enraizamiento
Manipulacin mediante la ejecucin de un entorno simulado para
encontrar vulnerabilidades
Captura del usuario, datos de tarjeta, valores CVM y claves

Mvil

Adquiriente

Aplicacin
de pago
mvil
HCE APIs
Controlador
NFC

Punto de venta

La vulnerabilidad del

dispositivo mvil 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
Manipulacin mediante la
captura de criptogramas
y claves de acceso para
descubrir la debilidad del
criptograma de acceso
Posibles medidas

Operador Telefona
Mvil

Operador TSM

Entidad bancaria TSM

Verificacin de usuario y de
hardware (A)
Restricciones a las
transacciones (B)
Autenticacin o tokens (F)

Estudio sobre Seguridad en los Pagos Mviles

4. Soluciones de seguridad
hardware y software en
pagos mviles
Este captulo presenta un marco de evaluacin para ayudar a
comparar las soluciones de seguridad en pagos mviles hardware
y software. Soluciones tpicas tanto software como hardware son
evaluadas en la figura 4.3.
4.1 Elemento seguro y soluciones de HCE
En esta seccin se analizan una solucin hardware y una software con niveles de seguridad
similares, incluyendo medidas de seguridad relevantes para la mitigacin de riesgos.
La figura 4.1 analiza la solucin 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 informacin 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 mvil

FIGURA 4.1

Solucin de seguridad hardware en un elemento seguro

Aspecto de la
seguridad

Solucin 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

Fsica

Lgica

Mitigacin de riesgos

Reduce la probabilidad de un ataque

exitoso

Reduce el impacto de un ataque exitoso

En una solucin hardware, la principal seguridad proviene del SE (por ejemplo una UICC).
Para proporcionar aplicaciones seguras y personalizar la aplicacin de pago, se establece una
conexin segura con el SE y las entidades bancarias pueden de controlar por completo sus
activos dentro de la UICC a travs de los estndares GlobalPlatform. 1

1. Especificaciones de GlobalPlatform. http://www.globalplatform.org/specifications.asp

14

Estudio sobre Seguridad en los Pagos Mviles

La figura 4.2 mira a una solucin 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 aplicacin mvil
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 tokenizacin se usa por la aplicacin para generar claves. Estas contendrn todos
cualquier dato confidencial utilizado y proporcionarn autentificacin de usuario
La criptografa de caja blanca se usa para proteger los datos confidenciales
Se activa el PIN offline u online dependiendo de la transaccin

Figura 4.2 Solucin de seguridad software de HCE

Aspecto de la
seguridad

Solucin de HCE con tres medas de seguridad

Medidas de seguridad

1. Criptografa de caja blanca

2. Tokenizacin

3. Autenticacin usuario

Tipo de seguridad

Lgica

Lgica

Lgica

Mitigacin 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 solucin de seguridad, la conexin con la red se realiza directamente desde la

aplicacin a travs de NFC. Para habilitar los pagos, el usuario tendr que autenticarse en la
nube para obtener tokens de pago que le tendrn que ser suministrados de forma segura,
lo que implica un emisor de tokens. La tokenizacin se utiliza para reducir el impacto de un
ataque exitoso y estos tokens se almacenarn en el telfono mvil para que el consumidor
pueda hacer los pagos. La solucin software implica un menor nmero de partes implicadas,
pero necesita ms medidas de seguridad de software para compensar la falta de un SE,
incluyendo las mencionadas en la figura anterior.

Implementacin del mercado: Bankinter

Esta aplicacin de pago mvil de software
ofrece transacciones de comercio
electrnico (pagos remotos) y pagos de
HCE en el punto de venta. Las tarjetas de
pago se guardan como tarjetas mviles
virtuales en el dispositivo, al que se
vinculan. No se necesita conectividad
mvil para transacciones NFC, slo para
la reposicin al dispositivo mvil de las
credenciales parcialmente calculadas.

Principales mecanismos de seguridad:

Tokenizacin: en forma de creacin de
una Tarjeta Virtual Mvil (MVT) en el
dispositivo y tarjetas de un solo uso
Criptografa: criptograma EMV
Limitaciones a las transacciones:
limitaciones de tiempo de 60 segundos
para cada tarjeta de uso nico
Validez
Verificacin de usuario y de hardware:
PIN de la Tarjeta Virtual Mvil +
verificacin del ID del dispositivo

15

Estudio sobre Seguridad en los Pagos Mviles

Estudio sobre Seguridad en los Pagos Mviles

FIGURA 4.3 MARCO DE EVALUACIN

4.2 Marco de evaluacin de

la seguridad
Para comparar soluciones, se utiliza un
marco de evaluacin de la seguridad basado
en cinco aspectos: seguridad, usabilidad,
costes, auditabilidad y complejidad. Otros
factores, como los medios especficos de la
configuracin, el despliegue y la viabilidad
de las medidas de mitigacin de riesgos,
no se consideran en este marco, ya que son
especficos de cada implementacin.

Marco
Seguridad
Las medidas de seguridad reducen la cantidad de riesgos y esta seguridad
debe evaluarse en cada implementacin especfica. Dentro del marco, la
estimacin del riesgo se realiza de acuerdo con el ecosistema. Sus puntos
de vulnerabilidad y medidas de mitigacin 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 evala la seguridad factual, ya que la percepcin de
seguridad del usuario vara segn 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
contraseas adicionales aumentan la seguridad, pero reducen la usabilidad
(la gente tiene que memorizar otra contrasea).

Solucin hardware

Solucin software

La estrategia para mitigar el riesgo se centra en la reduccin

de la probabilidad de un ataque con xito. En una aplicacin
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
manipulacin, producido y testado durante ms de 10 aos.
El suministro de datos es gestionado y enviado directamente
de forma segura, sin ir a travs del SO del dispositivo.
La seguridad ha sido certificada por proveedores de tarjetas
antes los ataques recientes ms conocidos.

La seguridad de una solucin software no coincide con

la seguridad de una solucin hardware. La mejora de la
seguridad de una solucin software requiere criptografa de
caja blanca y mtodos de verificacin de usuario, que inciden
en otros aspectos del marco.
La estrategia para mitigar riesgos se centra principalmente
en la reduccin del impacto de un ataque con xito a travs
de la tokenizacin y limitaciones de transaccin (slo 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 solucin hardware es buena, ya que

ofrece la posibilidad de hacer pagos de bajo valor sin PIN y
pagos incluso cuando el dispositivo mvil 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 mvil es necesaria de forma regular para
conectar con el servidor de tokens emplazado en la nube para
reponer tokens.
La aplicacin necesitar actualizaciones peridicas de
software para mantener las medidas de seguridad de software
al da.
El acceso seguro a la nube requerir del usuario que se vuelva
a autenticar peridicamente con mecanismos de autenticacin
fuerte.
Transacciones rpidas, como el pago de bucle abierto para
el transporte pblico, es posible que se queden fuera del
alcance.

Para el aprovisionamiento seguro y personalizacin de tarjetas

de pago virtuales en los telfonos mviles, se necesita que
se involucren partes como los proveedores de TSM y los
operadores mviles podran cobrar una tasa por el uso de la
UICC como SE.

El emisor no necesita contratar muchas partes externas, como

TSMs y, operadores mviles 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 gestin de nuevas
complejidades (ver en este marco el apartado complejidad)
incurrirn en otros costes de magnitud an desconocida y
especficos de la implementacin.
La aplicacin an 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 Evaluacin de la seguridad

El marco de evaluacin de la seguridad
presenta una comparacin exhaustiva
basada en cinco aspectos: seguridad,
usabilidad, costes, auditabilidad y
complejidad. Una comparacin completa
requerira un anlisis completo de
riesgos de ambas implementaciones.
Ntese que en la prctica, la evaluacin
del nivel de riesgo de una aplicacin de
software tendr que ser completada con
un perodo de monitorizacin operativa
antes de que est funcionando el proyecto
(certificacin, riesgo de las transacciones,
provisin para riesgos financieros). En
su lugar, se ofrece una comparacin en
profundidad que tiene en cuenta las
caractersticas generales de las soluciones
hardware y software.

Costes
Los costes se ven afectados principalmente por el tamao del ecosistema,
el nivel de implementacin de la seguridad y el tipo de medidas de
seguridad.

Se necesita una inversin significativa en infraestructura de

varias partes: generalmente el coste de la configuracin y
gestin del TSM lo cubre el dueo del SE y la conexin es
cubierta por el usuario.

Auditabilidad
Otro aspecto importante para las entidades bancarias es la auditabilidad
que tiene la solucin, sus transacciones y la integridad de las transacciones
que se realicen. Una implementacin compleja es ms difcil de evaluar.

Complejidad
La complejidad se puede determinar por el nmero de partes, el tamao
del ecosistema y el nivel de seguridad deseado.

16

Es robusto ya que hay un proceso establecido desde hace

muchos aos para la prueba, la certificacin y la evaluacin de
la seguridad formal.

La auditabilidad no est tan madura como con las soluciones

hardware ya que los procesos formales estn siendo
desarrollados.
Los procesos son deliberadamente oscurecidos o protegidos
criptogrficamente, haciendo que sea menos transparente y,
en consecuencia, menos auditable.

La complejidad de una solucin de pago mvil 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 solucin exitosa. Surgen dudas de integracin
e interoperabilidad debido a la cantidad de interfaces y la
complejidad de ir sumando entidades bancarias adicionales u
operadores mviles.

El ecosistema puede tener menos partes, aunque el papel

de los operadores mviles 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,
necesitarn ser adaptados para incorporar una plataforma
de pago en la nube que gestione los pagos mviles 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 aplicacin incorpora algoritmos criptogrficos,
se necesita que otra parte haga llegar las claves o las
actualizaciones de seguridad. Otro ejemplo es la tokenizacin,
donde se requiere un gestor de tokens.

17

Estudio sobre Seguridad en los Pagos Mviles

5. Sumario
Se pueden obtener niveles similares de riesgo, sin embargo el impacto
en la usabilidad, costes, auditabilidad y complejidad vara, como se
puede comprobar en Figura 5.1.

FIGURA 5.1 RESUMEN COMPARATIVO DEL MARCO DE EVALUACIN DE LA SEGURIDAD

Aspecto del marco

18

Impacto
Solucin hardware

Solucin software

Seguridad

Nivel de seguridad probado y bien

entendido.

Se pueden lograr niveles similares de

seguridad, pero una implementacin 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 fsica.

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 podran
aadir factores aadidos de coste y
complejidad a las entidades bancarias.

Costes

La participacin de varias partes como

los TSMs y los operadores mviles,
para hacer llegar el producto de pago
de forma segura al usuario, eleva los
costes en este ecosistema de mltiples
miembros.

Para un nivel de seguridad similar, se

requieren medidas de tokenizacin y
criptografa, lo que aade factores de
coste como el proveedor de servicios de
tokenizacin y una tarifa para actualizar el
software de seguridad. El back-end de la
entidad bancaria debe adaptarse, lo que
tambin 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 Mviles

En general, cuando se implementa una

solucin de seguridad software mediante la
implementacin de medidas de seguridad
lgicas como la tokenizacin, las limitaciones
a las transacciones y la criptografa de caja
blanca, se puede mantener el riesgo, en
principio, en niveles comparables. Se debera
aplicar una gran variedad de medidas de
seguridad lgicas 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
sera necesaria una autenticacin compleja
del usuario para acceder desde el terminal
al almacenamiento seguro en la nube, lo
que afecta a la usabilidad de una solucin
software. A pesar de ello, la experiencia
del usuario podra ser mantenida a un nivel
comparable a la de una solucin hardware,
dependiendo de la aplicacin 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 solucin software,
no hay necesidad de una integracin a gran
escala de los miembros del ecosistema.
Sin embargo, se incrementa la complejidad
para la entidad en trminos de integracin
back-end, lo que unido a la implementacin
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 evaluacin de
la seguridad se est desarrollando para
certificar este nuevo tipo de solucin de
pago mvil. Dicho esto, las respuestas
definitivas sobre el nivel de riesgo llegarn
del trabajo operativo de los pioneros y hasta
entonces los riesgos debern ser evaluados y
tratados caso a caso.

El coste de lanzar y operar una solucin

software podra reducirse por la falta
de dependencia de agentes externos,
sin embargo, costes adicionales para la
entidad bancaria son probables ya que la
complejidad tcnica es absorbida por la
entidad. La solucin puede desarrollarse
internamente en la empresa o por agentes
externos, como en el caso de un gestor de
servicios de tokenizacin.
La auditabilidad mediante procesos
formales est presente en el estado,
certificacin y evaluacin de la seguridad
de las aplicaciones de pago de SE. Para una
solucin software este tipo de procesos
estn en desarrollo y se determinarn con el
paso del tiempo.

19

Acerca de UL
UL es una compaa global lder en seguridad cientfica que ha abogado por el
progreso durante 120 aos. Sus ms de 10.000 profesionales se guan por la misin
de UL de promover entornos de trabajo y vitales seguros para todo el mundo. UL
utiliza la investigacin y los estndares para avanzar y satisfacer unas necesidades
de seguridad en constante evolucin. Nos asociamos con empresas, fabricantes,
asociaciones comerciales y autoridades reguladoras internacionales para aportar
soluciones a una cadena de suministro global ms compleja.
La divisin de Seguridad en las Transacciones de UL orienta a las empresas de los
sectores mvil, de pagos y de trnsito en el complejo mundo de las transacciones
electrnicas. UL es el lder mundial en garantizar la seguridad, el cumplimiento y la
interoperabilidad global. Ofrece servicios de asesoramiento, prueba y certificacin,
evaluaciones de seguridad y herramientas de prueba, durante todo el ciclo de vida:
desde el proceso de desarrollo de su producto o durante la implantacin de nuevas
tecnologas. El personal de UL colabora activamente con los agentes del sector
para definir normas y polticas slidas. 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 ms informacin visite www.UL.com

Acerca de la GSMA
La GSMA representa los intereses de los operadores mviles en todo el mundo.
Abarcando ms de 220 pases, la GSMA rene a casi 800 operadores mviles
de todo el mundo y 250 empresas del amplio ecosistema mvil, incluyendo
fabricantes de dispositivos mviles, empresas de software, proveedores de equipos
y compaas 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
pblicos. La GSMA tambin organiza eventos lderes en el sector como Mobile
World Congress y Mobile Asia Expo.
El programa de Comercio Digital de la GSMA trabaja con operadores mviles,
comerciantes, bancos, redes de pago, operadores de transporte y proveedores de
servicios para apoyar el despliegue de servicios de comercio mvil. Al fomentar el
ecosistema para alentar y facilitar la colaboracin, el programa ha colaborado con
el ecosistema mvil para desarrollar directrices y especificaciones para la aplicacin
tcnica y para construir propuestas de valor para los sectores adyacentes.
Para ms informacin 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