sam_
DZSatien V.I.P
- Inscrit
- 12/11/10
- Messages
- 1 144
Hello tutti. Je me permets de reposter la documentation pour la compréhension des ECMs histoire que ce ne soit pas perdu dans les lymbes. Pour ceux que ça intéresse, je posterai au fur et à mesure.
Bonne lecture.
Introduction.
Ce document est une tentative, sans la prétention d'être un document exhaustif, de
collecte et de réorganisation de divers postes et sujets existants, sur le NET, sur le Seca2.
Pour la compréhension du ce document, il est nécessaire de connaître le fonctionnement
du système SECA1. Pour les débutants lisez les divers documents disponibles sur la toile.
Tout ce qui est écrit dans ce document sert exclusivement à la recherche et à l'étude
ludique.
La vision des chaînes cryptées sans abonnement est une infraction punissable par la loi.
L'auteur n'est pas responsable des dommages éventuels ou des abus qui pourraient être
occasionné par l’utilisation détournée de document
Avant d’exposer quoi que ce soit et pour clarifier le tout, nous allons définir les termes les plus
importants qui seront utilisés dans cette FAQ. J’utiliserais, autant que possible, une
nomenclature informatique acceptée de tous.
Le Bit.
Un bit est tout d'abord la plus petite unité information utilisée en informatique, il ne peut avoir que la
valeur de 0 ou de 1.
Le Quartet ou NIBBLE
Le Quarte vaut 4 bits dans une écriture en hexadécimal il représente une des deux parties. Le quartet
fort se trouve à gauche par exemple ici FA ( FA 51) le quartet faible se trouve à droite ici 51
L’ Octet ou BYTE
Un octet comporte 8 bits.
Le Mot ou WORD
Un mot est formé de deux octet, soit de 16 bits.
Le Double Mot ou DWORD
Le double mot, regroupe 4 octets, ou encore deux mots, soit un total de 32 bits.
Le Triple Mot ou FWORD
Le triple mot, regroupe 6 octets, ou encore trois mots, soit un total de 48 bits.
Le Quadruple Mot ou QWORD ou OTTETTO (pour les italiens et les espagnols)
Le quadruple mot, regroupe 8 octets, ou encore quatre mots, soit un total de 64 bits.
Pour ma part j’utiliserais le plus souvent la nomenclature française, celle que j’ai mis en rouge, sauf
lorsque le terme anglais utilisé sera devenu, au fil de la FAQ, courant .
Bonne lecture et bonnes études à tous, ça va être passionnant.
Nouveauté du système dit SECA2 (Médiaguard V1+)
En partant du LOG d’une ECM, il est possible d’établir les premiers caractères du nouveau système :
C1 3C 01 BE 5C
10 01 CD 99 F1 E7 88 F1 E9 00 50 F9 09 5B 02 43
DD 03 35 39 1B C2 41 97 AF B3 8A A7 F7 9A FA 78
12 C9 BA 23 16 42 99 0E 9A F3 31 72 22 BC B8 C6
62 45 37 F9 7F 68 15 7C BB 7C A7 F2 3D F8 27 82
52 49 54 56 98 0C AB 94 26 95 74 A7 12 B6 83 4D
23 46 03 F1 E1 A5 66 31 05 96 46 48 [90 00]
Entre deux ECM tous les octets changent à l’exception de ceux qui sont mis en évidence (ceux en
bleu), après eux plus rien de reconnaissable, plus de NANO, pas de trace de la signature.
La raison en est que les données ont étés cryptées.
Il est désormais notoire que sont présents en SECA2, deux passages de cryptage : la
SUPERENCRYPTION (qui opère sur des blocs d’octets) et la SECONDARY SUPERENCRYPTION
(SSE ou ENVELOPPE) qui agit sur l’ensemble des données.
Ces procédés de cryptage sont obligatoires pour les données des instructions C1 3C/38/40.
L’algorithme utilisé pour l’enveloppe n’est pas connu, même si on a émit comme hypothèse un
(dé)cryptage du type RSA (pour ceux que ça intéressent, il existe sur la toile, beaucoup de documents
sur l’argument), la SUPER-ENCRYPTION est elle, constituée du même algorithme que celui utilisé
par le SECA1, auquel on a ajouté un procédé de masquage des octets.
************************************************************************************************************************************
SUPER-ENCRYPTION (SECA1)
On prend le corps de l’instruction et on subdivise en blocs de 8 octets, à chaque bloc on
applique l’algorithme de cryptage avec la clé indiquée par P2. Les derniers octets qui ne
peuvent pas former un bloc de huit octets, ne sont pas cryptés et restent donc en clair.
Pour exemple si vous avez dans une trame, un corps de 34 octets à crypter, vous aurez 4 blocs
de huit octets (32 octets) qui seront cryptés et deux octets (les deux derniers du corps) qui
resteront en clair.
************************************************************************************************************************************
L’obligation d’utiliser la SUPER-ENCRYPTION est fixée par le contenu de certains flags qui sont
mémorisés dans l’EEPROM. Actuellement nous n’avons aucun procédé de modification de ces flags
La Structure des instructions C13C/38/40
La norme ISO7819 régissant le SECA1 à été maintenue :
C1 38/3C/40 P1 P2 LEN + PAQUET DE DONNEES
• P1 : sur 1 octet de deux quartets organisés de la façon suivante :
Composition de l’octet de P1 XY
X quartet fort bit 7 6 5 4
Y quartet faible bit 3 2 1 0
Le quartet faible (3210) (LOW NIBBLE)
Bit de 0 à 3 : index du PROVIDER à qui on envois l’instruction, nous avons en effet la possibilité
d’allez jusqu’à 1111 (binaire) soit F en hexadécimal 16 providers gérables Seca (0) compris
Le quartet fort (7654) (HIGH NIBBLE)
Bit 4 : utilisation de la clef primaire bit à (0) ou de la clef primaire et secondaire bit à (1)
Bit 5 et 6 : indique comment initialiser le hash buffer pour le calcul de la signature.
Bit 7 : pas utilisé
• P2 : sur un octet de deux quartets organisé de la façon suivante :
Composition de l’octet de P2 VZ
V quartet fort bit 7 6 5 4
Z quartet faible bit 3 2 1 0
Le quartet faible (3210) (LOW NIBBLE)
Bit de 0 à trois : index de la clef à utiliser pour le décryptage, nous avons donc en théorie la
possibilité d’utiliser 16 clés, 1111 (binaire) maximum soit 0F (hexadécimal), soit 16 (décimal)
Le quartet fort (7654) (HIGH NIBBLE)
Bit 4 : signification inconnue doit être à 1
Bit 5 et 6 : sélectionne les tables et éventuellement le user Algo (pas actif sur V7)
Bit 7 : si la trame est sur-encryptée ou pas ; 1 sur-encrypt et 0 pas sur-encrypt pour le seca2 il
doit être à 1.
• LEN : le nombre d’octets du paquet de données (on commence le calcul juste après l’octet de
la LEN)
Exemple de LEN 5C (hexadécimal = 92 octets en vert) :
C1 40 01 B1 5C
10 01 12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A
EB A5 B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A
05 4F AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44
E3 BA 45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1
1F 40 F4 50 D1 57 D0 96 88 5B EB 93 2A 10 CE E8
4D 36 1F 80 A7 65 A6 9C 3E 03 78 49
Nous avons déjà fait allusion aux deux octets mis en évidences (en bleu) qui sont identiques pour
toutes les INS loggués, ils constituent des paramètres pour la DE-ENVELOPPE et sont gérés de
façon différentes par rapport aux autres données. On leur a donnés comme définition de paramètre
P3 et P4, à l’intérieur du paquet de données nous avons un paramètre supplémentaire qui n’est pas
visible car crypté.
Sa fonction sera expliquée par la suite, pour l’instant il suffit de savoir qu’il existe, qu’il correspond au
dernier octet et qu’il à été défini comme paramètre P5.
A la lumière de tout cela nous pouvons donner une nouvelle représentation de la structure de l’INS :
CLA INS P1 P2 LEN P3 P4 +paquet de données+ P5
Processus d’exécution des INS
Dans les grandes lignes nous devrions avoir cette séquence logique (et temporelle) :
1 – Contrôle normal sur le protocole ISO7816 CLA/INS/LEN (possible erreur statut 6D00, 6E00,
6700)
2 – Contrôle sur P1, présence du Provider (statut 9004 si inexistant)
3 – Contrôle sur bit 4 de P2 (doit être = 1, statut 9024 dans le cas contraire)
4 – Contrôle sur bit 0 de P4 (doit être = 1, statut 9024 dans le cas contraire)
******************************************************************************************************************************
Le traitement réservé à P3 est similaire à celui d’une NANOCOMMANDE mais :
1 - Doit avoir comme valeur minimum 10 (statut 9024 pour des valeurs inférieures)
2 - Il est complètement ignorer, avec les données auquel il est associé, pour les procédures
suivantes :
Décryptage SSE (DE-ENVELOPPE) et décryptage SE
• PARSING et exécution (Nous entendons par PARSING (littéralement analyse de la
• Période) dans notre contexte c’est l’examen des NANOCOMMANDES et de leurs
paramètres.
3 - Fait partie des données pour le calcul de la signature.
4- P4 est le premier octet de donnée pour P3.
Pour savoir le nombre d’octets associé à P3, nous suivons le tableau classique des LEN
Exemple:
NANO 0x04 = NANO 0x4 de Longueur 0x0, n’est suivie d’aucunes données.
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 (IMPORTANT le 0 n’est pas une valeur admissible pour P3)
Les F=32 octets
NANO 0xD1 = NANO 0x1 de longueur 0xD, suivie de 16 octets de données.
Tous les nombres seront donnés en hexadécimal.
******************************************************************************************************************************
Au terme de ce contrôle, nous pouvons obtenir le statut 6700 (Mauvaise longueur de données ) si
après les donnée de P3, il n’y a pas au moins 0x5A (90 décimal) octets de données, nous
expliquerons le motif plus en avant.
6 – Contrôle sur bit 1,2 de P4 (doivent être = 0, statut 9036 dans le cas contraire)
P4 est un indicateur pour le DE-ENVELOPPE mais sa fonction précise est encore inconnue
NOTE :
Pour les réponses suivantes, les octets de statut ne justifie pas la séquence de
1 à 6 …….. :
C1 38 01 91 00 Statut prévu : 9024 Statut obtenu : 9036
C1 38 01 91 01 19 Statut prévu :6700 Statut obtenu : 9036
7 – Décryptage SSE (ou de-enveloppe)
Bien que l’algorithme ne soit pas connu, on a pu observer qu’il utilisait des clés différentes pour
chaque fournisseur d’accès (mais les mêmes clés pour toutes les cartes d’un fournisseur d’accès) et
qu’il opère toujours et seulement sur les derniers 0x5A octets de données.
Les conséquences sont :
- Une ECM/EMM adressée à un fournisseur d’accès n’est pas applicable à un autre fournisseur
d’accès.
- Les données de P3 (données qui ne sont pas partie prenante au de-enveloppe) doivent être
suivies d’au moins 0x5A d’octets (voilà expliqué le pourquoi de 6700 pendant le contrôle sur
P3)
- Les éventuels octets ajoutés entre les données de P3 et les dernier 0x5A octets ne sont pas
dans la SSE/ENVELOPPE (IMPORTANT)
Exemple : Note : aucun des exemples
Ne viennent de LOG
C1 40 01 B1 6A réels
43 51 6E B1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A EB A5
B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A 05 4F
AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44 E3 BA
45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1 1F 40
F4 50 D1 57 D0 96 88 5B EB 93 2A 10 E8 4D 36
1F 80 A7 65 A6 9C 3E 03 78 49
Dans cette instruction, les octets mis en évidence en bleu représente P3 et ses données relatives (le
quartet fort de P3 = 4, donc nous avons 4 octets de données qui le suivent.
Ceux mis en évidence en bleu clair représente les 0x5A sous De-Enveloppe, les autres (ceux qui sont
sur fond blanc) sont en dehors de l’enveloppe et donc sont en clair ou en SUPER-ENCRYPTION.
Que trouvons-nous sous la DE-ENVELOPPE ?
On note immédiatement une grosse différence par rapport à SECA1 : la signature est en dehors de la
SUPER-ENCRYPTION et n’a pas de position fixe. Reprenons l’instruction précédente et faisons une
hypothèse sur une de-enveloppe possible :
C1 40 01 B1 6A
43 51 6E B1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD
A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71
54 9F 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 P5
P5 est maintenant en clair
Nous pouvons voir P3 avec ses données (en bleu) suivit des octets cryptés en SUPERENCRYPTION
(en vert ; il est important de rappeler que la partie soulignée, n’a pas subit de deenveloppe),
après est présente la NANO82 + la signature en clair, le reste ne sont que des octets de
remplissage jusqu’à l’avant dernier octet (compris).
L’instruction se termine par le paramètre P5, Celui-ci a comme fonction d’indiquer la position de la
NANO 82, cela signifie que la carte ne recherche pas la signature en scannant toute la chaîne de
commande mais qu’il va directement à la position pointée par P5.
Nous en déduisons deux informations supplémentaires sur la position de la NANO 82
- La signature est longue de huit octets, il n’est donc pas admissible que la NANO 82 puisse
être dans les 8 dernières positions de la chaîne de commande.
- Les données pour le calcul de la signature doivent être au moins 8, en d’autre mots, la NANO
82 doit être précédée d’au moins 8 octets.
...
Bonne lecture.
Introduction.
Ce document est une tentative, sans la prétention d'être un document exhaustif, de
collecte et de réorganisation de divers postes et sujets existants, sur le NET, sur le Seca2.
Pour la compréhension du ce document, il est nécessaire de connaître le fonctionnement
du système SECA1. Pour les débutants lisez les divers documents disponibles sur la toile.
Tout ce qui est écrit dans ce document sert exclusivement à la recherche et à l'étude
ludique.
La vision des chaînes cryptées sans abonnement est une infraction punissable par la loi.
L'auteur n'est pas responsable des dommages éventuels ou des abus qui pourraient être
occasionné par l’utilisation détournée de document
Avant d’exposer quoi que ce soit et pour clarifier le tout, nous allons définir les termes les plus
importants qui seront utilisés dans cette FAQ. J’utiliserais, autant que possible, une
nomenclature informatique acceptée de tous.
Le Bit.
Un bit est tout d'abord la plus petite unité information utilisée en informatique, il ne peut avoir que la
valeur de 0 ou de 1.
Le Quartet ou NIBBLE
Le Quarte vaut 4 bits dans une écriture en hexadécimal il représente une des deux parties. Le quartet
fort se trouve à gauche par exemple ici FA ( FA 51) le quartet faible se trouve à droite ici 51
L’ Octet ou BYTE
Un octet comporte 8 bits.
Le Mot ou WORD
Un mot est formé de deux octet, soit de 16 bits.
Le Double Mot ou DWORD
Le double mot, regroupe 4 octets, ou encore deux mots, soit un total de 32 bits.
Le Triple Mot ou FWORD
Le triple mot, regroupe 6 octets, ou encore trois mots, soit un total de 48 bits.
Le Quadruple Mot ou QWORD ou OTTETTO (pour les italiens et les espagnols)
Le quadruple mot, regroupe 8 octets, ou encore quatre mots, soit un total de 64 bits.
Pour ma part j’utiliserais le plus souvent la nomenclature française, celle que j’ai mis en rouge, sauf
lorsque le terme anglais utilisé sera devenu, au fil de la FAQ, courant .
Bonne lecture et bonnes études à tous, ça va être passionnant.
Nouveauté du système dit SECA2 (Médiaguard V1+)
En partant du LOG d’une ECM, il est possible d’établir les premiers caractères du nouveau système :
C1 3C 01 BE 5C
10 01 CD 99 F1 E7 88 F1 E9 00 50 F9 09 5B 02 43
DD 03 35 39 1B C2 41 97 AF B3 8A A7 F7 9A FA 78
12 C9 BA 23 16 42 99 0E 9A F3 31 72 22 BC B8 C6
62 45 37 F9 7F 68 15 7C BB 7C A7 F2 3D F8 27 82
52 49 54 56 98 0C AB 94 26 95 74 A7 12 B6 83 4D
23 46 03 F1 E1 A5 66 31 05 96 46 48 [90 00]
Entre deux ECM tous les octets changent à l’exception de ceux qui sont mis en évidence (ceux en
bleu), après eux plus rien de reconnaissable, plus de NANO, pas de trace de la signature.
La raison en est que les données ont étés cryptées.
Il est désormais notoire que sont présents en SECA2, deux passages de cryptage : la
SUPERENCRYPTION (qui opère sur des blocs d’octets) et la SECONDARY SUPERENCRYPTION
(SSE ou ENVELOPPE) qui agit sur l’ensemble des données.
Ces procédés de cryptage sont obligatoires pour les données des instructions C1 3C/38/40.
L’algorithme utilisé pour l’enveloppe n’est pas connu, même si on a émit comme hypothèse un
(dé)cryptage du type RSA (pour ceux que ça intéressent, il existe sur la toile, beaucoup de documents
sur l’argument), la SUPER-ENCRYPTION est elle, constituée du même algorithme que celui utilisé
par le SECA1, auquel on a ajouté un procédé de masquage des octets.
************************************************************************************************************************************
SUPER-ENCRYPTION (SECA1)
On prend le corps de l’instruction et on subdivise en blocs de 8 octets, à chaque bloc on
applique l’algorithme de cryptage avec la clé indiquée par P2. Les derniers octets qui ne
peuvent pas former un bloc de huit octets, ne sont pas cryptés et restent donc en clair.
Pour exemple si vous avez dans une trame, un corps de 34 octets à crypter, vous aurez 4 blocs
de huit octets (32 octets) qui seront cryptés et deux octets (les deux derniers du corps) qui
resteront en clair.
************************************************************************************************************************************
L’obligation d’utiliser la SUPER-ENCRYPTION est fixée par le contenu de certains flags qui sont
mémorisés dans l’EEPROM. Actuellement nous n’avons aucun procédé de modification de ces flags
La Structure des instructions C13C/38/40
La norme ISO7819 régissant le SECA1 à été maintenue :
C1 38/3C/40 P1 P2 LEN + PAQUET DE DONNEES
• P1 : sur 1 octet de deux quartets organisés de la façon suivante :
Composition de l’octet de P1 XY
X quartet fort bit 7 6 5 4
Y quartet faible bit 3 2 1 0
Le quartet faible (3210) (LOW NIBBLE)
Bit de 0 à 3 : index du PROVIDER à qui on envois l’instruction, nous avons en effet la possibilité
d’allez jusqu’à 1111 (binaire) soit F en hexadécimal 16 providers gérables Seca (0) compris
Le quartet fort (7654) (HIGH NIBBLE)
Bit 4 : utilisation de la clef primaire bit à (0) ou de la clef primaire et secondaire bit à (1)
Bit 5 et 6 : indique comment initialiser le hash buffer pour le calcul de la signature.
Bit 7 : pas utilisé
• P2 : sur un octet de deux quartets organisé de la façon suivante :
Composition de l’octet de P2 VZ
V quartet fort bit 7 6 5 4
Z quartet faible bit 3 2 1 0
Le quartet faible (3210) (LOW NIBBLE)
Bit de 0 à trois : index de la clef à utiliser pour le décryptage, nous avons donc en théorie la
possibilité d’utiliser 16 clés, 1111 (binaire) maximum soit 0F (hexadécimal), soit 16 (décimal)
Le quartet fort (7654) (HIGH NIBBLE)
Bit 4 : signification inconnue doit être à 1
Bit 5 et 6 : sélectionne les tables et éventuellement le user Algo (pas actif sur V7)
Bit 7 : si la trame est sur-encryptée ou pas ; 1 sur-encrypt et 0 pas sur-encrypt pour le seca2 il
doit être à 1.
• LEN : le nombre d’octets du paquet de données (on commence le calcul juste après l’octet de
la LEN)
Exemple de LEN 5C (hexadécimal = 92 octets en vert) :
C1 40 01 B1 5C
10 01 12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A
EB A5 B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A
05 4F AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44
E3 BA 45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1
1F 40 F4 50 D1 57 D0 96 88 5B EB 93 2A 10 CE E8
4D 36 1F 80 A7 65 A6 9C 3E 03 78 49
Nous avons déjà fait allusion aux deux octets mis en évidences (en bleu) qui sont identiques pour
toutes les INS loggués, ils constituent des paramètres pour la DE-ENVELOPPE et sont gérés de
façon différentes par rapport aux autres données. On leur a donnés comme définition de paramètre
P3 et P4, à l’intérieur du paquet de données nous avons un paramètre supplémentaire qui n’est pas
visible car crypté.
Sa fonction sera expliquée par la suite, pour l’instant il suffit de savoir qu’il existe, qu’il correspond au
dernier octet et qu’il à été défini comme paramètre P5.
A la lumière de tout cela nous pouvons donner une nouvelle représentation de la structure de l’INS :
CLA INS P1 P2 LEN P3 P4 +paquet de données+ P5
Processus d’exécution des INS
Dans les grandes lignes nous devrions avoir cette séquence logique (et temporelle) :
1 – Contrôle normal sur le protocole ISO7816 CLA/INS/LEN (possible erreur statut 6D00, 6E00,
6700)
2 – Contrôle sur P1, présence du Provider (statut 9004 si inexistant)
3 – Contrôle sur bit 4 de P2 (doit être = 1, statut 9024 dans le cas contraire)
4 – Contrôle sur bit 0 de P4 (doit être = 1, statut 9024 dans le cas contraire)
******************************************************************************************************************************
Le traitement réservé à P3 est similaire à celui d’une NANOCOMMANDE mais :
1 - Doit avoir comme valeur minimum 10 (statut 9024 pour des valeurs inférieures)
2 - Il est complètement ignorer, avec les données auquel il est associé, pour les procédures
suivantes :
Décryptage SSE (DE-ENVELOPPE) et décryptage SE
• PARSING et exécution (Nous entendons par PARSING (littéralement analyse de la
• Période) dans notre contexte c’est l’examen des NANOCOMMANDES et de leurs
paramètres.
3 - Fait partie des données pour le calcul de la signature.
4- P4 est le premier octet de donnée pour P3.
Pour savoir le nombre d’octets associé à P3, nous suivons le tableau classique des LEN
Exemple:
NANO 0x04 = NANO 0x4 de Longueur 0x0, n’est suivie d’aucunes données.
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 (IMPORTANT le 0 n’est pas une valeur admissible pour P3)
Les F=32 octets
NANO 0xD1 = NANO 0x1 de longueur 0xD, suivie de 16 octets de données.
Tous les nombres seront donnés en hexadécimal.
******************************************************************************************************************************
Au terme de ce contrôle, nous pouvons obtenir le statut 6700 (Mauvaise longueur de données ) si
après les donnée de P3, il n’y a pas au moins 0x5A (90 décimal) octets de données, nous
expliquerons le motif plus en avant.
6 – Contrôle sur bit 1,2 de P4 (doivent être = 0, statut 9036 dans le cas contraire)
P4 est un indicateur pour le DE-ENVELOPPE mais sa fonction précise est encore inconnue
NOTE :
Pour les réponses suivantes, les octets de statut ne justifie pas la séquence de
1 à 6 …….. :
C1 38 01 91 00 Statut prévu : 9024 Statut obtenu : 9036
C1 38 01 91 01 19 Statut prévu :6700 Statut obtenu : 9036
7 – Décryptage SSE (ou de-enveloppe)
Bien que l’algorithme ne soit pas connu, on a pu observer qu’il utilisait des clés différentes pour
chaque fournisseur d’accès (mais les mêmes clés pour toutes les cartes d’un fournisseur d’accès) et
qu’il opère toujours et seulement sur les derniers 0x5A octets de données.
Les conséquences sont :
- Une ECM/EMM adressée à un fournisseur d’accès n’est pas applicable à un autre fournisseur
d’accès.
- Les données de P3 (données qui ne sont pas partie prenante au de-enveloppe) doivent être
suivies d’au moins 0x5A d’octets (voilà expliqué le pourquoi de 6700 pendant le contrôle sur
P3)
- Les éventuels octets ajoutés entre les données de P3 et les dernier 0x5A octets ne sont pas
dans la SSE/ENVELOPPE (IMPORTANT)
Exemple : Note : aucun des exemples
Ne viennent de LOG
C1 40 01 B1 6A réels
43 51 6E B1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
12 08 F5 56 DE F0 11 12 D0 D8 40 3B 34 7A EB A5
B7 30 41 50 5F 02 6D B2 03 AB 29 2B 29 7A 05 4F
AF 83 18 75 1F 33 49 67 29 0C C0 22 C7 44 E3 BA
45 6D 1B 3A F3 56 07 A9 89 5D B4 5E 8A D1 1F 40
F4 50 D1 57 D0 96 88 5B EB 93 2A 10 E8 4D 36
1F 80 A7 65 A6 9C 3E 03 78 49
Dans cette instruction, les octets mis en évidence en bleu représente P3 et ses données relatives (le
quartet fort de P3 = 4, donc nous avons 4 octets de données qui le suivent.
Ceux mis en évidence en bleu clair représente les 0x5A sous De-Enveloppe, les autres (ceux qui sont
sur fond blanc) sont en dehors de l’enveloppe et donc sont en clair ou en SUPER-ENCRYPTION.
Que trouvons-nous sous la DE-ENVELOPPE ?
On note immédiatement une grosse différence par rapport à SECA1 : la signature est en dehors de la
SUPER-ENCRYPTION et n’a pas de position fixe. Reprenons l’instruction précédente et faisons une
hypothèse sur une de-enveloppe possible :
C1 40 01 B1 6A
43 51 6E B1 92 0F 87 17 D3 5C 87 47 34 5E 39 79
D7 C6 1A C9 4F E8 40 6C 67 E3 AB 84 4C 29 3F DD
A3 F0 E6 37 86 6D 8A 23 CB 88 55 9D 47 78 B6 71
54 9F 82 D8 85 1C 3E 05 34 36 27 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 P5
P5 est maintenant en clair
Nous pouvons voir P3 avec ses données (en bleu) suivit des octets cryptés en SUPERENCRYPTION
(en vert ; il est important de rappeler que la partie soulignée, n’a pas subit de deenveloppe),
après est présente la NANO82 + la signature en clair, le reste ne sont que des octets de
remplissage jusqu’à l’avant dernier octet (compris).
L’instruction se termine par le paramètre P5, Celui-ci a comme fonction d’indiquer la position de la
NANO 82, cela signifie que la carte ne recherche pas la signature en scannant toute la chaîne de
commande mais qu’il va directement à la position pointée par P5.
Nous en déduisons deux informations supplémentaires sur la position de la NANO 82
- La signature est longue de huit octets, il n’est donc pas admissible que la NANO 82 puisse
être dans les 8 dernières positions de la chaîne de commande.
- Les données pour le calcul de la signature doivent être au moins 8, en d’autre mots, la NANO
82 doit être précédée d’au moins 8 octets.
...
