ETUDE DE LA CODIFICATION 1/3
ATR d'une carte SECA
Format général de l'ATR (Anglais: „Answer To Reset", réponse au reset = la carte s'annonce au système avec ses spécifications):
3B F7 11 00 01 40 96 xx xx xx 0E 6C B6 D6 90 00
La norme ISO 7816 nous permet de nous y retrouver (en anglais dans le texte):
TS: 0x3B direct convention
T0: 0xF7 TA1, TA2, TA3, TA4 are transmitteds,;
7 historical characters
TA1: 0x11 FI (clock rate conversion factor) = 1 (372à min. 1 MHz to max. 5
MHz à use 3,579 MHz);
DI (bit rate adjustment factor) = 1
TB1: 0x00 II (maximum programming current) = 0 (25 à max. 25 mA);
PI1 (programming voltage) = 0 volt (no VPP [programming voltage input]) à indicates that VPP is connected in the card which generates an internal programming voltage from VCC [power suply input]

TC1: 0x01 N (extra guard time) = 1
TD1: 0x40 protocol T = 0 (asynchronous half duplex character transmission
protocol);
no TCK (check charakter);
TC2 is transmitted
TC2: 0x96 not specified in ISO, but used as guard time extension
- the following 7 bytes (T1-T7) are the historical characters
Les xx sont variables, mais ne doivent pas être différends. Cela signifie que l'ATR ne permet pas d'identifier le propriétaire de la carte. Les 90 00 sont des octets de statut (voir: „Octets de Statut"), et n'appartiennent pratiquement plus à l'ATR.
La carte SECA connaît trois modes de fonctionnement. L'ATR est différent dans chaque mode.
1 - mode de programmation haut (High Program fashion-HPM)
EFFC-EFFF sont égaux à 7F4F-7F52
L'ATR se termine par: A5 96 58 7C
Les possibilités: Changement du numéro de série, création du provider SECA avec ses clés.
2 - Le mode de programmation basse (Low Program fashion-LPM)
EFFC-EFFF sont égaux à 7F57-7F5A
L'ATR se termine par:: 9B 1B C2 A3
3 - Le mode utilisateur (Normal mode - NM)
EFFC-EFFF sont égaux à 7F53-7F56
L'ATR se termine par: 0E 6C B6 D6
C'est grâce à une caractéristique de la carte, qui permet des modifications de l'EEPROM dans cette zone que l'on pourra peut-être changer de mode de programmation, la recherche à ce sujet n'est cependant pas terminée. En fonction du mode de programmation de la carte, certaines instructions ne sont pas permises (Protégées), on obtient alors 6D 00, comme si cette instruction n'existait pas.
__________________________________________________ _________________
__________________________________________________ _________________
1.2 Clés
L'algorithme SECA se base sur un mot de 8 octets chiffré, (anglais: " crypted " ou
"encrypted" ControlWord [CW]), ce qui avec une clé de 16 octets permet d'obtenir
un mot de 8 octets déchiffré, (anglais: "decrypted"ou " plain ControlWord ").
Pour ceci on utilise les clés opérationnelles. Cet Algorithme est connu, la signature
peut être calculée et la Surencryption, (voir instruction 0x40), être utilisée. Ces
explications nous mèneraient trop loin, la procédure est disponible à la lecture dans le texte "Médiaguard Musings" de John MacDonald.
Les 16 octets de la clé sont divisés en une Clé Primaire, (PK) de 8 octets, et une
Clé Secondaire, (SK) de 8 octets. La Clé Secondaire et la Clé Primaire PEUVENT
être égales. Les PK et SK sont numérotées de 0x00 à 0x0F et nous avons donc 16
clés possibles.
Les Clés 0x0C à 0x0E sont les clés de décodage (CD). La Clé 0x0F paraît avoir une fonction spéciale. Les Clés 0x00 à 0x0B sont les clés de management (MK).
Nous ferons une distinction entre clés SECA et clés de Provider. Par la subdivision
en clés SECA et clés de provider une structure hiérarchique a été créée: chaque
provider peut changer uniquement ses propres données. Pour les opérations allant
au-delà de cela, comme justement l'ajout ou l'effacement de provider, une clé
SECA est nécessaire.

La clé SECA 0x00 est nécessaire pour chaque opération importante sur la carte,
comme l'effacement ou l'ajout de provider (diffuseurs de programme). Cette clé est
différente pour chaque carte et peut aussi être utilisée pour activer/annuler une carte.

La clé SECA 0x01, (67 67 05 45 0C DB F2 E1) est identique pour toutes les
cartes, indépendamment du fournisseur de la carte. Elle n'existe pas sur toutes les
cartes (par exemple elle n'existe plus sur les cartes Canal Satellite Numérique France [CSN], et est effacée à la mise en service de la carte.
Contrairement à la clé SECA 0x00 qui est unique pour chaque carte, on peut
transformer presque toutes les cartes avec la clé 0x01 au moyen d'EMM-G,
(voir instruction 0x40) !
Ce qui est valable pour les utilisateurs normaux ne l'est pas pour les cartes MOSC! (Modified Original Smart Cards).a l'aide de nos propres logiciels, avec n'importe quelle MK, et à l'aide d'INS 40, on peut rajouter une clé 0x01 ou ajouter ou retirer un provider!
La clé provider 0x00 est utilisée pour les jetons ou les event PPV . Le provider Canal Satellite digital España CSD affecte une nouvelle SA à ses cartes apparemment tous les deux mois. Avec la clé provider 0x00 la carte reçoit alors la nouvelle PPUA, une nouvelle clé provider 0x01 et les clés de décodage actives.
La clé provider 0x01 est extrêmement importante. Celle-ci est affectée à un groupe de cartes et sert à la mise à jour des clés de décodage. Avec la bonne clé 0x01 ainsi qu'avec un PPUA valide le provider envoie l'ordre C1 40 XX 81 4E avec lequel les clés sont mises à jour par Surencryption. Les données sont déchiffrés avec la clé 0x01 et on récupère les clés de décodage actives qui sont ensuite écrites sur la carte. Nous appellerons ce processus Autoupdate. Si on réussit à modifier une carte, pour qu'elle soit traitée par les provider comme un carte d'abonné régulière elle sera actualisée constamment. Une possibilité d'avoir une carte autoupdate serait ainsi le changement de PPUA et de MK1 d'une carte épuisée Si celle-ci est écrite correctement à l'endroit souhaité, on reçoit les mises à jour de clés (voir plus haut).

J'ai anticipé quelque peu dans ce chapitre, tous les processus cités sont expliqués plus loin dans le texte (voir instructions 0x0E, 0x12, 0x40).
Une autre clé à mentionner est la clé provider 0x02. Elle permet une phase de test d'abonnement (le temps d'essai est dépendant du provider) avec toutes les options activées. Ceci n'existe pas chez tous les provider ou est en cours de disparition. Elle est aussi effacée à l'initialisation de la carte. Sur le bouquet Canal+ NL des chaînes de commandes codées avec la MK02 sont émises qui effacent toutes les MK sauf la MK00.
Les nouvelles cartes possèdent une clé provider 0x03, qui n'a toujours pas été utilisée.
Si les clés sont stockés sur la carte en usine, le cinquième bit (de 0x10) est positionné. Les clés primaires sont stockées sur la carte de 0x10 à 0x1F, Elles sont numérotées ainsi (à partir de 0x10) si le cinquième bit est positionné. Nous verrons plus loin ce que "bit positionné" signifie.
Les clés sont stockées ainsi:
Si les clés primaires et secondaires sont stockées sur la carte, la clé primaire se nomme F0 par exemple (ici MK0x00) et la clé secondaire se nomme 50.
S'il n'y a que la clé primaire sur la carte, il lui est attribué l'index 5C par exemple.
Lors de l'utilisation éventuelle de clés de 16 octets, il serait probablement procédé de façon identique (par exemple FC comme clé primaire et 5C comme clé secondaire).
Une chose importante à noter: une carte en mode de programmation basse exige une clé 5X et en aucun cas une clé FX. Dans le LPM, la carte n'accepte aucune commande avec des clefs dont le bit 7 est mis (statut: 90 22), donc toujours utiliser de clefs de type 5X!
Résumé:
Actuellement, les clés de décodage utilisées par les providers courants (à l'exception par exemple de l'INS 0x40 d'AB SAT avec P1 = 82 qui utilise une clé primaire + une clé secondaire) sont des clés sur 8 octets, juste répétées deux fois, comme clé primaire et comme clé secondaire pour obtenir les 16 octets. Il serait aussi possible pour les providers d'utiliser des clés primaires et secondaires différentes. Sur les cartes, les clés de management disponibles sont déjà sur 16 octets en général.
Avec MOSC, nous pouvons changer bien sûr n'importe quand une commande afin qu'elle utilise seulement une clé sur 8 octets plus facile à manipuler.
L'utilisation des clés stockées sur la carte par les instructions est réglée par les valeurs des paramètres P1 et P2:
Ces explications seront mieux comprises à l'aide de quelques exemples:
a) instruction à la carte: C1 3C 04 0E LEN
Résultat:
La clé primaire 0x0E du provider 0x04 est utilisée donc 2 fois à la suite(16 octets).
b) instruction à la carte: C1 3C 14 0E LEN
A la différence de l'exemple précédent, le provider est déclaré dans P1 de la forme P1=0x1n (provider 4, mais au lieu de 04 il est noté 14).
Résultat:
La clé primaire 0x0E et la clé secondaire 0x0E du provider 0x04 sont utilisées, SI la clé primaire est appelée 0x1E et existe, AUTREMENT on utilise deux fois la clé primaire 0x0E, 0x0E.
Nous devons toutefois être un peu plus précis ici. L'instruction 0x3C (voir: instruction 0x3C) peut contenir du texte en clair (excepté les ControlWord) mais un encryptage des données est aussi possible. (voir: L'instruction 0x40, „Surencryption "). Le premier chiffre de P2 est utilisé pour indiquer ceci.
Les instructions 0x3C et 0x40 utilisent les mêmes deux routines au début: " compute_hash () et " decrypt_nanos ()" (L'initialisation du Hash-buffer pour le calcul de signature n'utilise pour le moment que [8*00]).
Le cinquième bit de P1 nous sert d'indicateur.(compté de droite à gauche). S'il est mis (1 au lieu de 0), deux clés différentes sont utilisées. Utilisons la calculatrice de Windows en mode scientifique pour convertir la valeur hexadécimale 14 en binaire par exemple, nous obtenons 10100. Nous voyons que le cinquième bit est mis . Avec la valeur 04 en binaire: 00100 le bit 5 n'est pas mis.
__________________________________________________ _________________

1.3 Structure d'une instruction SECA
Le système SECA connaît trois niveaux de commandes. Il est important de bien distinguer entre ceux-ci :
1. L'instruction (engl. : "instruction") : une fonction, sélectionné grâce à la valeur de l'octet INS (cf. : plus loin dans cette section).
2. La commande (engl. : "command") : une fonction qui se construit avec une valeur déterminée contenue dans le paquet de données envoyé à la carte. Elle fait partie de la construction d'une instruction.
3. Nanocommande ou Nano (engl. : "nanocommand" ou "Nano") : une fonction qui se construit avec une valeur déterminée contenue dans le paquet de données envoyé à la carte. Elle fait partie de la construction d'une commande.
Il est utilisé une structure de header universelle à 5 octets qui respecte la norme ISO 7816.Une instruction SECA a la structure suivante:

CLA INS P1 P2 (I)LEN/P3 DATA 82 SIG
CLA = Octet de classe
La seule classe valide pour SECA est C1.
INS = octet d'instruction
P1 = paramètre ou octet de référence
P2 = paramètre ou octet de référence
ILEN / LEN / P3 = Octet de longueur = Longueur de la chaîne de réponse (hexadécimal!)
DONNÉES = partie de données de l'instruction. Toutes les instructions n'utilisent pas de données (elle peut contenir commandes et Nanos avec leur partie de donnée propre)
82 = Nano 0x82 (suivie de la Signature)
SIG = Signature (si elle existe elle fait 8 octets. Pas nécessaire pour toutes les instructions)
Exemple:
Instruction: C1 3A 00 00 10
CLA=C1; INS=3A; P1=00; P2=00; LEN=10 (Hexa)
Réponse: 3A 01 44 45 50 41 05 44 D4 50 10 50 D6 00 01 51 B2 90 00
Nous voyons que la chaîne de réponse (soulignée) a une longueur de 16 (10hex) octets. Dans toutes les réponses nous trouvons au début l'octet d'instruction aussi appelé octet de confirmation (English: „Acknowledge bytes "). Il ne fait toutefois pas partie intégrante de la chaîne de réponse et n'est pas compté dans sa longueur de la même façon que les octets de statut, 90 00. Un statut de 90 00 signifie que la commande s'est terminée avec succès. Pour plus de précisions, voir la section " Octets de statut ".
L'octet Instruction renvoyé par la carte dans la chaîne de réponse s'appelle l'écho.
Les nombres hexadécimaux seront notés indifféremment: 10h, $10, 0x10, 10hex le nombre décimal correspondant est 16 dans tous ces cas.
Une Nano est construite de la façon suivante: xy = Nano y de longueur x, la longueur des données qui suit une nano fait partie intégrante de sa construction.
Exemple:
Nano 0x04 = Nano 0x4 de Longueur 0x0, n'est suivie d'aucune donnée.
Nano 0x82 = Nano 0x2 de Longueur 0x8, suivie de 8 octets de données.
Les longueurs suivantes sont admissibles:
0 ...C correspondent à 0 ..12 octets,
Les D=16 octets
Les E=24 octets
Les F=32 octets
Nano 0xD1 = Nano 0x1 de longueur 0xD, suivie de 16 octets de données.
Touts les nombres seront donnés en hexadécimal.
__________________________________________________ _________________
__________________________________________________ _________________
1.4 Octets de statut
Ces octets nous donnent une indication, qui n'est d'ailleurs pas nécessairement une erreur. Ces octets de statut sont d'ailleurs extrêmement dépendants de la version de la carte (voir: système d'exploitation de la carte). La V 3.0 ou 4.1 répond bien souvent différemment de la V4.0.
Les octets de statut commençant par 0x6X sont indépendants du système et valables pour toutes les cartes ISO7816. S'il vous arrive d'obtenir une chaîne 0x6X non documentée dans cette FAQ après une exécution, il faudra consulter l'ISO 7816, pour des octets de statut apparaissant rarement.
6700 Mauvaise longueur des données d'entrée
6B00 Paramètre/Octet(s) de référence non correct
6D00 Instruction non supportée / Instruction invalide ou protégée / Instruction non libérée
6E00 Classe d'instruction (Class) non supportée
6F00 Pas de diagnostic précis possible
6281 Données fournies peut-être incorrectes
6282 La fin le fichier était atteinte avant la fin du processus de lecture
6284 Le fichier choisi n'est pas valide
6501 Erreurs de stockage. Problème de Lecture/Ecriture sur l'Eeprom ou autre problème matériel
6800 Fonction non supportée par la carte
6A00 Mauvaise valeur de P1 et/ou de P2
6A80 Paramètre faux dans la partie de données
6A82 Fichier non trouvé
6A83 Enregistrement non trouvé
6A84 Cellules de mémoire insuffisantes dans dossier ou enregistrement
9000 Commande exécutée sans erreur
9002 Signature erronée ou absente
9004 Provider non supporté
9005 Nano réservée à SECA
9006 Ins 0x3C, Nano 0x15/0x19/0x2C: Pas de mémoire pour les Preview records
9007 Provider bloqué (utiliser Nano 02 pour débloquer)
9008 Ins 0x40, Nano 0x01: pas autorisée
9009 Ins 0x40: PPUA pas dans la bitmap F0,
9010 Ins 0x30: mauvais PIN
9011 Le testbit n'est pas à 0 : Instruction non supportée
9013 Ins 0x40: mauvaise clé, seules les MK's sont autorisées
9014 Instruction précédente incorrecte
9015 Ins 0x40, Nano 0x80: non autorisée
9015 Ins 0x3C, Nano 0x2C: non autorisée ou Nano 0x15: non autorisée
9015 Ins 0x32/0x36: donnée d'entrée non supportée
9016 Ins 0x40, Nano 0x87: décodage raté
9016 Ins 0x44: non autorisée
9017 Ins 0x50/0x54/0x56: non autorisée
9018 Provider existe déjà
9019 Ins 0x40, Nano 0x41: PPUA a été changé
901A Ins 0x3C, Nano 0x15/0x2C: achat via Jetons raté
901B Ins 0x3C, Nano 0x15/0x2C: aucun Jetons dispo ou aucun Crédit Record dispo
901C Ins 0x3C, Nano 0x15/0x2C: achat via Jetons ok
901D Clé Primaire inexistante
901E Erreur
901F Clé Secondaire inexistante
9021 Ins 0x04: la clé n'est pas 0x0F - refus
9022 Carte dans le mauvais mode
9024 Erreur de Checksum
9026 Ins 0x3C, Nano 0x31: plus aucun Preview
9027 Ins 0x3C, Nano 0x19: phase de Preview décryptée
9301 Ins 0x40, Nano 0x22/0x27: la date de la carte est au-delà de la date de validité
9302 Ins 0x3C, Nano D1: aucun décodage
9304 Ins 0x3C, Nano 0x12: contrôle parental, niveau trop bas
9305 Ins 0x3C, Nano 0xF1: non valide pour cette zone géographique
9401 Ins 0x32: Valeur de P1 incorrecte
9402 Ins 0x32: Valeur de P2 incorrecte : seule valeur admise : P2 = 0
9402 Ins 0x30: mauvaise valeur de P2.
9600 Ins 0x38: Chaîne d'entrée incorrecte (Nanos incorrectes, signature manquante)
9600 Ins 0x3C: Nano 0x15/0x2C: résultat égal à 0- Nanos traitées avec succès - aucun décodage
960A Index Clés non supportés
96xx Ins 0x3C: xx Nanos traitées, mais aucune Nano 0xD1 trouvée
96xx Ins 0x40: Toutes les Nanos ont été traitées avec succès
97xx Update de l'EEPROM pas nécessaire pour quelque Nanos. xx est le bitmap de ces Nanos, par exemple 3C: aucun Update pour Nano 2, 3, 4, 5 (le comptage commence à 0)
99xx date erronée: les crédits ont été changés aujourd'hui
99xx date erronée
__________________________________________________ _________________
__________________________________________________ _________________
1.5 Format de dates
Certaines commandes utilisent la date. Elle est encodée sous forme de bits. La date peut valoir de 01.01.1990 à 31.12.2118. Les bits sont lus de la gauche à droite:
7 bits codent l'année. A ce nombre il convient d'ajouter 1990.
4 bits codent le mois, avec 1= Janvier.
5 bits codent le jour du mois
Exemple:
Nous aurons à nouveau besoin de la calculatrice de Windows en mode scientifique!
Après une Instruction 0x12 nous obtenons cette chaîne:
12 00 04 43 41 4E 41 4C 53 41 54 45 4C 4C 49 54 45 20 20 00 1A 0C 34 0E FF 90 00
La date de fin d'abonnement est 0E FF. Entrons cette valeur dans la calculatrice en mode hexadécimal (entrons simplement EFF) et transformons ce nombre en binaire. Nous obtenons 111011111111, un nombre sur 12 bits. Nous savons que la date est toujours sur 16 bits et nous complétons donc avec 4 zéros positionnés à gauche de notre nombre: 0000111011111111 et nous le séparons comme indiqué ci-dessus :
0000111 (7 bits pour l'année), 0111 (4 bits pour le mois), 11111 (5 bits pour le jour). Nous transformons maintenant séparément ces nombres binaires en décimal (ne pas oublier d'ajouter 1990 pour l'année !) et nous obtenons la date suivante: 31.07.1997.
Le programme dDate pour IRDETO ne peux pas fonctionner ici!

1.6 EEPROM
Zone Octets Contenu
EFFC-EFFF 4 Octets historiques de l'ATR (suivant le mode de la carte)
EFF4-EFFB 8 Numéro de série de la carte + 2 octets
EFF4-EFF5 2 2 octets pour les calculs de Hash
EFF6-EFFB 6 Numéro de Série
E208-EFF3 3564 Zone des records: 297*12
E064-E207 420 zone pour 15 Providers: 15 * 28 = 420 =0x1a4
-------------------------
Sous-total 3984 = 0x0f90: Effacés par l'INS 0x0C avec P2=1
E040-E063 36 Enregistrement (SECA, Fournisseur 00)
E05C-E063 8 INS 0x40 Nano 0x03, INS 0x30 - 6 octets 00 + 2 PIN
E05B 1 PIN Statut, édition avec INS 0x16
E059-E05A 2 Bitmap des providers supportés, éditions avec 0x16
E020-E03F 32 Bitmap des nanos autorisées avec INS 0x44,
édition avec INS 0x44
E01B-E01F 5 vide
E01A 1 drapeaux de protection INS 0x56;Valeurs possibles:
00,55,FF, positionné par INS 0x40 Nano 1D
E019 1 drapeau de protection INS 0x50,0x54; Valeurs
possibles: 00,55,FF, positionné par INS 0x40 Nano 1F ;
E018 1 drapeau de protection INS 0x56,0x54;Valeurs
possibles: 00,55,FF, positionné par INS 0x40 Nano 1E ; Edition des drapeaux E018, E019 par INS 0x4A octets 33 + 34
E010-E017 8 Clés Système
E008-E00F 8 vide
E000-E007 8 non disponibles: tout à 00; Edition par INS 0x0A
----------------
Total 4096 = 4KB EEPROM

4.18 format de la date

Différents commandements utilisent la date. Et' codifiée au bit et il peut assumer valeurs de 01.01.1990 jusqu'à

31.12.2118. Les bits doivent être lus par droite vers la gauche.

7 bits contiennent l'an. au numéro obtenu il doit être additionné 1990.

4 bits contiennent le mois. 1 stà pour janvier

5 bits contiennent le jour du mois

Exemple:

Après un istrizione 0x12 nous obtenons un lacet du type:

12 00 04 43 41 4E 41 4C 53 41 54 45 4C 4C 49 54 45 20 20 00 1A 0C 34 0E FF 90 00

La date codifiée pour la fin de l'abonnement est 0E FF. Si nous convertissons en voie le deux byte nous obtenons

111011111111, 12 bits. La date est composée de 16 bits de toute façon, donc nous ajoutons les zéros manquants et

nous obtenons 0000111011111111.

les 7 bits sont ensuite: 0000111 (an)

4 bits sont: 0111 (mois)

5 bits sont: 11111 (jour)

En convertissant en chiffre décimal les numéros obtenus on obtient 31.07.1997.





ps:ces pas du seca2 mais sa permet de comprendre certaine chose.@+