We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Vehicle immobilization revisited

00:00
Untertitel
Aus
Abspielgeschwindigkeit
1
Untertitel
Aus
Englisch (automatisch erzeugt)
Abspielgeschwindigkeit
0.25
0.5
0.75
1
1.25
1.5
1.75
2
Qualität
576p
29
 Zitieren
 Teilen
 Zugehöriges Material
 Herunterladen Bestellen
Logo von Chaos Computer Club e.V.Chaos Computer Club e.V.
 Bokslag, Wouter

Formale Metadaten

Titel
Vehicle immobilization revisited
Untertitel
Uncovering and assessing a second authentication mechanism in modern vehicle immobilization systems
Serientitel
Anzahl der Teile
254
Autor
Lizenz
CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Modern road vehicles are fitted with an electronic immobilization system, which prevents the vehicle from starting unless an authorized transponder is present. It is common knowledge that the security transponder embedded in the key fob should be secure, and quite some work has been published on the (in)security of such transponders. However, we identify another crucial part of the immobilizer system, that has not yet received any academic attention. We investigated three vehicles, and found that the security transponder does not communicate with the ECM (Engine Control Module) but with the BCM (Body Control Module). After succesful authentication of the key, the BCM will then authenticate towards the ECM, after which immobilization is deactivated and the vehicle may start. If either the security transponder or this ECM-BCM authentication protocol is weak, vehicles may be started without presence of a valid security transponder. We present three case studies of such ECM-BCM protocols on vehicles from Peugeot, Fiat and Opel. The protocols are shown to be used in many different models, and also by other brands owned by the same group. We show how two of the protocols are completely broken, while the third one is derived directly from a 1995 security transponder. Both attacks can be carried out through the standardized OBD-II connector, present and conveniently located in all modern vehicles. Bottom line: cryptographic protocols used in the ECM-BCM authentication are not on par when compared with the crypto embedded in the transponder. Nowadays, immobilizers play an essential role in the prevention of vehicle theft. Intended to raise the complexity of theft through the introduction of non-mechanical safety measures, immobilizers have always worked by the same basic principle: to disallow ignition until some secret is presented to the vehicle. Immobilizers gained popularity in the 1990s, as a consequence of legislation: the European Union, Australia and Canada adopted regulation in the nineties, mandating the use of electronic immobilization systems in passenger cars. Immobilizers have shown to be highly effective in the effort to reduce theft rates. According to a 2016 study, the broad deployment of immobilization devices has lead to a reduction in car theft of an estimated 40% on average during 1995-2008. However, various tools are on the market to bypass electronic security mechanisms. Deployment of insecure immobilizer systems has real-world consequences: multiple sources report cars being stolen by exploiting vulnerabilities in electronic security, sometimes to extents where insurance companies refuse to insure models unless additional security measures are taken. In modern cars, the ECM (Engine Control Module) is responsible for operating the car engine, and is also responsible for starting the engine. A common misconception about immobilizer systems is that the car key always authenticates directly to the ECM, and that the ECM will only allow the car to start when it has established an authorized 125KHz RFID security transponder is present. In practise, the security transponder in the key fob authenticates towards the BCM (Body Control Module), which in turn authenticates towards the ECM. We have selected three cars from different major Original Equipment Manufacturers (OEMs) and identified immobilizer protocol messages from CAN-bus traffic, which can be accessed through the conveniently located OBD-II connector. We made traces of CAN-traffic when the ignition lock is switched to the ON position. Immobilizer related messages can be easily recognized when searching for high-entropy messages that strongly differ between traces. Confidence that the messages are indeed related to immobilizer can be increased by removing the security transponder from the key, which should result in different protocol messages. After identification of related messages, we dumped ECM and BCM micro-controller firmwares, either by leveraging existing software functions, or by using micro-controller debug functionality such as JTAG and BDM. We derived the immobilizer protocol through reverse-engineering. In all three cases, we established the same protocol is used in several different models from the same OEMs, including currently manufactured ones. We then analyzed the protocols for cryptographic strength. Two turn out to be completely broken, while the last one is directly derived from a 1995 security transponder. While it exhibits no obvious weaknesses, it is used in conjunction with current AES security transponders, and as such, we still recommend the manufacturer to replace it.
Schlagwörter
00:00
ComputerE-MailProtokoll <Datenverarbeitungssystem>SystemprogrammierungMathematische ModellierungSystemaufrufCASE <Informatik>Open SourceRechnernetzTypentheorieUmwandlungsenthalpieCAN-BusAdressraumKontrollstrukturBimodulFehlerkorrekturmodellPunktInfotainmentKonfiguration <Informatik>DifferenteInterprozesskommunikationAlgebraisch abgeschlossener KörperMultiplikationsoperatorBitPhysikalisches SystemModelltheorieComputersicherheitStandardabweichungSchlüsselverwaltungE-MailProtokoll <Datenverarbeitungssystem>Statistische HypotheseTelekommunikationKoroutineAdressraumDatenstrukturDatenverarbeitungssystemGamecontrollerRechnernetzTreiber <Programm>Rechter WinkelGrundraumFunktionalRegulärer GraphGewicht <Ausgleichsrechnung>Gesetz <Physik>Varietät <Mathematik>BildschirmfensterInnerer PunktMixed RealityKomponente <Software>InstantiierungStereometrieAusnahmebehandlungBenutzerschnittstellenverwaltungssystemBimodulFehlermeldungBus <Informatik>InfotainmentInverser LimesSystemaufrufCASE <Informatik>Gemeinsamer SpeicherCAN-BusComputeranimation
07:27
SinusfunktionComputersicherheitTransponderSoftwarekonfigurationsverwaltungBus <Informatik>MereologieSchlüsselverwaltungOpen SourceMaschinenschreibenSpannweite <Stochastik>CAN-BusExogene VariableFehlerkorrekturmodellSchlüsselverwaltungToter WinkelBimodulRechter WinkelGamecontrollerAuthentifikationExogene VariablePhysikalisches SystemComputersicherheitLeistung <Physik>BitrateTransponderBitCASE <Informatik>ARM <Computerarchitektur>CAN-BusPublic-domain-SoftwareModelltheorieSpannungsmessung <Mechanik>BildschirmfensterAggregatzustandDigitaltechnikProtokoll <Datenverarbeitungssystem>FlächeninhaltBeobachtungsstudieBasis <Mathematik>Coxeter-GruppeInternetworkingPerspektivePerfekte GruppePrimitive <Informatik>Güte der AnpassungValiditätDifferenteKryptologieNotepad-ComputerMobiles InternetSystemidentifikationTelekommunikationComputeranimation
12:57
Exogene VariableFehlerkorrekturmodellTransponderComputersicherheitCAN-BusMessage-PassingSpezialrechnerFirmwareDifferenteDatenbankInternetworkingDemoszene <Programmierung>Elektronische PublikationTransponderReverse EngineeringMessage-PassingProtokoll <Datenverarbeitungssystem>Primitive <Informatik>FunktionalBinärcodeMomentenproblemFirmwareDifferenteMultiplikationBitProtokollierungAlgorithmusMultiplikationsoperatorCodeStandardabweichungMikrocontrollerE-MailKonfiguration <Informatik>Bildgebendes VerfahrenCAN-BusKonfigurationsraumArithmetisches MittelAnalysisSchnittmengeInformationZahlenbereichMereologieHalbleiterspeicherPerspektiveOrtsoperatorMechanismus-Design-TheorieSystemidentifikationPunktSpeicherabzugFunktion <Mathematik>Exogene VariableFreewareBootenQuick-SortComputersicherheitDemoszene <Programmierung>InternetworkingAdressraumAusnahmebehandlungOvalMathematische ModellierungEinfügungsdämpfungGeradeVerknüpfungsgliedKryptologieGesetz <Physik>GrenzschichtablösungWeb SiteGamecontrollerGüte der Anpassung
18:26
BildschirmsymbolDatenstrukturDisjunktion <Logik>ProgrammschleifeGeradeFokalpunktInstantiierungProtokoll <Datenverarbeitungssystem>DatenstrukturPunktZahlenbereichFirmwareInformationDichte <Physik>Disjunktion <Logik>FunktionalUmkehrung <Mathematik>Reverse EngineeringVariableVersionsverwaltungProgrammschleifePRINCE2GruppenoperationEinfache GenauigkeitBitOpen SourceFundamentalkonstanteComputeranimationVorlesung/Konferenz
19:46
SoftwaretestReverse EngineeringFehlerkorrekturmodellPersönliche IdentifikationsnummerKonfiguration <Informatik>Exogene VariableComputersicherheitTransponderSchwingungMathematikEin-AusgabeFunktion <Mathematik>Transformation <Mathematik>Kategorie <Mathematik>ZufallszahlenUnternehmensarchitekturBeobachtungsstudieRundungDickeExogene VariableCASE <Informatik>SoftwaretestMultiplikationsoperatorReverse EngineeringEin-AusgabeFunktionalKategorie <Mathematik>OrtsoperatorFunktion <Mathematik>Persönliche IdentifikationsnummerMereologieProtokoll <Datenverarbeitungssystem>Mobiles InternetDigitalisierungDifferenteRandomisierungSchlüsselverwaltungKardinalzahlSoundverarbeitungModallogikCoxeter-GruppeMusterspracheBitTermTransponderRISCGamecontrollerInformationZweiunddreißig BitParametersystemDichte <Physik>CodeMapping <Computergraphik>Nichtlinearer OperatorResultanteTotal <Mathematik>EinsInelastischer StoßTransformation <Mathematik>AuthentifikationCAN-BusEigentliche AbbildungPhysikalisches SystemKryptologieBimodulMessage-PassingAlgorithmusVersionsverwaltungBinärdatenDivisionPunktProzess <Informatik>Kette <Mathematik>InstantiierungAntwortfunktionWorkstation <Musikinstrument>MathematikBildschirmfensterFigurierte ZahlQuaderNeuroinformatikUnternehmensarchitekturp-BlockSystem FDatenfeldKonditionszahlPrimitive <Informatik>MultiplikationMittelwertSkalarproduktVorlesung/KonferenzProgramm/QuellcodeComputeranimation
28:46
Exogene VariableFehlerkorrekturmodellComputersicherheitBeweistheorieChiffrierungLFSRFunktion <Mathematik>KonstanteRückkopplungLFSRBitStandardabweichungKonstruktor <Informatik>BeweistheorieUnrundheitNeuroinformatikSchlüsselverwaltungGamecontrollerAggregatzustandVerschiebungsoperatorChiffrierungPhysikalisches SystemAlgorithmusKryptologieExogene VariableKonstanteProtokoll <Datenverarbeitungssystem>ComputersicherheitOpen SourceOrtsoperatorEin-AusgabeFunktionalKonfiguration <Informatik>Gewicht <Ausgleichsrechnung>Dreiecksfreier GraphFunktion <Mathematik>TabelleZählenSchaltnetzQuick-SortEntartung <Mathematik>LastLuenberger-BeobachterLinearisierungRückkopplungVorlesung/Konferenz
32:33
Persönliche IdentifikationsnummerReverse EngineeringLeistung <Physik>FehlerkorrekturmodellAnalysisCASE <Informatik>Interface <Schaltung>ZahlenbereichGrößenordnungOrdnung <Mathematik>CodeEliminationsverfahrenMereologieZweiunddreißig BitTragbarer PersonalcomputerPersönliche IdentifikationsnummerImplementierungVirtuelle MaschineBeweistheorieKryptologieStandardabweichungLeistung <Physik>Ein-AusgabeBitQuadratzahlSpeicherabzugFunktionalDienst <Informatik>UnrundheitATMSchlüsselverwaltungBildschirmfensterDeterminanteZweiLesen <Datenverarbeitung>MultiplikationsoperatorKomplex <Algebra>Funktion <Mathematik>UnternehmensarchitekturAlgorithmusRückkopplungPlastikkarteOrtsoperatorAggregatzustandDigitalisierungForcingAntwortfunktionRechter WinkelHalbleiterspeicherVerknüpfungsgliedBinärdatenGlobale OptimierungMAPGamecontrollerCompilerTransformation <Mathematik>KontrollstrukturComputeranimation
36:50
Exogene VariableFehlerkorrekturmodellComputersicherheitImplementierungSoftwarePartielle DifferentiationKryptoanalyseStatistische HypotheseTransponderFunktion <Mathematik>MomentenproblemZufallsgeneratorSystemprogrammierungMathematische ModellierungPersönliche IdentifikationsnummerAlgorithmusKlon <Mathematik>t-TestKontrollstrukturMereologiePhysikalisches SystemKryptologieStandardabweichungBitExogene VariableProtokoll <Datenverarbeitungssystem>BeweistheorieBefehlscodeZweiunddreißig BitAuthentifikationUnrundheitSpieltheorieKomponente <Software>Web SiteMomentenproblemDatenfeldZufallsgeneratorZahlenbereichSmartphoneAggregatzustandCASE <Informatik>IndexberechnungSoftwareentwicklerKryptologieAbstandInformationMultiplikationsoperatorBeobachtungsstudieComputersicherheitTransponderMereologieModelltheorieEinsPhysikalisches SystemSchlüsselverwaltungFunktion <Mathematik>AlgorithmusImplementierungOpen SourceGamecontrollerPunktRandomisierungMinkowski-MetrikStandardabweichungCoxeter-GruppeInternetworkingWechselseitige InformationKontextbezogenes SystemFunktionalMechanismus-Design-TheorieMinimalgradChiffrierungPrimitive <Informatik>Chirurgie <Mathematik>ExpertensystemEinfügungsdämpfungARM <Computerarchitektur>Digitale PhotographieEinfacher RingBimodulGeradeMixed RealityPersönliche IdentifikationsnummerAnalysisKonstanteFirmwareMessage-PassingStatistische HypotheseDienst <Informatik>Differente
45:43
MereologieZahlenbereichFirmwareSoftwareHyperbelverfahrenBootenWeb logSystemplattformNormalvektorZweiProtokoll <Datenverarbeitungssystem>AlgorithmusCASE <Informatik>AuthentifikationModelltheorieBitAuswahlaxiomInverser LimesQuick-SortMultiplikationsoperatorInstantiierungWeb SiteEinfügungsdämpfungDatenfeldVorlesung/Konferenz
47:53
EindeutigkeitRechenwerkZahlenbereichCASE <Informatik>GamecontrollerAlgorithmische ProgrammierspracheProtokoll <Datenverarbeitungssystem>PunktTransponderBimodulIdentifizierbarkeitHardwareInformationBitrateMaßerweiterungSchlüsselverwaltungPersönliche IdentifikationsnummerInterprozesskommunikationRechter WinkelAlgorithmusForcingMathematische ModellierungEinsSoftwareindustrieAuthentifikationComputervirusSoftwareentwicklerEinflussgrößeGatewayInternetworkingFirmwareMereologieProzess <Informatik>FunktionalWort <Informatik>DatenfeldLie-GruppeExogene VariableDifferentePhysikalisches SystemGemeinsamer SpeicherEinfacher RingStrömungsrichtungInzidenzalgebraWellenpaketKonfigurationsraumWhiteboardGewicht <Ausgleichsrechnung>Vorlesung/Konferenz
54:55
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:22
There is no scooter sharing. Which brings me to the next talk. We tend to need kind of a security concept for not scooter sharing. So the easiest way would be to have kind of a scooter
00:42
lock. But we have the lock picking, guys. So that won't work. So the next option would be, we can have a GPS tracker. But we have the GPS spoofing, guys. Which is not also that good. A third option would be an immobilization system.
01:04
We have Walter Bockstag. Thank you. Hi. Thank you for the introduction. Thank you guys for the warm welcome. I'm really happy to see that still some people have have come together here at this ungodly hour
01:23
to watch my talk about vehicle immobilization. Well, briefly, something about me. I'm a Kekov security master. And the research I will be presenting today, I did as my master's thesis. So I spent about half a year analyzing various systems.
01:46
And well, I wrote something about that. And if you want to read the full story, you can look at my thesis, which is public since some time now. There's more detail there. Currently working as an automotive engineer. And if you feel like asking me questions beside the Q&A,
02:03
you can always contact me by mail. So first, responsible disclosure. This kind of stuff is not a joke. Automotive manufacturers think it's very important. And well, they have all reason to think so.
02:21
So naturally, we contacted them ahead of publication, even before my defense. And we laid out the findings. I had a couple of conv calls with the manufacturers. And I even went to one of them
02:40
to demonstrate the findings on premise. I need to point out that the research that I did was on fairly old vehicles like 2009 and around. But for the three cases that I really went in depth,
03:00
we have been able to confirm that they are still in currently produced models. So this in itself is kind of surprising because you think automotive, cars, electronics, security, it's fast moving industry. But well, no, not really. So everything that was in cars in 2009, at least regarding these three systems,
03:23
can still be found in currently produced models. I will disclose the vehicles that I've been working on because I think that is relevant. I hope you can forgive me that I'm not going to disclose the vehicles that I have identified these systems in that are still being produced.
03:41
I'm not really into facilitating theft. And I don't see what would be the added value. So the talk will be structured as follows. I will first introduce some standard stuff about immobilization systems and about computer networks inside vehicles.
04:01
I will tell you something about how I addressed the challenge. So for all three models, I kind of followed a similar approach. And I think it's more practical to lay that out once and then skip the details later on. And then I will present the three protocols that I uncovered in a Peugeot, a Fiat, and an Opel vehicle.
04:24
I will then summarize the findings in a series of takeaways. And there will be some time for questions. So modern vehicles are full of electronics and full of computer systems. They operate largely independent, but they are all
04:42
connected through a variety of different buses that talk to each other with different protocols. And there is a plethora of different standards, ISO standards, all kinds of standards. And then the manufacturer wants a lot of freedom
05:01
to do it in their own way. So even if you read these hundreds of papers of standards, still every vehicle you will look at will be kind of different. There are some practical, well, handles that you can use. And one of them is that every car has a OBD2 port.
05:26
Yeah. This is required by law, both in the US and in Europe, for quite some time now. And it needs to be conveniently located. And that is very near the driver's seat.
05:43
So this is a universal connector, and all cars with a combustion engine need to have one. And cars with electronic engines also need to have one. But the functionality that has to be implemented is much more limited. So in regular internal combustion engine powered cars,
06:04
you have to be able to read out emissions data and that kind of stuff. So many manufacturers thought this was a very convenient thing to also use for garage purposes, for workshops to read out error codes, to perform all kinds of routines on vehicles.
06:23
You might need to teach new keys to your car if you lost one or if you just want a third one. If you add a towel bar to your car, you need to tell a couple of ECUs in the car that it now has a towel bar. Depends on the vehicle, but telling this to five individual ECUs
06:41
is not an exception. And since it is a bus, the CAN bus, it can be directly addressed through the OBD connector on many vehicles. And you can talk to a lot of different components. So the ECM, the engine control module is one. The body control module is another.
07:00
That one controls, for instance, powered windows and all kinds of interior stuff. But also the airbag infotainment system, fancy interior lighting, stability control systems. Another feature of it being a bus is that you can also see the intercomponent communication.
07:24
So if the instrument panel cluster, the dashboard, needs to talk to, say, the body control module, you can see that packet going over the CAN bus. All my research has been focused on this OBD2 connector
07:42
and what you can do and what you can see from this perspective. Immobilizer systems are nowadays required to be implemented in vehicles since the late 19s legislation has been adopted in both the states and Europe,
08:01
mandating the use of an electronic immobilization system. And the purpose, of course, was to reduce the risk of theft. This is proven to be effective. According to one study, theft rates dropped by almost 40% in, I think, seven year span.
08:21
They base their data on. This is because car theft used to be quite simple. You could just put two wires together and you could power the starting circuit and you could actually start the engine. And the immobilizer system adds another step to that.
08:44
The engine control module that finally controls the engine wants to have some kind of assurance that the key presented in the system is actually valid and does so by validating a security transponder. First generations of these security transponders have been widely studied and often were found insecure.
09:06
Of course, this is a problem because, well, if it's insecure, it doesn't add any security and cars can be stolen nonetheless. So there's been kind of an arms race in this domain and we see that nowadays security transponders have become a lot better.
09:22
Your car might even use AES to validate that the key you're putting in the ignition is an actual key that is recognized by your vehicle. And this is really necessary because car thieves have shown to be able to wield quite high tech solutions,
09:42
procure them from shady companies, or just use official tools that can be used in illegitimate ways. A nice example of this is shown here. For certain models of Range Rover, they have a blind spot sensor so you can see if there's a car in your blind spot.
10:03
And if you pop up off a cap, then you can connect a 12 volt battery and power the internal ECUs of the vehicle. Then you can access the CAN bus, put the car into key teaching mode, and hold a blank key to the window and it will program the key, and recognize it as a valid key.
10:23
Well, needless to say, this was not intended behavior. And this has had consequences for consumers because insurance companies saw a rise in theft for these models. These are quite expensive cars and they started adding demands
10:41
before they would allow you to insure your car. So the insurance would get more expensive or you would not be able to get the insurance if at least at your own home you couldn't park it in a secured area. There is a common misconception
11:01
about how immobilizer systems work. And it's actually one of the reasons I want to give this talk and present this because I think it's important to realize that an immobilizer system is a bit more complicated than the single cryptographic step that seems logical.
11:23
So what you might think is that the engine control module sends a challenge to the body control module which communicates with the key. It implements the radio layer and it can then relay the challenge to the key. The key can compute the proper response based on a secret it shares with the ECM.
11:43
Send back the response which the ECM will turn forward to the ECM. The ECM can verify the validity and if this seems to be the right response immobilization is deactivated and the car can start. Sounds good, sounds easy,
12:00
but this is in modern cars no longer the case. Cross. What we see is that there is a second step. The ECM does an authentication with the BCM. The BCM does an authentication with the key. So if your key uses say AES for its authentication
12:22
then this will be an AES secured authentication between the BCM and the key. The BCM, if it can validate the legitimacy of the key will then send the correct response to the engine control module. But this is a whole different protocol
12:40
using different cryptographic primitives, using different keys sometimes, often. I don't know. And more importantly it has not yet been covered. So in the scientific literature I have found absolutely zero reference of this step being identified.
13:00
And here and there you find a reference that people know that this happens but no actual analysis of the security or the cryptographic primitives involved. Right, so that is an open question then and asks for further research. So how do you do that?
13:21
You can sniff CAN traffic from the OBD connector with tooling and by disconnecting ECUs and placing yourself in the middle you can also modify CAN traffic. You can analyze this CAN traffic, see if you can find immobilizer related messages.
13:41
Of course by the messages you cannot deduce the algorithm most of the time. So you will need a firmware image or something else you can reverse engineer to actually find the code that does the magic stuff. If you have that and if you are able to pinpoint where the algorithm is then you can start looking at if it's actually decent.
14:04
And once you're all there you will want to test if all the assumptions you've made on the way are correct and if it's actually working as you think it's working. So the first step, protocol identification is actually quite straightforward because you have some knowledge.
14:21
You know that this is a message exchange that happens when you switch the ignition to the on position. And you know that there must be at least two high entropy messages because the challenge has to be different every time and the response is the output of some cryptographic function
14:40
so it may be expected that that looks quite random too. Also if you switch the ignition on but no valid transponder is present you should be able to detect some kind of difference and this will probably be the very first moment you observe a difference because before that point the car didn't know there is no valid transponder.
15:02
So with a bit of fiddling and some patience and going through CAN traffic logs you can probably find this. Okay next step is to get a firmware image in which you hope to be able to find the actual cryptographic protocol. So there are several options.
15:22
Of course you already have the firmware but it's in a microcontroller in an ECU that is either laying on your desk or inside some vehicle. So you can try to get it straight out of that device. Debugging headers are a good option. You have JTAG, you have a BDM.
15:42
UART occasionally can be used but sometimes these are deactivated. Sometimes it just doesn't seem to work. Sometimes the tooling is prohibitively expensive. So if that doesn't work you can always go to the internet. Some manufacturers provide a means to download a set of information
16:01
about the vehicle based on its VIN number. You can find all kinds of configurations. You might be able to find actual parts or full firmwares, often encrypted, not always. And then there's the tuning scene. While you might think of neon lighting and stuff like that,
16:21
these guys are actually pretty knowledgeable about the internals of engine control modules in particular. And you might just be able to find a full firmware image or parts of it or some model that is highly related. And this is kind of a viable approach to getting your hands on the firmware.
16:40
But also very practical can be to just leverage the functionality that is implemented in the ECU. The ECU allows for diagnostic commands such as read memory by address and request upload which from the perspective of an ECU is sending you data.
17:01
And you might be able to just dump the whole firmware or dump memory or dump at least parts of the internals of the ECU. Then there is some kind of mechanism that's called second bootloader. It's a sort of standard, not every manufacturer implements it,
17:20
but quite some do, that allows you to actually send binary code to the ECU and it then jumps to it. So very convenient functionality. It's maybe very painstaking to get it working, but yeah, it's basically free code execution, except for the fact that you often need to authenticate
17:41
before you're allowed to use such functionality. So that might leave you with some kind of chicken and egg problem because you don't know how to authenticate, you don't have the algorithm for this authentication. And lastly, there are sometimes firmware updates for ECUs. You might be able to use an official dealer tool, you might be able to sniff can traffic.
18:02
Multiple ways of trying to update the firmware on your ECU, reconstructed from the can traffic. Once more, you have to go through a nicer standard before you understand how it's exactly chunked in eight byte messages, but you'll get there eventually.
18:21
So once you have this firmware, you have to pinpoint the cryptographic algorithm and ECU firmwares are typically between half megabytes and two megabytes. And that is a lot if we're talking assembly. The information density is extremely low and if you have to go through it line by line,
18:40
it's hardly doable. So you need to have some tricks. I think we're at a conference where we've seen a lot of reverse engineering, so this is not going to be my focus during this talk, but a couple of pointers, maybe someone is helped by that. Of course, you know the protocol because you have observed can traffic,
19:00
so you can search for immediate values, for numerical values that are used in the protocol to designate a packet type, for instance. It must be in the firmware somewhere. Also, you know that crypto usually uses XOR instructions and you would be surprised how little XOR instructions
19:20
there are in the firmware. Depending on the architecture, you might immediately dismiss most of those as a single bit flip or maybe inversion of a whole register and then you will find some XORs with either weird constants or variables. So those are points to focus on. Lastly, you can make some assumptions
19:42
on the structure of the cryptographic function. So it certainly doesn't do IO. It will not invoke a lot of other external functions, maybe some round function once or twice, maybe some initialization. It will probably have some loops. You can sometimes recognize the length of the challenge.
20:02
You can sometimes recognize the length of the response. That being said, let's dive in the first case study. So I reverse engineered a Peugeot 207, which is, as I said, not the most recent of vehicles. And this was my test setup.
20:21
It doesn't look like much, but everything that's relevant to me is there. And you can toggle the ignition and lights will show and all the ECUs are connected through a CAN bus and an OBD connector that you can see on the left side of the instrument panel. I investigated a tool
20:41
that had a kind of peculiar function and that is that you could obtain the vehicle pin, some kind of secret you needed to authenticate for diagnostics. By connecting this tool and toggling the ignition a couple of times. So that kind of gives you a hunch that the mobilization system might be involved
21:01
because it's triggered upon toggling the ignition and that you can derive in some way the vehicle pin from this. So for this Peugeot and for most PS8 vehicles in general, the pin is a four digit upper case and numeric code, excluding the O and I
21:23
because that would be confusing. So that leaves us with roughly 1.3 million keys which is nothing in terms of crypto. I finally reversed the algorithm. It is obviously in the engine control module and the body control module.
21:40
And the main part looked like here. Oh, wait, wait for it. And the protocol looks like this. So if you observe CAN traffic, you will see that some CAN ID 72 on that ID is sent a message that starts with double zero and then followed by a four byte challenge. And if the BCM is able to verify
22:01
that the valid key is present, it will respond with 04 and a four byte response. So this is a very small and straightforward protocol which, well, which does the bare necessary. And one of the first things I did was injecting challenges.
22:22
Just inject a challenge, send it to the BCM with a valid key and see what the response is going to be. And if I replace the zeros by dots, you see that an extremely apparent pattern is visible. So the ideal case that a single bit flip
22:41
in a challenge lead to 50-50 chance of a bit flip in every response bit is not exactly respected. You see that the effect of changing the challenge has very localized effect on the response. Another weird feature which is not very clearly visible
23:01
here but is visible in the last one is that on average, when you give average just random challenges, 75% of the bits of the response will be set. So that is a very, very heavy bias and it was quite puzzling to me what kind of cryptographic primitive would exhibit such behavior.
23:24
And then it became clear. This is the main function of the algorithm and there is a transform function that I left out but it basically does some multiplication, some division, some modulo, but mathematical operations.
23:40
It splits the challenge in two parts and it splits the vehicle pin, so the secret, in two parts. And the total of four parts are all used as input for this transform function. And we change challenge transformed left, challenge transformed right, and similarly
24:00
for the pin, a left and right transformed part. And then something interesting happens because the left transformed part of the challenge is ORed with a part of the pin. And an OR operation will lead to a, well, on average 75% set result.
24:23
So that kind of explains the weird behavior we saw before. Yeah, strange and maybe not so smart. Because an adversary will be able to either control or observe the challenge that is used
24:43
as input for this algorithm. So if you know the challenge, you know the transform challenge. And if you know the transform challenge, you know something about the output. Because if the transform challenge has a one bit, then the response will have a one bit in that same position.
25:04
There is another property for the transform function and that is that if the input is a zero, the further parameters of transform vary a bit but it doesn't affect this property. If the input is a zero, the output is a zero. So that gives us that if you have a challenge
25:21
of all zeros, you will obtain a transform challenge of all zeros. And that means that when you're doing the OR, you're ORing with nothing and the response will be entirely determined by the transformed pin. Another property is that the pin,
25:42
which is alphanumeric pin, is invertible once, wait, let me restart. Transform, if it takes a pin as input, then the output can be inverted. There is only one pin part input
26:00
that maps to one output of the transform function. So if you are able to supply the vehicle with a challenge of zeros, you will get one response and you can uniquely identify the secret of the car, the pin. And this pin can later be used to, for instance, authenticate for diagnostics or key teaching or whatever you want.
26:21
If you're not able to control the challenge, you can just collect a couple of random challenge responses and you will still have the pin. So that's bad. What's worse is that there are a lot of collisions because the bits that are set in the challenge transformed will hide the bits that are set in the pin transformed.
26:44
So a challenge transformed with a lot of ones set will accept a lot of different pins as proper input and result in the same response. So there is a quite simple attack we can mount here and that is that we get a challenge from the car
27:03
without a valid key present and we then compute for that challenge for all pins what response it would yield. And you will see that some pins, sorry, some responses are generated by a lot of different pins. It could easily be two, 3,000 pins resulting in the same challenge.
27:22
So you choose the most probable response and you send it. And either the ECU accepts it and disables immobilization or it doesn't. And if it doesn't accept it, then you know for 3,000 pins that it was not that. In general, this takes far less than 4,000 attempts
27:41
and far less than 15 minutes. I don't know exactly. I've tried it a couple of times and I've been able to deactivate the mobilization, I'll say three minutes once, maybe 10 minutes once. And after that, if you toggle the ignition switch, the car will actually start without transponder present.
28:07
So that was not so good. Next case is the Fiat. I investigated the Grande Punto and I reverse engineered the BCM. It's based on the NAC VA50 architecture, which is a nice 32-bit RISC architecture,
28:24
pretty readable, pretty fair information density. But still, I couldn't really figure out what the actual crypto part was, so I also investigated an engine control module. Surprisingly, I was able to find it there.
28:41
And then I immediately went back to the V850 because that at least is readable code. Protocol is as follows. It has a 32-bit challenge, then a four-bit, sorry, yeah, four-byte challenge, then a two-bit byte proof of knowledge.
29:03
And that's an interesting feature because that way, the engine control module proves to the body control module that it actually has knowledge of the key. So you cannot just spam a challenge and get a response for that. You have to prove that you know the secret.
29:21
Then you get back a two-byte response, and if that is correct, the ECM accepts it and the car can start. And this very, well, seemingly nice security feature that there is a proof of knowledge of the key is actually the flaw in this system, as it turns out.
29:43
The cipher is a linear feedback shift register-based cipher. It initializes states with the key, sort with the challenge, sort with some constant, and then it does 38 rounds. If you don't know what an LFSR is, I will tell you in the next slide, then it generates the proof.
30:02
That is 12 rounds, actually 12 bits output, and if you look back in the protocol, you actually see that the first nibble is indeed a zero, so it's not 16 bits, but it's only 12 bits. After generating the proof, it loads an additional 16-bit constant and then generates the 14-bit response.
30:23
This is a fairly standard construction in crypto, and there is a fairly standard attack to it. So what you see here is an LFSR. It's a 32-bit register, and it operates in ticks.
30:40
So it is loaded with this initial secret state at the beginning of the algorithm, and each tick, it takes four bits, and they are sorted together. Then the whole register shifts one position to the left, so bit zero goes to bit one, one to two, et cetera.
31:01
Bit 31 shifts out, and the previously computed sort bit is shifted in in the zero position. So that way, it cycles and continuously updates its internal state. And then there is an output function that takes eight bits of input, and each tick, it computes one bit from an eight-bit input
31:25
and on the lower left, you can see the output generation table. So it kind of just counts through this, and if the eight bits together add up to, say, A2, then you pick bit position A2 in this table.
31:42
And that is then the bit that is being generated as proof or response bit during that round. Now, what we see here is that there is actually eight bits of the LFSR that determine the output bit.
32:00
And of these eight bits, they generate, so, 256 different values. Now, there are 256 different combinations, and only half will generate the observed output bit. So that means that 128 different options
32:21
may be valid options for these eight bits to generate a response or a proof that we have observed earlier. And that is pretty interesting, and you can use that to construct a guess and determine attack, which means that you make an assumption on the internal state.
32:41
We have 128 candidate internal states, and then we do a round. So we shift the guessed bits one position to the left, we do the feedback function, and then we are going to evaluate the second bit that was generated. For the second bit, we already have some knowledge,
33:01
because we made assumptions earlier. So the green squares designate the bits that we already know. And you see that throughout the rounds, each round you can eliminate half the candidates because they generate the wrong output bit.
33:21
And you need to guess less and less bits in order to fill in the state. And this continuous elimination of half the candidate states makes this far more efficient than just a brute force attack. The total complexity of this attack is two to the power of 21,
33:42
which is orders of magnitude less than mounting a brute force attack. Right, so that's okay. That is fairly standard stuff in crypto. Now there is a big problem in the way they implemented this because they did some secret reuse.
34:02
And the secret that is being used to generate the proof is, in some mangled way, the vehicle pin. If you take this 32-bit secret input value and you take the five rightmost nibbles and then transform the letters into numbers
34:20
and then replace the zeros by sevens, then you get a five-digit number and that number is the pin. So what we have now is an attack that observes a couple of challenges together with their proof of knowledge, which is always there, and you get it for free
34:41
when you just power the ECU. And you run an attack on that that takes, well, my not so optimised implementation takes six seconds on a single core. You can probably do better. Runs in seconds, and what you get is the pin.
35:00
So you can still not authenticate towards CCM, but you do get the pin, which you can then use to authenticate for diagnostic services. You can maybe read memory, you can maybe reprogram stuff, you can maybe enter key teaching mode. There is absolutely ways to leverage this and, well, get the card to start.
35:25
The third case I investigated was in Opel Astra H, and I've decided to skip the crypto part in this one because I couldn't break it. And I wouldn't want to bore you with a fairly complicated algorithm
35:41
and then not present an attack. If you're interested, it's in my thesis, so you can look it up. But there is still some funny things to point out here. I reverse engineered an ECM that was based on a PowerPC architecture microcontroller,
36:01
and that is very nice because there is a decompiler for that, and IDA Pro will nicely transform the assembly into, well, somewhat accurate, somewhat readable C code. That was good, but it was not enough, so I purchased some tool
36:21
to use the BDM interface of this ECU, which was active and usable. And it took me a lot of time to get the tools working because virtual machines were not okay, et cetera, et cetera. I installed Windows and did crazy stuff. And then I was able to read memory,
36:41
modify registers on the actual ECU, and that helped a great deal in debugging and finding the actual functions. So this is the protocol that I found. It has a two-byte opcode, then two-byte status data, then a four-byte challenge, and similarly, two-byte opcode for the response,
37:03
two-byte status data, four-byte response. No proof of knowledge here, just a 32-bit, two 32-bit challenge response authentication. And what was funny, when I finally uncovered the algorithm,
37:22
is that this is not an algorithm that was designed by Opal. It is an algorithm that is used by a security transponder. It is used by the PCF7935 security transponder, which is the predecessor of high-tech two, which you may be familiar with.
37:42
It uses a 128-bit secret, so that is a really, really big secret, and a 32-bit internal state. And when I saw that 32-bit internal state, I was like, okay, this is going to be doable. It wasn't. Because it does a lot of rounds between output moments,
38:02
not as in the Fiat case, one round, one-bit output. It does 34 rounds, and then it outputs two bits, and then it does another 34 rounds and two more bits. And during these 34 rounds, it mixes the whole 128-bit secret key into the state, and there's so much distance
38:22
between these moments that it's very, very hard to relate any of this information or have any usable assumption that survives so much new mixing of information. I did my best. I found some stuff,
38:41
nothing that is usable to mount an attack. You can read my thesis if you're interested in the details. I found it funny to find an implementation of a security transponder in an engine while I, in the beginning of this talk, pointed out that the engine doesn't talk with a transponder.
39:02
So I went back in time and I analyzed another vehicle, a Corsa Model C, and found that this was different. This car had indeed an engine that talked with the key. And what probably happened is that they wanted to decouple development of engines
39:21
and development of cars so they could upgrade security transponders without replacing their engines or replacing their engine firmwares. So I think that is how this happened and why they just decided to, well, then implement a security transponder and emulate it in the body control module
39:40
towards the engine. It seemed like an inconvenient solution, I guess. It is by far the strongest algorithm I have encountered in these three case studies. And while it is out of scope, because I limited myself to the actual cryptographic primitives, I felt the need to point out that the random number generator is really not very good.
40:04
They use the tick counter of the CPU as source of randomness, and then they use a couple of constants that if you Google them, direct you to the Netscape random number generator.
40:21
So, summing it up, we found that Peugeot used a tiny key space with only 1.3 million different possible pin codes. They leak a lot of information in the response. If you can inject a zero challenge,
40:40
you immediately get the full secret. It has a lot of collisions, which makes it really not very robust against an adversary. Fiat has a school book algorithm, and it's vulnerable to school book attack. It's a nice idea to implement mutual authentication,
41:02
but it doesn't really work in this context, and worse, they reuse that part of the secret as the vehicle pin, as opposed to using the other part of the secret that is used to generate the response.
41:20
If that would have been the vehicle pin, I would not have been able to mount this attack. And lastly, Opal decided to clone an obsolete security transponder. The successor, Hi-Tech 2, was desperately broken. This one wasn't, not by me. I have a master's degree, not in crypt analysis.
41:43
I'm not convinced that it's a secure transponder, but it is certainly better than the other two I analyzed. And also interesting is that all these three systems are still around in new vehicles. Maybe not all models, but they're still being manufactured.
42:01
So I am curious to see how this relates to other manufacturers, other models, and I think it would be interesting to do some further research in this domain and see what else is out there. So to finish with a few takeaways,
42:21
don't do your own crypto. It's often said and repeated, you are going to mess it up. Just use standardized cryptographic components and maybe try to get people that are actually security experts to implement it instead of hoping for the best. Don't reuse secrets.
42:42
These two case studies revealed that reuse of secret made the attack much more powerful than it needed to be. Minimize the number of cryptographic protocols and cryptographic primitives that you're using. The more different primitives, the more attack service you create for an adversary.
43:03
And lastly, as I mentioned before, there has been an arms race in transponder security. How is it possible that a modern car key may be equipped with AES or other fairly secure cryptographic features? And these protocols that date from 1995 and such
43:22
are still there, not replaced. Apparently no one either figured it out or there are other very important reasons to just leave them there. So I hope that was interesting, maybe entertaining. And I'll happily take any questions you have for me.
43:46
We're done. Wouter, bokstag, thank you. You know the game if you have questions. Oh, we already have questions. There are microphones. Microphones number 127 and 228.
44:00
And the internet has questions already. So we start with the internet. Internet, please. Why don't make cars more use of rings of security or a more layered permission system? Oh, well, this is embedded security. This is not a PC or a smartphone security.
44:22
It's embedded security. And I think automotive manufacturers do their best, but this is just not their game. And yeah, there is plenty of ways you could do this in a more secure manner. But they didn't. I cannot really say why not do it better.
44:43
Of course they should do it better, but I think it's understandable that, well, they're maybe a bit behind on this game that is relatively new to them. Thank you, and microphone number one. Hi, amazing work, but I have a question.
45:02
Did you find any simpler, more entertaining mistakes like storing the pin in the open in other components in the car? Well, yeah, I did do some other stuff besides the three cases I presented here. I also investigated some authentication mechanisms for diagnostic functionality.
45:23
And I didn't put them in my thesis because it's nice to have a clear message and a clear, well, line of research. But I've seen authentications that are really pretty hilarious, such as challenge, secret, subtract, response.
45:46
Answered? I think this is a yes. Microphone number two, please. Hi, thank you for the talk. Two short questions. How did you specifically choose those three cars and which parts or are parts of these flaws
46:02
fixable in a later firmware bootloader or software coding update, whatever? Yeah, okay. Yeah, I chose these cars mainly by availability. I didn't really cherry-pick models. It was just at the place where I was doing my internship, then I was, I had some platforms to play around with.
46:24
You have seen my very professional PSA setup that was the most professional I had. So yeah, this is what I had. And since I, in the end, found that they're still relevant right now, I think that wasn't really harmful in any way.
46:42
It's still, it turns out to be a good choice. Your second question was? Can those flaws be fixed in an update? Well, in some sense, except that there is no real infrastructure to roll out updates, so all the cars that are out there,
47:01
I don't think they are going to recall them to update firmwares. Normal servicing? Yeah, you can do that. It takes time, so it doesn't incur costs for the manufacturer. But what you could do, for instance, is just use timeouts in the PSA case. Make sure it's not too easy
47:21
to try lots of authentication attempts. It's not a fix, because it doesn't really fix it, but well, it's certainly a mitigation. It somewhat limits the impact. In the Fiat case, it's a bit harder,
47:41
because you cannot really change an entire algorithm because there's different engines, and yeah, I think that would be quite a hassle. You really have to change the protocol there. Thank you. Thank you. Microphone number five, please. Are the secrets unique per car, and if so, how do you handle the case
48:01
when one of the units has to get replaced? Yeah, the secrets are unique per car, and replacement frequently involves a procedure to couple the new ECU in the current system, and you just have to put the ECU there, connect to the ECU, and enter the vehicle pin.
48:23
So that is quite probably also the reason that they reuse the secret, because if you use a different secret, you have to have some kind of complicated secret-sharing protocol that, well, brings the new ECU up to speed with the key material that's being used inside the vehicle.
48:43
Thank you. Microphone number one, please. Hello. So what I'm struggling to understand here is why there was the need to decouple the communication in the first place and just split it in two. I can guess it is so that the ECU
49:01
can be trained on new keys, but then isn't it easier to just, instead of training the ECU and telling, hey, this is the new key's key, just load the ECU's key on the new transponder? So if I understand your question correctly, is that you wonder why we need two different authentication systems,
49:22
one for the key to BCM and one for the engine to BCM, and not use the simple model of having the key talk to the engine control module? That's correct. All right. You have to understand that engine development is done by different companies, and the same engine may be used in various different vehicles,
49:41
maybe even from completely different ranges, and it is complicated to give these cars a different firmware. So it's definitely possible, but they just want to build an engine and build a car and have it work together, and another car with the same engine should also work.
50:02
So it has to do with their process of developing vehicles. But then shouldn't also, I mean, I'm assuming that the part that talks to the transponder and talks to the engine
50:20
still has to match the engine communication protocol anyway. So doesn't the car producer still have to match the engine protocol anyway at some point? So why just not implement it on the key in the first place? Yeah, well, this is all speculation from my side as well. I have no inside information as to why they did this.
50:43
But I can imagine ways that they could fix this and they don't do it, and my experience is that generally this has to do with legacy and compatibility issues. They could also just embed five algorithms
51:01
in the BCM or the engine control module and just by configuration, choose the one that fits for that vehicle. I have no idea why they don't do that, but once again, these are not software companies. These are automotive companies. Awesome, thanks. Thank you, microphone number three, please.
51:21
Hello, thank you for the great talk. Once we have the OBD connected to the internet, and do you see any other like complication that could prevent me to hack the car remotely from there? OBD connected to the internet.
51:41
No, well, no. Once you have OBD access, so you can use the OBD port, you can do a lot. There are cars that use a gateway that is some kind of filter or you have to authenticate towards it before you can access the internals of the vehicle.
52:01
So it really depends on the model, it depends on the manufacturer, to which extent you have room to maneuver there. For some it will be super easy, for some it will be a lot of work, for some it might be impossible. But you certainly have a very, very good starting point. Thank you. Microphone number one, please.
52:22
Hello, did you spot any kind of anti-brute force measures during your analysis? That's question number one. And question number two is, obviously you had access to the internal communication between the BCM and ECM, but were those attacks successful on Fiat and Peugeot,
52:41
or are they doable using just the OBD2 port or do you actually need to see the internal communications? I tried to point out in the beginning of my talk that I carry out all the attacks presented and I focused only on functionality that is exposed through OBD. So yes, I did some stuff on the hardware of the ECUs,
53:04
but that was just for research. So the attacks are absolutely doable over OBD. Okay, and the previous question, which was already partially answered. So no like locking out after five failed trials?
53:23
Yeah, yeah. I did find something that was peculiar in the PSA case, and that is that if you, let me think. There is rate limiting implemented in the PSA
53:42
on the engine control module, is that right? No, on the body control module. And that means that if you spam challenges, it will at some point no longer give you the response, which sounds like a good idea, right? Rate limiting, but they did it on the wrong side.
54:03
Great, thank you. Thank you. Microphone number two, please. Have you spotted some kind of relationship between like public identifier of the car and the secret used to authenticate? Yeah, so if the VIN in some ways
54:23
could be converted in the secret, the pin code of the car. No, I see where you had it, but I haven't spotted anything like that. Okay, thanks. Questions from the internet? No more. No more. In this case, ladies and gentlemen,
54:42
bedankt Wouter Boxdag. Thank you very much.