bien que les infos circulent parmis les différentes personnes qui codent les firms cela n'est pas simple de faire les modifications. Afin d'informer ceux qui ne le sont pas encore voici quelques explications sait-on jamais en esperant que cela puisse faire avancer plus vite le devellopement.
Fonctionnement actuel de tps avec liste d'aes
tps utilise 4 types d'encryption actuellement
- la pré-surencryption (ou preSE)
- l'encryption tpscrypte (ou tps)
- le via 2.3
- la post-surencryption (ou postSE)
La grosse nouveauté consiste dans l'introduction d'un nouvel algo impliquer dans le processus le RC6 en l'occurence.
La preSE et la postSE peuvent donc utiliser maitenant 2 algos différents : le RC6 ou l' AES l'encryption tpscrytp étant toujours en algo AES.
la liste extraite chaque jour (tps.bin) contiens des cycles de clé d'environ 6 minutes avec 3 clés :
Voila a quoi ressemble un fichier tps.bin apres décryptage
28/12/2006 04:20:00
C8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxA8
C8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxA8
7BxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxFC
0201021C
28/12/2006 04:26:00
67xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxF3
FCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx16
9BxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxE5
0201021C
- 1ere clef pour la preSE
- 2eme clef pour tpscrypte
- 3eme clef pour la postSE
ainsi que 3 flags
- 1er pour la preSE en algo RC6 (flag=2) ou en algo AES (flag=1)
- 2eme pour tpscrytpe toujours en algo AES (flag=1)
- 3eme pour la postSE en algo RC6 (flag=2) ou en algo AES (flag=1)
si un flag est à 0 il n'a pas d'encryption de ce type
et 1 flag d'autorisation de désencryption pour les 3 types:
- bit 2 = 1 autorise désencryption tpscrypte
- bit 3 = 1 autorise pré-désencryption
- bit 4 = 1 autorise post-désencryption
généralement ce flag est a 0x1C (les 3 autorisés)
donc quand le demo recoit une ecm originelle il faut que cette ecm transite par la preSE,TPScrypte,via2.3(gerée par les cartes habituelles),la postSE
or c'est là que tps a bien rusé en effet c'est ecm elle-meme qui contient les
types de désencryption à faire
une ecm originelle ressemble à:
80 7m nn 00 D2 01 01 40 03 00
08 DF ww gh ij kl ..... avec :
7m= 71 si trame impaire 70 si trame paire
nn= longueur de l'ecm
D2 01 01 identifient du tpscrypte (à suprimer)
40 03 ruse tps (à transformer en 90 03)
00
08 identifiant provider et clef en cours
DF la nano DF:
- ww longueur de la nano DF
- gh utilisé pour "savoir" s'il faut faire une désencryption tpscrypte
(mais s'il y avait D20101 alors de toute façon tpscrypte)
- ij utilisé pour "savoir" s'il faut faire une désencryption preSE
- kl utilisé pour "savoir" s'il faut faire une désencryption postSE
(l'opération pour "savoir" est un petit algorythme)
Donc des fois on peut avoir les 3 types, ou 2, ou 1
et évidement les clefs sont utilisées en meme tant pour traiter une ecm
Les algos RC6 et AES générent à partir de la clef une table de hash
par laquelle l'ecm est xorée
Pour l'instant tout le monde utilise le fichier tps.bin mais la solution finale pour ne pas devoir flasher tous les jours est l'extraction du keyset qui est envoyé actuellement par tps en stream sur un pid bien defini. Malheureusement la aussi tps a corser dernierement le systeme et envois non seulement le keyset mais également separement une régle a utiliser pour l'extraction des clés celle-ci est régulierement modifier c'est ce qui pose probleme actuellemet au démo FTE qui auparavant pouvais extraire le keyset en automatique et gerer tout ca mais maitenant des que les regles d'extractions sont modifier le fte nécéssite une mise a jour car le keyset extrait n'est pas bon.
Voila espérons que cela fasse avancer quelque peux le schmilblik