Le compte à rebours est lancé pour Keyfactor Tech Days | Réservez votre place dès aujourd'hui !

  • Accueil
  • Blog
  • iOS 5, S/MIME et gestion des certificats numériques

iOS 5, S/MIME et gestion des certificats numériques

iOS 5, le nouveau système d'exploitation d'Apple pour l'iPad, l'iPhone et l'iPod Touch, sortira "bientôt" - Apple dit officiellement "cet automne", et de nombreux pronostiqueurs parlent d'octobre. Bien que la nouvelle version comporte des centaines de nouvelles fonctionnalités, celle qui intéresse particulièrement les praticiens de l'identité numérique tels que CSS est une fonctionnalité dont on a très peu parlé jusqu'à présent : S/MIME.

La version actuelle d' iOS4.x prend en charge l'utilisation de certificats numériques pour l'authentification: à des éléments tels que les réseaux sans fil, les VPN et Microsoft ActiveSync . Mais à partir d'iOS 5, les utilisateurs d'iPhone, d'iPad et d'iPod Touch pourront envoyer et recevoir des courriers électroniques signés numériquement. et cryptés directement depuis leur appareil.

Il s'agit d'une étape importante, qui augmente encore le niveau de pertinence d'iOS dans l'espace de l'entreprise. Cependant, même dans les circonstances les plus simples, la planification du déploiement de S/MIME ne doit pas être prise à la légère. L'utilisation de S/MIME avec des appareils mobiles augmente encore la complexité.

Notre objectif ici est d'exposer certaines des considérations de planification et de déploiement associées à un déploiement de S/MIME impliquant des appareils iOS.

Bref aperçu de S/MIME

En tant que protocole, S/MIME (qui signifie "Secure Multipurpose Internet Mail Extensions") existe depuis la fin des années 1990, soit depuis presque aussi longtemps que SSL , et il est pris en charge de manière native par presque tous les clients de messagerie électronique courants. Pourtant, il n'a pas bénéficié du même niveau d'adoption omniprésente que SSL.

Comment cela se fait-il ? La réponse réside probablement dans la manière dont S/MIME fonctionne. Les facteurs importants sont les suivants :

  • Le destinataire a besoin d'un certificat : En raison du mode de fonctionnement de la cryptographie à clé publique, un message est crypté avec la clé publique du destinataire figurant dans son certificat. Seule la clé privée correspondante du destinataire peut déchiffrer le message. Cela signifie que si vous venez de déployer PKI ou d'acheter un certificat de messagerie à un tiers, vous n'êtes pas nécessairement en mesure d'envoyer du courrier crypté S/MIME. Si votre destinataire se trouve en dehors de votre organisation et ne dispose pas d'un certificat de messagerie, vous n'avez pas de chance.
  • Vous devez disposer du certificat du destinataire : Cela semble simpliste, mais au moment où vous êtes prêt à envoyer le message, votre client de messagerie doit disposer du certificat du destinataire, afin de pouvoir utiliser sa clé publique pour crypter le message. S'il s'agit d'une personne interne à votre organisation, son certificat peut probablement être recherché dans un annuaire d'entreprise. Mais si ce n'est pas le cas, il se peut que vous n'ayez pas de chance. La plupart des clients de messagerie disposent d'un moyen ad hoc de partager des certificats, en échangeant d'abord des courriels signés numériquement avec le destinataire. Mais cette méthode n'est pas toujours pratique ou évolutive. C'est pourquoi de nombreux déploiements de S/MIME sont axés sur des scénarios de cryptage interne uniquement .
  • Les anciennes clés privées doivent être conservées : Lorsque le certificat d'un utilisateur expire et qu'il en demande un nouveau, l'ancien certificat ne peut pas être supprimé, sinon l'utilisateur ne pourra pas lire les courriels qui ont été cryptés par l'ancien certificat.
  • Les clés privées doivent être archivées : Chaque fois que vous prévoyez de conserver des données sur un disque sous forme cryptée - et le courrier électronique crypté en est un excellent exemple - vous devez disposer d'un solide plan d'archivage et de récupération des clés, faute de quoi vous risquez de perdre des données. Si un utilisateur perd sa clé privée, s'il est licencié, s'il prend sa retraite, etc. Dans de nombreux cas, il s'agit d'une exigence de conservation des données, avec des ramifications juridiques ou de conformité.
  • Séparation des certificats : Les certificats de chiffrement ont besoin de clés privées archivées. Mais les certificats d'authentification ou de signature ont l'exigence inverse en ce qui concerne la protection des clés : pour que les signatures numériques aient une valeur de "non-répudiation", vous devez être en mesure de dire que l'utilisateur, et seulement ce dernier, a eu accès aux clés privées... ce qui est bien sûr impossible si les clés sont archivées et récupérables par d'autres. C'est pourquoi la plupart des clients de messagerie prennent en charge l'utilisation de certificats de messagerie distincts : un pour le cryptage du courrier électronique et un autre pour la signature. Mais contrairement aux certificats de cryptage, il n'y a pas de risque de perte de données en cas de perte d'un certificat de signature ; il suffit d'en émettre un nouveau.

 

S/MIME et iOS

Heureusement, tout ce qui précède est réalisable, moyennant une planification adéquate. Le CSS propose les suggestions suivantes pour une approche générale de la prise en charge d'un déploiement S/MIME impliquant iOS 5.

Inscription pour les certificats d'authentification et de signature à l'aide de SCEP : Les appareils iOS supportent nativement le protocole SCEP (Simple Certificate Enrollment Protocol)... tout comme un certain nombre d'autorités de certification, dont Microsoft CA. Les certificats inscrits SCEP des iPhones et iPads ont leurs clés privées générées sur l'appareil lui-même, et ils ne peuvent jamais être exportés. Si l'appareil est protégé par un code d'accès, la non-répudiation est relativement bien assurée. En outre, les certificats d'authentification sont généralement utilisés pour s'authentifier auprès de systèmes internes tels que les réseaux VPN et sans fil, ce qui signifie qu'un site PKI à racine publique n'est pas nécessaire.

NE PAS s'inscrire pour des certificats de cryptage de courrier électronique en utilisant SCEP : l'inscription par SCEP empêche la possibilité d'archiver les clés privées. En outre, pour pouvoir lire des courriels à plusieurs endroits, chaque utilisateur doit avoir exactement un Chaque système sur lequel l'utilisateur lit son courrier électronique doit avoir le même certificat et la même clé privée, et tous ceux qui lui envoient du courrier électronique doivent utiliser ce certificat lorsqu'ils envoient du courrier crypté.

Les certificats de cryptage des courriels doivent donc être générés ailleurs et importés en toute sécurité dans l'appareil. Mais l'inscription des utilisateurs à des certificats sur leurs ordinateurs portables ou leurs postes de travail, puis la migration de leurs clés vers l'appareil posent des problèmes supplémentaires. Dans la mesure du possible, les clés privées des utilisateurs finaux ne devraient pas ne pas pas être marquées comme exportables. Il est trop facile pour les utilisateurs de les exporter et de les déplacer dans des endroits où elles n'ont pas leur place. En outre, la plupart des utilisateurs choisissent de mauvais mots de passe pour protéger les clés exportées et ne suppriment pas les fichiers lorsqu'ils ont fini de les utiliser, ce qui les expose à un risque important de compromission. CSS recommande fortement d'utiliser une solution centralisée d'archivage et de récupération des clés.

L'approche privilégiée consiste donc à disposer d'une solution automatisée capable d'enregistrer et/ou de fournir les certificats de cryptage S/MIME actuels et passés d'un utilisateur à son appareil iOS avec un minimum d'effort de sa part.

Certificat Planification de la gestion

La gestion des certificats reste l'un des aspects les moins pris en compte dans le déploiement d'applications sur le site PKI. Avant de déployer une application d'entreprise, il convient d'accorder une attention particulière à des aspects tels que :

  • Inscription au certificat : Comment les certificats seront-ils inscrits et délivrés ?
  • Expiration du certificat : Que se passe-t-il lorsque les certificats expirent ? Qui est responsable de la mise à jour des certificats et à quoi ressemblera ce processus ?
  • Révocation des certificats : Ces certificats devront-ils être révoqués dans certaines circonstances ? Dans l'affirmative, quelles sont ces circonstances, qui en est responsable et comment cela sera-t-il géré ?
  • Perte d'un certificat : quel est le plan de remplacement en cas de perte d'un certificat ? Si des certificats de cryptage sont utilisés, le certificat exact (ou au moins un certificat avec les mêmes clés privée et publique) devra être récupéré et remis à l'utilisateur. En fonction des types de certificats concernés, il peut également s'agir d'une discussion sur la révocation.

 

En raison de sa complexité, S/MIME sur les appareils mobiles nécessite une planification particulièrement soignée de la gestion des certificats. Par exemple, iOS ne prend aucune mesure en termes de réinscription ou de notification à l'utilisateur lorsque son certificat est sur le point d'expirer. Il ne fait rien non plus lorsque le certificat expire effectivement.

Élaborer une solution

Keyfactor s'attaque depuis plus de dix ans à des problèmes difficiles pour les grandes entreprises clientes, en combinant des produits prêts à l'emploi, des services professionnels et ses propres produits et outils. En grande partie, les composants d'une solution complète aux défis mentionnés ci-dessus existent déjà. Nous envisageons une solution impliquant les produits suivants :

  • Une infrastructure à clé publique basée sur Microsoft CA software pour créer et délivrer des certificats aux acteurs nécessaires. SCEP sera pris en charge par le rôle Network Device Enrollment Service (NDES) sur Windows Server 2008.
  • Microsoft Active Directory, qui contrôle le contenu des certificats et les critères d'inscription, et stocke les certificats de messagerie enregistrés par les utilisateurs pour les utiliser avec des clients de messagerie tels qu'Outlook. iOS 5 peut récupérer automatiquement les certificats des destinataires à partir d'Active Directory grâce à son connecteur de messagerie Exchange natif.
  • Microsoft Forefront Identity Manager - Gestion des certificats : Composant moins connu de la suite Microsoft Identity Management, "FIM-CM" fournit un flux de travail évolutif et une automatisation des événements du cycle de vie des certificats mentionnés dans la section ci-dessus - en particulier l'archivage et la récupération des clés privées.
  • Le Certificate Reporting Tool (CRT) de Certified Security Solutions, qui aide à surveiller les AC de Microsoft pour les certificats arrivant à expiration, et notifie les détenteurs de certificats ou les administrateurs de l'expiration imminente des certificats. CRT fournit également un cadre flexible et enfichable pour effectuer des actions personnalisées liées à la gestion des certificats. Pour plus d'informations sur CRT , cliquez ici.
  • Mobile Certificate Management System (mCMS) de Certified Security Solutions : dont la sortie est prévue en octobre 2011, mCMS permet une automatisation en douceur des certificats inscrits au SCEP sans ouvrir la voie à d'éventuelles vulnérabilités en matière de sécurité. De plus amples informations techniques concernant le mCMS sont disponibles ici.
  • L'utilitaire de configuration de l'iPhone d'Apple (IPCU), qui permet aux administrateurs de créer des profils de configuration de base utilisés par le mCMS de CSS.
  • Visitez la page du système mobile de gestion des certificats (mCMS) ici.