Si está leyendo esto, es muy probable que ya haya visto los informes sobre las ramificaciones de seguridad de la emisión de certificados a dispositivos móviles mediante el Protocolo simple de inscripción de certificados (más información en nuestro sitio aquí). Hemos recibido muchas preguntas sobre cómo determinar si un sistema determinado está en riesgo y, en caso afirmativo, qué niveles de exposición puede implicar. La cuestión se complica por el gran número de productos de gestión de dispositivos móviles (MDM) que existen y la gran variedad de opciones de configuración que ofrecen. Debido a toda esta variabilidad, la simple pregunta "¿Está afectado {el productoX}?" puede dar lugar a respuestas demasiado simplistas que podrían dejarle expuesto al riesgo.
Evaluar el riesgo de una determinada implantación de MDM puede ser un poco matizado, ya que hay una serie de factores que entran en juego. Los principales criterios que deben examinarse al realizar una evaluación son:
1) Dónde se envían los retos SCEP (y por lo tanto potencialmente mal utilizados). Como es de esperar, cuantos más lugares se envíen las contraseñas de seguridad y menos seguros sean esos lugares, peor será la situación. Los sistemas que desactivan o permiten la reutilización de las contraseñas de comprobación son aún peores.
2) Qué tipo de contenido de certificado fraudulento puede solicitarse. Cuantas menos restricciones se impongan a la aplicación del contenido del certificado solicitado, más posibilidades habrá de que surjan problemas.
3) Qué sistemas o entidades confían en los certificados potencialmente fraudulentos. Cuanto más generalizada sea la confianza en los certificados emitidos, mayor será el riesgo. Si está buscando emitir certificados en los que confíe la PKI de su organización, esto es definitivamente algo que debería tener muy en cuenta. muy cuidadosamente.
Con el número 1, hay dos áreas en las que los sistemas MDM pueden hacer uso de SCEP: Una gran fuente de riesgo proviene de los casos en los que los perfiles SCEP se utilizan para entregar certificados de autenticación. Pero casi todos los sistemas MDM utilizan SCEP durante la inscripción inicial de dispositivos iOS.
Algunos MDM utilizan SCEP en el servidor MDM, para recuperar certificados en nombre del usuario, y luego entregarlos como PKCS#12 al dispositivo. Esto mantiene un mejor control de las contraseñas de desafío SCEP, pero a expensas de la generación de claves en el dispositivo que admite iOS. Desde el punto de vista de un profesional de PKI, la generación de claves en el dispositivo es muy preferible y ayuda a evitar los quebraderos de cabeza de la gestión de PKI que suponen los certificados que se "pierden" y se entregan a usuarios o dispositivos a los que no pertenecen. Por este motivo, muchos documentos de política de certificados (CP) exigen la generación de claves en el dispositivo o en hardware , o claves privadas no exportables.
#2 depende en gran medida del servidor SCEP y de la PKI que se utilice. En algunos casos se aceptará casi cualquier PKCS#10. Otros permiten algunos campos de campos, mientras que otros se establecen mediante programación. Por ejemplo, muchas plantillas de certificados de Microsoft sobrescriben prácticamente todo lo que se solicita, excepto la clave pública y el asunto y el nombre alternativo del certificado solicitados.
#3 depende de para qué se utilice la PKI que gestiona las solicitudes SCEP. Hemos visto casos en los que organizaciones que ni siquiera están interesadas en emitir certificados de autenticación a través de MDM se han expuesto a riesgos al aprovechar su PKI interna para gestionar la inscripción inicial del dispositivo MDM.
La clave está en la interacción de estos tres factores. Pero incluso en los casos en los que la PKI del servidor SCEP está totalmente aislada y sólo emite certificados de inscripción de dispositivos, sigue existiendo el posible riesgo de que alguien solicite un certificado que represente un dispositivo diferente al sistema MDM, quizás uno con un mayor nivel de acceso o menos restricciones. En referencia al punto 3, esto podría tener un mayor impacto en un despliegue MDM basado en la nube.
Todavía hay muchos matices involucrados, pero esperamos que esto ayude a establecer el contexto. CSS tiene una solución que permite que esto se haga de forma segura, utilizando un Servicio de Validación SCEP para evitar el mal uso de las contraseñas capturadas. En mi opinión, sin algo como esto en su lugar siempre habrá algún riesgo riesgo cada vez que los retos SCEP viajen fuera de un límite de confianza - la única pregunta es cuánto.
