Les spécifications Personal Computer/Smart Card PC/SC

By 13 May 2012

Les spécifications Personal Computer/Smart Card PC/SC : Chapitre 2

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)
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
Architecture du système

Une carte (ICC) dans son lecteur (IFD)
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 ICC. (l’ICC exigeant ICC n’est pas conforme à ces spécifications. Si c6 est présente, elle doit être isolée électriquement).
* 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
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
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
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