7 AFS (Andrew)

Andrew File System (AFS) est un environnement distribué en service depuis 1986 sur le campus de Carnegie Mellon. Commencé avec 400 stations de travail (= Virtue), et 15 serveurs de fichiers de un gigabit (= Vice), Andrew est prévu pour interconnecter un parc de 5.000 à 10.000 stations et le nombre correspondant de serveurs [41]

7.2 objectifs.

La taille du système est la principale nouveauté de cette réalisation. Il faut d'une part rester transparent à l'utilisateur final qui ne voit qu'un file-system à la Unix. D'autre part faciliter la tâche des administrateurs système. Et finalement prévoir des tentatives d'intrusions en proportion de la taille et du prestige de la réalisation.

7.3 chiffrement.

7.4 hypothèses.

S'agissant de connecter un grand nombre de stations de travail, il n'y a pas lieu de prévoir de restrictions sur la puissance de calcul des clients (= Virtue). En particulier, on suppose des circuits-DES et des horloges (non-synchronisées). Les centrales d'identification et serveurs de fichiers (= Vice) sont physiquement protégés et n'exécutent aucun code utilisateur. Ils communiquent par un réseau fiable spécial.

7.5 déroulement.

AndrewFS utilise un mécanisme de tickets (cf. Table 4) entre Vice et Vertu. On notera que l'entité fiable de ce dialogue est Vice... ("deine Untreue glaub' ich" disait la chanson !). Il y a donc un "troisième homme" dans ce dialogue, qui est Venus [21], un processus Unix s'exécutant sur toutes les stations Vertu, et qui est chargé de présenter à l'utilisateur le Andrew File System sous l'apparence d'une arborescence Unix.

Table 6: Andrew : un dialogue BIND.

1	$P\hookrightarrow S$	$P, \left\{ np\right\} _{Wp'}$
		xx = $\left\{ \left\{ np\right\} _{Wp'}\right\} _{Wp^{-1}}$
2	$S\hookrightarrow P$	$\left\{ xx+1, ns\right\} _{Wp}$
		yy = $\left\{ \left\{ ns\right\} _{Wp}\right\} _{Wp'^{-1}}$
3	$P\hookrightarrow S$	$\left\{ yy+1\right\} _{Wp'}$
4	$S\hookrightarrow P$	$\left\{ k, seq\right\} _{Wp}$

La Table 6 décrit un bind, c'est à dire l'échange de messages prévu par AndrewFS entre deux entités P et S, partageant une même clef secrète

. S peut désigner la centrale d'identification.

est alors le mot de passe de P, et l'objectif est la transmission d'un ticket. Ou bien S désigne un serveur Vice et

est alors une clef de session, préalablement transmise dans un ticket, l'objectif étant la transmission d'une clef temporaire (k) et un point de départ (seq) pour la numérotation en séquence des messages chiffrés avec cette clef.

Il est désagréable de le dire, mais ce protocole est faux. La Table 7 utilise le formalisme B.A.N. pour indiquer où se trouve la brèche. Celle-ci ressemble à cette blague téléphonique qui était possible avec l'ancienne implémentation du "service automatique du réveil" des Télécommunications. On était invité à composer son propre numéro de téléphone, puis l'heure de réveil souhaitée. Pour éviter les plaisantins élémentaires, on était alors invité à rester en communication le temps que le central vérifie que la ligne était bien occupée. La contre-(contre-mesure) consistait alors à appeler le destinataire de la plaisanterie en même temps que le service du réveil, nécessitant deux lignes téléphoniques.

Table: La brèche dans le BIND.

L'ajout de 1 à xx et yy traduit un mélange entre les questions de logique et celle d'implémentation. L'utilisation du mode CBC et de brouilleurs, ou bien du mode CBC et du message $\left\{ ns, xx\right\}$ ou tout simplement la présence du nom du chiffreur dans le message seraient d'autres implémentations tout aussi bonnes.

Supposons que l'on obtienne : $\mathrm{admet}\left( P , xx=np \right)$ . Comme $\mathrm{admet}\left( P , \mathrm{recent}\left( np \right) \right)$ , on a alors successivement : $\mathrm{admet}\left( P , Wp=Wp' \right)$ puis $\mathrm{admet}\left( P , \mathrm{dixit}\left( S , \mathrm{sec}\left( Wp' , P , S \right) \right) \right)$ et enfin : $\mathrm{admet}\left( P , \mathrm{admet}\left( S , \mathrm{sec}\left( Wp , P , S \right) \right) \right)$ . Et symétriquement, établissant la communication.

Mais on ne va pas au delà de $\mathrm{admet}\left( P , \mathrm{dixit}\left( S , \left\{ k, seq\right\} \right) \right)$ , car il n'y a rien dans le message (4) qui en prouve la fraîcheur. Un intrus pourrait alors rejouer un ancien message (4) pour inciter P à réutiliser une ancienne clef, peut-être compromise.

En fait ns est déjà une base de numérotage en séquence des messages, puisque P et S admettent $\mathrm{recent}\left( ns \right)$ . Il aurait fallu :

4'	$S\hookrightarrow P$	$\left\{ k, ns+2\right\} _{Wp}$
5'	$P\hookrightarrow S$	$\left\{ hello, ns+3\right\} _{k}$

7.6 critique.

Un mécanisme de RPC sécurisé, semblable dans son principe à celui de Birrell, assure une transparence effective vis à vis de l'utilisateur final, qui ne perçoit qu'un file-system Unix. De plus l'utilisateur peut choisir le degré de protection qu'il souhaite, depuis "ni identifié, ni chiffré" jusqu'à "identifié et totalité des paquets chiffrés".

Autre point positif, la gestion des capacités. Elle se fait par affiliation à des groupes, avec héritage des capacités par les sous-groupes. Un exemple frappant est celui des administrateurs-système, l'équivalent du superuser Unix. C'est l'appartenance au groupe Système:Administrateurs qui confère le privilège. Mais c'est l'individu qui s'identifie. Permettant ainsi un meilleur audit, et aussi une rectification des droits plus facile : supprimer un nom d'un groupe versus aviser tous les sysadmins du nouveau password-système.

La réalisation des hypothèses matérielles n'est pas complète. Il semblerait que la nature par essence impalpable de la sécurité en fasse une victime de choix toute les fois que se posent de douloureux problèmes de répartition de crédits. Ainsi, en 1989 [41], le lien privilégié entre les serveurs Vice ... n'était autre que la transmission en clair sur le réseau général. Quant au chiffrement, en l'absence des circuits-DES prévus, il a été (paramétriquement) remplacé par un simple XOR.

Il est apparu à l'usage d'autres problèmes liés au matériel. Ainsi faudrait-il prévoir des modifications matérielles sur les stations en libre-service, afin d'empêcher de les booter "standalone". Ceci pour protéger les fichiers-source du processus Venus contre les modifications malicieuses.

Il faut signaler que tous les serveurs Vice partagent la même clef secrète. Il n'y a donc besoin que d'un seul ticket par login, mais il ne semble pas qu'un échange de clefs entre deux entités quelconques du niveau Vertu soit possible.

De nombreuses modifications ont été apportées au code Unix, en essayant d'en garder l'interface-utilisateur. Login est évidement modifié. Mais aussi tous les processus qui sont liés à root, soit que leur utilisation soit restreinte, soit qu'ils s'exécutent en mode setuid. De même su, rsh, etc. Il reste qu'un programme comme rem, permettant de récupérer la puissance de calcul des stations inutilisées, est aussi une occasion d'envoyer les tickets et leur clefs en clair sur le réseau, ce qui est certainement un problème.

7.7 conclusion.

L'expérience accumulée autour d'AndrewFS montre qu'il n'est pas facile d'appliquer des principes, mêmes simples et clairs, dans le monde Unix. Le poids de l'existant et la résistance des utilisateurs au changement de leurs habitudes imposent de "faire comme s'il n'y avait pas de protocole de sécurité", et d'émuler au mieux des pratiques par ailleurs discutables. L'absence d'enjeu perceptible va également dans ce sens.

Au total, on a un environnement distribué qui fonctionne, et qui fonctionne sans qu'on s'en rende trop compte, ce qui n'est pas si fréquent à aussi grande échelle. Cet environnement est très largement plus "sécurisé" que l'environnement Unix ordinaire. Une révision majeure est en cours, qui doit réaliser une plus grande paramétrisation de AFS, afin de séparer les principes d'avec les compromis effort-efficacité décidés soit au niveau du site, soit au niveau de l'utilisateur individuel final.