Hé, Charlie Miller! Laten we het hebben over het beveiligen van autonome voertuigen

Een recent Wired-artikel over Charlie Miller (berucht vanwege het op afstand hacken en besturen van een Jeep) beweert dat "open gesprek en samenwerking tussen bedrijven" noodzakelijke voorwaarden zijn voor het bouwen van veilige autonome voertuigen. Dit lijkt nogal vergezocht wanneer zoveel bedrijven racen om de toekomst van de eens zo goed als dood maar pas nieuw leven ingeblazen (herinner je je de grote drie reddingsoperaties?) auto-industrie te domineren. Hoe naïef dat deel van het artikel ook klinkt, wat me echt versteld deed staan, was de implicatie dat het antwoord op het opnieuw ontwerpen van beveiliging uitsluitend binnen de sector van autonome voertuigen ligt.

Het concept van beveiliging staat niet alleen voor autonome voertuigen dus het heeft geen zin om te doen alsof dat het geval is. Elke IIoT-industrie probeert soortgelijke problemen op te lossen en staat verrassend open voor het delen van hun bevindingen. Ik zeg niet dat Miller een reis van verlichting door alle andere industrieën moet maken om de ideale oplossing voor beveiliging te creëren. Ik zeg dat dit al voor ons is gedaan, complimenten van het Industrial Internet Consortium (IIC).

De IIC bestaat uit meer dan 250 bedrijven in verschillende sectoren - waaronder autoleveranciers zoals Bosch, Denso en TTTech - met hetzelfde fundamentele probleem van het balanceren van beveiliging, veiligheid, prestaties en natuurlijk de kosten voor hun aangesloten systemen. Indien Bedraad en Miller zijn op zoek naar een open gesprek - het gebeurt op het IIC. De IIC heeft de Industrial Internet Reference Architecture gepubliceerd, die voor iedereen gratis beschikbaar is - zoals in 'gratis bier', vooral als de auto het rijden voor je doet! De uitbreidingen op dit document zijn het Industrial Internet Connectivity Framework (IICF) en Industrial Internet Security Framework (IISF). Deze documenten bieden begeleiding vanuit een zakelijk perspectief tot aan de implementatie, en de IISF is met name van toepassing omdat het betrekking heeft op Wired's korte vermeldingen voor het beveiligen van de connectiviteitseindpunten en de gegevens die ertussen gaan.

Maak een ritje met mij en kijk hoe we de architectuur van de connected car kunnen aanpassen om ons te beschermen tegen potentiële tegenstanders. Aangezien we geen kwaadaardige aanvallen op auto's bekend hebben, kunnen we beginnen met Miller's Jeep-hack. Dankzij een backdoor-"functie" in de Harmon Kardon-hoofdeenheid, was Miller in staat om vrij gemakkelijk onbeschermde afstandsbedieningsopdrachten uit te voeren. Door deze eerste exploit was hij in staat om een ​​chip die op de CAN-bus was aangesloten, te herprogrammeren. Vanaf daar had hij bijna de volledige controle over de auto. Je denkt, "verwijder die onbeschermde interface gewoon", toch?

Miller zou daar niet zijn gestopt, dus wij ook niet. Ervan uitgaande dat we nog steeds een exploit konden vinden die ons toegang gaf om de ARM-chip te herprogrammeren, dan Wired's artikel suggereert terecht om een ​​geauthenticeerde applicatie op te zetten - misschien te beginnen met veilig opstarten voor de onderliggende kernel, gebruik te maken van ARM Trust Zone voor de volgende fase van kritieke software, en een soort van authenticatie te implementeren voor hogere besturingssystemen en applicatieprocessen. Het eindpunt van uw apparaat kan er gaan uitzien als een vertrouwde applicatiestack (Afbeelding 1 hieronder). Ik kan alleen maar raden hoeveel deze head-unit nu kost, maar om eerlijk te zijn, dit zijn geldige overwegingen om een ​​vertrouwde applicatie te draaien. Het probleem is nu dat we eigenlijk nergens verbinding mee hebben gemaakt, laat staan ​​veilig. Maak je geen zorgen, ik laat je niet langs de weg staan.

Veel van deze vertrouwde applicaties maken rechtstreeks verbinding met de CAN-bus, waardoor het aanvalsoppervlak aantoonbaar wordt uitgebreid naar de voertuigbesturing. De gegevens die tussen deze toepassingen worden uitgewisseld, zijn niet beschermd tegen onbevoegde gegevensschrijvers en -lezers. In het geval van autonome taxi's, zoals Wired wijst erop dat potentiële hackers nu fysieke toegang hebben tot hun doelwit, wat hun kans vergroot om een ​​applicatie over te nemen of een bedrieger te introduceren. Nu wordt de vraag:kunnen applicaties elkaar en de data op de CAN-bus vertrouwen? Hoe vertrouwt het instrumentenpaneel de externe temperatuurgegevens? Is het echt nodig? Misschien niet en dat is oké. Ik ben er echter vrij zeker van dat de voertuigbesturing LIDAR, Radar, camera's, enzovoort moet vertrouwen. Het laatste waar iemand zich zorgen over wil maken, is dat een hacker op afstand de auto meeneemt voor een joyride.

We hebben het echt over gegevensauthenticiteit en toegangscontrole:twee bepalingen die het risico tegen de hack van Miller verder zouden hebben beperkt. Het beveiligen van de legacy-applicaties is een goede stap, maar laten we eens kijken naar het scenario waarin een niet-geautoriseerde producent van gegevens in het systeem wordt geïntroduceerd. Deze indringer kan commando's op de CAN-bus injecteren - berichten die het sturen en remmen regelen. De CAN-Bus voorkomt niet dat onbevoegde uitgevers van gegevens niet komen en zorgt er evenmin voor dat de gegevens afkomstig zijn van de geverifieerde producent. Ik suggereer niet dat het vervangen van de CAN-bus de beste manier is, hoewel ik niet tegen het idee ben om het te vervangen door een meer datagerichte oplossing. Realistisch gezien kunnen we met een raamwerk zoals Data Distribution Services (DDS) een gelaagde architectuur creëren zoals geleid door de IISF (Figuur 2 hieronder). De CAN-bus en kritische aandrijfcomponenten zijn in feite legacy-systemen waarvoor het beveiligingsrisico kan worden beperkt door een DDS-databusbarrière te creëren. Nieuwe componenten kunnen vervolgens veilig worden geïntegreerd met behulp van DDS zonder de controle over uw voertuig verder in gevaar te brengen. Dus wat is DDS? En hoe helpt het om mijn voertuig te beveiligen? Blij dat je het vraagt.

Stel je een netwerk voor van automotive sensoren, controllers en andere 'deelnemers' die peer-to-peer communiceren. Elke deelnemer krijgt alleen de gegevens die hij nodig heeft van een andere deelnemer en vice versa. Met peer-to-peer kunnen deelnemers aan dat netwerk elkaar onderling authenticeren en als onze vertrouwde applicaties het houden, geldt dat ook voor onze vertrouwde connectiviteit. Hoe beveiligen we die peer-to-peer verbindingen? TLS toch? Mogelijk, maar met de complexiteit van het beveiligen van ons voertuig willen we de flexibiliteit om een ​​afweging te maken tussen prestaties en beveiliging en toegangscontrolemechanismen toe te passen.

Laten we een beetje teruggaan en ons gesprek over de IICF opnieuw bezoeken, dat richtlijnen biedt voor connectiviteit voor industriële besturingssystemen. De IICF identificeert bestaande open standaarden en schrijft deze beknopt toe aan precieze functies van een industrieel IoT-systeem. In de kern is een autonoom voertuig, hoe cool het ook klinkt, gewoon een industrieel IoT-systeem in een gestroomlijnde, aerodynamische carrosserie met optionele lederen stoelen. Dus wat stelt de IICF voor voor het integreren van software voor een industrieel IoT-systeem, of meer specifiek, autonome systemen? Je hebt het geraden! DDS:een open set van standaarden ontworpen en gedocumenteerd door middel van open gesprekken door de Object Management Group (OMG). Een ideale automotive-oplossing die gebruikmaakt van DDS, stelt systeemtoepassingen in staat om alleen berichten te publiceren en erop te abonneren die ze nodig hebben (zie afbeelding 3 hieronder voor onze kijk op een autonome architectuur). Met deze datacentrische benadering kunnen we berichten architectonisch opsplitsen op basis van kritiekheid voor veiligheid of behoefte aan gegevensintegriteit.

En nu we een connectiviteitsoplossing voor ons autonome voertuig hebben ontwikkeld, kunnen we weer praten over beveiliging en ons TLS-alternatief:een datacentrische beveiligingsoplossing voor een datacentrisch messaging-framework. Met DDS Security kunnen industriële IoT-systeemarchitecten beveiligingsplug-ins gebruiken om de compromissen tussen beveiliging en prestaties te verfijnen, een noodzakelijke mogelijkheid die niet wordt geboden door TLS (Afbeelding 4 hieronder). Alleen bepaalde gegevensonderwerpen verifiëren, maar niet meer? Controleren. Alleen gevoelige informatie versleutelen, maar niet meer? Controleren. Eigenlijk is er meer. Afgezien van gecentraliseerde makelaars, biedt DDS Security gedistribueerde toegangscontrolemechanismen die dicteren wat deelnemers kunnen publiceren of zich kunnen abonneren op bepaalde onderwerpen zonder enige kwetsbaarheid. Dit betekent dat de niet-geautoriseerde toepassing van Miller de toestemming zou worden ontzegd om commando's te publiceren om remmen of sturen te regelen. Of als Miller de gegevens in beweging compromitteerde, zou de ge

[1] [2] 下一页