Une radiocommande 12 canaux à “rolling code”
Nous terminons ce mois-ci la description de notre système de contrôle à distance à douze canaux avec codage HCS par l’analyse d’aspects importants touchant la sécurité. Pour cela nous vous proposons des expérimentations pratiques de programmation de la télécommande; nous analysons les séquences émises et le programme résident nécessaire pour faire fonctionner le décodeur.
Après avoir réalisé le décodeur et le programmateur A pour télécommandes à “rolling-code”, nous pouvons
enfin analyser quelques aspects pratiques et fonctionnels qui nous permettront d’atteindre un bon niveau de sécurité. Paramétrer le codeur HCS300/301 est une étape fondamentale mais risque de demeurer sans effet si nous ne mettons pas à jour le programme résident du décodeur. En second lieu, dans le choix des paramètres de base comme la clé de cryptage, il est nécessaire d’effectuer des choix qui pourraient entacher la sécurité du mécanisme tout entier. Pour cela des règles de production ont été fixées:
elles se divisent en beaucoup de systèmes professionnels et si on veut on peut les personnaliser. Si vous avez lu les deux premières parties de l’article, vous vous serez sans doute demandé quels poids ont les divers paramètres de programmation et comment il est possible de réaliser un système suffisamment sûr mais en même temps assez simple à implémenter. Le mois dernier en effet nous avons décrit en détail la signification de chaque champ et nous voulons maintenant vous fournir une clé de lecture afin que l’utilisation de ces paramètres soit le plus intuitif possible. Nous nous lancerons ensuite dans quelques expérimentations pratiques de programmation de la télécommande et analyserons les séquences transmises et les parties du programme résident nécessaires au fonctionnement du décodeur. Pour la première fois nous introduirons le concept d’“attaque de la sécurité”. L’électronique est désormais prépondérante dans ce domaine et quiconque développe un système à utilisation exclusive doit être conscient que ceux qui tenteront de le violer seront nombreux et habiles!
Nous essaierons de voir de quelles attaques peut être victime un décodeur à “rolling-code” et quelles sont les méthodes disponibles pour en limiter l’efficacité. Avant de commencer, permettez-nous de citer une phrase de Phil Zimmermann (www.philzimmermann.c om), expert renommé en cryptographie et concepteur du fameux PGP (Pretty Good Privacy): “Quiconque pense avoir inventé un algorithme cryptographique inviolable est soit un incroyable génie soit un ingénu inexpérimenté”.
Pavés de programmation des télécommandes Aurel TX1, TX2, TX3
Dans la deuxième partie, nous nous sommes occupés particulièrement de la télécommande à douze canaux que nous avons ensuite utilisée avec le décodeur. Pour nos expérimentations, nous nous réfèrerons cette fois à des émetteurs répondant au protocole HCS300 et insérés dans les télécommandes OVO à 1, 2, 3 canaux. Ce choix vient de ce qu’ils sont programmables plus facilement et sans piste à couper.
Nous pourrons ainsi tester les diverses configurations sans sortir le fer à souder De plus, vu leur faible coût, si nous faisons une erreur et en détruisons un, nous ne nous lamenterons pas trop longtemps! Ouvrons donc un TX1, sortons la pile et retournons la platine:
le circuit qui nous apparaît est celui de la Figure 1.
Vous voyez les quatre pavés (pastilles carrées de cuivre étamé) présents en haut de la platine ronde? Il est facile d’identifier le brochage. Si nous suivons les pistes du circuit imprimé nous voyons qu’elles arrivent aux quatre broches principales du codeur CMS HCS300. Numérotons les pavés de gauche à droite. Le Tableau 1 reprend le résultat de cette observation. Nous pouvons alors relier le circuit de la télécommande au programmateur que nous avons construit le mois dernier et commencer tout de suite à expérimenter le fonctionnement des différents paramètres.
Algorithmes d’apprentissage
Pour le développement d’un décodeur “rolling-code”, il est nécessaire de choisir une méthode d’apprentissage des dispositifs autorisés pour l’activation et la désactivation des charges. Durant cette phase on active les diverses télécommandes à utiliser pour que le microcontrôleur puisse les identifier et mémoriser les informations nécessaires pour leur reconnaissance et pour connaître le cryptage utilisé. Durant le fonctionnement normal, il sera en mesure de comprendre si l’émission arrive d’une télécommande autorisée en décryptant le champ relatif à l’activation des charges. Trois modes d’apprentissage ou “learning” sont employés:
1) SIMPLE LEARNING (apprentissage simple)
2) NORMAL LEARNING (apprentissage normal)
3) SECURE LEARNING (apprentissage de sécurité)
Analysons-les séparément et précisons pour chacun les côtés positifs et les négatifs, en effectuant un essai concret de programmation.
Apprentissage simple
Chaque constructeur utilise un code à 64 bits appelé “Manufacturer’s Code” afin de différentier ses propres télécommandes. Naturellement ce code doit être conservé de manière à éviter toute utilisation abusive. Eh bien, dans ce mode chaque télécommande est identifiée par un numéro série spécifique, mais tous ont la même clé de cryptage, laquelle est justement égale au ManCode. Il est clair qu’il s’agit du système à la sécurité la plus basse et il est primordial de maintenir cette clé secrète. Si quelqu’un en effet venait à la connaître, il pourrait simuler d’un seul coup les séquences transmises par chaque télécommande de la série d’un constructeur Pour éviter que cela n’arrive, certains logiciels de programmation (PRO MATE Il de Microchip) établissent que la clé doit être produite sur la base de deux valeurs à vingt chiffres appelées “custodian key” et conservées par deux personnes différentes. On pense toutefois que ces informations sont faciles à trouver auprès des techniciens du secteur.. Laspect positif de ce système est bien sûr sa facilité d’implémentation. Il n’est en effet pas nécessaire ici d’insérer dans le décodeur des algorithmes de production de la clé, la vérification de l’émission se faisant directement à travers le ManCode. En second lieu, la phase d’apprentissage est extrêmement simple puisqu’il suffit de mémoriser les numéros de série des émetteurs et les valeurs de synchronisation. Généralement les systèmes qui utilisent cette méthode se servent d’une “Discrimination Value” correspondant aux 10 bits les moins significatifs du numéro série; la vérification de l’émission se réduit donc à comparer les valeurs en EEPROM et celles reçues, sans autre transformation. En bref, ce système n’a qu’un niveau de sécurité donné par la clé de cryptage et il est donc facile à implémenter mais relativement peu sûr. Prenons un exemple pratique et programmons notre TX1 avec les valeurs suivantes tout en maintenant les autres champs par défaut:
MANCODE= ABCDEF0123456789
SERIAL NUM. = 9678512
DISCR. VALUE= 112
Voici ce que nous trouvons si nous enregistrons la séquence envoyée par la télécommande (Tableau 2). En appliquant la fonction de décryptage au bloc de 32 bits en utilisant comme clé la ManCode on a:
2E15795Dh---> 81120001h
Si nous analysons la séquence, nous voyons que les 10 bits du discriminant correspondent justement aux 10 bits
les moins significatifs du numéro série, comme établi durant la programmation. Cette vérification permet d’identifier à nouveau la télécommande et de savoir si l’opération de décryptage a abouti.
Apprentissage normal
Dans ce mode, chaque télécommande est identifiée par un numéro de série et par une clé de cryptage spécifiques et différents d’un émetteur à l’autre. En particulier, la clé à 64 bits est produite sur la base du ManCode et du numéro de série à 32 bits utilisé comme noyau.
La fonction de décryptage est la propriété de KEELOQ et elle est disponible moyennant l’acquisition d’une licence adéquate. Il s’agit d’un algorithme de cryptage symétrique à clé à 64 bits travaillant sur des blocs à 32 bits et se basant sur le calcul d’une fonction non linéaire. Le cryptage symétrique est également appelé cryptage à clé secrète vu qu’on utilise la même clé pour le cryptage et le décryptage d’un bloc. On utilise deux types d’algorithmes de production que reprend le diagramme de la Figure 2.
En fait, deux noyaux différents sont calculés: ils correspondent au numéro de série du dispositif à 28 bits auquel on ajoute en tête 4 bits égaux à 02h pour le premier et 06h pour le second. Le code à 32 bits qui en résulte est utilisé avec le ManCode comme entrée pour une fonction de transformation
qui peut être la fonction de décryptage ou un OR exclusif. Voyons les deux cas pratiquement en reprenant les mêmes valeurs de ManCode et numéro de série que précédemment:
Exemple 1:
Fonction de transformation XOR
SEME1=29678512
SEME2=69678512
MANCODE1=23456789
(les 32 bits les moins significatifs extraits)
MANCODE2=ABCDEFO1
(les 32 bits les plus significatifs extraits)
Calculons le OR exclusif:
SEME2 XOR MANCODE2 = C2AA6AI3
SEMEI XOR MANCODEI = 0A22E29B
Donc la clé à 64 bits résultante est:
C2AA6A130A22 E29 B
Exemple 2:
Fonction de transformation Décryptage KEELOQ
SEME1=29678512
SEME2=69678512
MANCODE= ABCDEF0123456789
Calculons la fonction en utilisant les deux noyaux comme blocs d’entrée:
DEC IFRA(MANCODE, SEME2) =
5CBBDAIF
DEC IFRA(MANCODE, SEMEI) =
53IA2BDD
Donc la clé à 64 bits résultante est:
5CBBDA1F531A2BDD
On voit clairement que dans les deux cas le ManCode est dûment caché afin de rendre plus difficile le travail d’un éventuel brigand.
En outre, la clé de cryptage change pour chaque télécommande vu qu’elle est liée au numéro de série qui l’identifie. La relation entre le numéro de série et la clé résultante n’est pas évidente. Par conséquent, avec ce système, nous ajoutons un autre niveau de sécurité donné par l’algorithme d’apprentissage, ce qui rend le programme résident plus complexe mais plus sûr.
Rien ne nous interdit d’implémenter des fonctions de transformation personnalisées, l’important est de rendre le lien entre le numéro de série et la clé résultante peu ou non intuitif.
Apprentissage de sécurité
Dans cette dernière méthode on fait dépendre la clé d’un noyau à 32 bits qu’on mémorise à l’intérieur de la télécommande et qui est transmise exclusivement au moment de l’app re nti ssa ge.
On crée donc un autre niveau de sécurité car la connaissance de l’algorithme d’apprentissage ne donne aucune information utile pour accéder au système de manière frauduleuse.
Figure 4: Si nous nous servons du programme HCSPRG, l’écran principal au terme des opérations est celui-ci.
Là encore on peut utiliser soit un OR exclusif soit la fonction de décryptage comme fonction de transformation.
Il est possible en particulier de mélanger la valeur du noyau avec celle du numéro série (voir Figure 3).
À titre d’exemple pratique, supposons que nous ayons utilisé comme SEED la valeur à 32 bits AABBCCDDh.
Exemple 1:
Fonction de transformation XOR
SEME1=AABBCCDD
SEM E2=O9678512
MANCODE1= 23456789
(les 32 bits les moins significatifs extraits)
MANCODE2=ABCDEFO1
(les 32 bits les plus significatifs extraits)
Calculons le OR exclusif:
SEME2 XOR MANCODE2 = A2AA6A13
SEME1 XOR MANCODE1 = 89FEAB54
Donc la clé à 64 bits résultante est:
A2AA6A1389FEAB54
Exemple 2:
Fonction de transformation
Décryptage KEELOQ
SEME1= AABBCCDD
SEME2=O9678512
MANCODE= ABCDEFO123456789
Calculons la fonction en utilisant les deux noyaux comme blocs d’entrée:
DEC IFRA(MANCODE, SEME2) = 72A992BC
DEC IFRA(MANCODE, SEME1) = DD64D27C
Donc la clé à 64 bits résultante est:
72A992BCDD64D27C
Ce qui rend cette méthode d’apprentissage plus sûre, c’est que la valeur à 32 bits qui distingue les SEED est transmise seulement dans une occasion particulière, c’est-à-dire quand on active en même temps les broches SO, Si, S2, S3 du HCS300/ 301. Cette opération est effectuée durant la phase d’apprentissage et plus ensuite, en utilisation normale de la télécommande. Cela est très important car le passage du noyau, avec lequel on produit la clé secrète de cryptage, se fait à un moment où le décodeur et la télécommande se trouvent en lieu sûr, c’est-à-dire protégés de toute possibilité d’interception.
Ensuite, on ne pourra plus extraire la valeur du SEED sans habiliter les quatre broches du codeur, procédure qui oblige à démonter la télécommande. En second lieu cette valeur est conservée en EEPROM, mémoire qui ne peut être lue qu’en effectuant la programmation, c’est-à-dire la surécriture des données précédentes lesquelles sont alors irrémédiablement perdues. Si on utilise des codeurs HC5360, il est possible de mettre à profit un champ SEED plus long (48 bits) et éventuellement de bloquer la possibilité d’envoi de cette valeur après que le compteur
de synchronisation ait atteint le quota 128. Ainsi, même si la télécommande arrive dans des mains scélérates, il ne sera pas possible d’extraire la valeur recherchée même si on active en même temps les quatre broches SO, 51, S2, S3.
Essayons de programmer notre télécommande (cette fois une TX2) en utilisant les paramètres précédents. Si nous nous servons du programme HCSPRG, l’écran principal au terme des opérations est celui que montre la Figure 4.
Si nous essayons maintenant d’effectuer une émission en mettant au niveau logique haut les quatre broches du HCS300, nous verrons que le code crypté à 32 bits est remplacé directement par le champ noyau en clair. Le décodeur est ainsi en mesure de calculer la clé de manière autonome pour décrypter les séquences suivantes. Séquence envoyée avec SO,S1,52,53=llllb (Tableau 3).
Si en revanche nous effectuons une émission normalement, nous verrons que la séquence envoyée change et que le noyau est remplacé par le code crypté à 32 bits (Tableau 4). Si nous décodons le champ en question en utilisant la clé à 64 bits insérée (72A992BCDD64D27C) nous trouvons:
E4E72B79h ---> 41120003h
Là encore la présence de la séquence mise en évidence nous assure que l’opération a abouti, ce qui permet une vérification supplémentaire de l’identité de la télécommande.
Rendre le programme résident plus sûr
Selon la méthode d’apprentissage utilisée, il est nécessaire de développer dans le programme résident du micro- contrôleur la séquence permettant de la gérer. Dans notre projet initial, on suit une procédure d’apprentissage simple. En fait, quand on enlève le cavalier Ji, le décodeur se met en attente d’une séquence à apprendre.
Dès que nous pressons le poussoir de la télécommande, le micro enregistre simplement la séquence reçue dans I’EEPROM en créant un tableau spécifique ayant comme clé primaire le
numéro de série de la télécommande. Pour nous, il n’est pas nécessaire de produire la clé de cryptage vu que nous utilisons des télécommandes non paramétrables “tout à zéro”.
Quand l’apprentissage est terminé, le micro se met en attente d’une émission. Dès qu’il la reçoit, il recherche le numéro de série émis en clair à l’intérieur de I’EEPROM ; quand il la trouve, il décrypte le champ à 32 bits et active les charges. Si en revanche nous utilisions un apprentissage normal, le micro devrait produire la clé de décryptage en fonction des informations transférées lorsque le cavalier Ji est retiré.
Dans ce cas, il faut choisir si on veut produire la clé au moment de l’apprentissage et la sauvegarder à l’intérieur de I’EEPROM (attention, ce choix pourrait compromettre la sécurité du système) ou bien effectuer le recalcul à chaque réception. Le second cas est de toute évidence le plus sûr. Si vous regardez le “listing” vous verrez que les séquences reçues sont disposées dans un “buffer” spécial CSR7. ..CSRO.
Il est nécessaire de déclarer une constante MCODE7... MCODEO contenant le ManCode (ABCDEFO123456789h),
alors que nous utiliserons la variable CHIAVE7...CHIAVEO déjà présente dans le “listing” pour conserver la clé produite. Rappelez-vous que le sous programme de réception effectue la mise à zéro des quatre bits les plus significatifs du numéro de série.
Supposons que nous ayons utilisé une fonction de transformation XOR, nous obtiendrons ce que montre le “Listing” 1. lI est alors possible d’appeler la fonction “DECIFRA” qui nécessite en entrée la variable SEME3...SEMEO comme code à décrypter et la variable CHIAVE7...CHIAVEO comme clé de décryptage. Le code décrypté peut être utilisé pour le “check” (contrôle, vérification) de l’émission et l’activation des charges.
De même, si nous devions développer un système d’apprentissage sûr, nous devrions nécessairement utiliser la valeur du SEED conservée en EEPROM. Le code du compilateur PlCBasic, utilisant toujours le XOR comme fonction de transformation, devient ce que montre le “Listing” 2.
Une autre phase revêt une certaine importance pour augmenter la sécurité du système: c’est la phase de vérification de la séquence reçue.
Dans notre “listing” initial, une fois décryptée la séquence des quatre “Function bits” qui identifient la touche pressée, on passe directement à l’activation des charges. Un contrôle (check”) de l’émission devenait alors superflu vu que l’on se sert de télécommandes non paramétrables.
Maintenant que vous avez construit le programmateur, vous pouvez introduire le concept de vérification de la valeur discriminante et de synchronisation. Dans le premier cas on effectue une double vérification sur la télécommande émettrice.
La première touche le numéro de série qui est comparé avec ceux des dispositifs autorisés. La seconde la comparaison de la valeur discriminante contenue dans le code crypté avec celle mémorisée durant l’apprentissage. Cette vérification permet d’établir encore une fois que l’émetteur est un de ceux autorisés et elle permet implicitement de contrôler que l’opération de décryptage a abouti.
On a l’habitude de valoriser le discriminant avec les 10 bits les moins significatifs du numéro de série. Attention, après avoir appelé la fonction “DECIFRA” on obtient le code en clair dans la variable SEME3...SEMEO selon la séquence suivante:
SEME3: 4 Function bit + 2 Overflow
bit + 2 Discrimination bit (MS)
SEME2: 8 Discrimination bit (LS)
SEMEI: 8 Synchronisation bit (MS)
SEMEO: 8 Synchronisation bit (LS)
Le code correspondant est visible “Listing” 3. De même on gère la synchronisation en établissant une fenêtre d’autorisation à l’intérieur de laquelle la valeur de synchronisation doit rester pour pouvoir considérer l’émission comme acceptable. Par exemple, nous établissons que le compteur ne doit pas dépasser 16 pas (steps”) successifs par rapport à ce qui a été mémorisé lors de la transmission précédente. Dans le cas d’un “Normal Learning”, le code correspondant est celui décrit dans le “Listing” 4.
Résumons-nous: le programme résident, pour atteindre un bon niveau de sécurité doit prévoir:
1) Production de la clé de cryptage au vol en fonction d’un algorithme associant des données échangées en environnement protégé (SEED mémorisé seulement au moment de l’apprentissage);
2) Vérification du numéro de série reçu dans la liste mémorisée durant l’apprentissage;
3) Vérification de la valeur discriminante en fonction de ce qui a été mémorisé durant l’apprentissage;
4) Vérification de la valeur de synchronisation par l’utilisation d’une fenêtre d’autorisation.
Les attaques
les plus fréquentes
Il existe en gros deux types d’attaques connues, appelées respectivement “Code Scanning” et “Code Grabbing”. Dans le premier cas on utilise un petit émetteur numérique réglé sur la même fréquence que le décodeur. Le malotru effectue un balayage des codes possibles en fonction de la longueur de la séquence envoyée par les télécommandes à simuler. Dans notre cas ce type d’attaque est plutôt faible car les HCS300 utilisent des séquences à 66 bits, ce qui fait tout de même environ 73 * 10 puissance 19 combinaisons. Vu qu’une émission dans le cas d’un Te=400jJs dure environ 100 ms, cela prendra au voleur 2,3 * 10 puissance 11 années pour les parcourir toutes!
On peut, il est vrai, réduire ce nombre en considérant qu’une partie à 34 bits de la séquence reste fixe. La recherche restante doit encore être faite sur 32 bits au lieu de 66 et le nombre de combinaisons devient nettement inférieur (environ 4,3 milliards). En comptant toujours 100 ms par émission, il est clair que cela prend encore beaucoup de temps! Ces tentatives portent leur fruit lorsque les télécommandes envoient des séquences relativement courtes, basées par exemple sur la position d’un micro-interrupteur. Dans ces cas, 8 ou 16 bits sont assez faciles à déjouer (de quelques secondes à quelques heures au maximum).
L’autre système est légèrement plus insidieux et se base sur un émetteur/ récepteur qui enregistre les séquences envoyées par le légitime propriétaire, pour ensuite en envoyer une comme commande. Le décodeur en réalité ne se laisse pas tromper si facilement car, si vous avez inséré le contrôle de synchronisation, au moment où la séquence est retransmise, il écarte le paquet puisqu’il n’entre pas dans la fenêtre d’autorisation.
La valeur de synchronisation doit être augmentée à chaque émission, mais le “grabber” n’a pas la possibilité de le faire car le code à 32 bits est crypté
et il n’y a pas de relation intuitive entre la valeur contenue et celle émise. L’unique point d’attaque vraiment efficace dans les systèmes à “rolling-code” est la clé à 64 bits.
Pour le moment on ne connaît pas de point faible à l’algorithme et les attaques brutales ne sont pas efficaces, même en considérant que certaines parties du code en clair sont connues a priori. Dans ces cas, la seule porte d’accès peut venir d’une programmation ingénue ou de la conception du décodeur.
Dans le premier cas, l’utilisation de clés à 0, de codes connus ou avec des valeurs très intuitives, peuvent facilement occasionner la faillite des systèmes de défense. De même pour la mémorisation de la clé en EEPROM facilement accessible durant une intervention d’entretien.
À partir du moment où on a connaissance de la clé de cryptage, il devient assez facile, avec un “grabbing” des séquences transmises, de cloner la télécommande. Il suffit d’intercepter une seule séquence pour calculer la valeur de synchronisation et ensuite retransmettre la séquence suivante correctement.
Publié dans Electronique-Magazine N°_99_Novembre_2007
0 Commentaires