Bonjour,
Je suis nouveau, et très impressionné par le travail de reverse réalisé ici.
Je vais bientôt recevoir une 5008 neuve, et je m'interroge sur la sécurité de l'engin (je parle de l'IT dedans, pas de crash-test). J'ai lu les histoires de voitures volées via les relay-attacks sur les systèmes handsfree (1), et aussi la reprog de clés via la prises obd (2).
Comme l'algo UDS est maintenant public ce qui permet de faire (2) facilement des qu'on est dans la voiture via (1) ou en cassant une vitre, je me demande comment protéger l'engin.
Avec, cet outil (ou Diagbox) peut on désactiver le système d'entrée mains libres (hors CAN, je n'ai trouvé que ça, et je ne suis pas sur que ça marche
https://www.peugeotforums.com/threads/how-to-turn-off-keyless-entry.336110/post-2301355)?
Existe t'il un moyen simple de désactiver l'obd et le réactiver à la demande (fusible?) pour éviter (2) sans avoir à faire trop de modif sur la prise physique elle même?
S'il existe un thread plus approprié, merci de me rediriger.
Encore une fois, le boulot est ouf.
Un peu HS comme sujet, mais bon:
La securite des voitures PSA est disons "minimale": ca n'a quasiment pas change depuis 20ans, et c'est casse depuis bien avant que y'ai l'algo disponible publiquement (plusieurs entreprises ont deja RE et casse les deux algos, antidemarrage et UDS, depuis bien longtemps). Fondamentalement, la seule facon de corriger ca serait de revoir tout le systeme d'anti-demarrage et de diagnostique (il y a une eu amelioration avec le "telecodage securise" dans AEE2010, mais ca se base sur exactement le meme algo que la MaJ de calculateurs, depuis 20ans, donc, aucune vrai amelioration).
* L'anti-demarrage est casse depuis le debut des annees 2000
* L'algo UDS est reverse engineer (et encore plus facilement casse) depuis au moins 12ans
* Les cles 433mhz sont elles aussi cassees (algo hitag2) depuis longtemps
* Les cles pour l'ADML (donc les nouvelles) sont tres probablement du meme accabit (pas ete verifier, j'ai pas l'ADML, mais vu depuis le temps que ca existe, je devine que ca utilise les memes bases que les autres systemes)
NB: c'est pas des masses mieux chez les autres en general aussi, c'est loin d'etre un soucis specifique a peugeot...
De maniere tres realiste, tu ne pourras malheureusement pas te proteger des attaques, mais par contre, il faut prendre en compte 3 choses dans son modele de menace:
* L'immense majorite des vols sont opportunistes
* La grande majorite des voleurs sont low-tech: inutile de reprogrammer une nouvelle cle quand tu peux juste la voler dans la maison a cote. Et les plus "high tech" ont deja les outils depuis longtemps (les voleurs attendent pas vraiment l'arrivee de projets opensource pour se mettre a viser un type de voiture
)
* La securite par l'obscurite n'existe
pas: "tout ce qui a ete fait par l'homme peut etre detruit par l'homme", principe de base en securite info, peu importe si les donnees et le code sont publiques ou non.
Le meilleur moyen de se proteger est donc d'eviter de laisser l'opportunite aux voleurs, et d'avoir une bonne assurance derriere, tout le reste n'est globalement que poudre aux yeux, et contre un adversaire determine, il n'y aura aucune securite reelement efficace...
Globalement (du point de vue de peugeot, c'est pas realiste de le faire de notre cote), pour avoir un truc secure, peugeot aurait du faire comme ca:
* Avoir une cle ou le protocole de transport n'a aucune fonction de securite (loi de Kerckhoffs), donc un truc en BLE irait parfaitement par exemple (il me semble que l'ADML se base sur du BLE d'ailleurs)
* Utiliser un algo entre la cle et le HDC (le recepteur) standard et robuste, sans secret partage, par exemple HMAC-SHA256 (la crypto asymetrique est trop gourmande pour etre utilise en embarque). Ce que no peugeot ni NXP ont fait...
* Idem pour l'anti-demarrage et l'auth UDS, avec des secrets evidemment differents a chaque fois
* Stocker toutes les donnees sensibles dans une zone a part, non modifiable, non exportable (donc TZ, IC de smartcard...). le gros inconvenient de faire ca, c'est que ca enleve la possibilite d'ajouter de nouvelles cles
* Si vraiment y'a besoin de pouvoir ajouter de nouvelles cle (sans changer le BSI et CMM), au minimum signer les demandes la aussi avec un algo robuste, se baser sur les SA d'UDS/KWP2K ne suffisent pas, et mettre la zone de memoire la toujours non-exportable
* Ne pas stocker les secrets dans l'eeprom, mais bien on-die, et meme idealement, dans le SoC directement