MagicalTux in Japan

Il est toujours intéréssant de voir comment les choses sont faites, et de quelle manière elles sont protégées. Je me suis donc penché sur les cartes satellite TPS, la manière dont ça marche et la manière dont le fameux cryptage TPS fonctionne.

Le flux transmit par le satellite vers les abonnés est du MPEG-2 dont les trames sont cryptées à l’aide d’une clé de 8 octets. Cette clée, apellée clé Mk, est stockée sur la carte TPS. Quelles sont les sécurités qui font que le décodeur décode ou non le flux MPEG-2 reçu du satellite ?

Voir Viaccess 2.4 – Outil de lecture des cartes

Et bien là, grosse déçéption. Il semble que le cryptage se contente d’utiliser la clé de cryptage fourni par la carte, clé qui n’a pas changé depuis quelques années. Toutefois mon but est plutôt de m’intérésser à cette fameuse carte…

En effet, la carte TPS est une carte fournie par une société connue sous le nom de Viaccess. Là ce qui choque le plus, ce n’est pas la tête du type à gauche (qui pourtant est déjà pas mal choquante) mais ce qui est écrit juste en dessous du logo : “a France Telecom company”.
Alors, qu’est-ce que ça vaut un système de sécurité signé France Telecom ?

Déjà, impossible de savoir exactement ce qui est stocké sur la carte. La liaison se fait via le port série sur une interface Phoenix, en 9600bps, parité impaire, 2 bits de stop. Chaque instruction fait 5 octets, sous la forme “CLA INS P1 P2 LEN”.

• CLA est la classe de l’instruction. Il existe à priori deux classes officielles, 0xCA qui permet d’obtenir des informations de la part de la carte, et 0×87 qui permet d’apeller des procédures sur la carte. Il existe aussi sur les cartes Viaccess 2.4 et précédentes une classe 0xBC contenant une instruction de débug sur laquelle je reviendrais plus loin.
• INS et le numéro d’instruction lui même. On ne peut donc avoir que 256 instructions par classe, mais cela suffit largement.
• P1 et P2 sont les paramètres de la commande
• LEN est la longueur des paramètres additionnels de la commande. Cela sert par exemple quand une commande est signée.

Comme on peut le voir, le système d’instruction est relativement simple. Lors de son initialisation (envoi du signal RST) la carte transmet une série de 12 octets, connus sous le nom d’ATR (answer to reset, quelle originalité). Ces 12 octets donnent des informations sur le mode de fonctionnement de la carte. Les deux derniers octets sont “90 00″, qui correspond au code de réponse de la carte. En général, quand la carte répond un code “90 00″ c’est que tout vas bien.

Voilà, donc je reprend mes explications. Dans la carte peuvent également être stockés plusieurs fournisseurs (les “providers”). Un fournisseur dispose d’un nom (semble pouvoir faire jusqu’à 8 caractères sur certains décodeurs, ou 24 sur d’autres…), un numéro PPUA (identifiant client), un numéro GCA (Group Customer Address, généralement défini à 0xffffffff), une série de clés numérotées de 0×0 à 0xf (généralement la clé 0×8 sert pour le décodage), et diverses autres choses telles que les jetons (utilisés pour l’achat de films) et les “subscriptions” (liste des classes de chaines disponibles, avec les dates de validités).

Toutefois la carte ne nous laissera pas obtenir les clé si facilement. D’après ce que j’ai pu comprendre, seules l’index des trames-clé du flux MPEG-2 sont codées, le décodeur transmet l’index à la carte qui décode elle-même l’index et le renvois au décodeur, qui peut alors afficher le flux correctement.

Il existe également sur la carte un provider principal, avec le nom ISSUER et le numéro id “FF F4 00”. En connaissant la clé 0×0 ou la clé 0×4 de ce fournisseur, il est possible de modifier les clé des autres fournisseurs, et en connaissant la clé 0×0 du fournisseur TPS (00 7C 00), il est possible de modifier les “subscriptions”.
En gros, à partir du moment où l’on connait les clés, on peut faire ce que l’on veut avec la carte.

On pourrais imaginer que pour obtenir cette clé, il faille envoyer des données à décrypter à la carte, puis analyser ces données afin de déterminer la clé utilisée (on sais que l’algorythme utilisé est un dérivé de DES, et on connais l’algorythme exact).

Toutefois, il se trouve qu’une faille assez importante dans les cartes viaccess 2.4 permet d’obtenir directement les clé comme ça, en clair. La fameuse classe 0xBC, qui ne possède que l’instruction 0×52 est la clé de cette faille (elle a été retirée des cartes viaccess 2.5).

Malgrès de nombreuses recherches je n’ai pas pu trouver exactement le but initial de cette fonction, mais voilà à peu près la procédure utilisée pour obtenir une clé.

• On séléctionne le provider avant tout. Il serait bête de ne pas obtenir la bonne clé
• On demande le nom du provider. Normalement l’obtention du contenu des données se fait par l’appel d’une autre procédure de la carte. Toutefois en l’occurence on n’y fait pas appel. Il en résulte que la carte est en état “j’ai des données à envoyer”.
• On envois une requête de décodage avec un paquet bidon. Là, la carte vas prendre en mémoire la clé, et décoder les données qu’on lui envoie.
• Là, on envois le fameux paquet “BC 52 00 00 00”.
• Ensuite on lit les données disponible de la même manière que si l’on avais voulu lire le nom de la carte. Toutefois au lieu d’y trouver le nom de la carte on y trouve toute une série de données “junk” (le décodage du paquet bidon?), et à l’offset 140 on trouve les 8 octets de la clé…

C’est relativement bête de pouvoir obtenir une clé avec autant d’aisance. Toutefois le problème à été réglé sur les nouvelles cartes Viaccess, et je suis en train d’analyser ces cartes là. Bientôt un autre communiqué technique sur ces cartes là…