Sécurité Mobile et MDM

1. Description des MDM

Un MDM est un logiciel de gestion de flotte d'appareils mobiles. Il se compose d'une partie serveur et comporte la plupart du temps une partie client sous forme d'une application à télécharger sur mobiles. La partie serveur est soit hébergée dans le système d'information de l'utilisateur, soit chez un hébergeur dédié qui n'est pas forcément le fournisseur de MDM lui-même.

L'expérience pour un utilisateur final est simple : il télécharge l'application MDM sur son mobile, entre son adresse email puis est redirigé vers le serveur de son entreprise. Il va ensuite s'authentifier à l'aide de son mot de passe d'annuaire, ou d'un mot de passe à usage unique qui lui a été communiqué avec les instructions initiales. La suite est automatique : le téléphone est configuré pour les accès entreprise, et tout autre paramètre jugé important pour l'usage professionnel du terminal est configuré. Le point à noter est que l'utilisateur est authentifié par le MDM de son entreprise et non par le site web générique du vendeur de la solution qui ne voit donc jamais passer aucun mot de passe entreprise.

Un administrateur de flotte va définir des politiques d'utilisation des téléphones généralement similaires à celles définissant l'accès des ordinateurs personnels au SI. Le MDM va fournir notamment à l'administrateur un tableau de bord de gestion permettant de savoir en permanence quels sont les terminaux habilités à entrer sur le réseau, ainsi que des fonctionnalités de gestion à distance pour l'effacement des terminaux ou leur géolocalisation.

Il existe aujourd'hui une centaine d'acteurs fournissant des solutions de MDM. Une liste complète et régulièrement mise à jour est disponible à l'adresse http://www.enterpriseios.com/.

2. Sécurité des MDM

Les serveurs MDM gèrent des terminaux connectés depuis des réseaux publics, ils sont généralement placés sur une adresse IP publique pour être joignables depuis tout appareil au moins une fois. Ceci les place en première ligne vis-à-vis des attaques externes : s'il est possible de prendre le contrôle du MDM, il est possible de récupérer les identifiants nécessaires pour rentrer sur le réseau d'entreprise, par exemple les paramètres VPN. Protéger la sécurité de ces éléments devient critique pour l'entreprise. Comme il n'existe pas de solutions miracles pour protéger une machine en DMZ, il faut le faire avec beaucoup d'attention afin de ne pas compromettre la sécurité des accès clients depuis l'extérieur.

3 Sécurité des mobiles

La sécurité des terminaux mobiles se concentre sur deux points :

- protéger les données du terminal pour éviter perte, vol, ou compromission des données ;

- protéger les accès aux réseaux depuis ces terminaux pour éviter un rebond vers le SI.

3.1 Protéger les données du terminal (data-at-rest)

On veut s'assurer que seul le possesseur légitime d'un mobile peut accéder aux données qu'il contient, et ce même en cas de perte ou de vol. Plusieurs solutions existent, offrant des niveaux de protection plus ou moins contournables.

3.1.1 Complexité du mot de passe

Le premier élément de sécurité proposé par les MDM est d'imposer des politiques de sécurité comme l'obligation d'utiliser des mots de passe complexes, l'instar de ce qui est fait pour les postes de travail. Les écueils de cette politique sont pourtant connus : plus les mots de passe sont compliqués à retenir et plus on les trouve écrits sur des post-it collés autour des machines qu'ils sont censés protéger.

Un smartphone n'est pas un PC, entrer un mot de passe complexe va demander plus de temps, et la plupart d'entre eux aident l'utilisateur en lui montrant le dernier caractère saisi, ce qui facilite grandement le « shoulder-surfing » – la lecture de mot de passe par-dessus l'épaule. Un smartphone est également débloqué beaucoup plus souvent qu'un PC fixe d'entreprise, et souvent en public, ce qui augmente la probabilité de se faire voler le mot de passe par un observateur.

Un compromis doit être trouvé entre la complexité des mots de passe imposée par l'état de l'art et les risques associés aux utilisateurs. On ne peut pas imposer à des humains de retenir des mots de passe infiniment longs, compliqués, et qui changent très régulièrement. Augmenter la taille du PIN de déblocage de 4 à 8 chiffres semble acceptable en général.

3.1.2 Effacement des données à distance

Tous les MDM proposent cette option, malheureusement limitée contre un attaquant déterminé. Ce dernier prendra soin de retirer la carte SIM et de se placer hors de tout réseau sans fil pour empêcher le mobile de recevoir l'ordre d'effacement. Il n'est pas forcément non plus nécessaire d'allumer le mobile pour copier les données qu'il contient, extraire les puces de stockages flash peut être suffisant.

Configurer un effacement à distance peut causer par erreur plus de pertes de données légitimes que protéger des données. Les MDM n'étant pas exempts de bugs, les ordres intempestifs d'effacement peuvent arriver. L'effacement à distance est un sujet à manipuler avec précaution.

3.1.3 Chiffrement de la mémoire de masse

Cette option est actuellement disponible sur iOS, BlackBerry, et les versions récentes d'Android. Un tel type de chiffrement reste vulnérable au fait que la clé de chiffrement du support est stockée sur le support lui-même et généralement protégée par un mot de passe utilisateur. Les constructeurs redoublent d'imagination pour rendre l'accès à celle-ci le plus difficile possible. Ce faisant, on offre un niveau de protection considéré comme suffisant si le téléphone a été volé pour sa valeur et non les données qu'il contient. Attention cependant : les composants mémoire utilisés dans les mobiles ne sont pas spécifiquement conçus pour protéger les données, comme c'est le cas par exemple pour les cartes à puce. On considère généralement qu'une machine est compromise du moment que l'attaquant peut y accéder physiquement, les appareils mobiles n'échappent pas à cette règle.

On peut imaginer séparer la clé de chiffrement et la placer dans un élément sécurisé du mobile : il existe plusieurs options possibles, elles sont décrites plus bas.

À noter : on peut acheter sur le marché des utilitaires logiciels permettant de copier l'intégralité d'un mobile iOS ou BlackBerry par câble. Certains outils (Elcomsoft) vont jusqu'à automatiser le déchiffrement des données. Une copie intégrale prend en général moins de 10 minutes et ne nécessite pas de mettre le téléphone en réseau.

3.1.4 Containers professionnels chiffrés

Certains fournisseurs de MDM comme Good Technology vont jusqu'à proposer l'installation d'un container chiffré sur les appareils mobiles. Pour l'utilisateur, la transition est évidente : pour accéder à ses documents ou son réseau professionnel, il doit débloquer une application par mot de passe et se trouve face à une famille d'applications spécifiques pour son activité professionnelle.

L'avantage de tels containers est de séparer nettement vie privée et vie professionnelle, ce qui permet théoriquement d'effacer l'un sans toucher à l'autre. En pratique, les données sont toujours stockées sur le terminal de l'utilisateur qui garde les pleins pouvoirs sur le mobile, et la frontière n'est pas si étanche entre les deux mondes. En effet, une fois un mobile compromis (root sur Android, jailbreak sur iOS), rien ne peut empêcher l'utilisateur de transférer ses données d'un monde à l'autre afin de, par exemple, s'envoyer des documents confidentiels vers une adresse mail privée.

Si la plupart des MDM proposent aujourd'hui des fonctions de détection de root/jailbreak, celles-ci sont par définition facilement contournables. On parle d'une fonction qui demande à un menteur s'il est en train de mentir.

L'usage de containers professionnels n'est malgré tout pas à exclure. Le niveau de protection offert est suffisant pour se défendre de nombre d'attaques et la séparation vie privée/professionnelle peut éviter aux utilisateurs de mélanger involontairement les deux.

3.2 Protéger les accès aux réseaux

Distribuer des droits d'accès pour accéder à un réseau d'entreprise n'est pas chose nouvelle ; les mobiles héritent d'une famille d'outils déjà déployés. Le nouveau problème à résoudre est d'intégrer ces nouveaux terminaux dans les politiques de sécurité existantes.

Les cas d'usage les plus courants pour de l'authentification depuis des mobiles sont :

- authentification sur VPN ;

- authentification sur réseaux Wi-Fi avec WPA entreprise ;

- authentification mutuelle et chiffrement des communications via SSL pour HTTPS.

Les méthodes d'authentification des utilisateurs restent les mêmes : mot de passe, mot de passe à usage unique (OTP), challenge/response, authentification forte via certificats X.509. La suite de cet article se concentre sur la distribution et l'usage de certificats X.509 sur mobiles.

3.2.1 Rappels de PKI

Une Infrastructure à Clés Publiques ou PKI (Public-Key Infrastructure) permet de créer et gérer des autorités en charge de distribuer des identités numériques à des machines, des applications, et des utilisateurs. Ces identités sont composées de deux parties :

- une clé privée conservée par l'utilisateur et gardée secrète ;

- une partie publique, publiée sous forme d'un certificat au format X.509.

La protection d'identités basées sur des certificats numériques représente aujourd'hui la méthode la plus forte d'authentification abordable pour des entreprises, pour peu que les règles de bon usage soient respectées dans la distribution et le stockage des clés. De plus en plus d'entreprises mettent en place de telles infrastructures pour sécuriser leurs réseaux. Les certificats numériques sont supportés par la plupart des VPN, sont utilisables pour l'authentification Wi-Fi entreprise via EAP-TLS, et l'authentification mutuelle sur les serveurs HTTPS.

3.2.2 Utilisation des certificats numériques

Utiliser un moyen d'authentification forte ne fait pas qu'améliorer la sécurité. Bien implémentés, ces moyens simplifient aussi la vie des utilisateurs.

La première étape est l'enrôlement : l'utilisateur prouve son identité à un serveur ou un administrateur et reçoit en échange son identité numérique. Celle-ci est stockée dans un porte-clés (keystore) sur une carte à puce (quand c'est possible), ou dans le cas des mobiles, dans un container chiffré local au mobile.

Les porte-clés sont protégés par mot de passe. Un seul mot de passe (ou PIN, dans le cas d'une carte à puce) est nécessaire pour débloquer toutes les identités contenues dans le porte-clés. Un système de cache peut aussi permettre de débloquer une seule fois le porte-clés pour une durée allant de quelques minutes à quelques heures et ainsi éviter une saisie répétée de PIN ou mot de passe. C'est le cas sur les terminaux BlackBerry.

Une fois le porte-clés débloqué, un utilisateur pourra utiliser son certificat pour s'authentifier sur tous les systèmes qui le supportent : réseau Windows, VPN, Wi-Fi. Les systèmes d'exploitation mobiles sont aujourd'hui tous conçus pour supporter l'usage de certificats sans nécessiter d'intervention spécifique de l'utilisateur. Concrètement : une fois l'appareil déverrouillé, il se connecte automatiquement aux réseaux d'entreprise dont il a besoin, sans interaction spécifique.

L'usage des certificats numériques ne se limite pas à l'authentification forte. La norme S/MIME définie par l'IETF permet de signer/chiffrer ses e-mails, garantissant :

- l'intégrité du message délivré ;

- la confidentialité des données : seuls les destinataires attitrés sont capables de lire le contenu du message ;

- la signature de l'expéditeur.

Les terminaux iOS d'Apple et BlackBerry de RIM supportent nativement la signature et chiffrement d'emails à la norme S/MIME. Pour un utilisateur, la procédure est transparente une fois le terminal correctement configuré.

3.2.3 Stockage des clés privées sur mobiles

Pour que les authentifications restent fortes, il est nécessaire de protéger les clés privées liées aux identités numériques : ces clés ne doivent pas être facilement copiées ou transférées. Dans le monde informatique standard, il est courant d'utiliser une carte à puce comme porte-clés.

Il existe aussi des solutions matérielles dans le monde mobile :

- Les cartes à puce au format μSD : elles nécessitent un slot adapté sur le mobile, ce qui n'existe pas sur iOS, ni un certain nombre d'appareils Android. Les terminaux BlackBerry supportent nativement ce genre de porte-clés depuis quelques années.

- La carte SIM pourrait servir de porte-clés : elle contient déjà les clés utilisées pour s'authentifier sur un réseau GSM/3G. Très peu d'opérateurs (aucun en France) proposent à ce jour l'accès par des applications tierces à une carte SIM.

- Les processeurs ARM et Intel comportent une zone de mémoire sécurisée similaire à une carte à puce. Il est actuellement impossible d'écrire ses propres clés dans cette zone, elle est principalement utilisée pour protéger les systèmes d'exploitation mobiles, notamment pour du safe boot.

- La partie NFC (Near-Field Contactless) des téléphones récents peut contenir une carte à puce. Là encore, l'accès à ce porte-clés est pour l'instant limité au constructeur. Dans le cas de Google, ce container est principalement prévu pour gérer Google Wallet.

La seule solution viable et facilement déployable à ce jour est d'utiliser un container purement logique : un fichier stocké sur le mobile et protégé par mot de passe. On se retrouve dans le même cas de figure que la protection générale des données mobiles décrites plus haut, à quelques nuances près :

- iOS, BlackBerry et Android supportent tous nativement un système de container chiffré pour des clés privées PKI, sans nécessiter l'installation d'une application spécifique.

- Le volume à protéger est seulement de quelques kilo-octets par clé, ce qui est plus facile à accomplir que la protection de l'ensemble des données du mobile.

La protection principale des clés privées PKI réside dans le fait qu'un certificat se révoque côté serveur sans avoir à toucher la clé privée. En pratique : un utilisateur qui perd son mobile s'en rend compte généralement assez vite. Il suffit d'un appel au Help Desk pour faire révoquer tous les droits d'accès liés aux certificats dont la clé a été compromise. Pour peu que les serveurs d'authentification honorent la vérification des certificats révoqués, via CRL ou OCSP, la fenêtre de tir pour un attaquant reste très courte.

4. Distribution des certificats

Tous les mobiles supportant l'usage de certificats X.509 sont capables d'importer des identités présentées sous forme d'un fichier au format PKCS#12. Un tel fichier contient en général une clé privée, le certificat qui y est associé, et la chaîne d'autorités qui sont impliquées dans la délivrance du certificat. PKCS#12 est malheureusement un format complexe qui n'oblige pas tous ces éléments à être présents, mais si le fichier vient d'une autorité de confiance correctement configurée, le fichier a toutes les chances d'être compris par un mobile.

Les appareils iOS offrent une possibilité supplémentaire pour obtenir des certificats d'une autorité via le support du protocole SCEP, Simple Certificate Enrollment Protocol. Ce protocole est basé sur un échange au cours duquel le mobile génère une paire de clés et soumet la partie publique pour signature, recevant son certificat en fin de discussion. L'avantage de ce type de distribution est que l'autorité de confiance ne voit jamais passer la clé privée de ses clients.

4.1 Problèmes liés à SCEP

SCEP n'est pas un standard RFC mais un draft IETF. Initialement publié en 2001 par Cisco pour enrôler des routeurs sur un réseau local de confiance, l'extension au monde des mobiles se révèle un peu hasardeuse et se trouve à la source de nombreux problèmes de sécurité. Les auteurs du protocole eux-mêmes recommandent de l'abandonner en faveur d'autres protocoles plus récents (RFC 4210 et 5272) mais beaucoup plus lourds à implémenter. Cependant, le fait qu'il soit disponible sur les quelques millions d'appareils iOS en circulation laisse penser qu'il sera encore utilisé pendant de nombreuses années.

Une conversation SCEP se déroule autour de ces étapes :

- le serveur s'authentifie par certificat ;

- le client s'authentifie par un mot de passe à usage unique appelé Challenge ;

- le serveur spécifie le type de clé qu'il attend ;

- le client génère une bi-clé et soumet la partie publique pour signature ;

- le serveur signe la partie publique, génère un certificat et le retourne au client.

SCEP est un protocole basé sur HTTP (protocole non sécurisé), aussi faudrait-il mieux considérer l'utilisation de HTTPS qui apporte :

- une authentification mutuelle des participants : s'assurer que la personne à l'autre bout de la ligne est bien celle qu'elle prétend être ;

- un chiffrement des échanges pour garantir leur confidentialité.

SCEP apporte sa propre couche de sécurisation avec un chiffrement des échanges et une authentification mutuelle. Le problème est que cette authentification est facilement contournée (voir avis CERT mentionné plus bas) et souvent mal implémentée en pratique, ce qui ouvre la porte à nombre d'attaques.

L'authentification serveur fait l'hypothèse que le client connaît au préalable le certificat présenté par le serveur et lui fait confiance. Ce cas de figure n'est quasiment jamais vrai dans la pratique, la plupart des autorités d'entreprise n'étant pas publiques. Un mobile iOS va systématiquement faire confiance au serveur SCEP avec lequel il discute sans pouvoir vérifier son identité, ce qui permet de monter des attaques en MITM (Man In The Middle).

L'authentification client (le Challenge) est basée sur un secret partagé que le client vient présenter au serveur au moment où il vient demander un certificat. Cette procédure ne peut être considérée comme sécurisée que si ce secret partagé est à usage unique, limité dans le temps, et différent pour chaque utilisation du protocole. Le problème devient alors : comment générer un secret différent à chaque usage et le communiquer secrètement au client au préalable ?

On se rend compte qu'on a juste transféré le problème d'authentification des clients un cran plus loin : la distribution des certificats à leurs utilisateurs légitimes est maintenant basée sur la distribution de secrets partagés aux demandeurs de certificats. C'est ce dernier point qui pose le plus de problèmes de sécurité sur la distribution de certificats via des serveurs MDM.

4.2 Problèmes liés à SCEP sur MDM

Les serveurs MDM disponibles aujourd'hui n'ont généralement pas correctement intégré la notion de secret partagé à usage unique. Certains proposent simplement d'ignorer le secret et de faire totalement confiance aux clients qui viennent se connecter pour demander un certificat. La conséquence immédiate est que toute personne ayant accès au MDM peut se faire délivrer un certificat à un nom arbitraire. On peut se demander l'intérêt de déployer une authentification forte à base de certificats X.509 si aucun contrôle correct n'est fait au moment de leur distribution.

Ce problème d'authentification client a été souligné comme critique et fait l'objet d'un avis CERT : http://www.kb.cert.org/vuls/id/971035.

Cette erreur n'est pas uniquement présente chez les vendeurs de MDM. Dans la suite Windows Server, Microsoft propose des utilitaires permettant de construire soi-même son autorité de confiance pour émettre des certificats utilisateurs, incluant un connecteur SCEP sur lequel la plupart des MDM savent se connecter. Un article de la Knowledge Base Microsoft présente comme une amélioration le fait de pouvoir débrayer l'authentification utilisateur pour « raccourcir le temps nécessaire à la gestion de certificats SCEP ». Voir :

Two improvements are available that shorten the time that is required to manage SCEP certificates [...] - http://support.microsoft.com/kb/959193/en.

Une fois le hotfix appliqué, c'est le même mot de passe qui sera utilisé pour tous les enrôlements : toutes les demandes de certificats sont automatiquement validées. Rien de plus facile que de se faire délivrer un certificat pour une identité arbitraire !

4.3 Solutions pour SCEP

On veut s'assurer de l'authentification du client SCEP avec ce Challenge à usage unique. Ceci implique une conversation entre serveur MDM et l'autorité de confiance afin d'établir un Challenge différent pour chaque enrôlement. Le problème est qu'il n'existe aucun protocole standard de serveur à serveur pour négocier ce secret. Les choses progressent donc pas à pas pour chaque couple vendeur de PKI + vendeur de MDM, et pour l'instant, seuls les plus gros vendeurs de solutions MDM se sont lancés dans cette tâche. Les premiers partenariats annoncés ont été entre Air-Watch (MDM) et OpenTrust (PKI), et entre Good (MDM) et EnTrust (PKI). D'autres partenariats sont attendus dans les mois qui viennent.

Une fois un protocole établi entre serveur MDM et serveur PKI, il devient possible de tracer systématiquement toute délivrance de certificat et d'y associer une authentification client forte et unique pour chaque demande. L'usage d'identités numériques sur les mobiles peut alors se généraliser pour la sécurité des points d'accès à l'entreprise depuis les réseaux sans fil.

Si un mobile est perdu ou volé, un seul appel au Help Desk sera nécessaire pour faire révoquer les accès côté serveur. Nul besoin de chercher à obtenir un accès au mobile, les certificats ne seront plus valides. Une fois les accès coupés, les dégâts peuvent être confinés à la perte des données présentes sur le mobile au moment de sa disparition. Un effacement à distance déclenché par MDM peut permettre de se prémunir contre les vols opportunistes dans lesquels le mobile est volé pour sa valeur et non ce qu'il contient.

5. Scénario d'attaque

Essayons d'imaginer une attaque réaliste contre une entreprise pilotée par un MDM sécurisant mal la délivrance de certificats par SCEP.

5.1 Première phase : Analyse

Le responsable informatique s'inquiète du phénomène BYOD et demande à ses administrateurs de lui donner une liste des terminaux différents qui viennent se connecter au réseau d'entreprise, par exemple les User-Agents des navigateurs utilisés pour venir consulter le webmail d'entreprise. Il réalise qu'en six mois, le nombre de terminaux de type iOS a explosé, avec une pointe fin décembre. Il n'est plus possible d'ignorer ces utilisateurs, d'autant plus que le Directeur Général amène maintenant un iPad lors de toutes ses réunions.

5.2 Deuxième phase : Mise en place d'un MDM

Plusieurs solutions MDM sont à l'étude. Celles qui sont retenues sont celles qui proposent l'authentification la plus forte disponible actuellement, via l'usage de certificats X.509. Les administrateurs réseau confirment qu'il est possible de créer une autorité de certification (AC) sur Microsoft Server 2008 avec toutes les options nécessaires pour la connexion d'un MDM. On crée les autorités (un serveur Windows par autorité), on active l'authentification par certificat sur le VPN d'entreprise, puis on déploie un MDM et on le teste sur quelques utilisateurs témoins.

5.3 Troisième phase : Déploiement

Un mail est envoyé à tous les collaborateurs pour leur proposer d'inscrire leur terminaux iOS sur le MDM d'entreprise. Des certificats d'authentification sont créés pour tous, pour accéder au VPN, aux points d'accès Wi-Fi, et aux boîtes aux lettres Exchange. Le service informatique voit arriver des centaines de demandes de certificats de terminaux jusqu'ici inconnus, avec parfois plusieurs terminaux pour le même utilisateur, par exemple smartphone et tablette.

Problème : les AC Microsoft sont configurées en mode Challenge Unique, le même secret partagé pour tous les enrôlements. Cette configuration a pu être initiée par un administrateur qui a appliqué le hotfix suggéré par Microsoft, ou forcée par un MDM limité à une connexion en challenge unique.

L'attaque utilise le défaut d'authentification du client SCEP :

- Récupérer le challenge unique. Ceci peut être fait depuis la console d'administration du serveur Microsoft, depuis la console du MDM, ou en se faisant passer pour un appareil iOS.

- Soumettre une demande de certificat établie à un nom arbitraire, via SCEP.

- Une fois le certificat obtenu, les portes du réseau d'entreprise sont ouvertes. Suivant l'identité choisie, les droits peuvent être plus ou moins élevés et causer autant de dégâts.

Ce scénario est décrit en détail sur le site http://www.css-security.com/scep/.

Références

La NSA publie un document dédié aux recommandations de sécurité pour les appareils sous iOS 5. Voir : http://www.nsa.gov/ia/_files/os/applemac/Apple_iOS_5_Guide.pdf.

Le problème de la complexité des mots de passe est notamment mentionné dans le paragraphe 3.1.2 Passcode.

Le protocole décrit par Apple pour les MDM pilotant des appareils iOS est décrit sur les pages d'Apple : voir iOS Enterprise Integration. Ce même protocole a été largement disséqué et analysé d'un point de vue sécurité. Voir :

https://github.com/intrepidusgroup/imdmtools.

http://www.trailofbits.com/resources/ios4_security_evaluation_paper.pdf.

Ces références sont également citées dans le document NSA mentionné plus haut.

Conclusion

Si la sécurité des mobiles est encore aujourd'hui loin d'être parfaite, des efforts considérables ont été accomplis ces dernières années pour couvrir le fossé entre des appareils grand public et des appareils destinés à un usage d'entreprise. L'usage d'un MDM peut apporter les services nécessaires à une meilleure cohérence d'une flotte complète et la généralisation de règles de sécurité minimales, mais il peut aussi amener des risques structurels de sécurité qu'il n'est pas évident de détecter a priori. L'ajout d'un serveur aussi intimement lié à l'infrastructure existante devrait toujours déclencher une étude soigneuse des risques associés.

L'utilisation de mots de passe comme seul rempart de sécurité pour l'authentification doit absolument être remise en question pour les mobiles : un smartphone de 2013 est bien plus puissant qu'un PC de 2003, l'usage d'authentification forte à base de PKI devient extrêmement pertinent, sans devoir attendre que tous les appareils soient équipés de porte-clés inviolables. Distribuer des certificats X.509 n'est pas chose nouvelle : le sujet a eu le temps de mûrir depuis les vingt dernières années.