Skip to content

Cartapus Mystery Cache

Hidden : 4/22/2018
Difficulty:
4.5 out of 5
Terrain:
1.5 out of 5

Size: Size:   other (other)

Join now to view geocache location details. It's free!

Watch

How Geocaching Works

Please note Use of geocaching.com services is subject to the terms and conditions in our disclaimer.

Geocache Description:


stefdel06 21/05/2018 : quelques chiffres n'étaient pas à la bonne place dans le message, cependant cela ne gênait pas la résolution de l'énigme.
Le message a été corrigé, faites une actualisation si nécessaire.
Merci à Pierre G de me l'avoir signalé.

stefdel06 06/04/2020 : encore une petite erreur dans un chiffre du message, cependant cela ne gênait pas la résolution de l'énigme.
Le message a été corrigé, faites une actualisation si nécessaire.
Merci à Daemons88.



Bonjour, votre mission si vous l'acceptez, consiste à comprendre de quoi parle cette trace informatique, dont il semblerait qu'elle soit liée au monde de la carte à puce... On n'est pas certain que la totalité du message ait été intercepté, mais bon... comme on ne comprend pas tout, on fait appel à vous...





Carte à puce vous dites ? Tout le monde ou presque en possède et en utilise, mais peu de gens savent comment ça marche exactement. Voici donc un petit décryptage.

Au programme : un petit historique, quelques notions sur la technologie des cartes à puce, les normes, et enfin les points clés de la norme ISO 7816. Ne soyez pas affolés, seule cette dernière partie devrait vous aider à décoder le message, le reste est surtout pour votre culture. Pour les plus curieux, il y a même quelques liens pour approfondir vos connaissances.




Historique

C'est en 1950 que la compagnie américaine Diners'Club lance la première carte de voyage et de loisirs. Elle se présente sous la forme d'un petit carnet (en carton) qui contient une liste d'adresses (des hôtels restaurants qui acceptent cette carte) et dont la page de garde comporte la signature du titulaire et diverses informations.

L'année 1958 voit la naissance des cartes American Express (sur support plastique), émises par les héritiers de la célèbre compagnie de diligences Wells & Fargo.

En France, le groupe Carte Bleue apparaît en 1967 afin d'offrir un moyen de paiement concurrent des cartes américaines. L'objectif est de réduire le nombre de chèques en circulation qui représente déjà 40 % des opérations de paiement et atteindra 90% en 1980.

Les premier distributeurs automatiques de billets (DAB) voient le jour en 1971 et utilisent des cartes bleues munies de pistes magnétiques (une piste magnétique est constituée de deux zones de lectures d'une capacité de 200 octets).

En 1974, Roland Moreno dépose un premier brevet sur un objet portable à mémoire. Il décrit un ensemble (l'ancêtre des cartes à mémoires) constitué d'une mémoire électronique (E2PROM) collé sur un support (une bague par exemple) et un lecteur réalisant l'alimentation (par couplage électromagnétique) et l'échange de donnés (par liaison optique). Il réalise la démonstration de son système à plusieurs banques. Il fonde la compagnie Innovatron.

Grâce au ministère de l'industrie il est mis en relation avec la compagnie Honeywell Bull qui travaille sur la technologie TAB (Transfert Automatique sur Bande), réalisant le montage de circuits intégrés (puces) sur un ruban de 35 mm, à des fins de test.

En 1977, Michel Ugon (Bull) dépose un premier brevet qui décrit un système à deux puces un microprocesseur et une mémoire programmable. La compagnie BULL CP8 est créée. La première carte à deux composants est assemblée en 1979. Le Microprocesseur Auto-programmable Monolithique (MAM, en anglais Self Programmable One chip Microprocessor - SPOM)) voit le jour en 1981, c'est en fait le composant qui va équiper toutes les cartes à puces.

Marc Lassus (futur fondateur de Gemplus) supervise la réalisation des premières puces (microprocesseur et mémoire puis du MAM) encartées par CP8 (un nouveau process de fabrication est mis au point pour obtenir des épaisseurs inférieures à 1 mm).

Le GIE Carte à mémoire est crée en 1980 et comprend des industriels (CP8, Schlumberger, Philips), le secrétariat d'Etat des P&T, et plusieurs banques.

En 1982, plusieurs prototypes de publiphones utilisant des cartes à mémoires (les télécartes) sont commandées par la DGT (Délégation Générale des Télécommunications) à plusieurs industriels. Les télécartes vont constituer par la suite un marché très important pour les cartes à puces.

En 1984, la technologie CP8 (MAM) est retenue par les banques françaises, le système d'exploitation B0 va devenir le standard des cartes bancaires française. Le groupement des cartes bancaires (CB) émet une première commande de 12,4 millions de cartes.

Les standards de base des cartes à puces (ISO 7816) sont introduits à partir de 1988.

A partir de 1987, la norme des réseaux mobiles de seconde génération (GSM) introduit la notion de module de sécurité (une carte à puce SIM - Subscriber Identity Module). En raison du succès de la téléphonie mobile, les télécommunications deviennent le premier marché de la carte à puce.

A partir des années 96, l'apparition des cartes Java marque l'entrée des systèmes cartes à puce dans le monde des systèmes ouverts. Il devient en effet possible de développer des applications dans un langage largement diffusé.

Depuis 2005, certains composants intègrent des machines virtuelles .NET, ils sont usuellement dénommés dotnet card.

Les marchés actuels sont : Porte-monnaie électronique, Transport, Cartes fidélité, Sécurité internet, Transport, Bancaire, Santé, Téléphonie, Commerce électronique, TV...








Technologie des cartes à puce

Aperçu de la carte à puce

Les principales caractéristiques d'une carte à puce sont les suivantes :
- C'est un objet portable, qui héberge des données et des procédures.
- C'est un objet sécurisé, utilisant des procédés cryptographiques basés sur des clés.
- Le code est exécuté dans un espace de confiance, il n'est pas possible d'obtenir les clés associées à des algorithmes cryptographiques.
- Il doit être difficile de lire les données confidentielles stockées dans les mémoires de la puce.
- Une puce ne peut fonctionner seule, elle nécessite un élément (typiquement un lecteur de cartes) qui lui fournit de l'énergie, une horloge (base de temps), et un lien de communication.

Les cartes à mémoire

Elles comportent un bloc de sécurité (optionnel) qui contrôle les accès à des mémoires de type ROM ou E2PROM. Les télécartes de première génération (ou TG1) n'étaient pas sécurisées, les télécartes de seconde génération (ou TG2) comportent un bloc de sécurité.

Les cartes à microprocesseurs

Un microcontrôleur se présente typiquement sous la forme d'un rectangle de silicium dont la surface est inférieure à 25 mm2. D'une part cette taille est imposée par les contraintes de flexion induite par le support en PVC, et d'autre part cette dimension limitée réalise un compromis entre sécurité physique et complexité du composant.
Les capacités mémoires sont de l'ordre de 128 à 512 Ko pour la ROM (surface relative 1), 64 à 128 Ko pour l'E2PROM (surface relative 4), 4 à 32 Ko pour la RAM (surface relative 16). En raison de ces contraintes technologiques la taille de RAM est (relativement) modeste, l'E2PROM occupe une portion importante de l'ensemble du chip. Les écritures en E2PROM sont relativement lentes (de l'ordre de 1 ms par mot mémoire de 32 à 64 octets), et le nombre de ces opérations est limité (de l'ordre de 100 000 à 200 000 cycles). Depuis 2004, l'introduction des technologies de type mémoire Flash a conduit à des capacités de l'ordre de 1 Mo et plus.

Cycle de vie d'une carte à puce

Un logiciel (système d'exploitation) est réalisé par une entreprise spécialisée. Ce logiciel est dédié à une application spécifique (bancaire, porte-monnaie, transport, etc.), et pour un composant électronique particulier.

Ce logiciel est stocké dans la ROM ou Flash du composant lors du processus de fabrication. Au terme de cette phase (qui nécessite plusieurs semaines pour de la ROM), le fondeur de silicium protège les données en écrivant dans la mémoire de la puce une clé secrète, dite clé de fabrication, ainsi que des informations telles que numéro de série du produit, date de fabrication etc.

Le wafer (plaque de silicium circulaire qui comporte un ensemble de puces) est alors envoyé à l'encarteur qui réalise sa découpe, colle les puces sur des micromodules et en réalise le micro câblage. L'ensemble est alors protégé par une substance isolante, puis il est collé sur un support en plastique (PVC) dans lequel on a préalablement usiné une cavité.

Les cartes sont ensuite transférées vers l'émetteur de la carte qui peut y inscrire de nouvelles informations.

Puis l'émetteur fournit une carte personnalisée à l'utilisateur final.

Enfin, pendant la vie de la carte, de nouvelles informations peuvent être ajoutées ou effacées dans la carte, en fonction de son utilisation.






Normes

La technologie à base de carte à puce est normalisée par plusieurs comités, mais également par divers forums industriels.
Voici un aperçu rapide des principaux standards :

ISO/IEC 7816
Cette norme (la principale) est un ensemble de documents destinés à assurer l'interopérabilité entre cartes à puce et lecteurs. Elle comporte de multiples parties 7816-1, 7816-2, etc. qui décrivent :
- Les caractéristiques physiques des cartes à contacts
- Les signaux électriques et protocoles de transmission
- Les commandes utilisées pour les échanges avec les lecteurs
- L'organisation des données dans les cartes
- Les méthodes de codage des données

ISO/IEC 14443
Cette norme décrit les caractéristiques et le fonctionnement des cartes à puce dites sans contact qui sont alimentées et qui communiquent grâce à des couplages électromagnétiques. Il existe deux types principaux de dispositif, le type A d'origine Philips (cartes mifare) et le types B. La distance de fonctionnement entre lecteur et carte varie de 0 à 10 cm.

ISO/IEC 15693 - Vicinity cards (VICCs)
Ce standard définit les tags ou encore étiquettes électroniques (RFIDs). Les distances de fonctionnement sont de l'ordre du mètre.

PC/SC - Interoperability Specifications for Integrated Circuit Cards (ICCs) and Personal Computer Systems
La norme PC/SC permet d'intégrer des lecteurs de carte à puces aux PCs (Interface Device - IFD). Le concept de cette pile consiste à offrir une interface de type API (niveau 6) aux applications qui utilisent les ressources des cartes aux moyens de DLLs.

EMV 96, EMV 2000 et suivants
Ce standard publié en 1996 par Europay, Mastercard et Visa, est relatif au domaine bancaire. Il décrit les terminaux, les cartes et leur interaction.

Global Platform
Cet ensemble de spécifications est d'origine Visa, il est destiné à la gestion des applications et concerne les cartes et terminaux. Les APIs associées sont basées sur la technologie Java.

GSM
Cette série de normes éditées par l'ETSI définit les cartes SIM (Subscriber Identity Module) utilisées par les téléphones mobiles.
Pour l'essentiel un module SIM comporte un algorithme d'authentification et sa clé secrète, un IMSI (identifiant d'un abonné) et deux carnets d'adresses (numéros de services et numéros personnels).

CEN 726 - Requirements for IC cards and terminals for telecommunications use
Ce standard définit les cartes et terminaux utilisés dans les Publiphones, il est également connu sous l'appellation E9. Il est quelque peu obsolète.

ICAO
L'ICAO ou International Civil Aviation Organization publie des standards relatifs aux controles d'identités, plus particulièrement appliqués aux passports électroniques.






Points clés de la norme ISO 7816

Communication carte - lecteur

Les mécanismes de base de communication entre une carte à puce et un lecteur sont définis par la norme ISO 7816.

De façon simplifiée, les échanges fonctionnent selon la séquence suivante :
- Mise en route de l'alimentation
--> Reset de la puce
<-- Réponse au Reset (ATR / Answer To Reset)
--> Commande (requête APDU)
<-- Réponse éventuelle + Statut
--> Commande (requête APDU)
<-- Réponse éventuelle + Statut
...
--> Commande (requête APDU)
<-- Réponse éventuelle + Statut

Le lecteur fournit l'alimentation en énergie et une horloge dont la fréquence est typiquement 3.5 Mhz. L'échange de données entre puce et lecteur est assuré par une liaison série dont le débit est compris entre 9600 et 230,400 bauds.

La Réponse au Reset (ATR / Answer To Reset) envoyée par la carte indique les caractéristiques de cette dernière :
- Identifiant de la carte
- Numéro de série
- Protocole(s) de communication et vitesses supportés
- Données libres, propres à chaque personnalisateur et/ou application

L'ATR débute par 3B en codage T=0, ou par 3F en codage T=1 (valeurs en hexadécimal).

Quelques exemples d'ATR :
- Carte bancaire B0' Visa : 3F 65 25 08 36 04 6C 90 00
- Carte Sesame Vitale : 3F 65 25 00 2C 09 69 90 00
- Carte SIM Universal : 3B 3F 94 00 80 69 AF 03 07 06 68 00 60 0A 0E 83 3E 9F 16

A partir de ce point, le terminal produit une requête (APDU) qui comporte au moins 4 octets (CLA INS P1 P2 [P3]) et des octets optionnels (dont la longueur Lc est précisée par la valeur de l'octet optionnel P3). CLA désigne une classe ou famille de commandes, 00 est la valeur ISO, A0 est utilisé pour les cartes SIM, BC a été utilisé par Bull CP8, INS désigne un code instruction, P1 P2 P3 sont trois paramètres aux fonctions dépendant de chaque instruction.

La carte délivre un message de réponse qui comprend des octets d'information (dont la longueur Le est précisée par l'octet P3 si celui-ci est présent et ne désigne pas déjà Lc) et un mot de statut large de deux octets (ou Status Word SW1 SW2, la valeur "90 00" notifiant le succès d'une opération). Lorsque la longueur de la réponse n'est pas connue à priori, un mot de statut "61 Le" indique au terminal la longueur du message de réponse. Une fois ce paramètre connu le terminal obtient le message de réponse au moyen de la commande GET RESPONSE (CLA C0 00 00 Le).

Pour acheminer les requêtes et réponses, différents types de protocoles de transport existent, parmi lesquels :

T=0
Les octets sont transmis selon un protocole série (1 bit start, 8 bits, 1 bit parité, 2+N bits stop). La détection d'une erreur de parité est signalée par le récepteur (carte ou lecteur) en appliquant un zéro logique sur la ligne de transmission pendant 1 ou 2 etu (unité élemntaire de temps).

T=1
C'est un protocole orienté bloc. Il est rarement utilisé en mode contact, la norme ISO 14443-4 (dite contactless ou sans contact) a défini un protocole de transport T=CL très proche du T=1. Un bloc de données comporte un prologue de 3 octets (PCB CID NAD), un champ information (INF) de 0 à 254 octets, et un épilogue (LRC de 1 octet ou CRC de 2 octets).

Le système de fichier ISO 7816-4

Un peu comme dans un disque dur d'ordinateur, l'information dans la mémoire d'une carte à puce est organisée sous forme d'un système de fichiers hiérarchique qui comprend un répertoire maître (MF - Master File), des sous-répertoires (DF - Directory File), et des fichiers EF (Elementary File). Chacun de ses composants est identifié par un nombre de deux octets (LID - Long IDentifier).

Il existe quatre types principaux de fichiers :
- Transparent (Binary), le fichier est une zone de mémoire dans laquelle on peut accéder librement en lecture et/ou écriture.
- A enregistrement de taille fixe (Linear Fixed), le fichier est un ensemble de blocs de taille fixe. Les blocs sont lus et/ou écrits de manière atomique.
- A enregistrement de taille variable (Linear Variable), le fichier est un ensemble de blocs de taille variable.
- Cyclique (Cyclic Fixed), le fichier se présente sous la forme d'un liste circulaire de blocs de taille fixe.

Les enregistrements sont référencés par un nombre compris entre 1 et 254.
L'accès à un fichier est réalisé à l'aide d'une série de commandes qui sélectionnent les répertoires, les éventuels sous-répertoires, et enfin le fichier.

La réponse à une commande SELECT FILE est optionnellement une liste d'objets (File Control Information FCI) exprimés en ASN.1, c'est à dire sous une forme Type Longueur Valeur (TLV).
Le plus souvent elle retourne les caractéristiques du fichier sélectionné : identifiant, nombre et taille des enregistrements, droits d'accès...
Dans le monde du transport, les enregistrements comportent historiquement 29 octets.

Les données textuelles sont le plus souvent codées en ASCII.

La sécurité est assurée par des droits d'accès et/ou des protocoles d'authentification, qui en cas de succès autorisent l'accès aux fichiers.

Les principaux mécanismes de sécurité associés à l'accès aux fichiers sont les suivants :
- Authentification par mot de passe (commande VERIFY PIN)
- Authentification par un mécanisme de challenge (commandes GET CHALLENGE et EXTERNAL AUTHENTICATE)
- Authentification des données par un mécanisme de signature
- Chiffrement des données

Les commandes APDU ISO 7816-4

Les commandes APDUs (Application Protocol Data Unit) contiennent soit une message de requête, soit un message de réponse à une précédente requête.

Il existe quatre type d'APDUs :
- Cas 1 : pas de données dans la requête, pas de données dans la réponse
- Cas 2 : pas de données dans la requête, données présentes dans la réponse (ordre sortant)
- Cas 3 : données dans la requête, pas de données dans la réponse (ordre entrant)
- Cas 4 : données dans la requête, données dans la réponse (ordre entrant / sortant)

Une requête APDU comprend deux parties :
- un en tête (header) de 4 octets : CLA INS P1 P2
- un corps de commande optionnel (body), de longueur variable

Un APDU est représenté symboliquement sous la forme :
CLA INS P1 P2 [Lc 1 à 3 octets] [Data] [Le 0 à 3 octets]

Lc indique la longueur des données entrantes (du point de vue de la carte)
Le (optionnel) indique la longueur maximale de la réponse

La représentation des quatre types d'APDUs est en conséquence la suivante :
- Cas 1 : CLA INS P1 P2
- Cas 2 : CLA INS P1 P2 Le
- Cas 3 : CLA INS P1 P2 Lc Data
- Cas 4 : CLA INS P1 P2 Lc Data Le

La réponse comprend deux parties : une liste d'octets optionnels (body) et un mot de statut (trailer) comportant deux octets SW1 SW2 :
[liste d'octets optionnels] SW1 SW2
Le statut "90 00" indique une exécution correcte de la commande. En règle générale SW1 indique l'état de la carte, SW2 fournit des informations additionnelles.
- SW1=61 : pas de problème
- SW1=62 ou 63 : avertissement
- SW1=64 ou 65 : erreur d'exécution
- SW1=67 : longueur incorrecte

Quelques commandes de base

READ_BINARY
CLA B0 P1 P2 Le
Réalise la lecture de Le octets à partir d'un offset dans un fichier transparent.
• Si le bit de poids fort de P1 est égal à 1, l'EF est désigné par les 5 bits de poids faible, P2 représente l'offset
• Sinon l'offset est égal à (256*P1)+P2

WRITE_BINARY
CLA D0 P1 P2 Lc [Lc octets]
Réalise l'ecriture de Le octets à partir d'un offset dans un fichier transparent (opération OU avec les données déjà présentes).
• Si le bit de poids fort de P1 est égal à 1, l'EF est désigné par les 5 bits de poids faible, P2 représente l'offset
• Sinon l'offset est égal à (256*P1)+P2

UPDATE_BINARY
CLA D6 P1 P2 Lc [Lc octets]
Réalise l'écriture de Le octets à partir d'un offset dans un fichier transparent (remplacement des données déjà présentes).
• Si le bit de poids fort de P1 est égal à 1, l'EF est désigné par les 5 bits de poids faible, P2 représente l'offset
• Sinon l'offset est égal à (256*P1)+P2

READ_RECORD
CLA B2 P1 P2 Le
Réalise la lecture d'un enregistrement dans un fichier linéaire.
• P1 indique le numéro d'enregistrement ou du premier enregistrement, 00 indique l'enregistrement courant
• P2=04 indique le fichier courant, P1=05 indique la lecture des enregistrements à partir de P1 jusqu'à la fin du fichier

WRITE_RECORD
CLA D2 P1 P2 Lc [Lc octets]
Réalise l'écriture d'un enregistrement dans un fichier linéaire (opération OU avec les données déjà présentes).
• P1 indique le numéro d'enregistrement, 00 indique l'enregistrement courant
• P2=04 indique le fichier courant

APPEND_RECORD
CLA E2 P1 P2 Lc [Lc octets]
• Pour P1=P2=00, cette commande ajoute un nouvel enregistrement à la fin d'un fichier linéaire ou réalise l'écriture du premier enregistrement d'un fichier cyclique.

UPDATE_RECORD
CLA DC P1 P2 Lc [Lc octets]
Réalise la mise à jour d'un enregistrement (remplacement des données déjà présentes).
• P1 indique le numéro d'enregistrement, 00 indique l'enregistrement courant
• P2=04 indique le fichier courant

GET_DATA
CLA CA P1 P2 Le
Cette commande permet d'obtenir un objet identifié par son tag (P1 P2) dans le contexte courant (par exemple le DF sélectionné ou relatif à une implémentation particulière).

PUT_DATA
CLA DA P1 P2 Lc [Lc octets]
Cette commande insère un objet dans le contexte courant (DF sélectionné ou relatif à une implémentation particulière).
• P1 P2 désigne le type (tag) de l'objet

SELECT_FILE
CLA A4 P1 P2 Lc [Lc octets] [Le (ou omis)]
Sélectionne un répertoire ou un fichier.
• P1=00 indique la sélection par identifiant de MF, DF, EF
• P1=01 indique la sélection d'un DF
• P1=02 indique la sélection d'un EF
• P1=03 indique la sélection du père du DF courant
• P2=00 indique la première occurrence

VERIFY PIN
CLA 20 P1 P2 Lc (ou omis) [Lc octets]
Cette commande réalise la vérification d'un mot de passe (PIN).
Le nombre d'essai peut être limité.
• En général P1=P2=00

INTERNAL_AUTHENTICATE
CLA 88 P1 P2 Lc [Lc octets] Le
Cette commande réalise un calcul d'authentification relativement à une clé interne en transférant un nombre aléatoire (challenge) délivré par le lecteur.
• P1 représente la référence d'un algorithme
• P2=00 par défaut
• Le challenge est contenu dans les Lc octets sortants

EXTERNAL_AUTHENTICATE
CLA 88 P1 P2 Lc [Lc octets] Le
Cette commande met à jour l'état d'une carte en fonction du résultat d'un calcul réalisé par le lecteur à partir d'un nombre aléatoire délivré par la carte (challenge).
• P1 indique la référence d'un algorithme
• P2=00 par défaut

GET_CHALLENGE
CLA 84 P1 P2 Le
Cette commande produit un nombre aléatoire de Le octets.








Additional Hints (No hints available.)