Les spécifications Personal Computer/Smart Card PC/SC
Chapitre 2 : Les spécifications Personal Computer/Smart Card PC/SC
Introduction.
La carte à puces est une plate-forme sécurisée idéale pour les applications nécessitant une haute sécurité et une fonctionnalité de confidence.
Outre que la carte à puce ICC est un équipement de stockage sécurisé pour informations sensibles tels que : clés privées, numéros de comptes, mots de passe, informations médicales, . . . elle est dotée d’une fonction de traitement autonome capable de gérer ces informations sans les exposer au monde extérieur.
Ce qui est vraiment important pour certaines applications telles que : génération des signatures digitales, utilisation des clés privées pour authentification, traitement des représentations électroniques des valeurs (monnaies électroniques, crédits prépayés), . . .
Schéma fonctionnel de la carte à puce (ICC)
*** Problématique
Le groupe de travail PC/SC constitué de CP8 (Bull), HP, Microsoft, Schlumberger et Simens a développé ces spécifications pour faciliter l’Interopérabilité nécessaire, à voire la compatibilité de technologie des cartes à puce (ICC) avec l’environnement PC.
En effet, l’utilisation de la carte à puce (ICC) dans l’environnement PC est marquée par manque d’interopérabilité sur plusieurs niveaux :
* Pas de standard pour l’interface PC/ lecteur (Interface Device IFD). Donc une application écrite pour un lecteur X est incompréhensible à un lecteur Y. L’utilisateur est alors obligé de changer son lecteur, chaque fois qu’il utilise une nouvelle application.
* Pas de standard pour interface de programmation haut niveau pour les fonctionnalités connues des ICCs.
Ce qui rend les applications, dépendantes de l’implémentation spécifiques de l’ICC c à d une application qui fonctionne avec un ICC, ne peut l’être avec une version améliorée de ce même ICC.
L’encapsulation des interfaces ICC permet à plusieurs applications de partager le software de l’interface bas niveau.
*** Les objectifs.
Cette spécification cherche à réaliser les objectifs suivants :
– Maintenir les standards relatifs à l’ICC et au PC déjà existants.
– Indépendance de la plate-forme.
– Indépendance du vendeur (produit).
– Indépendance de l’application. (Le software de l’application reste le même avec l’avance technologique).
*** Les spécifications PC/SC.
** Architecture du système :
Architecture du système
Une carte (ICC) dans son lecteur (IFD)
** La carte à puce (ICC) :
La carte à puce – cette fameuse carte en plastique de la taille d’une carte de crédit avec un microprocesseur encastré – est une plate-forme sécurisée qui offre une variété de service, allant du stockage sécurisé des données jusqu’aux services cryptographiques.
D’après ces spécifications, la carte à puce doit être conforme physiquement et électriquement au standard de l’ISO 7816-1, 2, 3.
C’est à dire, ils reprennent exactement les recommandations ISO-7816 mais avec les restrictions suivantes :
- Pas de voltage de programmation
- Seulement, les protocoles suivants sont conformes : T=0, T=1 et Synchrone (optionnelle). L’IFD refuse n’importe quel protocole par défaut s’il n’est pas conforme.
- Les caractères en état de transite sur le port E/S sont de 10 bits :1 start bit (bas), 8 bits de données et 1 bit de parité.
Et ils ajoutent aux recommandations ISO-7816 les recommandations suivantes :
- Les lecteurs « loading contacts » sont recommandés. (Les lecteurs swiping contacts ne sont pas interdits).
- La tension d’alimentation est 5 V, c’est au lecteur de détecter la présence des cartes à 3 V. Lorsque le comité de l’ISO 7816 déterminera les méthodes, cette spécification sera mise à jour.
- On recommande l’absence de TA2 dans l’ATR. (L’ICC peut négocier la mode d’opération).
On comparant avec l’ISO-7816 on note les nuances suivantes :
* On n’a pas besoin que la carte demande l’authentification du monde extérieur, car le PC appartient au détenteur de la carte.
* L’organisation (Mapping) des APDUs en protocole T=0 ou T=1 est la responsabilité de l’ ICC et du TTL/SP (la couche Transport du Service Provider).
* Le sous-système IFD supporte la couche liaison de données :il détecte les erreurs de parités (T=0), les erreurs de protocole et perte de synchronisation (T=1), il essaye la retransmission 3 fois, si ça ne marche pas il informe le SP. (C’est le niveau transport).
Tandis qu’en ISO 7816 ou en EMV c’est la responsabilité du transmetteur (T=0) ou de TTL (T=1) càd on ne trouve pas cette discrimination entre la couche transport et celle de liaison de données.
* Les commandes sont toujours du lecteur vers la carte, c’est le SP qui les génère à la demande de l’application. L’IFD doit traiter ces commandes C-TPDU (la commande et les données associées en un seul bloque)
* L’IFD émet seulement l’entête de la commande (CLA, INS, P1, P2, P3)et attend l’octet de procédure :si c’est un ACK, il commence à envoyer les données étapes par étapes, mais si c’est un SW1= 0x6x ou 0x9x, il l’envoie au SP pour interprétation. Ce qui diffère cette spécification de l’ISO 7816-4 et de l’EMV.
On retrouve ici le même scénario :
Une fois la carte insérée, le lecteur lui applique un RESET à froid, la carte répond en émettant une trame ATR (Answer To Reset) d’une façon : asynchrone, semi-duplex et une durée de bit (etu ou elementary time unit) = 372/f avec 1<f
Cette trame ATR définit le protocole de transmission, la convention du codage (directe ou inverse) et les paramètres (débit, espacement entre caractère, négociabilité du protocole, . . . ) :
* Si la carte (ICC) retourne une séquence ATR non conforme, le lecteur (IFD) est obligé quand même à continuer avec le protocole et les paramètres y existants par défaut.
* Si la carte (ICC) ne retourne pas une séquence ATR, alors 2 cas se présentent :
1. La carte est mal insérée ou bien elle est en panne.
2. L’application ne supporte pas ce type de cartes (cartes synchrones par exemples).
Le lecteur (IFD) doit envoyer à RM le message « cette carte ne fonctionne pas ». C’est le RM qui gère le problème.
Handshacking et négociation du protocole à utiliser durant cette transaction.
** Le terminal :
Dans ces spécifications, la fonctionnalité du terminal (aussi appelé sous système IFD) est différente d’autres spécifications.
En effet le sous-système IFD consiste en :
- Une interface avec la carte à puce.
- Un canal E/S contrôlé par un « driver » des E/S du côté PC.
- Un software « IFD handler » dans le PC.
* Le lecteur (IFD ou ICC reader device) :
L’IFD joue le rôle d’une interface physique à travers laquelle la carte à puce communique avec le PC : à l’aide de ses contacts électriques, il assure l’alimentation, l’horloge et une ligne E/S à la carte à puce.
Il communique avec le PC à travers un canal E/S. En effet l’accès physique au PC se fait par le biais du port série (RS232), du port clavier (PS/2), du port USB ou du port PCcard (PCACIA).
Le protocole de communication de l’IFD avec le PC est de 3 couches :
Protocole de communication entre PC et Lecteur.
* L’IFD handler :
Ce software, lancé dans le PC, il fait implémenter un standard indépendant du hardware et une interface indépendante du canal E/S dans le sous-système IFD.
Le sous-système IFD est responsable des 2 couches physique et liaison de données :
Un IFD intelligent (supportant la couche liaison de données T=0 et T=1) nécessite un simple IFD handler. Tandis qu’un IFD moins intelligent (ne supportant que la couche physique) nécessite un handler supportant la couche liaison des données T=0 et T=1, et la gestion des erreurs, etc. . .
Le flux d’informations entre le SP et le sous-système IFD est indiqué par la figure
Flux entre lecteur et SP.
** ICC Resource Manager :
C’est le responsable de la gestion des autres ressources relevant à l’ICC dans le système, et il supporte l’accès contrôle à l’IFD et à l’ICC (à travers l’IFD).
Il résout 3 problèmes basiques dans la gestion d’accès à plusieurs IFDs et ICCs :
- Il est responsable de l’identification et le traking des ressources.
- Il est responsable de l’allocation de ressources.
- Il supporte les primitives de transaction d’accès aux services existants dans un ICC donné.
Le système doit avoir un et un seul ICCRM.
Lire le mémoire complet ==> (Les cartes à puces)
Mémoire de fin d’études
Diplômes d’Etudes Approfondies – Réseaux de télécommunications