REPORTE OFICIAL septiembre de Identidad en la seguridad móvil

Transcripción

1 REPORTE OFICIAL septiembre de 2014 Identidad en la seguridad móvil

2 2 Reporte oficial: Identidad en la seguridad móvil Tabla de contenido Introducción 3 Sección 1: Amenazas recientes 4 Sección 2: Desafíos para proteger las aplicaciones móviles 5 Protección de API (interfaz gráfica de usuario) PKI (infraestructura de clave pública) Normas de seguridad en evolución 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 9 Token cliente y almacenamiento de claves privadas Bibliotecas del lado cliente Sección 7: Flujo de protocolo de aprovisionamiento 11 Sección 8: Conclusión 12

3 3 Reporte oficial: Identidad en la seguridad móvil 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 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 hora 3. 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 4 Reporte oficial: Identidad en la seguridad móvil 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 nunca 4. 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 Rusia 5. 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 en 2013, con un 28 % detectado solo en el primer trimestre del año 6. 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ño 7. 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 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 5 Reporte oficial: Identidad en la seguridad móvil 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. 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 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. 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 de manera dinámica las solicitudes de API con el rigor de seguridad correspondiente.

6 6 Reporte oficial: Identidad en la seguridad móvil 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. Relación entre usuarios, aplicaciones y dispositivos Usuarios 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 AT&T 7 Reporte oficial: Identidad en la seguridad móvil 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 iphone PIN de un solo uso, SMS, APN, llamada Basados en normas CA Technologies 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 8 Reporte oficial: Identidad en la seguridad móvil 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 OAuth 2.0 OpenID Connect (incluidas extensiones relacionadas con SSO móvil) PKI Extremos relacionados con protocolos Extremos protegidos con OAuth relacionados con protocolos Descripción 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 se proporciona con extensiones para SSO móvil definidas como un nuevo alcance. Firma de CSR (solicitudes de firma de certificado) que identifican un dispositivo y lo registran para validaciones posteriores. /connect/device/register: registra un dispositivo y devuelve un certificado firmado. /connect/device/remove: quita el registro de un dispositivo. /connect/device/list: devuelve una lista de los dispositivos de un usuario. /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 Extremos relacionados con la administración /openid/connect/v1/userinfo: devuelve reclamos sobre un usuario. /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 AT&T 9 Reporte oficial: Identidad en la seguridad móvil 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. Relación entre usuarios, aplicaciones y dispositivos Dispositivo móvil Aplicaciones empresariales access_token refresh_token A (SDK) Certificado de servidor de confianza JWT (token web JSON) Certificado de clave privada B (SDK) access_token refresh_token Llavero privado Llavero compartido Llavero privado Aplicaciones de terceros 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 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 dispositivo 9. 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 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:@ ]]; [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 11 Reporte oficial: Identidad en la seguridad móvil 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 Usuario 1. Inicia la aplicación. 2. Muestra la pantalla. 3. Solicita recursos. / SDK Llavero privado 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. Llavero empresarial compartido CA Mobile API Gateway 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. 18. Guarda JWT. 19. Guarda los tokens. 17. JWT (token web JSON) 20. Usa la aplicación. 21. Llama la API con seguridad total. 22. Devuelve datos. Usuario / SDK Llavero privado Llavero empresarial compartido CA Mobile API Gateway

12 12 Reporte oficial: Identidad en la seguridad móvil 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. Dispositivo ya registrado que solicita otro access_token / SDK 1. Solicita el access_token. CA Mobile API Gateway 2. Valida al usuario (JWT) y la aplicación. 3. Emite el access_token. / 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 partes 10. 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 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 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. 1 Gartner. 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) de junio de CA Technologies. Identity-centric Security (Seguridad centrada en la identidad). Blog de CA Community, 13 de mayo de Dan 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'). Arstechnica, 27 de mayo de Sophos. Security Threat Report 2013 (Reporte de amenazas de seguridad de 2013). 5 Android Mobile Attacks Spreading across the Globe, McAfee finds (McAfee detecta que los ataques móviles contra Android se propagan por el mundo). revista CRN, 3 de junio de McAfee. McAfee Threats Report: First Quarter 2013 (Reporte de amenazas de McAfee: primer trimestre de 2013). 7 Estados 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). Septiembre de Examining Threats Facing PKI and SSL (Examen de las amenazas que enfrentan la PKI y la SSL). SecurityWeek, 11 de febrero de Colin Mortimer. Blog de Fishnet Security. ios Passwords: Quick Tips to Maximize Your Security (Contraseñas de ios: consejos rápidos para maximizar su seguridad) IETP. OAuth 2.0 Dynamic Client Registration Protocol (Protocolo de registro dinámico de clientes OAuth 2.0) 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. cs _0914