** Le SP (service Provider) : *Overview fonctionnel : Trois classes de service sont implémentées dans la plupart des ICCs : * Services de fichier. * Services d’authentification. * Services cryptographiques. Ces services ont une fonctionnalité en commun. Par conséquent, il est très intéressant de standardiser des interfaces à ces services pour que la maintenance et le développement d’application deviennent plus aisés. Ces spécifications définissent de telles interfaces, aussi bien qu’une interface standard pour contrôler l’accès à un ICC. Il y a d’autres services qui reflètent les besoins dans certains domaines d’applications spécifiques (EMV, GSM, . . . ). Ces spécifications industrielles doivent standardiser ces interfaces. Cette architecture supporte l’addition de telles interfaces. *Considérations d’implémentation : Le rôle de la SP est de faire abstraction des détails d’implémentation du niveau ICC, et de les exposer d’une manière standard pour que le software de l’application puisse y accéder facilement. En particulier, ces détails éliminent le besoin d’un développeur d’application d’avoir une connaissance des commandes de « mapping » et des paramètres de codage associés aux protocoles T=0 et T=1 de l’ISO. Ces interfaces exposées par le SP doivent être développées dans le contexte d’une plate-forme donnée. Il est possible d’implémenter les interfaces ainsi définies d’une manière convenable pour l’utilisation des langages de programmation orientés procédures (C, Pascal, . . . ) aussi bien pour des langages de programmation orientés objets (C++, Java, . . . ). Le SP est divisé en 2 sous composants : * ICCSP : Il est responsable de l’exposition des services non cryptographiques aux interfaces du plus haut niveau. Cette exposition doit inclure des interfaces communes (gestion des connexions de l’ICC, services d’authentification et d’accès fichier) et des interfaces définies par le vendeur. 
Les interfaces.
ICCSPInterface gestion de connexions * Mécanismes de connexion et disconnexion de l’ICC. Interface accès aux fichiers * Recherche d’un fichier par le nom. * création, ouverture et annulation de fichier. * Ecriture/Lecture dans fichier. * fermeture d’un fichier. * gestion des attributs d’un fichier. Interface authentification * vérification du détenteur de la carte. * authentification de l’ICC. * authentification de l’application à la carte.
* CSP (Cryptographic Service Provider) : Il isole les services de cryptographie. (pour répondre aux régulations d’importation et exportation imposées par les gouvernements). Le CSP encapsule l’accès à la fonctionnalité de cryptographie apportée par un ICC spécifique à travers des interfaces de programmation de haut niveau. Les interfaces définies dans ces spécifications sont pour les services générale de cryptographie : – génération des clés – gestion des clés – signatures digitales – hachages (condensât du message) – services de chiffrement « bulk » – import et exportation des clés * Uses Interfaces Elements (UI): L’ICCSP et le CSP n’apportent aucun élément UI. Alors, le SP doit implémenter des UIs pour la gestion de CHV (si CHV existe)et pour des services tels que : – gestion de PIN et mot de passe. – accès administratif à la fonctionnalité du CHV (activation et désactivation). – authentification du détenteur de la carte. * Modèle : Le SP convient au modèle PC individuel et au modèle client/serveur. Et si on a plusieurs SP, c’est le RM qui aide l’application à choisir le SP convenable. 
Différentes configurations de lecteurs (USB) :1. séparé, 2. composé, 3. dépendant. ** Application : Cette partie décrit comment une application peut utiliser les fonctions apportées par l’ICC. En utilisant les 2 couches ICCRM et ICCSP, une application peut utiliser les fonctions de la carte avec un certain degré d’indépendance d’un lecteur (IFD) spécifique, ou d’une carte (ICC) spécifique. Un développeur d’application n’a plus besoin de tenir compte d’aucune composante de gestion de l’ICC ou de l’IFD. Il peut accéder aux différents services en utilisant un API ou bien une interface modèle objet tel que C++, Java, . . . Donc c’est bien une plate-forme indépendante. 
Echanges entre les 2 parties d’une application (oncard et offcard) ** Sécurité et liberté personnelle (privacy) : Notons que ces spécifications assument que les services et les fonctions apportés par l’ICC servent aux programmes d’applications du détenteur de la carte sur son PC. Dans cet environnement, les données du PC, qui doivent être stockées dans la carte, sont en texte clair. De même, les données que le PC cherche dans la carte sont en clair aussi. C’est pour cette raison la messagerie sécurisée définie par l’ISO/IEC7816-4 n’est pas utilisée ici. De toute façon, le vendeur peut implémenter la messagerie sécurisée pour qu’il puisse répondre aux besoins d’une industrie spécifique. Le but de ce document est la protection des données au profit de l’utilisateur. On assume ici que les données emmagasinées dans la carte appartiennent à l’utilisateur et doivent lui être accessible (dans certain cas, cet accès est indirect, par exemple : la clé privée qui est utilisée pour la signature digitale). Ceci est en contraste avec les mécanismes définis pour les standards spécifiques aux industries. Ces standards sont orientés à la protection des données au profit de l’institut émettrice. Recommandations : La nécessité des fonctionnalités suivantes : 1) Identification et authentification 2) Intégrité, confidentialité, non répudiation. 3) Stockage sécurisé. a obligé le groupe OC/SC à proposer les recommandations suivantes :
-*- Services cryptographiques : les algorithmes reconnus sont * Hachage : SHA-1 (160 bits) et MD5 (128 bits). * Signature digitale : RSA (clés de 512 bits min. ) et DSA (Kp de 512-1024 bits, Ks de 160 bits). * Echange de clés : RSA, Diffie-Helman. * Chiffrement symétrique : RC2, RC4, DES, IDEA, SAFER. -*- Services d’authentification : les protocoles reconnus sont : * Authentification du détendeur à un lointain serveur : Shared Secret Challenge-Response Protocol SSCRP, et Enhanced SSCRP. * Authentification du détendeur à la carte : CHV. * Authentification de l’application à la carte : SSCRP. * Authentification de la carte : comme définie par le vendeur. -*- Services de stockage : comme définie par l’ISO7816-4 : * Fichiers de type : MF, DF, EF. * Contrôle d’accès : ALW (always, pas de restriction), NEV (never, inaccessible), CHV (cardholder verification, la commande est exécutable dans le fichier sélectionné si le détendeur introduit le bon code CHV, sinon l’application se bloque après 3 essais par exemple), APP (application verification, la commande est exécutable dans le fichier sélectionné si l’application s’est bien authentifiée auprès de la carte par SSCRP). * Fichiers spéciaux : EF spéciaux (EFchv, . . . ), Fichiers obligatoires (MF, . . . ), fichiers cryptographiques (EFclés). -*- Les commandes : 31 commandes sont recommandées, (y inclut les 18 commandes ISO) : * Commandes de sécurité : Verify, Change_Code, Unblock, Get_Challenge, Internal_Auth, External_Auth, User_Auth, Invalidate, Rehabilitate. * Commandes cryptographiques : Load_Pub_Key, Load_Priv_Key, Generate_Key, Get_Pub_Key, Delete_Key, Load_Data, Sign_Data, Load_Verify_Key, Verify_Signature, Load_Export_Key, Export_Key, Import_Key, Hash_Data. * Commandes administratives : Create_File, Delete_File, Select, Read_Binary, Get_Response, Get_Data, Write_Binary, Update_Binary, Put_Data. 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
