Les motivations

    De part son architecture la carte à puce permet de stocker des informations sensibles telles que :

• Clés privées
• Mot de passe
• Numéro de compte bancaire
• Informations médicales(carte Vitale)

    A ses débuts, pour chaque application on développait une interface de dialogue carte-terminale spécifique. Afin de palier à cette hétérogénéité des systèmes et ainsi de favoriser l'interopérabilité, les industriels ont tenté de standardiser les différentes interfaces existantes. Deux d'entre elles se sont démarquées : PCSC et OCF.

 

T=0 et T=1

    T0 et T1 sont les deux protocoles utilisés pour la communication entre le terminale et la carte à puce. T0 est un protocole orienté caractères, alors que T1 est orienté blocs.

 

PCSC

    PC/SC est un projet né sous l'impulsion d'un groupe industriel contenant entre autre Bull, Sun, Microsoft, Siemensetc et afin de répondre aux besoins de spécifications qui apporteraient l'interopérabilité entre les différents systèmes existant et les cartes à puces.

    Les spécifications de PCSC se décomposent en huit parties que nous détaillerons par la suite.

    La 1ere partie traite de la vue d'ensemble du système, celle-ci spécifie les différents composants de l'architecture PCSC qui sont :

• Les interfaces de communication terminal/carte à puce.
• L'interface au niveau programmation que doit offrir pilote d'un de ces appareils.
• L'API du gestionnaire de ressources(pour gérer plusieurs carte à puces).
• L'API et la spécification de certains services(comme la cryptographie)

    La seconde partie présente les caractéristique de l'interface de communication entre le PC et la carte à puce au niveau physique. En effet PC/SC définie l'interface de communication au niveau électrique, le format de la carte, ainsi que la position du connecteur(reprise en partie de la norme ISO).

    Une fois la communication hardware définie, il faut pouvoir utiliser le lecteur au niveau software et il c'est ce que traite la partie 3 : l'interface que doit fournir le pilote de l'IFD pour communiquer avec le Ressource Manager. Dans cette API sont déclarées des fonctions simples d'envoie et de réception de messages entre le Gestionnaire de Ressource et la carte à puce.

    Quand à la partie 4, elle donne des exemple de différentes possibilité de connexion des lecteurs de cartes à puce. Les canaux de communication présentés dans les spécifications traites de connectique dite standard telle que : RS232, USB, PS2. Mais il est tout a fait possible d'avoir une interface propriétaire il suffit pour cela de fournir les pilotes du lecteur conforme à l'API décrite dans la partie 3.

    La cinquième partie décrie l'interface et les fonctionnalités supportées par le gestionnaire de ressources.(Partie indispensable de l'architecture PCSC) Cette couche du model PC/SC permet d'abstraire l'utilisation de la carte à puce en accèdent directement à des services tel que le système de fichier de la carte à puce. Les classes suivantes sont définies : Le gestionnaire de ressources :

Class RESOURCEMANAGER{

HANDLE hContext // Handle to a communications Context associated with an

// SCARDMANAGER object instance (see below).Set to NULL

// on object creation.

RESOURCEMANAGER();

~ RESOURCEMANAGER();

RESPONSECODE EstablishContext();

RESPONSECODE ReleaseContext();

}

    La classe RESOURCEDB permet d'effectuer des opérations sur la mini-base de donnée que forme le gestionnaire de resource. Il est ainsi possible d'y ajouter, supprimer, et de gérer des groupe de lecteurs de cartes à puce.

Class RESOURCEDB extends RESOURCEDBQUERY {

private RESOURCEMANAGER resmgr; // Reference to a RESOURCEMANAGER object

RESOURCEDB(IN RESOURCEMANAGER resmgr)

~RESOURCEDB()

RESPONSECODE IntroduceReader();

RESPONSECODE ForgetReader();

RESPONSECODE IntroduceReaderGroup();

RESPONSECODE ForgetReaderGroup();

RESPONSECODE AddReaderToGroup();

RESPONSECODE RemoveReaderFromGroup();

RESPONSECODE IntroduceCardType();

RESPONSECODE ForgetCardType();

}

    La classe SCARDCOMM permet quand à elle de gérer la communication entre l'application(ou le service) et la carte à puce. Cette interface apporte des fonctions de gestion de connexion, de contrôle de transaction, d'envoie et de réception de commandes, et d'interrogation de l'état de la carte.

Class SCARDCOMM{

private RESOURCEMANAGER resmgr // Reference to a RESOURCEMANAGER object private HANDLE hCard

// Handle to a Context associated with communication to a

// specific card and/or Reader. Set to NULL on object creation.

// This context is established using the Connect()method and

// destroyed using Disconnect().

SCARDCOMM(RESOURCEMANAGER resmgr)

~SCARDCOMM()

RESPONSECODE Connect();

RESPONSECODE Reconnect();

RESPONSECODE Disconnect();

RESPONSECODE Status() ;

RESPONSECODE BeginTransaction() ;

RESPONSECODE EndTransaction();

RESPONSECODE Cancel();

RESPONSECODE Transmit();

RESPONSECODE Control();

RESPONSECODE GetReaderCapabilities ();

RESPONSECODE SetReaderCapabilities ();

}

    La partie 6 spécifie quand à elle l'accès à un plus haut niveau avec la carte à puce. La classe suivante est l'abstraction de la carte à puce. Elle permet à l'application d'utiliser la carte à puces.

Class SCARD{

HANDLE hContext ; // ICC Resource Manager

SCARD() ;

~SCARD();

RESPONSECODE CreateFileAccess();

RESPONSECODE CreateCHVerification();

RESPONSECODE CreateCardAuth();

RESPONSECODE CreateCryptProv();

RESPONSECODE AttachByHandle();

RESPONSECODE AttachByIFD();

RESPONSECODE Detach() ;

RESPONSECODE Reconnect();

RESPONSECODE Lock();

RESPONSECODE Unlock();

}

    Cette partie définie aussi d'autres interfaces telles que :

• FILEACCESS qui permet la une gestion haut niveau d'un système de fichier.
• CARDAUTH service permettant une authentification facile.
• CRYPTPROV accès à un service de cryptographie.
• CRYPTHASH gestion d'un service de hachage.

    La partie 7 donne l'architecture générale d'applications clientes. Elle spécifie les taches suivantes :

• Détermination dynamique des ressources disponibles.
• Connexion auprès de la carte désiré.
• Partage de ressources. · Utilisation du service de sécurité.
• Gestion des erreurs

    La partie 8 est une suite de recommandation pour l'implantation des différents services tel que la gestion des fichiers, ou l'authentification.

    Les spécifications de PC/SC on le mérite d'être très large et donc d'être très facilement transposable sur différentes plate-forme(c'est le cas de MUSCLE sous UNIX et OS X), mais aussi sous différents langages(C/C++, Java).

 

OpenCardFramework

OpenCard objectifs

    Du point de vue des développeurs d'applications, trois critères sont à prendre en compte :

• le terminal ou lecteur associé à la carte
• le système d'exploitation : aujourd'hui très variés
• localisation de l'application sur la carte par le fournisseur

Or ces trois paramètres varient énormément : d'un commerçant à un autre et d'une carte à l'autre.

    Ainsi, l'objectif d'OCF est de rendre indépendants ces trois critères pour le développeur et par ce biais de rendre les applications pour cartes à puce plus facile à développer. De plus, OCF a l 'ambition de devenir un standard évolutif.

L'Architecture OpenCard

    Pour atteindre les objectifs précédemment cités, l'architecture d'OCFse décompose en deux parties principales : la première couche est dite Carte-Terminal et la suivante Carte-Service. Le problème de la localisation de l'application sur la carte est géré quant à lui par un composant supplémentaire dit Gestionnaire de l'application. Nous allons à présent détailler ces trois parties.

 

La couche Carte-Terminal

    Cette couche permet d'accéder aux terminaux à carte, ainsi ce sont les constructeurs qui font en sorte (grâce aux drivers " OCF-compliant ") cela fonctionne bien.

    On trouve également dans cette couche des JAVA APIs (on cite éventuellement) qui permettent d'accéder aux terminaux PCSC. Plus généralement , cette couche permet à OCF d'être compatible avec la large gamme de terminaux d'aujourd'hui ou même du futur

La couche Carte-Service

    Cette couche permet à OCF de jongler entre les différents OS existant et surtout avec tout le panel de fonction qu'ils offrent. Parmi ces services, on trouve :

• FileAccessCardService

    Qui fournit tout un jeu complet d'interfaces et de classes abstraites ce qui rend le système de fichier accessible au programmeur. Tout comme pour le reste, les classes et interfaces constituant ce service ont été spécialement développés pour s'adapter facilement à JAVA, autant au niveau des entrée/ sortie que pour le développeur.

• SignatureCardService

    Le SignatureCardService apporte les méthodes permettant de générer et de contrôler les signature digitale en utilisant des algorithmes à clés publiques tels que RSA. Des fonctionnalités supplémentaires permettent de charger des clés privées ou publiques directement sur la carte ou même de faire générer des paires de clés par la carte elle même.

Le Gestionnaire de l'application

    Pour pouvoir gérer les multiples applications que peut contenir une seule et même carte, de nouvelles fonctionnalités (dependencies ) ont été développées.

C'est là qu'intervient le Gestionnaire de l'application. Celui-ci peut :

• soit locating and selecting card-resident applications on any given smart card,
• soit listing the applications which a particular smart card supports,
• soit installing and uninstalling applications on smart cards, and
• blocking and unblocking applications on smart cards,

et ainsi, il résout le problème de la délocalisation des application sur le support.

 

Lexique

OCF : OpenCard Framework

PC/SC : Personal Computer SmartCard(Interoperability Specification for ICCs and Personal Computer Systems)

MUSCLE : Movement for the Use of SmartCard in a Linux Environment

API : Advanced Programming Interface

ICC : Integrated Circuit Card

IFD Interface Device

T=0 Character-oriented asynchronous half duplex transmission protocol.

T=1 Block-oriented asynchronous half duplex transmission protocol.