Un système exécutant un démon IKE peut négocier les paramètres nécessaires pour créer une association de sécurité (SA) entre ce système et un autre système exécutant le démon IKE. Le protocole utilisé pour négocier cette SA et les SA IPsec suivantes est appelé IKE. Cette version d'Oracle Solaris prend en charge la version 1 (IKEv1) et la version 2 (IKEv2) du protocole IKE.
L'association de sécurité IKE (également appelée ISAKMP ou Phase 1 SA dans IKEv1) sécurise d'autres échanges de protocole entre ces deux systèmes IKE. Ces échanges négocient les algorithmes cryptographiques, la stratégie IPsec, ainsi que d'autres paramètres nécessaires à la création des SA IPsec.
Les systèmes exécutant un démon IKE peuvent également être configurés pour négocier des SA IPsec pour le compte d'autres systèmes. Les systèmes configurés de cette manière sont appelés passerelles de sécurité. Si la négociation IKE s'est déroulée avec succès, les SA IPsec permettent de protéger les paquets du réseau.
Si l'exigence stricte est de n'utiliser qu'une cryptographie validée FIPS 140-2, vous devez exécuter la version Oracle Solaris 11.1 SRU 5.5 ou la version Oracle Solaris 11.1 SRU 3. Oracle a obtenu la validation FIPS 140-2 relative à la structure cryptographique dans ces deux versions spécifiques. Oracle Solaris 11.2 s'appuie sur cette base validée pour apporter des améliorations logicielles concernant la performance, les fonctionnalités et la fiabilité. Configurez Oracle Solaris 11.2 chaque fois que possible en mode FIPS 140-2 pour bénéficier de ces améliorations.
Les paramètres négociés pour créer le SA IKE incluent les algorithmes cryptographiques qui protègent les échanges IKE et le matériel d'authentification. Le matériel d'authentification est utilisé pour déterminer si les paquets contenant les échanges de protocole IKE sont de confiance. Autrement dit, si les paquets proviennent d'un système approuvé et non pas d'un système se faisant passer pour ce système.
Oracle Solaris prend en charge deux types de supports d'authentification pour IKE, les clés prépartagées et les certificats de clés publiques.
Une clé prépartagée est une chaîne de caractères hexadécimaux ou ASCII uniquement connue des deux systèmes IKE. Les clés sont appelées prépartagées car les deux extrémités doivent connaître la valeur de la clé avant l'échange IKE. Cette clé doit faire partie de la configuration IKE sur les deux systèmes. La clé prépartagée est utilisée pour la génération de charges IKE, qui constituent les paquets qui implémentent le protocole IKE. Le système qui traite ces charges IKE utilise la même clé pour authentifier les charges qu'il reçoit.
La clé prépartagée IKE n'est pas échangée entre les points d'extrémité IKE en utilisant le protocole IKE. En règle générale, la clé est partagée avec le système homologue via un autre moyen, tel qu'un appel téléphonique.
La clé prépartagée des homologues utilisant cette authentification doit être identique. Les clés sont stockés dans un fichier sur chacun des systèmes.
Sécurisation des certificats de clés publiques et leur numériquement chaînes fournissent un mécanisme permettant d'identifier un système n'importe quel sans avoir à manuellement de change secret informations. Par conséquent, les certificats de clés publiques sont plus sûre que des clés prépartagées.
Un certificat de clé publique de données qui est un encode un BLOB en cas de présence de valeur de clé publique, certaines informations concernant la génération du certificat, comme son nom et un hachage qui l'a signé ou de la somme de contrôle du, le certificat et une signature numérique du dièse. Ensemble, ces valeurs constituent le certificat. La signature numérique garantit que le certificat n'a pas été modifié.
Une clé publique est une valeur mathématiquement dérivée d'une autre valeur, la clé privée. Qui permet d'obtenir la mathématique clé publique algorithme la clé privée rend l'extraction à partir de la clé privée à partir de la clé publique irréalisables. Par conséquent, certificats de clés publiques peuvent être gratuitement partagé. Parmi les algorithmes utilisés pour dériver des clés publiques, on peut citer RSA et les courbes elliptiques.
Une signature numérique est le résultat du traitement du contenu d'un certificat par un algorithme de signature tel que RSA, DSA ou ECDSA. Ces algorithmes, utiliser une clé de signature privée qui ne fait pas partie du certificat, et de produire une signature numérique. La signature est ajoutée au certificat. Là encore, le calcul de la clé de signature à partir du le contenu d'un certificat et la signature n'est pas pratique. D'autres informations pour ce point, la signature de certificat et que, par conséquent, les peuvent être facilement vérifier le contenu d'un certificat à l'aide d'un valeur, qui a été dérivée de la clé de signature.
Un certificat peut être auto-signé , auquel cas la signature du certificat peut-être vérifié par la clé publique du certificat, ou il peut être signée à l'aide d'une autre entité. Lorsqu'un autre entité signe le certificat, la valeur de la clé publique utilisé pour vérifier le certificat est également distribué sous forme de certificat de clé publique. Ce deuxième certificat sera signé par une autorité de certification (AC) de confiance ou par un intermédiaire. L'entité de signature fait confiance, en dernière analyse, à l'intermédiaire, c'est-à-dire l'AC root ou l'ancre sécurisée.
Ces certificats à clés publiques et les composants des structures, ainsi que les composants qui les implémentent les procédures, sont souvent appelés infrastructure à clé publique (PKI). La portée d'une PKI de l'organisation peut varier. Peut résider dans une simple une PKI permettant de signer les certificats CA pour utilisation locaux quelques. Vous pouvez saisir une grande diversité de PKI un est d'utiliser une en tant que globalement faisant autorité reconnu CA ancre sécurisée.
Cette section décrit les étapes générales à créer et à utiliser dans IKE les certificats de clés publiques. Les procédures spécifiques sont décrites aux sections Configuration d'IKEv2 avec des clés prépartagées et Configuration d'IKEv1 avec des clés prépartagées.
Si vous souhaitez utiliser un certificat autosigné ou un certificat issu d'une autorité de certification (CA), vous devez d'abord générer une paire de clés publique / privée
Pour un certificat autosigné, les homologues IKE échangent ensuite ces certificats, vérifient hors bande que les certificats sont authentiques, puis importent les certificats des homologues dans le keystore local. Keystore contient alors la le certificat auto-signé d'origine plus les certificats importés.
Pour les certificats d'une AC, il faut réaliser encore quelques opérations. Lorsque vous générez une paire clé publique / clé privée, vous pouvez également générer une CSR (certificate signing request). Une CSR contient la clé publique et les identificateurs. Un identificateur typique est un nom distinctif (ND), par exemple :
DN=”O=Example\, Inc, OU=qa, L=Silicon Valley, ST=CA, CN=enigma”
Envoyez la demande de signature de certificat à votre autorité de certification (CA).
Dans un processus type, vous devez coller la demande de signature de certificat dans un formulaire Web et soumettre ce dernier à votre autorité de certification. L'autorité de certification peut vous envoyer plusieurs certificats.
Obtenez les certificats signés auprès de l'autorité de certification (CA), puis importez-les dans votre keystore IKEv2 ou base de données IKEv1.
Vous devez importer tous les certificats que la CA a envoyés. Ces certificats se composent d'une "chaîne de confiance" à partir de la CA ancre sécurisée ou pour l'utilisateur root chacun identifiés, à votre certificat signé.
IKE répétez la procédure sur un pair.
Les règles IKE utiliser les certificats dans.
Vous indiquer le certificat par un DN, tel qu'un identificateur. Les certificats CA-signé pour, vous pouvez configurer IKE pour accepter tout certificat CA est signée par une particulière.
Un certificat signé est de confiance et valide car l'autorité de signature assure sa validité. Si un certificat est découvert ou déterminé est incorrect, le CA en tant que le révoquer.
Les AC conservent une liste de certificats révoqués, souvent appelée liste des certificats révoqués (CRL). Vous pouvez utiliser le protocole OCSP (Online Certificate Status Protocol) pour vérifier de manière dynamique le statut d'un certificat. Certains certificats de clés publiques intègrent des URI. Ils identifient un emplacement Web où vous pouvez vérifier la liste de révocation de certificats ou l'emplacement Web d'un serveur OCSP.
Pour plus d'informations, reportez-vous à RFC 2459: Certificate and CRL Profile et RFC 2560: Online Certificate Status Protocol - OCSP.
Les certificats de clés publiques contiennent la date et l'heure d'émission et leur durée de validité. Par conséquent, les horloges de systèmes générant doivent être précises et utiliser des certificats. Le NTP (Network Time Protocol) : ce logiciel peut être utilisé pour synchroniser les horloges sur les systèmes. Le logiciel NTP du domaine public de l'Université du Delaware est inclus dans la version Oracle Solaris. La documentation est disponible sur le site Web NTP Documentation. Vous pouvez également installer le package service/network/ptp pour configurer le service Precision Time Protocol (PTP). Reportez-vous à la norme IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems.