RAMN: Resistant Automotive Miniature Network
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 275 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/52099 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Chi-squared distributionMaxima and minimaWeightComputer networkOpen sourceSystem programmingTestbedObservational studyPhysical systemInformation securityPresentation of a groupComputing platformMultiplication signOperator (mathematics)AutomationPhysical systemProjective planeUtility softwareGoodness of fitCASE <Informatik>SoftwareInformation securityFocus (optics)Computer hardwareOpen sourceExterior algebraTestbedComputer animation
01:03
Information securitySystem programmingOpen sourcePublic domainConnectivity (graph theory)InfotainmentComputer hardwareSoftwareControl engineeringPhysical systemService (economics)Data transmissionModule (mathematics)System callOSI modelAuthenticationEncryptionCAN busMessage passingFrame problemComputer wormIntrusion detection systemField (computer science)Traffic reportingTerm (mathematics)InformationVector potentialAuthorizationOpen setComputer networkSimulationCodeInformation privacyPublic domainModel theoryShared memoryComputer fileFunction (mathematics)Software developerLeakSuspension (chemistry)BitInformationCategory of beingMessage passingArithmetic meanSource codeEvoluteRight angleDifferential equationVulnerability (computing)Data transmissionCASE <Informatik>Core dumpFeedbackProjective planeRegulator geneLink (knot theory)Information securityPhysical systemComputer wormCAN busSocial classSoftware testingAutonomous system (mathematics)Data exchangeState of matterFrame problemTestbedConnectivity (graph theory)HypermediaBus (computing)Control engineeringInfotainmentoutputProcess (computing)Rule of inferenceMultiplication signBasis <Mathematik>TelecommunicationObject (grammar)EncryptionSoftwareAuthenticationComputer hardwareMeasurementComputer simulationComputing platformMereologyExergieSeries (mathematics)Lattice (order)Differential equationComputer-assisted translationStress (mechanics)Key (cryptography)Line (geometry)AdditionFocus (optics)ComputerDifferent (Kate Ryan album)DemosceneCondition numberExpert systemPrice indexWebsitePlastikkarteObservational studyGroup actionPosition operatorPersonal digital assistantCausalityOpen sourcePresentation of a groupProduct (business)Term (mathematics)Computer animation
08:24
Overhead (computing)Computer hardwareSource codeWhiteboardCAN busInformationInformation securityHacker (term)Shared memoryComputer programCASE <Informatik>Source codeSoftwareLevel (video gaming)Direction (geometry)Computer hardwareWhiteboardSoftware developerComputer animation
09:28
Source codeObservational studySystem programmingComputing platformSimilarity (geometry)CAN busAuthenticationSoftwareSource codeProjective planePlastikkarteBus (computing)Service (economics)Multiplication signOptical disc driveExpert systemPhysical systemTestbedSimilarity (geometry)Pairwise comparisonComputer animation
10:36
Beta functionRadical (chemistry)Thermal expansionMenu (computing)Military operationDesign by contractOpen sourceCAN busBlock (periodic table)Connectivity (graph theory)Socket-SchnittstellePersonal identification numberAdditionWhiteboardComputer hardwareOpen sourceMessage passingPlastikkarteSign (mathematics)CASE <Informatik>Maxima and minimaOcean currentStudent's t-testCAN busExterior algebraFunctional (mathematics)Different (Kate Ryan album)File formatSoftwareComputer wormFree variables and bound variablesRandomizationReal numberDefault (computer science)Block diagramAuthorizationState of matterVotingBargaining problemDatabaseCore dumpWeb pageMilitary baseProgram flowchartComputer animation
12:20
Beta functionShift operatorPublic domainInterface (computing)FirmwareComputerWhiteboardInterface (computing)Key (cryptography)Vector potentialTouchscreenExpressionPosition operatorComputerFault-tolerant systemProjective planeCAN busSerial portShift operatorJoystickThermal expansionSlide ruleFirmware
13:28
Frame problemCollisionElectronic data interchangeOpen sourceSimulationAlgorithmSharewareIntrusion detection systemConfiguration spaceCAN busRight angleComputer wormSoftwareDirection (geometry)Group actionSpeech synthesisSingle-precision floating-point formatBasis <Mathematik>Open sourceConnectivity (graph theory)Computer simulationLoop (music)Core dumpProcess (computing)Control engineeringFocus (optics)ComputerClosed setOffice suiteComputer animation
14:47
SimulationComputer networkEuler anglesControl engineeringKeyboard shortcutoutputVolumenvisualisierungElectronic visual displayWordGUI widgetReverse engineeringBroadcasting (networking)CAN busComputer hardwareLoop (music)ComputerSoftwareCAN busRight angleSuite (music)Forcing (mathematics)Control engineeringLatent heatSocial classPhysicalismKeyboard shortcutMessage passingEvent horizonGame theoryNetwork topologyMultiplication signAddress spaceGodComputer animation
16:09
SharewareThermal expansionWhiteboard
17:03
Control engineeringElectronic visual displayWordVolumenvisualisierungGUI widgetFeedbackSimulationoutputReverse engineeringBlock (periodic table)Shift operatorMereologyMessage passingExpressionSoftwareControl engineeringTouchscreenCodeCAN busPhysicalismAlgorithmWhiteboardGroup actionComputer simulationLevel (video gaming)Category of beingFault-tolerant systemForcing (mathematics)Decision theorySinc functionBuildingCrash (computing)Computer animation
19:00
SharewareCAN busMessage passingCASE <Informatik>CausalityMultiplication signForcing (mathematics)Vector potentialProcess (computing)Office suite
19:59
Model theoryComputer hardwareSoftwareBootingCAN busOpen sourceCASE <Informatik>ComputerComputer-assisted translationMilitary baseMachine visionCore dumpCartesian coordinate systemArithmetic progressionComputer hardwareCAN busMicrocontrollerFirmwareCommunications protocolModel theoryWorkloadProgram flowchart
21:08
Computer hardwareBootingTransportschichtService (economics)Asynchronous Transfer ModeCAN busSingle-precision floating-point formatFile formatRevision controlMathematicsBit rateRead-only memoryCodeCommunications protocolWorkloadCAN busComputer hardwareCASE <Informatik>Cartesian coordinate systemMultiplication signMedical imagingForcing (mathematics)Regulator geneSoftwareInformation securityFile formatStructural loadWebsiteParameter (computer programming)Message passingMicrocontrollerScripting languageAsynchronous Transfer ModeBootingComputer wormFreewareProgram flowchartComputer animation
22:24
Read-only memoryInformationRevision controlReading (process)WritingFlash memoryAreaReading (process)Semiconductor memoryInformationScripting languageBootingCore dumpReverse engineeringSheaf (mathematics)Revision controlMusical ensembleCASE <Informatik>Computer animation
23:15
Read-only memoryAreaPhysical systemFlash memoryFirmwareBootingComputer hardwareThermal expansionInterface (computing)Semiconductor memoryComputer programWebsiteSpeciesBootingComputer hardwareWhiteboard2 (number)Thermal expansionComputing platformAdditionInterface (computing)Module (mathematics)DebuggerSource codeJSONProgram flowchart
24:20
Computer hardwareExpressionCASE <Informatik>Ferry CorstenOpen setSuite (music)Thermal expansionType theorySoftwareSemiconductor memoryLogikanalysatorAnalogy
25:13
WhiteboardTrailGraph (mathematics)Lattice (order)DigitizingTelecommunicationTouchscreenComputer hardwareWebsiteOpen sourceComponent-based software engineeringService (economics)Computer animation
26:01
AnalogyPhysical systemFirmwareData typeBeer steinMiddlewareFrequencyTask (computing)CAN busQueue (abstract data type)Memory managementRead-only memoryAnalog-to-digital converterSystem callService (economics)Line (geometry)Interrupt <Informatik>NP-hardExt functorAddress spaceFreewareAuthenticationSystem programmingBootingInformation securityImplementationOpen sourceSimulationOpen setControl engineeringGraphical user interfaceQueue (abstract data type)Task (computing)Differential equationProjective planeInterrupt <Informatik>CASE <Informatik>ProgrammschleifeControl engineeringMeasurementFirmwareForcing (mathematics)Real numberInsertion lossFrequencyGravitationSoftwarePhysical systemComputer hardwareInformation securityMultiplication signDifferent (Kate Ryan album)Physical lawFlow separationReal-time operating systemSheaf (mathematics)Principal ideal domainEstimatorTable (information)Library (computing)CAN busImplementationMicrocontrollerOpen sourceCartesian coordinate systemPeripheralPattern languageMassComputing platformSummierbarkeitSemiconductor memoryConfiguration spaceMaxima and minimaService (economics)Genetic programmingBasis <Mathematik>Digital photographyCausalityExergieInterface (computing)DatabaseAnalytic continuationMusical ensembleProcess (computing)Game theorySeries (mathematics)Group actionOperator (mathematics)EquationPower (physics)Reading (process)State of matter40 (number)Set (mathematics)Message passingAxiom of choiceLocal ringWordWebsitePentagonEngineering drawingComputer animation
30:52
Connectivity (graph theory)CAN busMessage passingFirmwareSimulationCurvatureLogical constantCAN busFirmwareComputer programStructural loadSheaf (mathematics)CodeLine (geometry)Level (video gaming)Offenes KommunikationssystemComputer animation
32:03
Message passingFile formatData typePrice indexScale (map)Bus (computing)Suite (music)Open sourceCAN busElectronic visual displayDesign by contractComputer fileInformationDifferential equationFactory (trading post)Graph (mathematics)Software testingMathematical analysisIntrusion detection systemFile formatEvoluteMultiplication signoutputCAN busOpen sourceControl engineeringMessage passingWave packetComputer fileStructural loadComputer wormAbstractionResultantQuicksortCalculus of variationsDigital photographyTable (information)Different (Kate Ryan album)Word2 (number)Differential equationNonlinear systemModel theoryRight angleCore dumpComputer animation
33:02
Control engineeringProgrammschleifeSimulationLoop (music)OctavePrice indexSoftwareDisintegrationDivision (mathematics)Function (mathematics)ForcePoint (geometry)Open setLogical constantDependent and independent variablesMomentumFeedbackFunctional (mathematics)MeasurementTransportation theory (mathematics)Machine visionDifferential equationDependent and independent variablesThresholding (image processing)Forcing (mathematics)Physical systemGod2 (number)Goodness of fitGravitationProduct (business)AstrophysicsINTEGRALInterface (computing)ResultantOpen sourceWater vaporControl engineeringÜbertragungsfunktionAssociative propertySoftwareArithmetic progressionSet (mathematics)Multiplication signoutputGraphical user interfaceMultiplicationAlgorithmComplex numberBlock (periodic table)Control theoryBitBlock diagramCurveConnectivity (graph theory)Differential (mechanical device)Software engineeringWaveformDivision (mathematics)DiagramProgram flowchart
35:55
Sign (mathematics)Graph (mathematics)FrustrationIdeal (ethics)Control engineeringSimulationPrincipal ideal domainPerturbation theoryPoint (geometry)ForceAlgorithmDifferent (Kate Ryan album)Dependent and independent variablesSampling (music)Function (mathematics)Error messageLoop (music)ImplementationCurvatureLevel (video gaming)Logical constantIterationSinguläres IntegralBilinear mapTransformation (genetics)SoftwareOscillationMeasurementFormal verificationMultiplication signControl engineeringDifferent (Kate Ryan album)SoftwareOffice suiteImplementationFunctional (mathematics)Control systemDigitizingBound stateControl theoryDigital photographyDerivation (linguistics)Block (periodic table)Singuläres IntegralPrincipal ideal domainError messageTime domainCASE <Informatik>Function (mathematics)SummierbarkeitMathematicsTransformation (genetics)Ocean currentTunisINTEGRALMultiplicationLogical constantCombinational logicZ-transformReverse engineeringAlgorithmStress (mechanics)Point (geometry)Identity managementInformation securityIterationDivision (mathematics)Digital signalOptimale KontrolleLinear regressionEquivalence relationData conversionView (database)Goodness of fitComputerResultant2 (number)Process (computing)Arrow of timeService (economics)Cellular automatonElectric generatorSystem callLattice (order)Sound effectGraph coloringCalculus of variationsState of matterKey (cryptography)Game theoryLevel (video gaming)Maxima and minimaAssociative propertyOperator (mathematics)WebsiteGroup actionLimit (category theory)Arithmetic progressionData storage deviceMedical imagingRoundness (object)Computer animation
41:43
Control engineeringOpen sourceComputer networkError messageCurvatureFunction (mathematics)Level (video gaming)Physical systemComputer hardwareSoftwareMathematical analysisAsynchronous Transfer ModeCodeSound effectControl engineeringImplementationGroup actionSoftware development kitWordComputer hardwareIdentity managementControl theoryLibrary (computing)Functional (mathematics)AlgorithmSoftwareReal numberINTEGRALSoftware bugChainLevel (video gaming)MereologyCartesian coordinate systemPhysical systemError messageStructural loadDifferent (Kate Ryan album)SpeciesVideo gameKey (cryptography)CASE <Informatik>DemosceneHypermediaArithmetic progressionComputer animation
45:20
CodeCurvatureError messageFunction (mathematics)IntegerImplementationSoftwareCohesion (computer science)Scheduling (computing)Interrupt <Informatik>MereologyComputer hardwareCausalityLine (geometry)Read-only memoryTelecommunicationQuantum stateBefehlsprozessorObservational studyFlash memoryVorwärtsfehlerkorrekturBackupPhysical systemCyclic redundancy checkIntrusion detection systemWindowData integrityDuality (mathematics)Independence (probability theory)Level (video gaming)Core dumpAsynchronous Transfer ModeSound effectMathematical analysisSimilarity (geometry)PolynomialElectronic mailing listSheaf (mathematics)WritingIntegrated development environmentGame theorySlide rulePhysical systemBitOffice suiteBlock (periodic table)Forcing (mathematics)Recurrence relationProcess (computing)Reverse engineeringFormal languageWorkstation <Musikinstrument>SoftwareInformation securityProjective planeFood energyComputer hardwareSemiconductor memoryAddress spaceTheory of everythingObservational studyDivisorError messageCASE <Informatik>Rule of inferenceExterior algebraSheaf (mathematics)Condition numberMultiplication signTelecommunicationNumberIntegrated development environmentQuicksortState of matterMessage passingRight angleConfidence intervalSummierbarkeitVideoconferencingClosed setRankingUniform resource locatorNetwork operating systemAdditionRoundness (object)CuboidLevel (video gaming)MicrocontrollerChainActive contour modelLibrary (computing)Real-time operating systemImplementationPrincipal ideal domainCodeDynamical systemLimit (category theory)Noise (electronics)SmartphoneCartesian coordinate systemLogical constantSubsetComplex (psychology)Variable (mathematics)Functional (mathematics)Electronic mailing listFerry CorstenComputerSoftware developerReal numberComponent-based software engineeringIntegerBuffer overflowRandomizationInterrupt <Informatik>Scheduling (computing)BefehlsprozessorComputer animation
51:45
Integrated development environmentHydraulic jumpReverse engineeringVibrationStructural loadSoftware crackingLevel (video gaming)Software testingTrailGradientSimilarity (geometry)Clique-widthVideo gameOperator (mathematics)SmartphoneInformation securitySoftware crackingRegular graphNP-hardIntegrated development environmentHypermediaDegree (graph theory)Cycle (graph theory)UsabilityResultantException handlingReading (process)Right angleRule of inferenceQuicksortDecision theoryPhysicalismSoftware testingService (economics)BitState of matterDiscrete element methodLogic gateRange (statistics)MereologyDivisorSpektrum <Mathematik>Component-based software engineeringMicrocontrollerLatent heatStructural loadGradientComputer animation
54:03
Standard deviationBlock (periodic table)Computer networkIntegrated development environmentWhiteboardPlastikkarteInformation securityPrice indexVorwärtsfehlerkorrekturRead-only memoryFirmwareAuthenticationCAN busPermanentPlastikkarteComplex (psychology)ComputerOptical disc driveOperator (mathematics)Range (statistics)CybersexControl flowIntrusion detection systemBootingAsymptotic analysisSoftware testingStrategy gameIntegrated development environmentInformation securityCASE <Informatik>Message passingMicrocontrollerDifferent (Kate Ryan album)Level (video gaming)Maxima and minimaCategory of beingResultantSemiconductor memoryComputer hardwareAuthenticationDegree (graph theory)SmartphoneAreaExpressionInheritance (object-oriented programming)Stress (mechanics)Data conversionWage labourGroup actionCausalityProduct (business)Coefficient of determinationNetwork topologyUniform resource locatorBit rateMultiplication signComputer animation
58:24
CAN busInformation securityPosition operatorPhysicalismTrajectory2 (number)Form (programming)Process (computing)Control engineeringAlgorithmPresentation of a groupState of matterDecision theoryMessage passing
59:20
GradientSystem programmingInteractive televisionObservational studyInteractive televisionProjective planeComputing platformPhysical systemOpen sourceForcing (mathematics)State of matterCodecLibrary (computing)Intelligent NetworkMaizeAddress spaceReduction of orderComputer hardwareMacro (computer science)MereologyService (economics)Multiplication signComputer animationMeeting/Interview
01:00:49
Finite element methodComputer animation
Transcript: English(auto-generated)
00:03
This is a presentation about Ramen, a platform that we developed to make education and research
00:23
in automotive systems more accessible. The automotive industry can be inaccessible to many people because automotive projects may involve prohibitive costs and be tied to NDA that not everybody is willing to sign. What we want to propose with this project is an expensive test bed to study and research
00:41
automotive systems, which is both open source and developed with open source tools. So that at least anyone can get access to a good alternative for education and research. The main focus of this test bed is security, but you will see that the usage of the test bed is not limited to security, and I will keep the security talk mostly for the end
01:01
of the presentation. I will start by giving a short introduction about automotive systems, then I will present the design details of that test bed, with various demonstrations and concrete details about its hardware and software. As an example of how the test bed can be used, I will spend some time experimenting
01:22
with rules control, and by that I mean I will go through the whole development process starting from evaluating differential equations of a simple mechanical model. I will experiment with various control strategies, implement them in C, and make measurements in a driving simulator using early data from the canvas.
01:42
And I will do all that using early open source tools. This is to demonstrate how the test bed can be used, but also to have a concrete project that I can use as a reference to explain after what concretely would have been different if we were experimenting with a real electronic control unit. I will also explain how we can get close to automotive hardware and software without
02:02
selling NDAs. So the second part of the talk is mainly here to give you more information about the automotive industry in case you are not familiar with it. Before I start, let me just clarify that this is not an advertisement, we are not selling anything we present here, and we do not profit financially from it. We are simply sharing design files with permissive licenses and without royalties.
02:27
Ok so first let me give you a very quick introduction about automotive systems. You can see a core of the collection of systems divided in 4 different domains. The powertrain domain, which includes the engine and the transmission. The chassis domain, which includes the steering, column, and suspensions.
02:43
The body domain, which includes the lights, the doors, and heating. And the infotainment domain, which includes navigation and connectivity. Many of the different systems that can be found in a core are controlled by electronic control units, or ECUs for short.
03:01
There are many kinds of ECUs in a core, sometimes hundreds of them, and usually they are not hard to understand. They have a limited number of inputs, generally data from sensors and actuators, and they also have a limited number of outputs, generally to control actuators. So for example, an airbag ECU may use an accelerometer as its input, and an airbag
03:21
trigger as its output. The role of the ECU will be to use data from the accelerometer to detect a shock, and output a signal at its actuator to detonate an airbag when a shock is detected. It is very common for ECUs to leak data from other ECUs. For instance, most of the time, ECUs will need to share data with other ECUs on the
03:44
same domain. In the case of an automatic core, for example, the transmission control unit needs input from the engine ECU to determine the correct gear. If that data is critical, that connection may even be redundant. ECUs may also need to communicate with ECUs on a different domain.
04:01
For example, the brake system, usually in the chassis domain, will need to communicate its state to the stock ramp, usually in the body domain. Most of the time, the technology that is used for communication is CAN. And CAN technology uses a bus topology, which means a CAN message will be received by all ECUs on the same CAN bus. There is no authentication or encryption at the link layer, so any message can be sent
04:25
by any ECU, and security features need to be implemented at higher layers. A standard CAN frame consists mainly of an arbitration ID of 11 bits and a payload of 8 bytes. CAN FD is a recent evolution of CAN, where the payload size may be extended up to 64 bytes.
04:46
For an ECU network, manufacturers will assign a meaning to each arbitration ID and each bit in their payload. The file that determines the traffic on the CAN bus is often referred to as a DBC file. For example, assuming a LAN controller and two lamps on the CAN bus, the manufacturer
05:03
may decide that ID 123 is used by the LAN controller to communicate the command of both lamps, that ID 124 is used by the left lamp to give feedback about its status, and that ID 125 is used by the right lamp to give feedback about its status.
05:21
Each of those messages will be broadcasted periodically by the assigned ECU on the CAN bus, and will serve as the basis for most data exchange between ECUs. So that is for the introduction. There are many reasons why people may be interested in Autonomous Systems and ECU networks.
05:40
The activity that gets by far the most attention from the media is vulnerability research, but there are also other reasons. For example, owners may want to check their class compliance with regulations, such as emissions regulations and privacy regulations, for example GDPR. Other owners may want to exercise their rights to repair, if they are guaranteed
06:03
by the country they live in. And finally, some owners may want to experiment and innovate with DIY features, or simply satisfy their curiosity and educate others. And while those may be valid reasons to experiment with a car, manufacturers are typically against people tinkering with a car because they may be worried about their intellectual
06:22
property being stolen, about vulnerabilities being exploited, or people hurting themselves and others while tinkering. And what probably suffers the most from this delicate situation is education and research in automotive security, because people cannot easily get access to safe equipment or access
06:41
to the information that they would need. In the long term, this may mean that manufacturers will have less security technologies to choose from to secure their cars, and that less talents will be available to develop and evaluate them. And the development of cars involves many people from many companies, so it is important to make sure that everyone involved is competent in automotive security.
07:02
And some people are pushing for more open sourcing cars, and who knows, maybe one day a car will be 100% open source, but if it happens, it is going to take a long time. And manufacturers themselves do not have access to 100% of the source code of the cars
07:22
they make, because ECUs contain intellectual property from other companies. So this is mostly a political topic, so there is not much we can contribute to as researchers. However, one way we can contribute technically right now is to try the other way around and use what is publicly available to make it accessible to learn and research automotive systems.
07:46
And that is what we try to do with Ramit, which is the topic of this presentation. The objective is to provide a platform for research that is open, and by that we mean it should be easy to modify the source code and reprogram the ECUs, accessible, and by
08:04
requiring no prior skills in automotive systems, safe with no risk of accidents or legal repercussions, and motivating something that you can interact with, so that you get the same kind of experience as you do when you experiment with a wheeled car. There are already some solutions available if you want to experiment with an ECU network,
08:23
besides of course a wheeled car. The first one is making your own testbed from wheeled ECUs, so we can see many hackers sharing their testbed at security conferences, and usually if you see something like this, you stop and you immediately get interested. So it is the next way to motivate people to learn. Unfortunately, those are not easy to reprogram because manufacturers do not share information
08:44
about the ECUs, and they require a lot of skills to build, so it's not accessible to everyone. Another option is to use development boards such as Arduino, and that is what you can see mostly on academic papers, they have the advantage of being reproducible, and you
09:02
can modify the source code as you want, so they can be used in many cases for research, but they lack many safety features often found on actual ECU hardware and software. Even if you are able to simulate a canvas, you don't get the same level of direction as you do with a car, so it's not something that motivates people and makes them want
09:25
to learn more. And the third option is to use a professional testbed, such as PASTA, another work from our team. This is a good option because you get access to the source code and you can reprogram the ECUs, and the canvas network is already simulating a full car, so the groundwork
09:42
is already done. It's a major drawback, though, that it is very expensive, so it is not accessible to everyone. So there are some options to study and research automotive systems, but none of them seem to be both accessible and motivating at the same time, so many people don't even think of learning about automotive systems because it never occurred to them that they could
10:02
like it. And in comparison with other industries, you have so many ways to get started. If you want to learn about Linux, you can start with a Raspberry Pi. If you want to learn about electronics, you can start with an Arduino, and so on. So we wanted something that would give a similar experience, but for automotive systems.
10:25
So we noticed that most of the testbeds that people are using to experiment with ECUs are made of four ECUs, so the ECUs are often communicating with each other using a canvas. So we tried to fit all that in a PCB the size of a credit card, and we named that
10:41
PCB Ramen. It features four ECUs connected over a common canvas, or canvas debus, which is accessible from outside by a terminal block. One of the ECUs is also connected to USB, which is also the power supply. Pin sockets can be used to connect sensors, actuators, and additional hardware.
11:03
And the board features many probes to easily access important electric signals. The four ECUs simulate a CAN network with messages identical to PASTA. The name Ramen is obviously a reference to PASTA since it is a cheap alternative mostly
11:21
aimed at students. In real course, CAN messages typically have different payload sizes, but by default we operate with maximum payload size to demonstrate heavy traffic. The basic format is like this, arbitration ID, two bytes for the data, two bytes for a counter, and four bytes of additional data, random data used as a placeholder for
11:41
additional data such as checksum or MAC. You can easily modify the CAN messages arbitration ID in format, and here we are assuming a full bi-wire vehicle, which means all physical functions of a car are accessible to the canvas, which is usually not the case on current cars.
12:01
The block diagram of Ramen looks like this, and as I explained earlier, all ECUs are periodically exchanging messages on the CAN bus. If you connect a CAN adapter and have a look at the traffic, it will typically look like this.
12:21
So the board itself is enough to simulate an ECU network, but it does not look very motivating. What we wanted on top of this was some sensors and actuators to make it more interactive. So we created four expansion boards for sensors and actuators to simulate the engine. For the engine containment domain, we simply use a screen.
12:40
For the body domain, we use an engine key and some LEDs. For the chassis domain, we mainly use a slide switch to simulate the side brake and a rotating potentiometer to simulate the steering wheel. And for the powertrain domain, we use slide potentiometers for the brake and accelerator
13:01
and a joystick for the shift lever. The ECU connected to USB implements a standard CAN or CAN FD interface, either over a standard serial port using SLCAN or over an active interface on Linux, thanks to the Condolite firmware project. If you connect the board to a USB port on a computer, it should be recognized as
13:22
a USB-to-CAN adapter, so it is not necessary to own an external CAN adapter to get started. This is a demo of what it looks like to use RAMEN. Just connect it over USB. If you use Linux, you can get it to be recognized as a standard CAN network interface, so it will show up in its config.
13:42
Then you can use various tools available on Linux to observe the traffic. For example, CAN Sniffer. Here you can see the traffic explained earlier, the CAN IDs on the left and the payload on the right. So with this, we can simulate an ECU network with sensors and actuators.
14:03
This is enough for basic interactions, but it still does not feel like you are actually experimenting with a car. Ideally, the ECU should be performing realistic ECU functions, not just lighting up LEDs based on some switches and potentiometers. And for this, we found that a connection in a closed loop with an open source driving
14:20
simulator would be an affordable and safe solution to feel like you are driving the ECU network. Fortunately, there is a great open source driving simulator for autonomous driving research. It is called CarNow. It features a Python API, so it is very easy to interact with it. And it also comes with an example self-driving algorithm, so you can immediately start
14:43
experimenting with your virtual self-driving car. So we wrote some scripts so that most sensors value, for example speed and altitude, will be simulated on the computer running CarNow, then broadcasted on the CAN bus. On the other side, we made it so that all controls of CarNow, such as throttle, steering
15:02
and brakes, would be decided by the ECU network. And this is what you could refer to as hills, or hardware in the loop simulation. In the automotive industry, Raman is not as advanced as professional tools, but at least it is accessible.
15:29
So to achieve manual control, it is not complicated with CarNow. On the manual control example provided with the API, there is a wide true game loop that reads events from the keyboard, applies controls, then updates the physics simulation.
15:44
So CarNow does not simulate a CAN bus by default, so we created a Python class to easily interact with the CAN bus using the CAN messages specifications of Raman. To integrate it with CarNow, we just need to replace keyboard controls with actuator control data read from the CAN bus. To close the loop, we broadcast sensor data using CAN messages, based on data retrieved
16:05
from the Python API of the physics simulator. And with this, we are able to control the car manually with the potentiometers on the board. Here, I gently press accelerator, release the handbrake, and I can control the car using the steering wheel on the expansion board.
17:04
So manual control is nice, but automatic control is better, because ultimately we want to focus on working on the CAN bus. So on the original CarNow project, there is also an example screen for automatic control. Again, there is a wide true loop, where the code basically simulates the physics,
17:20
lets the self-driving AI make a decision, then applies the controls to the physics simulation. To integrate Raman with the self-driving algorithm, again, we need to replace the apply control part with the controls from the ECU network. We also need to send CAN messages with sensor data retrieved from the Python API of the
17:40
physics simulation, that is identical to having manual control. What we need to do more is also send message to broadcast the status of the AI to the ECU network, so that the ECU network knows what controls the AI algorithm is requesting.
18:03
Periodically, the AI will broadcast its status by sending messages over USB, which are converted into CAN messages by the ECU connected to USB. All ECUs on the network will receive those messages, and will decide the actual controls of the car based on their own algorithm.
18:21
For example, the Part 1 ECU may decide to apply brakes, depending on the highest value between the AI brakes and the brake potentiometer. All ECUs will receive the CAN message that applies the control. Some ECUs may filter that message if they do not need it. Some ECUs, like the POD ECU, may process it and take action.
18:43
For example, if the brakes are engaged, the POD ECU will light up the stop lamp on the expression board. Finally, the ECU connected to USB will forward the brake controls to the simulator that will apply the brakes in the physics simulation.
19:02
So this is what it actually looks like. All I need to do again is release the handbrake, and the car will drive itself. The car is controlled by the ECU network, so when the car stops in the simulation, it is because the controls were applied on the Powertrain ECU. You can see that the stop lamp lights up, because the POD ECU also received and processed
19:22
the brake CAN message. Since the ECU is in charge of the controls, I can force the car to stop anytime by forcing brakes on the Powertrain ECU potentiometer.
19:45
So if you connect an external CAN adapter to the CAN bus, you will be able to send and receive messages. So using RAM end, you can experiment with the CAN bus of a self-driving virtual car.
20:02
When you want to reprogram an ECU, in the real world, you have two options. Either you interact with the hardware workloader of the ECU's microcontroller, which depends on the microcontroller's model and manufacturer, or you interact with diagnostics and calibration software, which depends on the car model and manufacturer. Diagnostic and calibration are often done on the CAN bus, but other options may be
20:23
available. For example, protocols are defined by standard documents. You often hear about UDS and OBD2, which both rely on the same transport layer IOTP. But there are also other protocols, such as Keyword Protocol 2000 or XCP.
20:41
All those protocols can often also be implemented over other layers. For the hardware workloaders, it depends on the microcontroller manufacturer. For example, for an XT-M32 microcontroller, you can reprogram the firmware by interacting over CAN, according to the application node 3154, over USB, according to the application
21:02
node 3156, or using other protocols defined in other application nodes. In the case of RAM end, we use the hardware workloader to reprogram the ECUs, and we can also use the UDS protocol over CAN. And in the future, we may consider adding XCP and KWP2000.
21:23
How to reprogram an ECU using calibration and diagnostic software is a topic that is already heavily discussed at automotive security talks, so I will not spend time on this topic. You can find the definition of the standards online. Usually, you need to pay for them, but you can also find summaries for free on some websites.
21:42
For example, Wikipedia. What is more interesting to discuss here is the hardware workloader. The various ways to force a microcontroller into bootloader mode are described in the application node 2606. The format of CAN messages you need to send to interact with the bootloader is defined
22:03
in the application node 3154, and it's not complicated. The format is simply command byte plus arguments, all that within the same CAN message payload. So we wrote some script to make it easier to interact with the bootloader.
22:26
So here, I am showing the script that we use to interact with the bootloader. First thing I do is retrieve all information from the bootloader, including the version, the supported commands, and the chip ID. I then use a read memory command to dump unknown sections of memories.
22:42
This includes ECU firmware, so it can be a good start to start experimenting with reverse engineering.
23:00
You can also activate memory without protection and see what happens when you try to dump the memory again. And in this case, it's not allowing memory dumps anymore. You can remove the memory protection, which will wipe out the memory.
23:23
And after you do that, you can use the bootloader to reprogram the ECUs.
23:47
For the hardware, we also designed additional expansion boards with various features. First one is an expansion to connect the JTAG debugger. Second one is a board to add external QuadSPI memories, which have SOIC packages such as EPROM, FRAM, FlashNord, NAND, SRAM, and so on.
24:04
The third one is a board to add a trusted platform module. And the last one is an interface to easily connect a chip whisperer.
24:22
All those expansions are compatible with each other, so you can stack them and create a very advanced ECU network with all ECUs featuring a TPM and one gigabit of memory. And it looks better when many expansions are stacked on top of each other. Since we would like to use RAMN for education, we tried to vary the type of electrical signals
24:44
used in the expansions. And we added many external probes to easily connect external tools.
25:04
You can use one of the many external probes to connect an oscilloscope and have a look at analog signals, for example, here's a bright potentiometer, or connect a logic analyzer and have a look at digital signals, for example, to analyze SPI communication between
25:25
the ECU and the screen. For the hardware design, we kept it simple using only two layers and keeping all components on the same side. We designed the hardware with large tolerances, so it should be easy to produce with most
25:42
PCB fabrication services. We used components with large drives, so if you have some skills in soldering, you should be able to solder one yourself. We designed the hardware using KiCad, which is an open source tool for designing hardware.
26:04
You can easily modify the schematics, layout, and even generate nice PDUs. The firmware is designed using STM32QID. It is accessible to beginners, and you can easily reconfigure peripherals and clocks
26:21
from the graphical interface. You will even get some statistics, such as estimated power consumption. But of course, you do not need to use the graphical interface and libraries if you would rather program everything yourself by interacting directly with registers. We use FreeRTOS as a real-time operating system.
26:41
The basic software of ECUs have several tasks running in parallel, one for receiving CAN messages, one for sending CAN messages, and several periodic tasks to take care of the ECU control loops. Those tasks receive data from different interrupt services routine, using queues and DMA memory overwrites.
27:01
The tasks can also exchange data between each other using queues or memory overwrites. Again, to keep the project accessible to beginners, we did the OS configuration using the graphical interface, where you can see all tasks as a configuration, for example, the priority. You can add or remove interrupts, and you can also configure the various queues in memory.
27:25
There is still a lot of memory left, even on the microcontroller with the less performances. So you can easily add your own application and double this. So that's all for the hardware and software section.
27:42
You can find more details on GitHub. I would like to move to the next section now and show you a usage example. There are usually two patterns for people working in automotive security. Either they are automotive engineers who learn about security, or they are security engineers who learn about automotive systems. Since this is a security conference, and I assume most people do not need me to explain
28:04
how the platform can be used to study and research basic security topics, I will focus on the automotive side. The diagnostics and calibration topic is already covered by many security talks, so I will not spend time on this.
28:24
So I will spend time on something that is not often mentioned in security conferences, control algorithms, and safety-critical hardware and software. And for this, I would like to demonstrate the design of a PID controller for cruise control as an example.
28:42
I will show you how the knowledgeable control systems may be relevant to security engineers, and how many of the activities that are done by engineers in the automotive industry can also be simulated using open-source tools, including RAME. Once we have an implementation in C that works, I will then use it as a reference
29:02
to talk about safety-critical systems and the differences with real ECU hardware and software. So let's get started. Cruise control is very simple. When a human is controlling the throttle with an accelerator pedal, depending on their skill, the car may have an even speed.
29:24
What we want is an ECU that optimizes the control of the throttle so that we can maintain a steady speed. An automatic car can be very easy to model. If you press the accelerator pedal, which opens the throttle, you will get speed out
29:41
of your car. But the relationship between speed and throttle is not as simple as a multiplication. Now, we have to follow the laws of dynamics, in this case that the sum of forces on the car is equal to its mass times its acceleration. We can consider that there is a force pushing the car that is proportional to the throttle,
30:01
and that there is an opposing force proportional to the speed due to friction. When we solve this differential equation, what we expect to see is the speed follow an exponential curve, and a simple way to control the speed that may come to your mind is open-loop control.
30:20
You make some measurements on a flat road of the relationship between throttle and maximum speed, and you keep it in order on the lookup table. When the user asks the ECU to reach a certain speed, the ECU can use the lookup table to find what throttle control should be applied based on path measurements.
30:40
And this may work in some situations, but according to the laws of dynamics, as soon as we reach an upward slope, the car will lose speed because of gravity. So at least that is what we expect, but we should verify that on a canvas. This is something we can use RAM and FOR. Here I am using an external CAN adapter connected to a second PC.
31:06
On that PC, I simply receive data from the physical canvas. For the rest of the section, I will only be modifying the firmware on the powertrain ECU. I will not change the simulator, I will not even reboot it.
31:25
So in the simulator, I drove around in the city to find a nice place to experiment. More precisely, I looked for a place with a flat road, followed by an upward slope.
31:40
Then I programmed the powertrain ECU to apply a constant throttle, which is only one line of code. And after reprogramming the ECU, I left the car drive straight, and I recorded data from the canvas.
32:05
I use an open source tool for CAN bus analysis called BusMaster. BusMaster allows you to load DBC files or to input manually the format of your CAN trains. Here I simply told BusMaster what were the CAN abstraction IDs of the throttle control message
32:22
and the speed sensor message, and what was the format of the payload. Once I do that, I can upload the evolution of the throttle and speed over time. And the results we get are exactly what we expected from our differential equations. The speed of the vehicle is following an exponential curve, and as soon as we reach the upward slope,
32:44
we start losing speed because the throttle is constant. There are some nodes and nonlinearities at low speed, but overall it seems our model of the car is correct. We are approaching the problem correctly. What we can see here is that it takes around 40 seconds for one test drive.
33:03
And 40 seconds is already too long. So before testing the ECU in the driving simulator, we want to use a software that can simulate differential equations so that we can see the impact of the cruise control algorithm directly without having to wait 40 seconds. Most of the time, this is done using a professional tool, such as MATLAB or Simulink, MATLAB and Simulink.
33:23
But here we will use the open source tool Scilab. It has a graphical interface where we can connect inputs and outputs from a block diagram. Differential equations are a bit hard to deal with because the relationship between inputs and outputs is complicated.
33:41
What you typically do in control theory is use a Laplace transform, which will change the variable from time t to a complex number called s. This may be complicated with our control theory background, but you just need to know that the differentiation is equivalent to multiplication by s, and that an integration is equivalent to division by s.
34:00
And our system is easier to model with the Laplace transform because we now have a simple relationship between throttle and speed. Speed equals transfer function of car times throttle. And based on the measurements from the canvas, we can evaluate the transfer function of the car
34:21
to be equal to approximately one over one plus four s. We can simulate the car in Scilab by using a block function, which has the exact same transfer function. Using Scilab, we can test various scenarios and get the results immediately. Here, I am testing the scenario in which we start from zero speed,
34:42
apply a constant throttle, and after 20 seconds, we add a new force, gravity, which corresponds to the slope. And this is what we call here the disturbance. And with Scilab simulation, we can verify we get waveforms similar to measurements on the canvas. With a constant throttle, the speed follows an exponential curve
35:01
that is close to maximum speed after around 14 seconds. And as soon as there is a disturbance, the gravity here showing green, we can check that the car loses speed because there is no reaction from the throttle. So to fix that, the solution is obvious. The ECUs need to have feedback.
35:23
We need the ECU to make use of the speed sensor data that it can find on the canvas so that it can adapt the throttle to the actual speed of the vehicle. So first solution that may come to mind to software engineers is bank bank control. Bank bank control is quite simple.
35:41
You measure the speed, and if it is above a certain threshold, you stop applying the throttle. If it goes below a certain threshold, you apply the throttle again. This is extremely easy to implement in C on the ECU. And once we reprogram the ECU on run end, we can make measurements on the canvas
36:01
and verify that this time we are not losing speed anymore when we reach a slope. But as you can see, there are some oscillations. And as you can imagine, the oscillations are not something very nice for passengers. Apparently, people driving like this is the reason cruise control was invented.
36:21
I do not know if that story is true, but I can believe it. So bank bank control made a good start, but it is not good enough for cruise control. And the most famous algorithm used in control theory is a PID controller. You can find a lot of resources online, but PID controller is one of the control mechanism
36:42
used in software by the self-driving AI of Cara. In the PID controller, you measure the difference between the target speed and the current speed. You call that difference the error. And you can control the throttle using the sum of three control blocks, the error multiplied by Kp, the integral of the error multiplied by Ki,
37:02
and the derivative of the error multiplied by Kd. Kp, Ki, and Kd are constants called gains. And you need to have a very fine tuning of those gains to achieve optimal control. Here, I can simulate the PID controller using Cylab
37:23
with different blocks. Remember that the division by S is an integration and the multiplication by S is a derivation. Thanks to the simulation, I am able to try many values before having to actually drive the car. And when we are able to find correct values, when we are able to find correct values
37:41
for the PID controller, we get this. So ECU is able to reach a target speed quickly without oscillations and without overshooting the maximum speed. And when there is a disturbance to gravity, it will dynamically adapt the controls of the throttle
38:00
so that the target speed is maintained. So this is good, because this is what we want for a cruise control. But is a gain of only one control block is incorrect? The speed of the vehicle may look like something totally different, potentially dangerous. And this is why the integrity of calibration data is important, not only from a safety point of view,
38:21
but also from a security point of view, because an attacker should not be able to make an ECU have a dangerous behavior with only one small change. And last thing I need to explain is how to implement this algorithm in C. And this is not obvious
38:41
because we are dealing with integration and derivations, which are not possible for digital functions. So there are many ways to implement this in a digital PID controller in C. I will just explain two approaches. The first approach is to stay in the time domain and approximate the derivation
39:01
by the difference between two successive errors divided by the sampling time. And we can approximate the integral operation with a Riemann sum, which is a running sum of all errors so far multiplied by the sampling time. This may look a bit intimidating, but when you look at it closely,
39:21
you can see it is just a combination of constants and values that can be computed from current and path sensor values from the canvas. So actual implementation in C looks like this. We need to define two variables, one to store the running sum of errors
39:41
and one to store the error from the previous control loop execution. In the control loop, we define constant gains for each stage. We compute the current error. We add the error to the sum of all errors. We compute the difference between current errors
40:02
and previous error. We then add all those value with that respective gain to the output variable, and we clone that output in case it goes out of bound. We then apply the photo control and save the current error in the previous error variable for use in the next iteration.
40:25
The second approach is to use the Laplace transform of the PID controller. We first need to convert it to a Z transform, the equivalent of Laplace transform, but for digital signals. It looks a bit complicated, but there are many tools to do the conversion for you.
40:42
If you want to do the conversion by hand, one way is to use the bi-linear transformation in which you replace S by this to approximate the Z transform of your ECU.
41:01
And again, this may all look a bit intimidating, but you can actually compute the photon output by using the photon output from two iterations ago, the current error, the previous error, and the error before that, which can all be computed from sensor values on the canvas.
41:20
And while this control algorithm is equivalent to our previous implementation, it looks totally different. And what I would like to stress here that identical control algorithm may have very different software implementations, which may be relevant for reverse engineers.
41:45
I only show the first implementation and not waste time, but you can see now that the ECU in Raman is able to make the car maintain a constant speed if a dynamic control of the photon.
42:03
So that's it for the example, I just wanted to show that Raman can be used for realistic activities on the canvas and that the ECUs are not just doing some random easy work. The control theory part may be complicated. And if that was going too fast for you, at least I hope it proves there is a lot of things to discover and experiment with,
42:22
and that all that learning can be done with open source tools. Now, I would like to discuss what would have been different with real ECUs, because as you can imagine,
42:41
actual ECU software is not as simple as this. I will also show you what identities we have to technologies hidden behind NDAs so that we can get as close as we can to real ECUs. We show that Raman in Raman that this cruise control ECU worked, but we only tried it on a single scenario,
43:01
namely a flat road followed by an upward slope. But what about the scenario in which the car in front is driving slowly? Or what about the scenario in which we are in a downward slope? In this case, the ECU would not be able to prevent the car from going too fast because it does not have access to the brakes, which could lead to an accident.
43:23
And the difficult problem here is not whether you can think of one more scenario. The difficult problem is, can you think of them all, and are you sure? And thinking of all dangerous scenarios, quantifying the risk and implementing countermeasures is what makes automotive systems really different.
43:44
And to prove that an ECU is reasonably safe, you ideally need to follow ISO 262 standard, which is a standard for functional safety. The standard defines different requirements at many levels. Not all ECUs are equally critical,
44:01
so safety-relevant ECUs are assigned an automotive safety integrity level, or ASIL for short. And ASIL-A is the less critical level, and ASIL-D is the most critical level. So if you were to design a real cruise control ECU for use in a real car, you could not just connect some random ECU to the canvas
44:22
and try it on the highway. You will need to go through a lot of analysis, just such as HAZOP, HAVRA, FMEA, STPA, and so on. Usually, there are so many requirements that it cannot be tracked with only a human and a sheet of paper. They are managed using dedicated tools,
44:40
such as rational tools. Now let's discuss how the software will be different. The main contribution of automotive software is to realize control algorithms safely. But without countermeasures, many things could go wrong. For example, there could be bugs in the ECU application code.
45:01
Even without any bug, the software may not be robust enough when there are transient errors in the hardware. There could also be problems with the tool chains that compile the firmware, and problems with the libraries and RTOS.
45:23
And when we have a close look at the PID controller implementation, which seemed good enough in our testing, we can see it is actually a terrible implementation. We're mixing integers and unsigned integers and floats before proper checks and typecasting. We're not checking for overflows and other random software issues.
45:44
And this is not acceptable both for safety and security. And in this case, the problems were obvious on purpose, but sometimes it can be very hard to spot because they stem from very subtle computing issues. And those issues may lead to system failures. So to avoid such scenarios,
46:00
the automotive industry usually mandates the use of a language subset, which restricts what developers can do, but make sure that numerical errors are less likely to happen. So usually, usually in the automotive industry, the standard that is used is MISRA-C.
46:20
And it is very similar to CERT-C, which is popular in the security industry. Using a language subset is only one of the requirements that are detected by ISO 26262. So there are many other requirements. At a high level, they try to enforce a low complexity of the software.
46:40
For example, by restricting the size of components, restricting the coupling between software components and making sure the scheduling is appropriate and that there are not too many interrupts. But they also have more concrete requirements, such as restricting functions to one entry and one exit point, forbid dynamic memory, avoid global variables,
47:01
limit the use of pointers, and so on. The other issues we have to deal with, which is unrelated to bugs, is transient errors. In a harsh environment, data is not always reliable. There may be a bit flip occurring outside of memory, for example, because of noise and communication lines.
47:21
But there also may be bit flips occurring inside a microcontroller's memory, for example, because of cosmic rays. Those issues do not originate from software, they originate from hardware, but they do need to be addressed by software. Because remember, in the case of the example cruise control ECU, just one bit flip could lead to unwanted behavior
47:41
of the ECU of the car. So to address these issues, automotive microcontrollers need special contour measures, for example, having redundant memory or having redundant CPUs. In ECUs, you will typically find microcontrollers that have been designed specially for automotive use.
48:03
All those microcontrollers require you to sign an NDA, so you can just buy them and start programming them. So that makes it a bit hard to study an actual ECU microcontroller and real automotive software. But ISO 26262 is not the only standard
48:20
for safety critical systems. ISO 26262 is actually derived from IEC 61508, so they are both similar in their concepts. And IEC 61508 microcontrollers, they do not require NTAs for most of the activities you may be interested in. And more completely, RAMAN can be used with STM32L4
48:43
or STM42L5 microcontrollers. And for those microcontrollers, you do not need an NDA to download guidelines on how to implement safe software. For example, you can find a list of features that are required for safety applications, and you can request more data that you would need to actually achieve compliance with IEC 61508, such as the FMEA and FMEA.
49:05
But to obtain those data, you would need to sign an NDA. Now, I personally do not think that those data are essential for education and research. So using such microcontrollers is a good alternative. But again, let me stress that this is an alternative
49:21
for learning and researching, not for actual use in the car. I don't have time to detail all the safety features. Let me just talk about memory redundancy, since this one impacts the code of the application of the example cruise control ECU. So in the example,
49:41
we wrote the gain of each stage in code memory, defining them as constants. For a safer application, they should not be here. They belong to another section, the data flash, where ECC protection can be activated. If possible, calibration data should be stored twice with flex sums and preferably max.
50:00
If you're not familiar with ECC memory, it is a kind of memory that can detect the flips and sometimes automatically correct them. Well, not that memory is also available for the RAM, but not at all addresses. So in the application, we have to ensure that safety critical variables are placed in a section of RAM in which bit flips can be detected.
50:21
In this case, in section S1-2. For data in RAM that are actually constant, such as the gains, you may also want to activate script, activate write protection, a feature that is only available in S1-2. Okay, last slide about software. In the example cruise control,
50:41
we're using GCC tool chain. In ISO 26262, it is a requirement to have what is called a tool confidence level to ensure that tool chains will not introduce errors, as it could be the case with some optimizations. So normally you could not use GCC. Real-time operating systems and libraries may also add problems. That is why they need to be certified.
51:01
Both STN42HAL and three RTOS are compliant with BISWASI, which is nice, but they are not compliant with ISO 262. However, it looks like ST is bringing all zero RTOS into the ecosystem, and that one is actually pre-certified ISO 26262. So maybe in the future,
51:21
it will be an option to experiment with an actual ISO 26262 operating system. So now let's talk a bit about hardware. In case it was not clear to you, you cannot use commercial electronics to implement an ECU. Smart phone vendors will often warn you not to let a device in your car because a parked car can reach extreme temperatures
51:43
that commercial electronics are not designed to resist. And if you think that the life inside the cabin is hard, you should think about an ECU, which has to stay in the engine compartment and operate without failures. And you would not think of putting your smartphone on an Arduino here and trust your life with it.
52:03
And extreme temperatures are just one of the many environmental factors that make it difficult for an ECU to stay reliable. The ECU also needs to resist high humidity, corrosive gases, vibrations, micro-cuts, load dumps, electrostatic discharges, electromagnetic noise, and so on.
52:24
And when subjected to such a harsh environment, many things could go wrong with electronics. You probably know about corrosion, but many other physical phenomena are at risk of happening to the components, solder cracks, intermetallic growth, whiskers, dendrites, electromagnetism, et cetera.
52:42
For example, whiskers are metal growing out of electrical components, and dendrites are metal leaving the plus side towards the minus side. And many other phenomena may result in a dangerous failure. So obviously, ECUs need to be designed to resist harsh environments and hard countermeasures against all those potential failures.
53:01
ECUs need to pass various tests that simulate harsh environments. Those tests are usually defined by manufacturers, and the test specifications are not made public. What is made public, however, is the test specifications for individual electronic components. And those tests are usually defined by AEC, so the Automotive Electronic Council.
53:22
And you can have a look at them online. For Raman, we tried to follow design deadlines similar to those of we ECUs, but of course we cannot follow actual rules as it would be much less accessible. Completely, we selected AEC 200 grade zero components for everything except collectors and microcontrollers,
53:43
because those may require NDA or not be easily accessible. Depending on the part reference, ECU microcontrollers may be usable from minus 40 to 125 degrees. Raman tried to stay close to automotive grade, but it is still not automotive grade, especially in the reliability department, so it cannot be used as a real ECU.
54:04
And the reason we try to stay close to automotive hardware is to help researchers evaluate the impact of manufacturing tolerances and environments, because remember, manufacturers are making millions of cars, that needs to operate on a large operator range. So if you are developing, for example,
54:20
a security technology that relies on hardware characteristics, such as the clocks of the ECUs, you will need to prove that the technology works despite manufacturing tolerances and harsh environments. And with Raman, it is easy to have a large sample of ECU networks, and since they are small, they can easily fit in various testing equipment.
54:43
And now let's move on to the last section, security. So in the automotive industry, they just cannot apply the same reasoning as you do in many other industries. For example, a credit card, if you detect the temperature is too cold, it may think that it is a tampering attack and decide to shut down,
55:00
because it is not safely critical. On the other hand, the card needs to start quickly, because the user should not be left out in the cold. And also, credit cards have an expiration date, so they do not need to guarantee security for more than a few years, but cards do not have an expiration date. If they are well-maintained,
55:21
they may be used for several decades, and the security technologies should keep on working. So in the end, automotive security technologies have different requirements. Unfortunately, according to past research, a security technology is often less reliable when you extend its operating temperature range and its lifetime.
55:40
For example, at low temperatures, you may be vulnerable to cold boot attacks. At high temperatures, it has also been shown that electronics tend to be less reliable concerning leaching attacks. And in those papers, high temperature means something like 60 degrees or 100 degrees Celsius, far from the maximum temperature required for some issues.
56:02
Also, it has been shown that a higher age for electronics usually results in different security properties. And you may think that the safety features of automotive microcontrollers will prevent some attacks such as leaching attacks, but it has been shown that ECC memories are also susceptible to leaching attacks,
56:22
and that even ISO 26062 ECT microcontrollers is the highest level of safety, may be susceptible to leaching. So safety features often help, but they are really enough to ensure security. What is also different with automotive is what you need to rethink the strategy
56:40
in case of security problems. For example, with credit cards, it is not uncommon for authentication to fail randomly. When the credit card fails to work, usually you just need to try it once more, and it will probably work. And even if it fails again, no light is at risk. But the card cannot have the same strategy
57:01
if you add authentication to the can break, if you add authentication to the break can message, and you start receiving break request messages that fail authentication, what should the card really do? Should the card really do? Because it may be a cyber attack, which you want to avoid, but you should not rule out the possibility of a random malfunction,
57:21
or a false positive for an intrusion detection system. And by adding complexity into the system, you always increase the odds of a problem. And which one would be worse between breaking because of a cyber attack, or not breaking because of a malfunction? And there is no easy way to answer that question,
57:41
but what I want to stress here is that many security countermeasures that people suggest for a car, such as encrypting the canvas, permanently disabling debug ports, debug ports, or obfuscating the firmware, they may not necessarily be the best ideas, because if you suspect a malfunction with an ECU, you need to investigate the problem seriously, because it may harm people.
58:02
You cannot just replace the car as you would with your credit card or a smartphone. So technologies that can truly take into account both automotive requirements and security requirements are better, and we should make sure that education and research in these areas are accessible
58:20
to many researchers, without NDAs or prohibitive costs. Now, of course, you can use Ramen to try out different attacks. The first obvious one is to inject messages to alter the behavior of the car. Here, for example, is the brakes.
58:53
Another kind of security that I did not mention in this presentation is physical security for sensors and actuators. Here, I am demonstrating what happens
59:01
when I overtake the control of the steering wheel actuator. A human will probably brake in this situation. The state driving algorithm in CARA here does not realize it has lost control of the steering wheel and is still trying to correct the trajectory, when a better decision will be to stop the car.
59:20
So this is the end of the presentation. We developed an inexpensive, safe, and interactive platform to study and research automotive systems. The platform is accessible to beginners. It is not automotive-grade, but it is close enough for research and educational purposes. The project is open source and with permissive licenses.
59:40
If you have questions or ideas, do not hesitate to contact us, especially if you are involved with education, research, training, CTF, et cetera. And thank you for watching. To me, thanks for this comprehensive talk.
01:00:00
this was amazing. We unfortunately don't have much time for your question and answers, but there's one question that popped up, which is about the hardware and your PCB. How did you design it? How much does it cost actually? How can you get actually hold of that thing? Yeah, so I designed everything with KiCad. And I mean, I think a few years ago it was very
01:00:23
hard to design hardware, but now you have footprints, libraries available online. It has become very easy. The bomb was between 50 to 100 euros for a quantity of one. The macro controllers are obviously the expensive parts. And the PCB and assembling part,
01:00:41
it is up to the PCB fabrication service. If you have questions, just ask me on GitHub. I would be happy to answer.