Última hora: Keyfactor adquiere InfoSec Global y CipherInsights | Soluciones integrales para descubrimiento, control y agilidad

  • Inicio
  • Blog
  • iOS 5, S/MIME y gestión de certificados digitales

iOS 5, S/MIME y gestión de certificados digitales

iOS 5, el nuevo sistema operativo de Apple para iPad, iPhone y iPod Touch, saldrá a la venta "pronto". Apple dice oficialmente que "este otoño", pero muchos pronosticadores apuntan a algún momento de octubre. Aunque la nueva versión tiene cientos de nuevas funciones, la que interesa especialmente a los profesionales de la identidad digital como CSS es una que ha recibido muy poca prensa hasta la fecha: S/MIME.

La versión actual de iOS 4.x admite el uso de certificados digitales para la autenticación en redes inalámbricas, VPN y Microsoft ActiveSync. Pero a partir de iOS 5, los usuarios de iPhone, iPad y iPod Touch podrán enviar y recibir mensajes de texto firmados digitalmente. y cifrados firmados y cifrados directamente desde su dispositivo.

Se trata de un gran paso, que de nuevo eleva el nivel de relevancia de iOS en el espacio empresarial. Sin embargo, incluso en las circunstancias más sencillas, la planificación de la implantación de S/MIME no debe tomarse a la ligera. S/MIME en combinación con dispositivos móviles aumenta aún más la complejidad.

Nuestro objetivo aquí es esbozar algunas de las consideraciones de planificación e implantación asociadas con un despliegue de S/MIME que incluya dispositivos iOS.

Breve descripción de S/MIME

Como protocolo, S/MIME (siglas de "Secure Multipurpose Internet Mail Extensions") existe desde finales de los años 90 -casi tanto como SSL - y está soportado de forma nativa por casi todos los clientes de correo electrónico populares. Sin embargo, no ha disfrutado ni de lejos del mismo nivel de adopción ubicua que SSL.

¿A qué se debe? La respuesta está probablemente en el funcionamiento de S/MIME. Entre los factores significativos se incluyen:

  • El destinatario necesita un certificado: Debido a la forma en que funciona la criptografía de clave pública, un mensaje se cifra con la clave pública del destinatario a partir de su certificado. Sólo la correspondiente clave privada del destinatario puede descifrar el mensaje. Esto significa que si acabas de implantar PKI o has comprado un certificado de correo electrónico a un tercero, no estás necesariamente más cerca de poder enviar correo cifrado S/MIME. Si el destinatario está fuera de su organización y no tiene un certificado de correo electrónico, no tiene suerte.
  • Necesitas tener el certificado del destinatario: Suena simplista, pero en el momento en que estás listo para enviar el mensaje, tu cliente de correo electrónico necesita tener a mano el certificado del destinatario, de modo que pueda utilizar su clave pública para cifrar el mensaje. Si se trata de una persona interna de la organización, es probable que pueda buscar su certificado en un directorio de la empresa. Pero si no, puede que vuelvas a tener mala suerte. La mayoría de los clientes de correo electrónico tienen una forma ad hoc de compartir certificados, intercambiando primero mensajes firmados digitalmente con el destinatario. Pero esto no siempre es práctico ni escalable. Como resultado, muchas implantaciones de S/MIME se centran en escenarios de cifrado exclusivamente internos .
  • Es necesario conservar las claves privadas antiguas: Cuando el certificado de un usuario caduca y se inscribe para obtener uno nuevo, el antiguo no puede borrarse, o el usuario no podrá leer ningún correo electrónico que haya sido cifrado por el certificado antiguo.
  • Las claves privadas deben archivarse: Siempre que planees mantener datos en forma de disco encriptado - y el correo electrónico encriptado es un buen ejemplo - necesitarás tener un sólido plan de archivo y recuperación de claves, o estarás arriesgando la pérdida de datos. Si un usuario pierde su clave privada, es despedido, se jubila, etc., seguirá siendo necesario acceder a su correo electrónico. En muchos casos, se trata de un requisito de conservación de datos, con ramificaciones legales o de cumplimiento.
  • Separación de certificados: Los certificados de cifrado necesitan claves privadas archivadas. Pero los certificados de autenticación o firma tienen el requisito opuesto cuando se trata de la protección de claves: para que las firmas digitales tengan valor de "no repudio", se quiere poder decir que el usuario, y sólo ese usuario, tuvo acceso a las claves privadas... lo que, por supuesto, es imposible si las claves están archivadas y pueden ser recuperadas por otros. Por eso la mayoría de los clientes de correo electrónico admiten el uso de certificados de correo separados: uno para el cifrado del correo y otro diferente para la firma. Pero, a diferencia de los certificados de cifrado, no hay riesgo de pérdida de datos por la pérdida de un certificado de firma: basta con emitir uno nuevo.

 

S/MIME e iOS

Afortunadamente, todo lo anterior es factible, con la planificación adecuada. CSS ofrece las siguientes sugerencias para un enfoque general de apoyo a un despliegue de S/MIME con iOS 5.

Inscripción de certificados de autenticación y firma mediante SCEP: los dispositivos iOS son compatibles de forma nativa con el Protocolo simple de inscripción de certificados (SCEP)... y también lo son varias autoridades de certificación, incluida Microsoft CA. Los certificados inscritos en SCEP de iPhones y iPads tienen sus claves privadas generadas en el propio dispositivo, y nunca pueden exportarse. Si el dispositivo está protegido por un código de acceso, la historia del no repudio es relativamente buena. Además, los certificados de autenticación se suelen utilizar para autenticarse en sistemas internos como VPN y redes inalámbricas, lo que significa que una PKI de raíz pública es innecesaria.

NO inscriba certificados de cifrado de correo electrónico mediante SCEP: la inscripción a través de SCEP impide archivar las claves privadas. Además, para poder leer el correo electrónico en varias ubicaciones, cada usuario necesita tener exactamente un certificado de cifrado de correo electrónico activo en todo momento: cada sistema en el que el usuario lea su correo electrónico debe tener el mismo certificado y clave privada, y todos los que le envíen correo electrónico deben utilizar ese certificado al enviar correo cifrado.

Por tanto, los certificados de cifrado del correo electrónico deben generarse en otro lugar e importarse de forma segura al dispositivo. Pero inscribir a los usuarios para que obtengan certificados en sus portátiles o estaciones de trabajo y luego migrar sus claves al dispositivo plantea retos adicionales. Si es posible, las claves privadas de los usuarios finales no deberían no marcarse como exportables. Es demasiado fácil para los usuarios exportarlas y moverlas a lugares a los que no pertenecen. Además, la mayoría de los usuarios eligen pésimas contraseñas para proteger las claves exportadas y no borran los archivos cuando terminan de usarlos, con lo que corren un gran riesgo de verse comprometidos. CSS recomienda encarecidamente aprovechar una solución centralizada de archivo y recuperación de claves.

El enfoque preferido, por tanto, es disponer de una solución automatizada que pueda inscribir y/o entregar los certificados de cifrado S/MIME actuales y anteriores de un usuario a su dispositivo iOS con un esfuerzo mínimo por su parte.

Planificación de la gestión de certificados

La gestión de certificados sigue siendo uno de los aspectos menos tratados de la implantación de aplicaciones con PKI. Antes de desplegar cualquier aplicación empresarial, deben tenerse muy en cuenta aspectos como:

  • Inscripción de certificados: ¿Cómo se inscribirán y entregarán los certificados?
  • Expiración de certificados: ¿Qué ocurre cuando caducan los certificados? ¿Quién es el responsable de gestionar la actualización de los certificados y cómo será ese proceso?
  • Revocación de certificados: ¿Habrá que revocar estos certificados en determinadas circunstancias? Si es así, ¿cuáles son, quién es el responsable y cómo se gestionará?
  • Pérdida de certificados: ¿Cuál es el plan de sustitución en caso de pérdida de un certificado? Si se utilizan certificados de cifrado, será necesario recuperar el certificado exacto (o al menos un certificado con las mismas claves pública y privada) y devolvérselo al usuario. Dependiendo de los tipos de certificados de que se trate, esto puede incluir también un debate sobre la revocación.

 

Debido a su complejidad, S/MIME en dispositivos móviles requiere una planificación especialmente cuidadosa de la gestión de certificados. Por ejemplo, iOS no realiza ninguna acción en términos de reinscripción o notificación al usuario cuando su certificado está a punto de caducar. Tampoco hace nada cuando el certificado caduca.

Poner en común una solución

Keyfactor lleva más de una década abordando problemas difíciles para clientes de grandes empresas, mediante una combinación de productos listos para usar, servicios profesionales y productos y herramientas propios. En gran medida, los componentes para una solución integral a los retos mencionados ya existen. Prevemos una solución que incluya los siguientes productos:

  • Una infraestructura de clave pública basada en Microsoft CA software para crear y entregar certificados a los actores necesarios. SCEP se soportará a través del rol Network Device Enrollment Service (NDES) en Windows Server 2008.
  • Microsoft Active Directory, que controla el contenido de los certificados y los criterios de inscripción, y almacena los certificados de correo electrónico de los usuarios inscritos para su uso con clientes de correo electrónico como Outlook. iOS 5 puede recuperar automáticamente los certificados de los destinatarios desde Active Directory a través de su conector nativo de correo electrónico Exchange.
  • Gestor de identidades de Microsoft Forefront - Gestión de certificados: Un componente menos conocido de la suite de Gestión de Identidades de Microsoft, "FIM-CM" proporciona un flujo de trabajo escalable y automatización sobre los eventos del ciclo de vida de los certificados mencionados en la sección anterior - particularmente archivo y recuperación de claves privadas.
  • Certificate Reporting Tool (CRT) de Certified Security Solutions, que ayuda a supervisar las CA de Microsoft en busca de certificados que vayan a caducar y notifica a los titulares o administradores de certificados la inminente caducidad de los mismos. CRT también proporciona un marco flexible y conectable para realizar acciones personalizadas relacionadas con la gestión de certificados. Encontrará más información sobre CRT aquí.
  • Sistema móvil de gestión de certificados (mCMS) de Certified Security Solutions: mCMS, que saldrá a la venta en octubre de 2011, permite automatizar sin problemas los certificados inscritos en el SCEP sin abrir posibles vulnerabilidades de seguridad. Puede encontrar más información técnica sobre mCMS aquí.
  • La Utilidad de Configuración del iPhone de Apple (IPCU), que permite a los administradores crear perfiles de configuración básicos que son utilizados por el mCMS de CSS.
  • Visite la página de Mobile Certificate Management System (mCMS) aquí.