Middleware : l’interface entre l’eID et l’application eID

Les fournisseurs des lecteurs de cartes offrent du middleware spécifique pour la communication avec leur hardware. La plupart des producteurs d’applications eID intègrent ce middleware dans leurs applications. Il existe aussi des applications pour lesquelles une installation préalable de middleware n’est pas nécessaire, ce qui est en soi convivial. Un exemple : digIDs, une plate-forme eID pour les applications web. Puisque le middleware est intégré dans l’application web, l’utilisateur

44

lui-même n’est pas obligé d’installer le middleware. Le software nécessaire est appelé automatiquement à partir de l’application. L’utilisateur doit seulement surfer vers le site web, introduire l’eID dans le lecteur de carte et l’enregistrement est effectué.

« Service Téléticket » est une application qui est basée sur la plate-forme digIDs (pour une réservation en ligne, entre autres, des billets de concerts et de matches de foot). Elle est également utilisée par « TMAB Business Events » pour l’inscription en ligne d’événements, par exemple le Congrès e-Government.

Fedict offre aussi du middleware. En tant qu’élément du processus d’homologation des lecteurs de carte, Fedict contrôle si les lecteurs de cartes sont conformes à ce middleware et vice-versa. Il faut remarquer que le middleware de Fedict ne supporte que l’eID et pas d’autres smartcards.

Des accords et des standards sont importants de manière à simplifier et stabiliser le ce processus d’intégration.

Standards pour les interfaces entre la smartcard et les applications

Pour que les applications puissent communiquer avec les smartcards, il existe deux standards :

x Le standard PKCS#11, aussi connu sous le nom CrypTokI, soit Cryptographic Token Interface.

Ce standard a été mis au point par la société RSA et a été mis dans le domaine public. Le middleware PKCS#11 est disponible pour beaucoup de smartcards sur plusieurs plates-formes comme Linux, Windows, BSD, UNIX etc.

x Le standard CSP (Cryptographic Service Provider), aussi connu comme MS CAPI. Ce standard a été mis au point par Microsoft et est uniquement disponible sur les plate-formes Windows. Une application ne s’adressera jamais directement à ce CSP, mais toujours à l’aide d’une interface, notamment le Crypto API (Application Programming Interface).

La figure ci-dessus est un schéma de la construction des composants lors de la mise au point des applications qui veulent utiliser les données sur la smartcard.

Software des autorités pour l’eID

Les autorités (Fedict) mettent un software à disposition pour l’utilisation de l’eID et pour la mise au point des applications pour l’eID. Ce software a été basé sur les standards susmentionnés

45

(PKCS#11 et CSP) pour les fonctions cryptographiques de la smartcard (authentification et signature électronique). L’interface PKCS#15 est utilisée pour la lecture des données ordinaires.

Belgium Identity Card Run-time :

Ceci est une application pour lire, valider et imprimer le contenu de l’eID. Ce software comprend trois fonctionnalités qui peuvent être téléchargées en un paquet :

x Card service : ce composant s’installera sur votre ordinateur et détectera chaque carte insérée dans le lecteur de carte à puce. S’il s’agit d’une eID, il présentera toutes les fonctions disponibles au middleware. Ce module comprend aussi les fonctionnalités qui empêchent un intrus d’utiliser votre eID à votre insu.

x Data Middleware : ce composant communiquera avec le ‘Card service’ pour présenter de façon standardisée les données d’identité dans la carte aux applications qui veulent accéder à ces informations.

x Crypto Middleware : ce composant communiquera avec le ‘Card service’ pour activer les fonctions cryptographiques pour l’authentification et la signature qui exigent la saisie d’un code secret.

Belgium Identity Card Developer’s Kit :

Ce Software Development Kit (SDK) pour l’eID est destiné aux développeurs qui veulent créer une interface avec les applications existantes et/ou qui veulent créer de nouvelles applications avec l’eID. Ce kit comprend, entre autres, les bibliothèques nécessaires (utilisant des API : Application Programming Interfaces) pour la compilation des programmes ainsi que des exemples de code source. Il est mis à disposition dans les versions Microsoft, Mac et Linux.

Approche générique de l’Identity & Access management – support de plusieurs plates-formes

Dans ce paragraphe, nous examinons en détail les solutions « Identity & Access Management » qui supportent plusieurs cartes : des eID provenant de plusieurs pays ou d’autres smartcards comme, par exemple, Bancontact, Isabel, Visa ou des tokens USB.

En général, de telles solutions sont achetées dans le cadre d’une approche globale des identités et de la gestion d’accès, par des grandes entreprises ou des organisations qui ressentent ce besoin et peuvent utiliser à cet effet un budget relativement plus élevé. Ces plates-formes ont l’avantage qu’elles peuvent être intégrées entièrement dans des solutions complètes pour l’organisation (en général les plates-formes sont mises au point sur mesure pour l’organisation) et elles sont ouvertes pour d’autres cartes en dehors de l’eID.

Notez que le middleware des autorités (Fedict) et par conséquent toutes les applications qui sont mises au point à base de ce middleware, ne supporte que l’eID belge. Ceci n’exclut pas que Fedict

APPLICATION

Lecteur

46

– sur l’ordre d’autres services publics fédéraux - mette au point des applications qui permettent aussi l’utilisation d’autres cartes, comme la carte Isabel.

Voici quelques exemples de composants dans les applications Identity & Access Management :

x eID Safe Sign Identity Client (AET) : middleware cryptographique pour une authentification puissante avec des smartcards, tokens USB et/ou des cartes SIM dans les systèmes PKI. Cette technologie a été utilisée sur l’ordre des autorités flamandes lors des élections municipales pour la communication entre EDS-Telindus et les présidents des bureaux de vote. Via la carte eID du président, les listes électorales ont été transférées à l’aide d’une connexion sécurisée en ligne avec une signature électronique.

x PK Suite (Intesi) : offre la possibilité d’intégrer une PKI dans les applications de software, notamment pour l’identification, l’authentification et la signature électronique via l’eID ou d’autres smartcards, y compris l’horodatage et la gestion des certificats.

x Certains fournisseurs de software offrent des « service packs » qui peuvent être intégrés comme composants dans une application déterminée. Les utilisateurs peuvent intégrer l’eID, avec un minimum d’efforts. Un exemple : le « eID Service Platform » provenant de « the eID Company » qui offre du travail sur mesure à base de conditions spécifiques. Ils mettent au point, par exemple, des « packs » professionnels adaptés aux besoins des fleetmanagers ou des courtiers d’assurance, par exemple, ou des « packs » de fonction qui assurent le contrôle d’âge, le contrôle du code postal, etc.

x Un exemple d’application qui utilise le concept « Single Sign-On » (SSO) est « OneSign » d’Imprivata. C’est une plate-forme d’authentification grâce à laquelle l’on peut se connecter au réseau à l’aide d’un seul mot de passe (ou l’eID) et où un accès peut être accordé à toutes les applications. Pour chaque application, à l’arrière-plan, des mots de passe uniques et puissants sont créés et des modifications éventuellement nécessaires de mot de passe, sont générées automatiquement pour les utilisateurs. Pour cette raison, les problèmes liés au fait de gérer différents pseudos et mots de passe sont résolus. En outre, OneSign prévoit l’enregistrement complet et le rapportage des actions exécutées par les utilisateurs.

Construire des applications pour l’eID

Le middleware offert par les autorités (Fedict) peut être utilisé pour construire des applications qui utilisent l’eID. Celui-ci a toutefois plusieurs restrictions :

x Il est uniquement utilisable pour l’eID. Si un producteur veut mettre au point une application qui supporte plusieurs smartcards, il devra utiliser un autre middleware commercial, comme l’un de ceux décrits ci-dessus.

x Il offre une bonne assistance pour les environnements PC, mais des adaptations supplémentaires seront nécessaires pour d’autres environnements. Comme il ressort de l’étude de cas d’iDTV, (voir le chapitre « Études de cas ») il n’existe par exemple pas encore un middleware adapté aux développeurs permettant une intégration simple de l’eID dans la télévision numérique interactive.

La Belgique est un pionnier dans le déploiement de l’eID à une échelle aussi grande et générale.

Beaucoup d’applications sont spécifiques à l’environnement belge (pensons à toutes les applications e-gouvernement) ou sont « first of a kind ». Peu de standards ont été mis en place, l’environnement n’en est encore qu’aux balbutiements.

Le cadre adapID

Les autorités investissent dans la recherche pour favoriser une approche générique et la mise au point de composants de manière à ne pas réinventer la roue à tout moment. A cette fin, un cadre

47

(framework) est établi dans le projet adapID (advanced applications for electronic IDentity cards en Flandre). Ce cadre adapID permettra aux développeurs d’applications de construire des applications sensibles au niveau de la vie privée.

Le cadre est présenté dans le schéma suivant.

Source : Présentation deuxième commission utilisateur e-IDea (30-01-08) - Kristof Verslype (version provisoire - work in progress) Le cadre contient les composants suivants :

x Credential Manager : pour la gestion des credentials des utilisateurs (des credentials sont des certificats anonymes qui permettent de dévoiler des données sélectionnées qui ne sont pas liées à l’identité, voir également ci-après dans cette étude). Ici un module d’un tiers de confiance (par exemple Certipost) peut être intégré.

x Credential Handler : veille à ce que les credentials puissent être utilisés.

x Privacy Manager : note les informations dévoilées ainsi que la partie à laquelle elles ont été dévoilées et donne un avertissement en temps utile, par exemple.

x Deanonymizer : annuler l’anonymat lors d’un mauvais usage (ce composant sera hébergé probablement dans le Credential Handler).

x Communication : pour garantir l’intégrité et la confidentialité du trafic réseau (par exemple, le support des connexions sécurisées en cachant l’adresse IP).

x TAS : Trusted Archival Service : pour la protection de l’intégrité des documents électroniques.

En utilisant un TAS, l’intégrité des documents peut être assurée au-delà de la durée de vie du certificat avec lequel le document a été signé (le certificat de signature sur l’eID n’a qu’une validité de 10 ans, par exemple).

x Policy Manager : établit les règles standard pour montrer ou non tout ou partie des credentials.

Si le policy manager ne peut pas prendre une décision lui-même, l’utilisateur devra décider quels attributs de certains credentials seront montrés.

48

Le but du projet adapID n’est pas de livrer un produit de software commercial mais un cadre dans lequel toutes sortes de fournisseurs peuvent participer. Ces fournisseurs proposent des implémentations pour un ou plusieurs composants. Ainsi, par exemple, différentes implémentations pour le Credential Handler peuvent faire en sorte que vous pouvez utiliser l’eID belge, l’eID autrichienne ou les certificats standards x.509, par exemple. Ces fournisseurs ne proposent pas nécessairement l’implémentation complète, mais peuvent aussi – par exemple s’occuper de sous-composants pour que le middleware existant pour l’eID belge puisse être intégré dans le cadre.

Afin d’augmenter la convivialité du cadre, une couche additionnelle sera encore construite au dessus de la couche fonctionnelle, de façon à rendre les couches sous-jacentes invisibles au maximum pour les développeurs d’applications.

Le projet adapID sera analysé dans son intégralité dans le chapitre « Recherche scientifique sur l’eID ».