Si vous lisez ces lignes, il y a de fortes chances que vous ayez déjà vu les rapports sur les ramifications en matière de sécurité de l'émission de certificats pour les appareils mobiles à l'aide du protocole Simple Certificate Enrollment Protocol (plus d'informations sur notre site ici). Nous avons reçu de nombreuses demandes de renseignements sur la manière de déterminer si un système donné est exposé à un risque et, le cas échéant, sur les niveaux d'exposition possibles. Le nombre de produits de gestion des appareils mobiles (MDM) existants et la grande variété d'options de configuration qu'ils offrent compliquent le problème. En raison de cette variabilité, le simple fait de demander "Le {produitX} est-il affecté ?" peut conduire à des réponses trop simples qui peuvent encore vous exposer à un risque.
L'évaluation du risque d'un déploiement MDM donné peut être un peu nuancée, car un certain nombre de facteurs entrent en jeu. Les principaux critères à examiner lors de l'évaluation sont les suivants :
1) L'endroit où les défis SCEP sont envoyés (et donc potentiellement utilisés à mauvais escient). Comme on peut s'y attendre, plus il y a d'endroits où les mots de passe de contestation sont envoyés, et moins ces endroits sont sécurisés, plus la situation est mauvaise. Les systèmes qui désactivent ou autorisent la réutilisation des mots de passe de contestation sont encore pires.
2) Quel type de contenu de certificat frauduleux peut être demandé. Moins il y a de restrictions sur l'application du contenu des certificats demandés, plus il y a de risques de problèmes.
3) Quels systèmes ou entités font confiance aux certificats potentiellement frauduleux. Plus la confiance dans les certificats émis est répandue, plus le risque est grand. Si vous souhaitez émettre des certificats auxquels votre organisation accorde sa confiance sur le site PKI, il s'agit là d'un aspect qu'il convient de prendre très au sérieux. très très attentivement.
Avec le numéro 1, il y a deux domaines dans lesquels les systèmes MDM peuvent utiliser SCEP : une grande source de risque provient des cas où les profils SCEP sont utilisés pour délivrer des certificats d'authentification. Mais presque tous les systèmes MDM utilisent SCEP lors de l'enrôlement initial des appareils iOS.
Certains MDM utilisent SCEP au niveau du serveur MDM, pour récupérer les certificats au nom de l'utilisateur, puis les délivrer sous forme de PKCS#12 à l'appareil. Cela permet de mieux contrôler les mots de passe de défi SCEP, mais au détriment de la génération de clés sur l'appareil qu'iOS prend en charge. Du point de vue d'un praticien de PKI , la génération de clés sur l'appareil est largement préférable et permet d'éviter les maux de tête liés à la gestion de PKI lorsque les certificats "s'égarent" et sont remis à des utilisateurs ou à des appareils auxquels ils n'appartiennent pas. C'est pourquoi de nombreux documents de politique de certification (CP) imposent en fait la génération de clés sur l'appareil ou sur hardware , ou des clés privées non exportables.
#2 dépend fortement du serveur SCEP et de PKI utilisés. Dans certains cas, presque tous les PKCS#10 sont acceptés. D'autres autorisent certains tandis que d'autres champs sont définis par programme. Par exemple, de nombreux modèles de certificats Microsoft écrasent à peu près tout ce qui est demandé, à l'exception de la clé publique, du sujet du certificat demandé et du nom du sujet alt.
#Le numéro 3 dépend de l'utilisation qui est faite du site PKI qui traite les requêtes SCEP. Nous avons vu des cas où des organisations qui ne sont même pas intéressées par l'émission de certificats d'authentification via MDM se sont exposées à des risques en utilisant leur PKI interne pour gérer l'enrôlement initial de l'appareil MDM.
C'est l'interaction de ces trois facteurs qui est déterminante. Mais même dans les cas où le serveur SCEP PKI est entièrement isolé et n'émet que des certificats d'inscription d'appareil, il existe toujours un risque possible que quelqu'un demande un certificat qui représente un appareil différent du système MDM - peut-être un appareil avec un niveau d'accès plus élevé ou moins de restrictions. Pour faire référence au point 3, cela pourrait avoir un impact plus important dans le cadre d'un déploiement MDM basé sur le cloud.
Il y a encore beaucoup de nuances à faire, mais j'espère que cela aidera à définir le contexte. CSS a une solution qui permet de le faire en toute sécurité, en utilisant un service de validation SCEP pour empêcher l'utilisation abusive des mots de passe de défi capturés. À mon avis, sans une telle solution en place, il y aura toujours risque risque à chaque fois que les défis SCEP voyagent en dehors d'une limite de confiance - la seule question est de savoir dans quelle mesure.
