Identidad en la seguridad móvil

REPORTE OFICIAL| septiembre de 2014
Identidad en
la seguridad móvil
2 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Tabla de contenido
Introducción
3
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 respecto 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 proporcionar 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 mejorado 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 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.
En este reporte se presentan amenazas recientes que han afectado
a millones de usuarios y se sugiere una solución potente aunque
simple y de bajo costo 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.
4 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
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 a los datos confidenciales de los usuarios.
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
5 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
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. Solo en esa
situación se protegen las API back-end y la transacción se ejecuta
correctamente.
administradores de todo el mundo.8 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.
PKI (infraestructura de clave pública)
Normas de seguridad en evolución
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.
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.
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
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 de
manera dinámica las solicitudes de API con el rigor de seguridad
correspondiente.
6 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
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.
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.
7 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
Sección 4
Un nuevo enfoque respecto 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.
Descripción general de
un perímetro de
seguridad
Servidores
de API
PIN de un solo uso,
SMS, APN, llamada
CA Technologies
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: Funciones admitidas de SSO móvil
Característica
Descripción
OAuth 2.0
En esta propuesta de SSO móvil, 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 SSO móvil)
OpenID Connect se proporciona con extensiones para SSO móvil 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 SSO móvil 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.
Figura 3.
Dispositivo móvil
Relación entre
usuarios, aplicaciones
y dispositivos
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
Aplicaciones
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
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 descifrarse
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
ca.com/ar
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 una SSL mutua
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. 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:[AFJSONRequestOperati
on 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
11 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
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. En la ilustración
4, se 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 el usuario, en este caso, a CA Mobile API Gateway.
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 CA Mobile API Gateway. 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.
Figura 4.
Dispositivo que se
registra por primera
vez y solicita un token
de acceso
Aplicación/
SDK
Usuario
Llavero
empresarial
compartido
Llavero
privado
CA Mobile
API
Gateway
1. Inicia la aplicación.
2. 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
Aplicación/
SDK
Llavero
privado
Llavero
empresarial
compartido
CA
Mobile API
Gateway
12 | Reporte oficial: Identidad en la seguridad móvil
ca.com/ar
En la ilustración 5, hay 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 (token web JSON) y la aplicación. Se emite el access_token cuando el JWT y la aplicación
son validados.
Ilustración 5.
Aplicación/
SDK
Dispositivo ya
registrado que solicita
otro access_token
CA Mobile API Gateway
1. Solicita el access_token.
2. Valida al usuario (JWT) y la aplicación.
3. Emite el access_token.
Aplicación/
SDK
CA Mobile API Gateway
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. CA Mobile API Gateway, que proporciona una solución de SSO móvil, contiene una medida de
seguridad basada en estándares completa 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).
13 | Reporte oficial: Identidad en la seguridad móvil
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 subyacentes. CA Mobile API Gateway
proporciona esta funcionalidad a través de los estándares abiertos.
Comuníquese con CA Technologies en ca.com/ar.
CA Technologies (NASDAQ: CA) crea un software que impulsa la transformación en las empresas y les permite
aprovechar las oportunidades de la economía de la aplicación. El software es el centro de cada empresa, en cada
industria. Desde la planificación hasta el desarrollo, la administración y la seguridad, CA trabaja con empresas en
todo el mundo para cambiar la forma de vivir, de realizar transacciones y de comunicarse, mediante entornos
móviles, de nube pública y privada, y centrales y distribuidos. Obtenga más información en 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.
6McAfee. 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-key-infrastructurepkiand-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. En ningún caso CA será responsable de cualquier pérdida o daño, directo
o indirecto, derivado del uso del presente documento, incluidos, entre otros, el lucro cesante, la interrupción de la actividad comercial, la pérdida del fondo de comercio o de
datos, incluso cuando CA haya recibido notificación acerca de la posibilidad de dichos daños.CS200-87343_0914