Identidad en la seguridad móvil

REPORTE OFICIAL | Marzo de 2014
Identidad en la
seguridad móvil
2 | Reporte oficial: Identidad en la seguridad móvil
Tabla de contenidos
ca.com/ar
Introducción3
Sección 1: Amenazas recientes 4
Sección 2: Desafíos para proteger las aplicaciones móviles
Protección de API (interfaz gráfica de usuario)
PKI (infraestructura de clave pública)
Normas de seguridad en evolución
5
Sección 3: Requisitos 6
Sección 4: Un nuevo enfoque de la seguridad
7
Sección 5: Características del lado servidor
8
Sección 6: Arquitectura cliente
Token cliente y almacenamiento de claves privadas
Bibliotecas del lado cliente
9
Sección 7: Flujo de protocolo de aprovisionamiento 11
Sección 8: Conclusión
12
3 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Introducción
En los últimos años, el concepto de “computación en cualquier lugar, en cualquier momento” se ha convertido en
el denominador común que impulsa las ventas de dispositivos electrónicos personales a medida que los usuarios
adoptan nuevas categorías de dispositivos, como teléfonos inteligentes, tabletas y televisores inteligentes.
Estos dispositivos permiten que los clientes y los empleados accedan a información y servicios desde casi cualquier
dispositivo en cualquier momento. Estudios de Gartner muestran que el mercado de teléfonos móviles estimado
llegará a los 1800 millones de dispositivos en 20131.
Mientras el auge de las ventas de dispositivos móviles continúa, proliferan las aplicaciones con iOS y Android que
brindan una experiencia de aplicación más personalizada para el uso profesional y privado. Para hacer frente a la
gran demanda, los desarrolladores del mundo aprovechan las plataformas de identidad de las redes sociales o los
sistemas empresariales de identidad para proporciona una experiencia de aplicación personalizada. Además de
esto, las aplicaciones y los datos se encuentran diseminados en varios centros de datos en el mundo, y el desafío
principal consiste en cómo administrar la cantidad creciente de identidades de usuario que necesitan acceder de
manera segura a estas aplicaciones.2 Sin embargo, es posible que la protección de la información sobre la identidad
del usuario no se tenga en cuenta con la frecuencia que los usuarios desearían. En muchos casos, los usuarios
necesitan acceso a diferentes recursos que residen en un entorno de nube o detrás de un firewall empresarial.
Por lo tanto, la protección de la identidad ha sustituido el perímetro de red empresarial tradicional como el nuevo
modelo para la seguridad.
El concepto de usar la identidad como base para controlar el acceso no es una invención digital nueva,
los pasaportes nacionales, por ejemplo, han sido una fuente inequívoca de comprobación de la identidad por más
de 600 años. No obstante, la facilidad para transferir información en un mundo digital y móvil ha hecho que la
administración de los datos confidenciales sea más imprescindible, especialmente en las aplicaciones móviles.
El pago mediante un dispositivo móvil es un ejemplo de un servicio móvil nuevo e innovador que se basa
enormemente en información comprobada pero confidencial del usuario. La manera exacta en que una aplicación
móvil acepta las credenciales del usuario y comprueba la información es un factor clave para el éxito. Por lo tanto,
este problema tiene dos partes: la autenticación y la protección de los datos. Las aplicaciones móviles deben
resolver y comprobar las identidades de los usuarios de un modo confiable. El protocolo OAuth (Autorización abierta)
se introdujo para derrotar el patrón anticontraseña, en el que los usuarios debían compartir previamente sus
credenciales con las aplicaciones cuando se requería acceso a un recurso protegido. Aunque OAuth ha mejora la
situación, aún es frecuente que se solicite al usuario que escriba contraseñas. Como resultado, se ha incrementado
el uso de contraseñas de baja entropía. Un estudio reciente mostró que aproximadamente el 82 % de las contraseñas
se descifraron en una hora3. Esto es una preocupación y, como la identidad del usuario se convierte rápidamente en
el principal habilitador de servicios clave, es imperativo poner mayor atención en la seguridad móvil. Hasta no hace
mucho tiempo, toda la industria móvil ha estado preocupada principalmente con la administración de los dispositivos
y lo que ha faltado ha sido un enfoque renovado en la habilitación de aplicaciones seguras. Junto con Samsung, la NSA
(Administración de Seguridad Nacional) ha dado pasos en esta dirección creando SE (Securiy Enhanced) Android.
Sin embargo, esta solución solo está disponible mediante el programa Samsung Knox y no aborda un escenario
particularmente importante en el que la aplicación móvil consume datos confidenciales en el back-end.
Analizando las brechas de seguridad de las aplicaciones móviles, las siguientes áreas clave se deben resolver
para proteger la identidad y los datos del usuario. Primero, se debe establecer confianza mutua entre la aplicación
cliente y el proveedor de la API (interfaz de programación de aplicaciones) back-end. Segundo, la infraestructura
de administración de identidades de la empresa o la organización debe desarrollar un método para asistir a las
4 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
aplicaciones móviles que requieren acceso a los recursos que están detrás del firewall. Tercero, el uso de esquemas
de autenticación de nombre de usuario y contraseña se debe reducir al mínimo mientras las reglas de seguridad
aún se implementan.
Este reporte presenta amenazas que han afectado a millones de usuarios y sugiere una solución potente aunque
simple que no solo permite que las aplicaciones móviles accedan a datos confidenciales, sino que también retiene
la confianza de las aplicaciones cliente y sus usuarios.
Sección 1:
Amenazas recientes
En 2012, millones de cuentas de usuarios de Facebook, Twitter y Pinterest fueron comprometidas cuando los
atacantes lanzaron ataques de ingeniería social más sofisticados que nunca4. Recientemente, a principios de 2013,
un ataque a gran escala de una aplicación móvil disfrazada como “software de banca seguro” victimizó a usuarios
de Android en diversos países enviando información personal a piratas informáticos en Rusia5. En una escala más
pequeña, algunos programas troyanos, como Android/MarketpayA, realizaron compras sin el conocimiento del
usuario móvil. Estas son solo algunas de las amenazas que han afectado a los usuarios móviles de todo el mundo.
Según los informes de amenazas de McAfee, las muestras de software malintencionado móvil se han incrementado
de manera alarmante, las cuales llegaron a más de 50 000 en 2013, con un 28 % detectado solo en el primer
trimestre del año6. Simultáneamente, como parte de un conjunto de recomendaciones para el Gobierno federal,
la GAO (Oficina de Responsabilidad Gubernamental de EE. UU.) reportó que el software malintencionado aumentó
un 185 % en menos de un año7. Aunque las motivaciones comunes, como ganancias financieras y adquisición de
contenido gratuito, siguen impulsando la cantidad de casos de amenazas de seguridad, se informa que el spyware
malintencionado y los ataques dirigidos se volvieron más prominentes en 2013.
Con el aumento de la cantidad de empresas que permiten la metodología BYOD (Traer su propio dispositivo),
es posible que los dispositivos móviles personales de los empleados no tengan el mismo nivel de medidas de
seguridad que la mayoría de los administradores empresariales especificarían en los dispositivos emitidos por
la empresa. Los dispositivos móviles se han vuelto más versátiles en cuanto al uso, desde proporcionar llamadas
de video hasta pagar un café en el café local. Al mismo tiempo, las aplicaciones corporativas empresariales han
accedido a datos que están muy en lo profundo de la empresa. Muchos de los denominados programas de uso
según BYOD han complicado el inventario de dispositivos, y hay un cambio hacia el control de las aplicaciones
móviles y sus usuarios. Sin embargo, la forma más común de autenticación del usuario se basa en el mecanismo
de nombre de usuario y contraseña. Más alarmante es que muchas aplicaciones simplifican el proceso de inicio
de sesión almacenando las credenciales localmente en texto no cifrado.
La mayoría de las veces, la protección de la información del usuario es secundaria a la administración de
los dispositivos en el proceso de desarrollo; por lo tanto, son comunes las implementaciones defectuosas de
protocolos de comprobación de identidades. En consecuencia, han proliferado los ataques de intermediario
en los que la aplicación malintencionada puede obtener acceso a la información de una empresa o los datos
confidenciales de los usuarios.
5 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Sección 2:
Desafíos para proteger las aplicaciones móviles
Existe una plétora de motivos para el incremento de las brechas de seguridad. Generalmente, los desarrolladores
de aplicaciones deben seguir un cronograma muy justo para entregar características con alta visibilidad y, por eso,
la seguridad no suele ser el foco de sus proyectos. Al mismo tiempo, la cantidad de ataques nuevos que surge está
creciendo tan rápidamente que es cada vez más difícil abordarla de una manera adecuada. Idealmente, se esperaría
que las plataformas de los diversos dispositivos proporcionaran seguridad incorporada. Pero la realidad es que,
aunque la seguridad de las plataformas está mejorando, no es coherente entre todas las plataformas ni es
suficiente para hacer frente a todos los problemas de seguridad. Identificamos tres desafíos comunes que los
desarrolladores enfrentan cuando desarrollan aplicaciones seguras.
Protección de las API
Uno de los principales desafíos que presentan las aplicaciones móviles es poder consumir las API back-end
y proporcionar acceso adecuado a solicitudes autenticadas y autorizadas. Si bien muchas soluciones señalan
a OAuth como una solución, en realidad, esto solo cubre el mínimo básico. API diferentes tienen requisitos
diferentes. En cuanto a las API de gran valor en las que el recurso protegido tiene valor monetario o necesita un
alto nivel de garantía, se esperaría que se realizara el establecimiento de una confianza bidireccional antes de que
la API se pueda invocar correctamente. Además, normas como la HIPAA (Ley de Responsabilidad y Portabilidad del
Seguro Médico), cumplimiento con la PCI (Industria de las tarjetas de pago) y la ley Sarbanes Oxley (en las que,
por ley, se requieren niveles criptográficamente asegurados de confianza) son de suma importancia en algunos
sectores industriales muy grandes. Se debe establecer una confianza mutua entre la aplicación y el back-end.
Únicamente en esa situación se protegen las API back-end y la transacción se ejecuta correctamente.
PKI (infraestructura de clave pública)
La seguridad criptográfica mediante firmas digitales y cifrado es útil en muchas áreas. Como un elemento
estructural de la protección de las aplicaciones, los sistemas de PKI pueden establecer identidades de componentes
en un sistema y en el desarrollo de aplicaciones móviles que incluye dispositivos, aplicaciones y usuarios. Lo que es
más importante, la PKI respalda el establecimiento de confianza entre estas entidades.
Cada entidad que participa en un ecosistema de PKI tiene un par de claves pública y privada. La clave pública
se encuentra incrustada en un certificado digital para vincularlo con el propietario de la clave privada. Se requiere
una jerarquía de CA (autoridades de certificación) para administrar la emisión y la revocación de los certificados
digitales en un sistema de PKI. Las dos partes de una transacción en la que se utilicen certificados digitales
confiarán en la CA. Es extremadamente importante proteger las claves privadas de inicio de sesión de estas
autoridades de certificación, porque si las claves se comprometen, todo el sistema de confianza colapsará. De igual
manera, es un desafío mantener en secreto la clave privada en un dispositivo móvil que se puede exponer
fácilmente mediante software malintencionado.
Recientemente, la cantidad de casos que involucran aprovechamientos, ataques y alteraciones de datos
confidenciales demanda la mejora de las prácticas de cifrado en las arquitecturas de PKI. Ataques, como el ataque
informático de VeriSign en 2010 y en varias organizaciones de CA, por ejemplo, GlobalSign y DigicertMalaysia,
han generado inquietudes graves en los administradores de todo el mundo8. Los sistemas de claves privadas
son vulnerables a los ataques de intermediario. Como estos certificados digitales tienen información vital sobre
los usuarios identificados, se puede concluir que proteger la autenticidad y la integridad del certificado es,
de hecho, imperativo.
6 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Normas de seguridad en evolución
El sector y los proveedores están elaborando normas y soluciones de seguridad a una velocidad acelerada.
Las normas y soluciones en evolución pueden ser difíciles de comprender, implementar y mantener para el
desarrollador promedio. Existen muchas tecnologías disponibles para identificación, autenticación y autorización.
Solo en el sistema back-end, hay una infinidad de normas, como SSL (capa de sockets seguros) con autenticación
mutua, credenciales de FTP (protocolo de transferencia de archivos), HTTP (protocolo de transferencia de hipertexto)
básico y certificados X.509. Además, existen mecanismos de SSO (inicio de sesión único) registrados que son
relevantes para el desarrollo de aplicaciones en este momento.
La adopción de OAuth ha incorporado requisitos nuevos en la norma OAuth 2.0. De manera similar, OpenID Connect
evoluciona constantemente para cumplir con los requisitos de los desarrolladores. La rápida elaboración de estas
normas deja a los desarrolladores con las opciones de mantener el soporte de las implementaciones existentes
o adoptar versiones nuevas. Todas estas normas y soluciones pueden no ser necesariamente el centro de atención
del desarrollador de la aplicación cuando existen otras inquietudes más inmediatas, como cumplir con el plazo de
un proyecto complicado para lanzar “algo” al mercado. En ese punto, ciertamente no hay tiempo para proporcionar
capacidades avanzadas que armen dinámicamente las solicitudes de API con el rigor de seguridad correspondiente.
Sección 3:
Requisitos
Las organizaciones que exponen API para aplicaciones móviles requieren el control total de los mecanismos de
protección contra amenazas que se implementan. Pero el “control total” se debe equilibrar con un modelo viable
que los desarrolladores puedan usar y comprender fácilmente.
Una manera óptima para simplificar el esfuerzo de los desarrolladores de aplicaciones móviles en cuanto a la
seguridad es ofrecerles un SDK (kit de desarrollo de software) del lado cliente que oculte la complejidad de la
seguridad. El SDK debe brindar una API fácil de usar que mejore las llamadas a la API back-end con el rigor
de seguridad necesario.
Cuando se invente un nuevo esquema de autenticación, será sencillo actualizar una biblioteca cliente y back-end sin
forzar al desarrollador a comprender los detalles. Proporciona una separación clara de la lógica de las aplicaciones
y las inquietudes de seguridad. Los requisitos clave para esta solución incluyen proporcionar mecanismos para MSSO
(SSO móvil) y una SSL mutua. El fin del MSSO es reducir la cantidad de veces que se deben escribir las contraseñas
en un dispositivo. Cuando se usa una sesión con SSO, se evita posible comportamiento confuso de la aplicación y la
experiencia del usuario se mejora. A la vez, la SSL mutua asegurará el establecimiento de la confianza bidireccional
entre el cliente y la API back-end.
En el lado cliente, toda material de clave o token se debe almacenar de manera segura. Este requisito, sin embargo,
sigue siendo un desafío, ya que los proveedores de software independiente continúan basándose en la potencia de
la plataforma subyacente. Además, la arquitectura debe distinguir entre las entidades principales de un caso de uso
de seguridad móvil: usuario, aplicación y dispositivo. Cada una puede tener que obtener un token de autenticación
y un administrador del sistema debe poder revocar el acceso a cada entidad individual.
7 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Ilustración 1:
Usuarios
Relación entre
usuarios, aplicaciones
y dispositivos
Aplicaciones
Dispositivos
El resto de este reporte analizará una solución que usa una combinación de OAuth 2.0, OpenID Connect y PKI para
abordar estos requisitos.
Sección 4
Un nuevo enfoque de la seguridad
En este nuevo enfoque de la protección de las aplicaciones móviles, buscamos aprovechar al máximo la
infraestructura existente. Para administrar las API de una organización cuando se exponen a aplicaciones internas,
externas o de socios de negocios, usualmente se necesita que una solución de administración de API establezca
fácilmente un perímetro de seguridad en la periferia de la red. Las aplicaciones móviles se vinculan con una
biblioteca cliente que conecta la aplicación con el punto de entrada de la empresa en la periferia. Con una
llamada de API simple, el cliente establece un SSO y un canal seguro para el consumo de la API back-end.
Para ver un ejemplo, consulte la ilustración 2.
Ilustración 2:
Servidores
de API
Descripción general
de un perímetro
de seguridad
PIN de un solo uso,
SMS, APN, llamada
CA Layer 7
AT&T
iPhone
o
nn
os e
ad
Bas
s
rma
Red
empresarial
Android
iPad
Almacenamiento seguro de
claves que se pueden compartir
entre aplicaciones administrado
por bibliotecas cliente
Este enfoque requiere un lado servidor que utilice OpenID Connect y OAuth 2.0, y que pueda admitir extensiones
de protocolos adicionales.
8 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Sección 5
Características del lado servidor
Para proporcionar una solución completa, se necesita un componente del lado servidor que admita la norma
OAuth 2.0 y los extremos de OpenID Connect. Además, proponemos extensiones de estos protocolos para
administrar mejor la relación entre usuarios, dispositivos y aplicaciones.
Para admitir cierto grado de seguridad y uso cuando las aplicaciones se utilizan en dispositivos móviles, se deben
agregar características nuevas a los protocolos existentes. El objetivo es proporcionar tareas relacionadas con la
seguridad y los protocolos mediante el SDK de una manera que sea más o menos transparente para el desarrollador.
También se busca brindar a los usuarios el máximo control posible del acceso a las aplicaciones y los dispositivos
sin tener que recurrir a un administrador.
La tabla 1 a continuación describe esta solución con más detalle.
Tabla 1:
SSO móvil: características
admitidas
Característica
Descripción
OAuth 2.0
En esta propuesta de MSSO, se requiere OAuth 2.0 con compatibilidad con el tipo de
concesión de contraseña y el tipo de concesión de token portador de JWT (token web
de notación de objetos de JavaScript).
OpenID Connect
(incluidas extensiones
relacionadas con MSSO)
OpenID Connect se proporciona con extensiones para MSSO definidas como un nuevo
alcance.
PKI
Firma de CSR (solicitudes de firma de certificado) que identifican un dispositivo y lo
registran para validaciones posteriores.
Extremos relacionados
con protocolos
/connect/device/register: registra un dispositivo y devuelve un certificado firmado.
Extremos protegidos con
OAuth relacionados con
protocolos
/connect/device/list: devuelve una lista de los dispositivos de un usuario.
/connect/device/remove: quita el registro de un dispositivo.
/connect/session/status: devuelve el estado de la sesión de un usuario.
/connet/session/logout: cierra la sesión de un usuario y la finaliza.
/auth/oauth/v2/token/revoke: revoca un token.
Extremos de OpenID
Connect protegidos
con OAuth
/openid/connect/v1/userinfo: devuelve reclamos sobre un usuario.
Extremos relacionados con
la administración
/msso/manager: una vista simple basada en API de REST (transferencia de estado
representacional) que permite a un usuario verificar el estado de la sesión, los dispositivos
registrados y las aplicaciones en ejecución.
El protocolo usa las extensiones de OAuth 2.0, OpenID Connect, JWT y OAuth. De esta manera, el protocolo no solo
mejora, sino que no altera ninguna implementación relacionada con OpenID Connect u OAuth. OAuth contiene el
concepto de secreto compartido para las aplicaciones (client_id/ client_secret) para fines de autorización. Algunas
empresas no aprecian este enfoque, porque podría ser posible que los desarrolladores de aplicaciones obtuvieran
acceso a estos valores y los utilizaran incorrectamente. Pero para abordar este problema, el protocolo permite que
los desarrolladores usen una SSL mutua, la que agrega autenticación sólida a las aplicaciones. El certificado del lado
cliente se puede utilizar para autenticar un dispositivo o un usuario.
9 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Sección 6:
Arquitectura cliente
A fin de ocultar la complejidad de los protocolos de seguridad y autenticación, proponemos un SDK cliente con API
fáciles de usar para desarrolladores de aplicaciones móviles. El SDK cliente tendrá una biblioteca que se utilizará
para desarrollar las aplicaciones, cuando participen en una sesión de MSSO y consuman API back-end. Para ser un
contenedor de inicio de sesión seguro, la biblioteca cliente administrará el flujo de protocolos y el almacenamiento
seguro de todo material de clave, tokens de acceso, tokens de usuarios y certificados. Cada aplicación tendrá
su propio llavero. Las aplicaciones que están firmadas con la misma clave de desarrollador empresarial usarán
un llavero compartido para certificados y token de usuario. El siguiente diagrama ilustra dónde se almacenan las
aplicaciones y los certificados, y cómo interactúan entre ellos en el dispositivo.
Ilustración 3:
Ilustración de la
arquitectura de
aplicaciones
empresariales
Dispositivo
móvil
AT&T
Aplicaciones
empresariales
access_token
refresh_token
Aplicación A
(SDK)
Certificado de servidor
de confianza
JWT (token web JSON)
Certificado de clave privada
access_token
refresh_token
Aplicación B
(SDK)
Llavero privado
Llavero privado
Llavero compartido
Aplicación
Aplicación
Aplicación
Aplicación
Aplicación
de terceros
Aplicación
En el dispositivo móvil, el área de aplicaciones empresariales solo contiene las aplicaciones que fueron firmadas
por la empresa. En la ilustración 3, las aplicaciones están marcadas como “A” y “B”. Cada una de estas aplicaciones
contiene el SDK, el cual maneja la comunicación con OAuth, crea pares de claves y genera una CSR. La puerta de
enlace solo acepta la CSR si contiene un DN (nombre distintivo) único.
Cada aplicación tiene acceso únicamente a su respectivo llavero privado. El llavero privado contiene el access_token
y el refresh_token. Todas las aplicaciones dentro del área de la empresa tienen acceso al mismo llavero compartido
mediante el SDK. En el área del llavero compartido, el certificado de servidor de confianza se importa desde la
puerta de enlace, el que se requiere cuando se usa una CA independiente. Se genera la clave privada y la puerta
de enlace firma el certificado. El JWT está disponible en el llavero compartido mientras el usuario esté en el SSO.
Cuando el usuario cierra sesión, el JWT se elimina.
10 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Token cliente y almacenamiento de claves privadas
El desafío principal es almacenar los tokens y las claves de una manera segura en el lado cliente. En la plataforma
de iOS, tokens portadores y material de clave (por ejemplo, exponentes privados para una clave de RSA [Rivest,
Shamir y Adleman]) se almacenan en el llavero de iOS cuando no los usa una aplicación. Las aplicaciones firmadas
por la misma clave de desarrollador pueden compartir secretos entre ellas con el llavero. El contenido del llavero
se cifra con una clave que está mezclada con el código de acceso de bloqueo del dispositivo (si hay uno) —este es
el PIN (número de identificación personal) de 4 dígitos en iOS— y el id. único secreto de hardware del dispositivo.
Cuando un dispositivo está bloqueado con el código de acceso, la clave se borra de la memoria e, incluso, si la
memoria flash es clonada, el contenido del llavero es inaccesible. Una clave de acceso simple se puede adivinar
en algún momento mediante prueba y error, pero esto requiere la posesión física del dispositivo, porque el UID
(número de identificación único) no se puede extraer de él. Como esto se tiene que realizar en el dispositivo y el
hardware solo puede intentar una cantidad limitada de claves por segundo (muy por debajo de 100), esto puede
llevar mucho tiempo con una clave de acceso compleja. Además, esto requiere conectar el teléfono a un hardware
USB (bus serie universal), debido a que la capa de software de iOS se puede configurar para restablecer la clave
de descifrado de la memoria del dispositivo después de 10 intentos fallidos de adivinar la clave de acceso.
Fishnet Security calcula que una clave de acceso alfanumérica de siete caracteres llevaría un milenio para descifrar
en un ataque de fuerza bruta en el dispositivo9. En la plataforma Android, los tokens portadores y el material de
clave privada se almacenan con el mecanismo de almacenamiento de credenciales de Android cuando no lo usa
una aplicación. Este sistema es proporcionado por un daemon de almacenamiento de claves de sistema que
administra un directorio, el cual contiene archivos cifrados. Las aplicaciones firmadas por la misma clave de
desarrollador y que tengan el mismo id. de Android pueden compartir secretos entre ellas con este mecanismo.
El contenido del almacenamiento de claves se cifra con una clave maestra que se deriva del código de desbloqueo
del dispositivo. Se debe establecer un código de desbloqueo en el dispositivo para usar este mecanismo.
Los bloqueos de pantalla del tipo “Ninguno” o “Deslizar” están deshabilitados mientras el almacenamiento de
credenciales está en uso. La actividad de configuración no permitirá que se seleccionen estos tipos de pantalla
de bloqueo a menos que el usuario active la función “Borrar credenciales” primero. La clave maestra del
almacenamiento de credenciales se borra de la memoria cuando se bloquea el dispositivo. Los ataques de fuerza
bruta sin conexión en una memoria flash clonada son posibles, pero se previenen gracias al uso de la PBKDF2
(función de derivación de claves basada en contraseña 2) (con un recuento de iteración de 8192) como la función
de derivación de claves. Con una GPU (unidad de procesamiento gráfico) de alta gama capaz de computar
4000 millones de iteraciones de la PBKDF2 por segundo, descifrar, en un ataque de fuerza bruta, una clave maestra
derivada de una clave de acceso con entropía equivalente a una clave de acceso alfanumérica de 10 caracteres
debería llevar un milenio (aunque se debe mencionar que un ataque puede dividirse en tantas GPU como el
atacante puede permitirse).
Bibliotecas del lado cliente
Las bibliotecas del lado cliente contienen API fáciles de usar para agregar la aplicación a una sesión de SSO.
Se establece un SSL muta y solo se necesita una llamada de API para aprovechar la seguridad criptográfica, OAuth,
OpenID Connect y el JWT. Las bibliotecas del lado cliente mejoran la solicitud con los parámetros de seguridad
correctos según la configuración del dispositivo.
11 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
A continuación, se encuentra un ejemplo de una biblioteca cliente que realiza una llamada de API habilitada por un
SSO con el método GET.
L7SHTTPClient *httpClient = [[L7SHTTPClient alloc] initWithBaseURL:
[NSURL URLWithString:@”https://www.example.com”]];
[httpClient registerHTTPOperationClass:[AFJSONRequestOperation class]];
[httpClient setDefaultHeader:@”Accept” value:@”application/json”];
NSMutableDictionary * parameters = [[NSMutableDictionary alloc] init];
[parameters setObject:@”listProducts” forKey:@”operation”];
[httpClient getPath:@”/path_to_resources”
parameters:parameters
success:^(AFHTTPRequestOperation *operation,
id responseObject) {
//code to handle success response
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
//code to handle failure response
Sección 7:
Flujo de protocolo de aprovisionamiento
A continuación, se presentan dos diagramas que ilustran cómo un dispositivo recibe un access_token. La ilustración
4, en la siguiente página, ejemplifica una situación en la que el dispositivo es registrado por primera vez y solicita
un token de acceso. El área gris es la aplicación que conecta al usuario con la puerta de enlace de acceso móvil.
Como es la primera vez que el usuario registra el dispositivo, no hay claves ni certificados disponibles. Múltiples
puntos de comprobación están involucrados, ya que primero se deben establecer la autenticación mutua y las
claves privadas. El SDK genera una clave privada y el id. del dispositivo en el llavero empresarial. Al mismo tiempo,
se genera una CSR y, luego, la información del perfil del usuario se envía a la puerta de enlace de acceso móvil.
Es posible que en este punto se realicen comprobaciones adicionales. Cuando el certificado firmado es devuelto
y el dispositivo está correctamente registrado, se puede otorgar la solicitud del access_token.
El segundo diagrama, en la ilustración 5, representa un escenario más simple, en el que el dispositivo ya ha sido
registrado y se ha establecido la autenticación mutua. En este caso el dispositivo registrado solicita un token
subsiguiente. La puerta de enlace valida al usuario con el JWT y la aplicación. Se emite el access_token cuando
el JWT y la aplicación son validados.
12 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Ilustración 4:
Dispositivo que se
registra por primera
vez y solicita un token
de acceso
Aplicación/
SDK
Usuario
Llavero
empresarial
compartido
Llavero
privado
Puerta de
enlace de
acceso móvil
1. Inicia la aplicación
2. Se muestra la pantalla
3. Solicita recursos
4. Usa un certificado del llavero compartido
5. No hay una clave o certificado disponible
6. Solicitud de credenciales de registro
7. Credenciales
8. Genera la clave privada, incluye
el id. del dispositivo en el DN
9. Genera una CSR
10. Se registra con detalles
11. Valida las credenciales, firma el certificado
12. Devuelve el certificado firmado y el id. del dispositivo
13. Guarda el certificado
14. El dispositivo está registrado
15. Solicita el token de OAuth
16. Autentica al usuario y la aplicación
17. JWT (token web JSON)
18. Guarda JWT
19. Guarda los tokens
20. Usa la aplicación
21. Llama la API con seguridad total
22. Devuelve datos
Usuario
Ilustración 5:
Dispositivo ya registrado
que solicita otro access_
token
Aplicación/
SDK
Aplicación/
SDK
Llavero
privado
Llavero
empresarial
compartido
Puerta de enlace
de acceso móvil
1. Solicita el access_token
2. Valida al usuario (JWT) y la aplicación
3. Emite el access_token
Aplicación/
SDK
Puerta de enlace
de acceso móvil
Puerta de
enlace de
acceso móvil
13 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Sección 8:
Conclusión
Como las amenazas de seguridad y el robo de identidad siguen prevaleciendo, se recomienda considerar las
medidas de seguridad para manipular datos confidenciales como una prioridad más importante en un mapa de ruta
de desarrollo de aplicaciones móviles. El lanzamiento CA Layer 7 MAG (Mobile Access Gateway) 2.0, que proporciona
una solución de MSSO, contiene una medida de seguridad completa y basada en normas que es fácil de implementar.
Con un SDK móvil que ofrece una API simple en el dispositivo, cualquier desarrollador móvil puede agregar SSO
y proteger las llamadas de API al back-end mediante la puerta de acceso móvil, sin tener que ser un experto en
seguridad. A medida que esta área de la tecnología evoluciona, vemos varios campos prometedores de investigación.
Primero, se encuentra la mejora de los aspectos dentro del flujo de OAuth. En la actualidad, el IETF (Grupo de
Trabajo de Ingeniería de Internet) está trabajando en el registro dinámico de los clientes. Esto mejoraría el uso
considerablemente, ya que antes no existían interacciones entre las partes10.
En segundo lugar, un aprovisionamiento más dinámico de la configuración del cliente podría permitir a las
empresas actualizar la configuración de solicitudes por aplicación o API. A medida que los dispositivos móviles
cambian de contexto, el rigor de la seguridad debe reflejar el nivel de amenaza actual.
Tercero, mejorar el almacenamiento de material de clave y tokens en el dispositivo es beneficioso. Android 4.2
(también conocido como “Jelly Bean”) admite el almacenamiento de claves con el respaldo del módulo
criptográfico ENGINE de OpenSSL, el cual puede usar almacenamiento de claves de hardware seguro donde exista
compatibilidad con hardware y controladores. El módulo criptográfico ENGINE admite que una clave privada de RSA
almacenada de manera segura se utilice para la autorización del cliente de TLS (seguridad de la capa de transporte)
con una firma de RSA, durante la cual el material de clave privada nunca sale del almacenamiento de hardware
seguro ni figura en la RAM (memoria de acceso aleatorio) de una aplicación no protegida (ni siquiera
temporalmente).
Fourth está investigando cómo las aplicaciones back-end pueden confiar en otras fuentes de identidad;
por ejemplo, un sistema de MDM (administración de datos maestros) mediante una fuente externa, como
un certificado de PIV (comprobación de identidad personal) o una tarjeta de acceso común. Sería más rentable
permitir que los desarrolladores de aplicaciones se vinculen con los activos de infraestructura de identidad
existentes de una organización. La combinación de esto con un sistema de autenticación avanzada puede
proporcionar una autenticación en tiempo real basada en riesgos que determinaría el nivel de riesgo de actividades
en línea. Otro beneficio es amalgamar la identificación del usuario, la aplicación y el dispositivo con ubicación
geográfica y patrones históricos, que se pueden usar con reglas personalizadas para calcular el riesgo de cada
autenticación o transacción.
En conclusión, la estrategia correcta para escribir aplicaciones móviles que aprovechen las API back-end
es implementar una función de puerta de enlace en el perímetro de la red y usar las bibliotecas del lado
cliente para proteger al desarrollador de aplicaciones de los protocolos de seguridad subyacente.
CA Layer 7 Mobile Access Gateway proporciona esta funcionalidad mediante normas abiertas.
14 | Reporte oficial: Identidad en la seguridad móvil
Comuníquese con CA Technologies en ca.com/ar.
Agility Made Possible: la ventaja de CA Technologies
CA Technologies (NASDAQ: CA) ofrece soluciones de administración de TI que ayudan a los clientes a administrar
y proteger los entornos de TI complejos para permitir la provisión de servicios de negocio ágiles. Las organizaciones
aprovechan el software de CA Technologies y las soluciones de SaaS (software como servicio) para acelerar la
innovación, transformar la infraestructura y proteger los datos y las identidades, desde el centro de datos hasta la
nube. CA Technologies asume el compromiso de garantizar que los clientes obtengan los resultados deseados y el
valor de negocio previsto, gracias a la utilización de nuestra tecnología. Para obtener más información sobre los
programas para el éxito del cliente, visite ca.com/ar/customer-success. Para obtener más información sobre
CA Technologies, vaya a ca.com/ar.
1Gartner. “Gartner Says Worldwide PC, Tablet and Mobile Phone Shipments to Grow 5.9 Percent in 2013 as Anytime-Anywhere-Computing Drives Buyer Behavior” (Gartner
dice que los envíos de equipos, tabletas y teléfonos móviles crecerá un 5,9 % en 2013 a medida que la computación en cualquier momento y en cualquier lugar impulsa
el comportamiento de los compradores).
http://www.gartner.com/newsroom/id/2525515. 24 de junio de 2013.
2CA Technologies. “Identity-centric Security” (Seguridad centrada en la identidad). http://community.ca.com/blogs/iam/archive/2013/05/13/identity-centricsecurity.aspx.
Blog de CA Community, 13 de mayo de 2013.
3Dan Goodin,”Anatomy of a hack: How crackers ransack passwords like 'qeadzcwrsfxv1331'” (Anatomía de un ataque: cómo saquean los descifradores contraseñas como
'qeadzcwrsfxv1331'). http://arstechnica.com/security/2013/05/how-crackersmake-minced-meat-out-of-your-passwords/. Arstechnica, 27 de mayo de 2013.
4Sophos. Security Threat Report 2013 (Reporte de amenazas de seguridad de 2013). http://www.sophos.com/enus/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf
5 “Android Mobile Attacks Spreading across the Globe, McAfee finds” (McAfee detecta que los ataques móviles contra Android se propagan por el mundo). http://www.crn.com/
news/security/240155913/android-mobile-attacks-spreadingacross-the-globe-mcafee-finds.htm, revista CRN, 3 de junio de 2013.
6 McAfee. McAfee Threats Report: First Quarter 2013 (Reporte de amenazas de McAfee: primer trimestre de 2013). http://www.mcafee.com/us/resources/reports/rp-quarterlythreat-q1-2013.pdf?cid=BHP014
7Estados Unidos. GAO. “Information Security: Better Implementation of Controls for Mobile Devices Should Be Encouraged” (Seguridad de la información: se debe impulsar
una implementación mejor de los controles para dispositivos móviles). http://www.gao.gov/assets/650/648519.pdf. Septiembre de 2012.
8 “Examining Threats Facing PKI and SSL” (Examen de las amenazas que enfrentan la PKI y la SSL). http://www.securityweek.com/examining-threats-facing-public-keyinfrastructure-pkiand-secure-socket-layer-ssl, SecurityWeek, 11 de febrero de 2012.
9Colin Mortimer. Blog de Fishnet Security. “iOS Passwords: Quick Tips to Maximize Your Security” (Contraseñas de iOS: consejos rápidos para maximizar su seguridad).
http://www.fishnetsecurity.com/6labs/blog/ios-passwords-quick-tipsmaximize-your-security.
10IETP. “OAuth 2.0 Dynamic Client Registration Protocol” (Protocolo de registro dinámico de clientes OAuth 2.0) http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/.
OAuth Working Group. 29 de julio de 2013.
Copyright ©2014 CA. Todos los derechos reservados. Todas las marcas registradas, los nombres comerciales, las marcas de servicios y los logotipos mencionados en este
documento pertenecen a sus respectivas empresas. El propósito de este documento es meramente informativo. CA no se responsabiliza de la exactitud e integridad de
la información. En la medida de lo permitido por la ley vigente, CA proporciona esta documentación “tal cual”, sin garantía de ningún tipo, incluidas, a título enunciativo y no
taxativo, las garantías implícitas de comercialidad, adecuación a un fin específico o no incumplimiento. CA no responderá en ningún caso en los supuestos de demandas por
pérdidas o daños, directos o indirectos, que se deriven del uso de esta documentación, incluidas, a título enunciativo y no taxativo, la pérdida de beneficios, la interrupción de
la actividad empresarial, la pérdida del fondo de comercio o la fuga de datos, incluso cuando CA hubiera podido ser advertida con antelación y expresamente de la posibilidad
de dichos daños. CSX200-59649_0314