IDsat
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.
IDsat


 
AccueilPortailRechercherDernières imagesS'enregistrerConnexion
Le Deal du moment :
ETB Pokémon Fable Nébuleuse : où ...
Voir le deal

 

 Mediaguard -> Etude de la codification

Aller en bas 
AuteurMessage
Fondateur

Fondateur


Nombre de messages : 670
Date d'inscription : 05/10/2006

Mediaguard -> Etude de la codification Empty
MessageSujet: Mediaguard -> Etude de la codification   Mediaguard -> Etude de la codification EmptySam 21 Avr - 8:38

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
Revenir en haut Aller en bas
https://idsat.probb.fr
 
Mediaguard -> Etude de la codification
Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» Videoguard -> Etude de la codification
» Mediaguard

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
IDsat :: *** Systèmes de Cryptages *** :: Seca II-
Sauter vers:  
Ne ratez plus aucun deal !
Abonnez-vous pour recevoir par notification une sélection des meilleurs deals chaque jour.
IgnorerAutoriser