SecOC : l'authentification des trames CAN

Le bus CAN a été conçu à une époque où la question « qui a envoyé cette trame ? » ne se posait pas. Un identifiant de message, des données, une somme de contrôle de transmission : rien qui permette de distinguer l'émetteur légitime d'un autre. SecOC — Secure Onboard Communication — comble ce manque sur les messages jugés sensibles.

Le problème que cela résout

Sur un réseau classique, décrit dans le bus CAN, un message est identifié par son numéro, pas par son émetteur. Trois faiblesses en découlent :

• rien ne prouve l'origine d'une trame ;
• rien n'empêche de renvoyer plus tard une trame valide capturée auparavant — ce qu'on appelle le rejeu ;
• la somme de contrôle du protocole détecte les erreurs de transmission, pas les messages volontairement fabriqués.

Tant que le véhicule restait un système fermé, c'était acceptable. Dès lors qu'il communique avec l'extérieur — télématique, mise à jour à distance, accès numérique — l'analyse de risque imposée par R155 rend ces faiblesses inacceptables sur les fonctions critiques.

Le principe, en trois éléments

SecOC est une brique standardisée dans l'architecture logicielle AUTOSAR. Son principe tient en trois éléments ajoutés à la trame protégée.

1. Une empreinte d'authentification. L'émetteur calcule, à partir du contenu du message et d'une clé secrète partagée avec le récepteur, une empreinte cryptographique — un code d'authentification de message. Le récepteur refait le même calcul et compare. Sans la clé, on ne peut pas produire une empreinte valide.

2. Une valeur de fraîcheur. Un compteur, ou un élément lié au temps, est intégré au calcul. Deux trames identiques envoyées à deux instants différents n'ont donc pas la même empreinte. Rejouer une trame capturée ne fonctionne pas : sa valeur de fraîcheur est périmée.

3. Une troncature. Une trame CAN classique ne transporte que huit octets. On ne peut pas y loger une empreinte complète. SecOC n'en transmet donc que les premiers bits, quelques dizaines au plus. C'est un compromis assumé entre robustesse et place disponible — l'une des raisons pour lesquelles les architectures récentes migrent vers le CAN FD, dont les trames sont bien plus longues.

Le calcul lui-même est confié au module de sécurité matériel, qui détient la clé et effectue l'opération sans jamais l'exposer.

Ce que cela empêche

• Injecter un message crédible sur une fonction protégée : sans clé, l'empreinte ne peut pas être calculée.
• Rejouer un message enregistré : la valeur de fraîcheur ne concorde plus.
• Faire passer un équipement pour un autre sur les fonctions protégées.

Le récepteur qui constate une empreinte invalide ignore simplement le message. Selon les stratégies, il peut aussi mémoriser un défaut ou basculer sur une valeur de repli.

Ce que cela n'empêche pas

Il faut être précis, car les raccourcis circulent.

• SecOC ne chiffre rien. Le contenu des trames reste lisible : c'est de l'authentification, pas de la confidentialité.
• SecOC ne protège pas tout le réseau. Les constructeurs le déploient de façon ciblée, sur les fonctions à enjeu : couple, freinage, direction, aides à la conduite, antidémarrage. Les innombrables trames de confort restent classiques.
• SecOC ne remplace pas le cloisonnement. Il vient s'ajouter au filtrage assuré par la passerelle, pas s'y substituer.

L'effet de bord sur le diagnostic

C'est là que le reprogrammateur rencontre SecOC dans la vraie vie.

• Le relevé de données passif reste possible. Écouter un bus ne demande aucune clé. La lecture de paramètres par les services de diagnostic normalisés continue de fonctionner. Voir le relevé de données.
• Les commandes actives se durcissent. Piloter un actionneur, forcer un état, lancer une routine sur une fonction protégée demande de plus en plus un accès authentifié, et non plus une simple question-réponse. Voir seed and key.
• Les outils génériques perdent du terrain sur ces fonctions précises. Cela n'a rien d'un défaut de l'outil.
• Le diagnostic sur Ethernet accompagne le mouvement : les architectures qui déploient SecOC sont souvent celles qui utilisent DoIP.

L'effet de bord sur les boîtiers additionnels

C'est la conséquence la plus lourde, et elle mérite d'être expliquée clairement au client.

Un boîtier additionnel fonctionne en s'intercalant : il modifie un signal de capteur, ou il émet sur le réseau des messages destinés à influencer une consigne. Sur une fonction couverte par SecOC, la seconde approche ne fonctionne pas — les messages émis n'ont pas d'empreinte valide et sont ignorés.

Il en résulte, sur les véhicules récents, des situations où le boîtier n'a aucun effet, ou un effet erratique, ou déclenche des défauts de communication et un fonctionnement dégradé. Voir les boîtiers additionnels face au reflash et le mode dégradé.

Le message à tenir est simple : sur ces architectures, un montage qui « parle » sur un réseau protégé n'est pas une solution, quel qu'en soit le prix.

La position professionnelle

SecOC est un dispositif de sécurité au sens propre : il protège des fonctions dont dépend l'intégrité du véhicule et de ses occupants. On ne cherche ni à le neutraliser, ni à s'en accommoder par un montage parallèle. Lorsqu'une prestation le suppose, la réponse est un refus argumenté.

Voir aussi le bus CAN, la passerelle et le filtrage des trames et le HSM.

Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.