S´ ecurit´ e et agents mobiles :

La s´ecurit´e des agents mobiles constitue un probl`eme tr`es complexe et crucial qui doit ˆ

etre r´esolu si l’on souhaite que les applications bas´ees sur les agents mobiles d´epassent le stade exp´erimental et soient largement utilis´ees.

3.3.1 Probl` emes courants

Il existe une premi`ere menace lorsque les agents sont transf´er´es sur le r´eseau. Une machine pirate α peut ´ecouter ce qui se passe sur le r´eseau pour essayer d’obtenir des in-formations confidentielles [LO98].αpeut ´egalement intercepter les agents et les corrompre.

Ce type d’attaques peut ˆetre ´evit´e en utilisant les protocoles d’´echanges s´ecuris´es clas-siques (SSL...). Une seconde menace de taille implique le serveur distant que les agents visitent. En fait, quand on envoie des agents vers un serveur β distant, on s’attend `a ce que β traite les agents normalement et n’essaie pas de les corrompre. Mais l’agent est compl`etement aux mains du serveur β qu’il visite. β est enti`erement responsable de l’ex´ecution de l’agent, et peut ne pas l’ex´ecuter correctement. Le serveur peut donner par ailleurs de mauvaises informations `a l’agent. L’itin´eraire de l’agent peut ne pas ˆetre sˆur. Un serveur peut empˆecher un agent d’aller vers un autre serveur avec lequel il est en comp´etition, et au lieu de cela il peut l’envoyer vers un serveur avec lequel il poss`ede des accointances. De ce fait, il vaut mieux et il faut que les d´ecisions critiques prises par les agents ne soient prises que sur des hˆotes de confiance. Pour tisser un r´eseau d’hˆotes de confiance, on peut envisager la possibilit´e d’´echanger des codes crypt´es (encrypt´es avec la cl´e publique du serveur de destination), ce qui garanti la confidentialit´e des informations qui transitent. Ce m´ecanisme est assez lourd, et n’est pas encore arriv´e `a maturit´e sur la plupart des plates-formes d’agents mobiles. Par ailleurs, il est n´ecessaire que tous les protagonistes de ce dispositif se fassent confiance.

3.3.2 Types d’attaques possibles sur un serveur :

Les probl`emes de s´ecurit´e ne concernent pas seulement les agents eux-mˆemes mais les agents peuvent aussi pr´esenter un risque pour les serveurs. L’agent peut annoncer de fausses informations concernant son authentification. Pour parer `a cela, il est pos-sible d’employer la signature digitale pour encrypter les informations demand´ees lors de l’authentification. Par ailleurs, dans un agent mobile, il est possible de trouver des so-lutions pour prot´eger les informations invariantes comme l’identit´e de son propri´etaire par exemple. Par contre, il est difficile, voire impossible, de crypter l’´etat de l’agent car il change au cours de sa propre vie. Il n’y a pas de mani`ere pour v´erifier l’´etat courant d’un agent, car c’est le r´esultat de l’ex´ecution du programme qu’il transporte sur un hˆote du r´eseau, il est ainsi difficile d’authentifier compl`etement l’agent, car on ne peut jamais ˆ

etre vraiment sˆur que son ´etat n’a pas ´et´e corrompu. Il existe plusieurs mani`eres pour am´eliorer le process d’authentification d’un agent. Par exemple, si on sait d`es le d´epart qu’une portion de l’´etat de l’agent reste identique pendant tout son cycle de vie, il peut alors ˆetre sign´e par le propri´etaire par exemple. Par ailleurs, on peut faire des suppositions

3.3. S´ecurit´e et agents mobiles : pour v´erifier que l’´etat dynamique d’un agent n’est pas absurde. Ces solutions ne sont pas parfaites et ne permettent en aucun cas de garantir `a 100% l’int´egrit´e de l’agent.

L’agent est corrompu :

Cela veut non seulement dire que le code de l’agent a ´et´e corrompu, mais aussi que son ´etat a ´et´e probablement alt´er´e. Si l’agent revient vers le serveur qui l’a initialement instanci´e et ´emis, il est facile de v´erifier l’int´egrit´e du code, mais par contre, il est difficile, voire impossible, de v´erifier si l’´etat de l’agent est correct. La seule solution qui soit sˆure ici est d’avoir un groupe de serveurs qui se font confiance les uns les autres, de telle mani`ere qu’il est possible d’authentifier le code de l’agent ”visiteur” sans probl`eme aupr`es du serveur originel.

L’agent abuse de ses droits et nuit au serveur :

La signature de code ne garantit en rien le comportement des agents. Ces agents peuvent ainsi abuser de leurs droits d’acc`es si le serveur d’accueil est mal configur´e. Pour limiter les risques li´es `a l’abus de droits d’acc`es, la plate-forme d’agents mobiles doit poss´eder les propri´et´es suivantes :

♦ s´ecurit´e du langage : tous les dispositifs du langage de programmation des agents permettant des acc`es ill´egaux `a la m´emoire syst`eme ou `a des informations priv´ees doivent ˆetre strictement interdits `a la compilation du code.

♦ respect des autorisations : tous les agents doivent ˆetre strictement contrˆol´es grˆace `a des politiques de contrˆole d’acc`es d´efinies de mani`ere globale. Il ne devrait pas ˆetre possible de contourner ces politiques.

Il y a trois probl`emes majeurs concernant la s´ecurit´e des syst`emes d’agents mobiles :

♦ les hˆotes doivent ˆetre prot´eg´es des agents nuisibles.

♦ les agents ”migrateurs” doivent ˆetre prot´eg´es contre les ´eventuelles manipulations perp´etr´ees par les hˆotes les h´ebergeant.

♦ enfin, le comportement global du syst`eme bas´e sur les agents doit ˆetre contrˆol´e.

3.3.3 Points techniques

D’une mani`ere g´en´erale, pour assurer la s´ecurit´e dans une plate-forme d’agents mobiles, il est n´ecessaire d’´etudier les points suivants (qui seront d´ecrits en d´etail dans la suite du document) :

♦ l’authentification,

♦ l’int´egrit´e,

♦ la confidentialit´e,

♦ le contrˆole d’acc`es,

♦ la non-r´epudiation,

♦ l’audit.

Authentification :

`

a la r´eception : avant d’accepter un agent mobile (AM) entrant, un serveur a besoin de savoir qui est l’´emetteur de cet AM. Il est donc n´ecessaire ici d’authentifier l’AM. Ce processus inclue le contrˆole d’identit´e de :

♦ l’entit´e qui a d´evelopp´e l’AM,

♦ l’entit´e qui a instanci´ee et dispatch´ee l’AM.

`

a l’´emission : avant d’envoyer un AM, le serveur ´emetteur a besoin de v´erifier que le serveur de destination est vraiment le serveur qu’il pr´etend ˆetre. Le concept d’authen-tification est fondamental en ce qui concerne la s´ecurit´e dans une plate-forme d’agents mobiles. On rel`eve quatre types d’authentification dans les AM :

♦ authentification de l’utilisateur : l’utilisateur a besoin de s’authentifier lui-mˆeme sur un serveur donn´e. L’encryptage a cl´e publique ou un mot de passe peut ˆetre utilis´e pour cela.

♦ authentification de l’hˆote : avant qu’un serveur ne commence `a communiquer avec un autre serveur ou client, il a besoin de connaˆıtre avec qui il communique. Ce point est important, car on ne peut pas assurer l’int´egrit´e et la confidentialit´e sans connaˆıtre l’entit´e de laquelle on re¸coit les agents ou l’entit´e `a laquelle on envoie les agents.

♦ authentification du code : avant d’ex´ecuter le code d’un agent entrant, le serveur a besoin de connaˆıtre qui est responsable de l’impl´ementation de l’agent. Les signa-tures digitales sont g´en´eralement utilis´ees `a cet effet.

♦ authentification de l’agent : avant d’ex´ecuter le code d’un agent entrant, le serveur a ´egalement besoin de savoir qui est le propri´etaire de cet agent. C’est un probl`eme toujours d’actualit´e.

L’int´egrit´e : pour se fier `a un agent, il faut s’assurer que personne n’a corrompu son

´

etat et son code. Contrˆoler l’int´egrit´e d’un agent revient en d´efinitive `a v´erifier qu’il n’y a pas eu d’alt´erations ill´egitimes `a l’´etat et au code de l’agent.

La confidentialit´e : un agent peut transporter des informations confidentielles qui ne devraient ˆetre lisibles que par des agents ou des serveurs particuliers. Cette information doit rester ind´echiffrable pour les autres serveurs et agents.

Le contrˆole d’acc`es : un AM entrant devrait acc´eder uniquement aux informations auxquelles il a le droit d’acc´eder. Le contrˆole d’acc`es est la mani`ere de sp´ecifier et de donner les possibilit´es `a l’agent d’acc´eder `a l’information dont il a besoin, ou d’utiliser les services fournis par un serveur.

La non-r´epudiation : les m´ecanismes de non-r´epudiation empˆeche `a un agent ou `a un serveur de nier qu’un ´echange particulier a eu lieu.

3.3. S´ecurit´e et agents mobiles : L’audit : l’audit se base sur l’archivage de toutes les donn´ees concernant les activit´es des agents. Ce service est fondamental pour analyser ce qui s’est pass´e en cas d’attaque par exemple.

3.3.4 De la s´ ecurit´ e des codes mobiles et de l’ex´ ecution de fonc-tions encrypt´ ees :

Les codes mobiles posent de nouvelles contraintes de s´ecurit´e qui se d´ecomposent en deux cat´egories :

♦ Comment prot´eger l’hˆote qui ex´ecute des codes mobiles potentiellement dangereux ?

♦ Comment prot´eger les codes mobiles d’un hˆote potentiellement dangereux ?

Un sondage de l’´etat de l’art des technologies des agents mobiles en ce qui concerne la s´ecurit´e est d´ecrit par Karjoth et Posegga dans [PK00], du point de vue d’un op´erateur pu-blic de r´eseaux. Ils s’int´eressent aux deux cat´egories de contraintes de s´ecurit´e mentionn´ees ci-dessus et en d´eduisent les m´ecanismes de protection potentiellement utilisables.

Prot´eger l’hˆote :

Cette question a re¸cue une attention consid´erable `a cause notamment des virus (qui sont une forme de codes mobiles). Les solutions couramment utilis´ees pour ce probl`eme sont d’ex´ecuter les codes mobiles dans une zone m´emoire prot´eg´ee (”sandbox” ou ”bac `a sable”) `a l’aide de politiques de contrˆole d’acc`es et en appliquant la signature de code.

Karjoth et al. [KLO97] d´ecrivent un mod`ele global de s´ecurit´e pour la plate-forme Aglet qui supporte la d´efinition de politiques de s´ecurit´e relativement flexibles.

Prot´eger les codes mobiles eux-mˆemes :

Il a longtemps ´et´e admis que les codes mobiles ne peuvent pas ˆetre prot´eg´es des falsifications d’un hˆote corrompu. Cependant, Sander et Tshudin [ST98] montrent qu’il est possible, au moins dans le principe, de prot´eger les codes mobiles en appliquant des principes de base de la cryptographie. Karjoth et al. [KAG98] montrent comment prot´eger l’int´egrit´e des r´esultats de l’ex´ecution d’un agent visitant plusieurs hˆotes. Yao [Yao86] et d’autres ont montr´e qu’il ´etait possible de s´ecuriser le traitement informatique de fonctions arbitraires dans un environnement distribu´e. Cependant, ces protocoles ont besoin pour fonctionner de beaucoup d’interactions entre l’utilisateur et l’hˆote. Or, dans un syst`eme se disant bas´e sur les codes mobiles autonomes, on ne peut tol´erer qu’un seul message `a l’aller et un seul message au retour (ce message ´etant le code mobile lui-mˆeme). Cachin et al. dans [CCKM00] montre qu’il est possible de prot´eger le code mobile d’un hˆote espion.

Cependant, une telle application est limit´ee au cas o`u le code mobile ne change pas l’´etat de l’hˆote de quelque mani`ere que ce soit. Cette contrainte forte s’applique ´egalement aux travaux de Karjoth et Yao. Dans le cas o`u l’hˆote accueillant l’agent mobile doit prendre en compte des r´esultats des traitements de l’agent mobile, alors il est n´ecessaire d’avoir confiance en un ´equipement tiers `a l’´epreuve des falsifications. La s´ecurit´e des codes mobiles peut-ˆetre obtenue en partie grˆace `a l’utilisation de tels ´equipements s´ecuris´es, comme il est propos´e dans [ACCK01].

3.3.5 Conclusion :

En conclusion, il est possible, au moins th´eoriquement, de traiter des donn´ees en-crypt´ees, d’ex´ecuter des fonctions encrypt´ees, et de prot´eger le code mobile d’un hˆote espion. Cela a ´et´e d´emontr´e en pratique, mais seulement sur des programmes minus-cules. Mais d’une mani`ere g´en´erale, les syst`emes bas´es sur les agents mobiles posent beaucoup de probl`emes en ce qui concerne la s´ecurit´e. Il ´etait admis pendant longtemps qu’un programme interpr´et´e ´etait d´ej`a un programme sˆur. Cependant, cette assertion est

´

evidemment fausse, et la communaut´e gravitant autour des codes mobiles prend conscience que la s´ecurit´e des AM est un des plus gros obstacle concernant les AM, ce qui en empˆeche une utilisation plus r´epandue.

Bien qu’en principe, il soit possible de s´ecuriser un hˆote contre les agents mobiles, le prix `a payer est tr`es ´elev´e : protection bas´ee sur des ´equipements mat´eriels, flexibilit´e r´eduite, et coˆut ´elev´e. Il est fondamentalement impossible de prot´eger un agent contre un hˆote corrompu s’il n’y a pas des ´equipements hardware auxquels on peut faire confiance sur chaque nœud. L’´etat de l’art en mati`ere de s´ecurit´e des agents mobiles ne fournit au-cune solution proposant une approche acceptable pour faire face aux probl`emes de s´ecurit´e dans les syst`emes `a agents mobiles. Les technologies disponibles (m´emoire prot´eg´ee, cryp-tographie...) ne peuvent couvrir que certains aspects seulement de la s´ecurit´e dans les agents mobiles, et ´echouent parfois `a r´esoudre ces aspects de mani`ere satisfaisante. Un concept global pour faire face `a ces probl`emes n’a pas encore ´et´e trouv´e. Les agents mo-biles constituent un champ de recherche actif et la s´ecurit´e des codes mobiles offre un potentiel immense pour des recherches futures.

Il est donc dangereux pour l’instant d’ouvrir pleinement les r´eseaux aux agents. Le seul sc´enario tol´erable est d’ex´ecuter des agents propri´etaires dans des r´eseaux compl`etement contrˆol´es et isol´es. Curieusement, mˆeme cette situation semble risqu´ee, vue qu’il n’y a en pratique pas de mani`ere de contrˆoler rigoureusement un r´eseau d´epassant une cer-taine taille. Il n’est pas suffisant de cr´eer des applications attractives bas´ees sur les agents mobiles. Ce qui est ´egalement n´ecessaire est un concept applicable pour faire face aux probl`emes de s´ecurit´e qui sont inh´erents `a ce type d’environnement. Un tel concept doit remplir des contraintes tr`es fortes, sinon il n’y aura pas d’investissement dans les en-vironnements d’agents mobiles, et cette technologie sera condamn´ee `a rester au stade exp´erimental. Cependant, aucun syst`eme informatique ne peut ˆetre sˆur `a 100% `a ce jour, il est donc n´ecessaire de faire des compromis. Dans les entreprises, cependant, les compro-mis sont gouvern´es par des consid´erations ´economiques : le gain potentiel doit d´epasser les coˆuts, et le risque doit ˆetre ´evaluable. C’est pour cette raison que l’utilisation futur d’applications bas´ees sur les agents mobiles dans un but commercial n’est pas pr´evisible.