Présentation du RPC sécurisé

Le RPC (Remote Procedure Call, appel de procédure à distance) sécurisé protège les procédures distantes par le biais d'un mécanisme d'authentification. Le mécanisme d'authentification Diffie-Hellman authentifie à la fois l'hôte et l'utilisateur à l'origine d'une demande de service. Le mécanisme d'authentification utilise le chiffrement Data Encryption Standard (DES). Les applications qui utilisent le RPC sécurisé incluent le service de noms NFS et NIS.

Services NFS et RPC sécurisé

NFS permet à plusieurs hôtes de partager des fichiers sur le réseau. Dans le cadre du service NFS, un serveur contient les données et les ressources pour plusieurs clients. Les clients ont accès aux systèmes de fichiers que le serveur partage avec les clients. Les utilisateurs connectés aux systèmes client peuvent accéder aux systèmes de fichiers en montant les systèmes de fichiers à partir du serveur. Pour l'utilisateur sur le système client, il s'affiche comme si les fichiers étaient des fichiers locaux pour le client. L'une des utilisations les plus courantes de NFS permet aux systèmes d'être installés dans les bureaux, tout en stockant tous les fichiers utilisateur dans un emplacement central. Certaines fonctions du service NFS, telles que l'option -nosuid de la commande mount peuvent être utilisées pour interdire l'ouverture des périphériques et systèmes de fichiers par des utilisateurs non autorisés.

Le service NFS utilise le RPC sécurisé afin d'authentifier les utilisateurs adressant des demandes sur le réseau. Ce processus est appelé NFS sécurisé. Le mécanisme d'authentification Diffie-Hellman AUTH_DH utilise des fonctions de chiffrement DES pour garantir un accès autorisé. Le mécanisme AUTH_DH est également appelé AUTH_DES. Pour plus d'informations, reportez-vous aux références suivantes :

• Pour configurer et administrer le service NFS sécurisé, reportez-vous à la section Administration du système NFS sécurisé du manuel Administration d’Oracle Solaris : Services réseau.

• Pour une présentation des transactions impliquées dans l'authentification RPC, reportez-vous à la section Mise en oeuvre de l'authentification Diffie-Hellman.

Chiffrement DES avec NFS sécurisé

Les fonctions de chiffrement Data Encryption Standard (DES) utilisent une clé 56 bits pour chiffrer les données. Si deux utilisateurs identifiés ou principaux disposent de la même clé DES, ils peuvent communiquer en privé à l'aide de la clé pour chiffrer et déchiffrer du texte. DES est un mécanisme de chiffrement relativement rapide.

Le risque lié à l'utilisation de la clé DES uniquement est qu'un intrus puisse recueillir suffisamment de messages texte chiffrés avec la même clé pour être en mesure de découvrir la clé et déchiffrer les messages. C'est pour cette raison que les systèmes de sécurité tels que NFS sécurisé doivent changer de clés fréquemment.

Authentification Kerberos

Kerberos est un système d'authentification développé au MIT. Une partie du chiffrement dans Kerberos est basée sur DES. La prise en charge de Kerberos V4 n'est plus assurée dans le cadre du RPC sécurisé. Cependant, une mise en oeuvre côté client et côté serveur de Kerberos V5, qui utilise RPCSEC_GSS, est incluse dans cette version. Pour plus d'informations, reportez-vous au Chapitre 19, Introduction au service Kerberos.

Authentification Diffie-Hellman et RPC sécurisé

La méthode Diffie-Hellman (DH) d'authentification des utilisateurs se révèle très difficile à déchiffrer pour un intrus. Le client et le serveur disposent chacun de leur clé privée, qu'ils utilisent avec la clé publique pour créer une clé commune. La clé privée est également appelée clé secrète. Le client et le serveur utilisent la clé commune pour communiquer l'un avec l'autre. La clé commune est chiffrée à l'aide d'une fonction de chiffrement convenue, comme par exemple la méthode DES.

L'authentification est basée sur la capacité du système émetteur à utiliser la clé commune pour chiffrer l'heure actuelle. Le système récepteur peut ensuite la déchiffrer et la vérifier par rapport à son heure actuelle. L'heure du client et l'heure du serveur doivent être synchronisées. Pour plus d'informations, reportez-vous à la section Gestion du protocole NTP (tâches) du manuel Administration d’Oracle Solaris : Services réseau.

Les clés publiques et privées sont conservées dans une base de données NIS. NIS stocke les clés dans la carte publickey. Ce fichier contient la clé publique et la clé privée pour tous les utilisateurs potentiels.

L'administrateur système est responsable du paramétrage des cartes NIS, et de la génération d'une clé publique et d'une clé privée pour chaque utilisateur. La clé privée est stockée sous forme chiffrée avec le mot de passe de l'utilisateur. Du fait de ce processus, la clé privée n'est connue que de l'utilisateur.

Mise en oeuvre de l'authentification Diffie-Hellman

Cette section décrit la série de transactions dans une session client-serveur utilisant la méthode d'authentification Diffie-Hellman (AUTH__DH).

Génération de clés publiques et de clés secrètes pour le RPC sécurisé

Avant une transaction, l'administrateur exécute la commande newkey ou nisaddcred pour générer une clé publique et une clé secrète. . Chaque utilisateur dispose de ses propres clé publique et clé secrète. La clé publique est stockée dans une base de données publique. La clé secrète est stockée sous forme chiffrée dans la même base de données. La commande chkey modifie la paire de clés.

Exécution de la commande keylogin pour le RPC sécurisé

Normalement, le mot de passe de connexion est identique au mot de passe du RPC sécurisé. Dans ce cas, la commande keylogin n'est pas requise. Toutefois, si les mots de passe sont différents, les utilisateurs doivent se connecter, puis exécuter la commande keylogin.

La commande keylogin invite l'utilisateur à indiquer son mot de passe de RPC sécurisé. La commande utilise ensuite le mot de passe pour déchiffrer la clé secrète. La commande keylogin transmet ensuite la clé secrète déchiffrée au programme du serveur de clés. Le serveur de clés est un service RPC avec une instance locale sur chaque ordinateur. Le serveur de clés enregistre la clé secrète déchiffrée et attend que l'utilisateur lance une transaction de RPC sécurisé avec un serveur.

Si le mot de passe de connexion et le mot de passe RPC sont identiques, le processus de connexion transmet la clé secrète au serveur de clés. Si les mots de passe doivent être différents, l'utilisateur doit toujours exécuter la commande keylogin. Lorsque la commande keylogin est incluse dans le fichier de configuration d'environnement de l'utilisateur, tels que le fichier ~/.login, ~/.cshrc ou ~/.profile, la commande keylogin s'exécute automatiquement chaque fois que l'utilisateur se connecte.

Génération de la clé de conversation pour le RPC sécurisé

Lorsque l'utilisateur lance une transaction avec un serveur, les événements suivants se produisent :

1. Le serveur de clés génère une clé de conversation de manière aléatoire.

2. Le noyau utilise la clé de conversation, ainsi que d'autres matériaux, pour chiffrer l'horodatage du client.

3. Le serveur de clés recherche la clé publique du serveur dans la base de données des clés publiques. Pour plus d'informations, reportez-vous à la page de manuel publickey(4).

4. Le serveur de clés utilise la clé secrète du client et la clé publique du serveur pour générer une clé commune.

5. Le serveur de clés chiffre la clé de conversation avec la clé commune.

Connexion initiale au serveur dans le RPC sécurisé

La transmission, qui inclut l'horodatage chiffré et la clé de conversation chiffrée, est ensuite envoyée au serveur. La transmission comprend également des informations d'identification et un vérificateur. L'information d'identification contient trois composants :

• Le nom de réseau du client

• La clé de conversation chiffrée à l'aide de la clé commune

• Une "fenêtre" chiffrée à l'aide de la clé de conversation

La fenêtre correspond à la différence de temps qui doit être autorisée selon le client entre l'horloge du serveur et l'horodatage du client. Si la différence entre l'horloge du serveur et l'horodatage est supérieure à la fenêtre, le serveur rejette la demande du client. Dans des circonstances normales, ce rejet ne se produit pas, car le client se synchronise d'abord avec le serveur avant de commencer la session RPC.

Le vérificateur du client contient les éléments suivants :

• L'horodatage chiffré

• Un vérificateur chiffré de la fenêtre spécifiée, décrémenté de 1.

Le vérificateur de fenêtre est requis au cas où quelqu'un tenterait d'usurper l'identité d'un utilisateur. L'usurpateur peut écrire un programme qui, au lieu de remplir les champs chiffrés avec les informations d'identification et le vérificateur, insère simplement des bits aléatoires. Le serveur déchiffre la clé de conversation dans une clé aléatoire. Le serveur utilise ensuite la clé pour tenter de déchiffrer la fenêtre et l'horodatage. Il en résulte des nombres aléatoires. Cependant, après quelques milliers d'essais, la paire fenêtre/horodatage aléatoire est susceptible de passer le système d'authentification. Le vérificateur de fenêtre réduit les risques que des informations d'identification fausses puissent être authentifiées.

Déchiffrement de la clé de conversation dans le RPC sécurisé

Lorsque le serveur reçoit la transmission du client, les événements suivants se produisent :

1. Le serveur de clés qui est local pour le serveur recherche la clé publique du client dans la base de données de clés publiques.

2. Le serveur de clés utilise la clé publique du client et la clé secrète du serveur pour en déduire la clé commune. La clé commune est identique à celle calculée par le client. Seul le serveur et le client peuvent calculer la clé commune car le calcul nécessite de connaître l'une des clés secrètes.

3. Le noyau utilise la clé commune pour déchiffrer la clé de conversation.

4. Le noyau appelle le serveur de clés pour déchiffrer l'horodatage du client à l'aide de la clé de conversation déchiffrée.

Stockage d'informations sur le serveur dans le RPC sécurisé

Une fois l'horodatage du client déchiffré par le serveur, ce dernier enregistre quatre éléments d'informations dans une table des informations d'identification :

• Le nom d'ordinateur du client

• La clé de conversation

• La fenêtre

• L'horodatage du client

Le serveur enregistre les trois premiers éléments pour une utilisation ultérieure. Le serveur enregistre l'horodatage du client pour empêcher toute rediffusion. Le serveur accepte uniquement les horodatages qui sont postérieurs au dernier horodatage vu. Par conséquent, les transactions rediffusées sont garanties d'être rejetées.

Renvoi du vérificateur au client dans le RPC sécurisé

Le serveur renvoie un vérificateur au client incluant les éléments suivants :

• L'ID d'index, qui est enregistré par le serveur dans son cache des informations d'identification

• L'horodatage du client moins 1, qui est chiffré à l'aide de la clé de conversation

La soustraction de 1 à l'horodatage du client permet de garantir que l'horodatage est obsolète Un horodatage obsolète ne peut pas être réutilisé comme vérificateur de client.

Authentification du serveur dans le RPC sécurisé

Le client reçoit le vérificateur et authentifie le serveur. Le client sait que seul le serveur peut avoir envoyé le vérificateur car le serveur est le seul à connaître l'horodatage envoyé par le client.

Traitement des transactions dans le RPC sécurisé

Avec chaque transaction survenant après la première transaction, le client renvoie l'ID d'index au serveur dans sa prochaine transaction. Le client envoie également un autre horodatage chiffré. Le serveur renvoie l'horodatage du client moins 1, chiffré par la clé de conversation.