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

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)
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 :

  1. Il est responsable de l’identification et le traking des ressources.
  2. Il est responsable de l’allocation de ressources.
  3. 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

Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top