6 Secure RPC

6.1 implémentation.

Implémenté en 1985 sur le réseau de recherche Xerox. Constitue un aspect d'une réalisation d'un système d'appel de procédure à distance (= RPC) [6].

6.2 objectifs.

"There are disappointingly few real implémentations of secure protocols" constatait Andrew Birrell en 1985. Il s'agissait alors de bâtir l'une des premières réalisations sérieuses. Et de le faire de la façon la plus transparente possible pour l'utilisateur final.

6.3 chiffrement.

A clef secrète (DES)

6.4 hypothèses.

Prévu pour des stations de travail, Secure RPC suppose la puissance de calcul nécessaire au protocole. En particulier, des circuits-DES et des horloges (non-synchronisées). Les centrales d'identification, physiquement protégées, gèrent la base de données répartie en utilisant Grapevine [5].

6.5 déroulement.

L'échange de messages est décrit Table 5. Les messages (1)-(2) permettent d'acquérir un ticket d'identification, limité dans le temps par un Time-to-live. Le nonce np sert à vérifier que le message (2) est bien récent. Que (2) émane bien de la centrale S est assuré par le fait qu'il soit chiffré avec la clef que S et P sont seuls à partager.

Table: RPC sécurisé.

1	$P\hookrightarrow S$	$P, Q, np$
	$S$	ticket = $\left\{ P, Ttl_{k}, k\right\} _{Wq}$
2	$S\hookrightarrow P$	$\left\{ ticket, np, Q, k\right\} _{Wp}$
3	$P\hookrightarrow Q$	convid ; $\left\{ seq, question\right\} _{k}$
4	$Q\hookrightarrow P$	rfa_id ; convid ; $\left\{ seq\right\} _{k}$ ; nq
5	$P\hookrightarrow Q$	rfa_id ; $\left\{ seq, nq\right\} _{k}$ ; ticket
6	$Q\hookrightarrow P$	convid ; $\left\{ seq, reponse\right\} _{k}$

Par la suite, P et Q échangent les messages (3) et (6) à chaque appel. Quant aux messages (4) et (5), ils ne sont échangés qu'à la première question-réponse, ou après un silence de P supérieur à la durée de purge de la table de hachage où Q stocke les couples (convid, k) les plus récents : le mécanisme qui assure au niveau transport la délivrance une seule fois et dans le bon ordre des éléments d'une connexion prend ici l'aspect d'une rfa (= request for authentificator).

6.6 critique.

On obtient une transparence effective. Le mécanisme de souches qui gère une librairie d'exécution, aurait de toutes façons été présent. Résidant dans la couche transport, c'est à dire au niveau le plus bas pour un protocole de bout en bout, Secure RPC est implémenté au meilleur endroit possible.

Erreurs cryptographiques : il est erroné [49] d'affirmer la non-modification des messages par la seule utilisation du DES en mode de chaînage de bloc (DES-CBC), le dernier bloc du texte clair étant le XOR de tous les autres (pour une discussion détaillée, se reporter à notre annexe G7.b). En fait, le protocole est paramétré pour utiliser n'importe quel système de chiffrement à clef privée, et l'implémentation n'utilisait qu'un simple XOR avec la clef, faute de circuits-DES spécialisés.

La gestion des uid est alourdie : la chaîne no_de_machine no_conversation no_séquence occupe 14 bytes. Mais il est vrai que la gène causée par les uid vient d'abord de leur existence. Une fois celle-ci prévue par le protocole de RPC, leur surdimensionnement n'est pas bien grave.

6.7 conclusion.

L'intégration des protocoles de sécurité au niveau le plus bas possible (couche 4) est très certainement le moyen de les rendre les plus transparents possible à l'utilisateur final. D'autre part ce protocole a été un des premiers à être effectivement en service.