007CD Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 Tror jeg skal utfordre stakkaren til å hacke min bil trådløst... Tror han blir fort temmelig skuffet da den eneste som KANSKJE lar seg hacke er radioen, som kanskje har noe avansert i seg. Men denne er det kun FM på, så den er avskrudd for tiden Bare pass deg så hacker noen radioen din og setter på Jostein Bever for full guffe! Da blir det liv i leiren tenker jeg Tja, da er det ut med askebegret og ta ett godt tak rundt sikringa til radioen og nappe den ut i allefall Ikke at det er såpass stort tap med mangelen på FM sendinger her til lands Lenke til kommentar
sverreb Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 Og det er helt unødvendig. Det er lett å adskille i to uavhengige systemer slik at man fortsatt kan gjøre ting fra apper eller radioen, uten at apper eller radioen kan forstyrre driftssikkerheten i bilen. Tja, i prinsippet er det ihvertfall lett å si at det er lett. Man kan jo bare ha separate systemer (Airgap) I praksis så er det ikke like enkelt å airgappe alt. Vil du ha feilmeldinger og statusinfo på motor, bremse, airbag etc. i Infosystemet ditt? Da må infotainment systemet snakke med disse modulene. Skal du ha fjernstyring av oppvarming og å blinke med lysene med en app da må mobilmodemet kunne kommunisere med motor/powersystemer og lys. Skal du overholde reguleringer og ha OBD2 support i bilen? Vel da har du et bussystem som hindrer deg å argappe alt det som kan logges dit. Hvis kommunikasjonsenheter har noe som helst med en enhet som logges til OBD2 er den ikke lengre airgappet fra noe av det. Kan bilprodusentene gjøre mer: Ja absolutt, men det er som alltid et kostnadsspørsmål. Softwareutvikling til automotive er ikke som å skrive en webapp. Du har ASIL (safety) krav som skal oppnås, og dette går ofte direkte ut over sikkerhet (security). ASIL stiller krav til feilbegrensing og overvåkning av funksjoner, mens sterk sikkerhet betyr a hindre interaksjon mellom komponenter. Disse kravene spiller ikke særlig godt på lag. Jeep hacket skjedde fordi noen hadde latt en debugport stå åpen. Du kan banne på at dette ble gjort fordi de har krav på å definere en prosess for å diagnostisere og rette feil som måtte finnes i felt. Kunne dette vært gjort på en bedre måte: Helt sikkert, men er det lett, nja... Lenke til kommentar
tommyb Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 (endret) Og det er helt unødvendig. Det er lett å adskille i to uavhengige systemer slik at man fortsatt kan gjøre ting fra apper eller radioen, uten at apper eller radioen kan forstyrre driftssikkerheten i bilen. Tja, i prinsippet er det ihvertfall lett å si at det er lett. Man kan jo bare ha separate systemer (Airgap) I praksis så er det ikke like enkelt å airgappe alt. Vil du ha feilmeldinger og statusinfo på motor, bremse, airbag etc. i Infosystemet ditt? Da må infotainment systemet snakke med disse modulene. Skal du ha fjernstyring av oppvarming og å blinke med lysene med en app da må mobilmodemet kunne kommunisere med motor/powersystemer og lys. Skal du overholde reguleringer og ha OBD2 support i bilen? Vel da har du et bussystem som hindrer deg å argappe alt det som kan logges dit. Hvis kommunikasjonsenheter har noe som helst med en enhet som logges til OBD2 er den ikke lengre airgappet fra noe av det. Kan bilprodusentene gjøre mer: Ja absolutt, men det er som alltid et kostnadsspørsmål. Softwareutvikling til automotive er ikke som å skrive en webapp. Du har ASIL (safety) krav som skal oppnås, og dette går ofte direkte ut over sikkerhet (security). ASIL stiller krav til feilbegrensing og overvåkning av funksjoner, mens sterk sikkerhet betyr a hindre interaksjon mellom komponenter. Disse kravene spiller ikke særlig godt på lag. Jeep hacket skjedde fordi noen hadde latt en debugport stå åpen. Du kan banne på at dette ble gjort fordi de har krav på å definere en prosess for å diagnostisere og rette feil som måtte finnes i felt. Kunne dette vært gjort på en bedre måte: Helt sikkert, men er det lett, nja... Det er likevel utrolig stor forskjell på å kjøre alt i ett system eller å skille ut den gamle smørja og den nye smørja, ikke la dem dele minne- og CPU-ressurser, og kun la dem kommunisere gjennom et API som i utgangspunktet kun tillater en whitelist av tjenester med nesten ingen parametre, og der APIet i tillegg er ressursbegrenset slik at flooding stopper der. Det vil alltid være en diagnoseport åpen. Hemmeligheten ligger i å vite at den er et angrepspunkt. Edit: det er jo ikke engang slik at det er bevisste valg man skal beskytte mot. En feil i multimedieenheten som blokkerer CPU eller en buss er jo heller ikke optimalt hvis styringssystem eller bremsepedaler er koblet på samme bussen. Endret 11. mai 2017 av tommyb Lenke til kommentar
sverreb Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 Det er likevel utrolig stor forskjell på å kjøre alt i ett system eller å skille ut den gamle smørja og den nye smørja, ikke la dem dele minne- og CPU-ressurser, og kun la dem kommunisere gjennom et API som i utgangspunktet kun tillater en whitelist av tjenester med nesten ingen parametre, og der APIet i tillegg er ressursbegrenset slik at flooding stopper der. Det vil alltid være en diagnoseport åpen. Hemmeligheten ligger i å vite at den er et angrepspunkt. Edit: det er jo ikke engang slik at det er bevisste valg man skal beskytte mot. En feil i multimedieenheten som blokkerer CPU eller en buss er jo heller ikke optimalt hvis styringssystem eller bremsepedaler er koblet på samme bussen. Det er flere delte busser i en bil. Mye er på canbus som stort sett er sikker mot jamming ved uhell (Ikke mot et villet angrep) siden den gjør arbitrering i PHY så høyere prioritets hardware alltid vinner. (Men man kan rekonfigurere prioriteten så et angrep er fortsatt mulig). Det meste av virkelig sikkerhetskritisk software kjører på separate kontrollere med dedikerte CPUer og minne. Biler har gjerne et hundretalls individuelle kontrollere (Derav CAN = Controller Area Network). De mest kritiske slik som ABS, Servo, airbag kjører på ASIL D ratede kontrollere som da gjerne kjører software i tandem (I.e. samme software på to CPUer og begge må være enige ellers så går kontrolleren i fail-safe mode) med ECC på både minner og busser. Kostnaden med slike kontrollere er såpass høy og software såpass vanskelig å lage at det ikke er ønskelig med masse lag med sikkerhetsoverbygging på samme kontroller. Nå er jo en flere systemer fysisk koplet direkte til førerens kontroller så software kan aldri ta fra fører muligheten til å styre eller bremse (Men bilen kan klart påvirke negativt om den blir styrt av software med vond vilje) Lenke til kommentar
tommyb Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 Vel, i så fall er sikkerheten allerede mye høyere enn det som artiklene om allerede gjennomførte hacks viser. Det er for eksempel ingen grunn til at man skal kunne slå av lysene eller åpne elektriske dørlåser fra et eksternt API i fart. Når bilen er parkert - ikke noe problem. Men dette har altså vist seg å være tilfelle. Det du sier virker betryggende, men det kan ikke stå så godt til - ellers hadde ikke vi fått advarsel etter advarsel etter allerede gjennomførte hacks. Lenke til kommentar
sverreb Skrevet 11. mai 2017 Del Skrevet 11. mai 2017 Vel, i så fall er sikkerheten allerede mye høyere enn det som artiklene om allerede gjennomførte hacks viser.Nja, jeg har ikke snakket så mye om sikkerheten (Security), jeg har snakket om tryggheten (safety). Jeg er ikke i noen spesiell tvil om at det finnes mye potensiellt skumle muligheter for å fjernangripe biler. Fokus i bilelektronikk har vært at den skal være pålitelig og ikke feile plutselig og på ufortsigbar måte. I.e. de er herdet mot temperatur og aldring, og lagd slik at feil uansett gir forutsigbar og veldefinert oppførsel (fail safe), men de er ikke lagd med noe autorisasjonssytemer eller annen typisk sikkerhets systemer. (Men de vil ha betydelig grad av inputsjekk så ikke forvent at du kan få til å styre de utover kommandosettet som er definert. Moderne biler har imidlertid komplekse asistansesystemer som autobrems, parkeringsassist, adaptiv cruice som betyr at det finnes en kopling mellom brems, throttle og styringskontroll og sensorsystemer. Sensorsystemene er store og komplekse, og har nesten uten unntak koplinger til infotainmentsystemet (Ryggekamare, ultralydsensorer etc.) Selv om en fører altid kan bremse og styre selv betyr det ikke at det ikke kan gå galt om en angriper også velger å bremse og styre på et kritisk tidspunkt og overumpler føreren. 1 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå