Giv mig et sted at stå...

Af 59

Vejen ud af overvågningshelvedet er lang og op ad bakke.

Inden vi kan kommunikere i fred, skal vi have en computerplatform vi kan stole på.

Inden vi kan skrive noget troværdigt software, hvilket i sig selv er en ganske stor udfordring ("Reflections on trusting trust" osv.), skal vi have noget troværdigt hardware at køre på.

I teorien er det umuligt. En god nok simulation er umulig at skelne fra den virkelighed den simulerer.

Men indenfor rammerne af den vedtagne kosmologi, kan vi komme nogenlunde tæt på.

Det første krav vi må stille, er at vi som ejere har 100% kontrol over hvilken kode der udføres, i hele computeren.

Med nogle få undtagelser er jeg meget tæt på totalt at have opgivet x86 platformen som troværdig hardware.

Undtagelserne er boards som Soekris 5501 som anvender relativt simple chips fra forskellige leverandører: Sandsynligheden for at der er en eller anden obskur "management over ethernet" mode i en VIA ethernetchip tilfældigvis ved hvordan man overtager kontrollen med den AMD CPU den er koblet til over en normal PCI bus, er meget, meget lav.

I midten af spekteret finde man f.eks et ITX board med en Intel CPU, med en håndfuld forskellige obskure og ofte utilgængelige "supervisor" levels som er "mandatory" for at chippen overhovedet kan virke uden at brænde sig selv af, koblet til en Intel netværks-controller der implementerer en håndfuld underlige "remote management" features, bootet af en BIOS som mildest talt er uigennemsigtig.

Det kan godt være at man kan sikre sådan en platform (den er det næppe som default) men det vil være en utrolig dyr omgang, på grund af komplexiteten.

Men så snart der tilføjes separate indlejrede processorer, ACPI "embedded processor", WLAN processors, "Trusted" Platform Modules, GPU osv. hvortil hvilke firmwaren ikke er tilgængelig og ikke umiddelbart mulig at lave reverse engineering på, er en "audit" helt uoverskuelig.

Den klassiske PC er med andre ord dømt helt ude som trusted platform, hvad enten det er som desktop, laptop eller server.

Kigger man på andre arkitekturer er der nogle muligheder i samme klasse som Soekris 5501 og nogle af dem har HW-faciliteter der i princippet kunne bruges til at konstruere en brugbar laptop eller workstation.

En af de absolut mest populære bud er RaspberryPI, men den må jeg desværre dømme ude.

På RaspberryPI er det GPU'en der har den virkelige kontrol med systemet og den er ikke alene lukket, den er lavet af det præcis samme firma -- BroadCom -- som er hovedårsagen til at man ikke kan stole på sin smartphone -- fordi chippen fundamentalt set er konstrueret til brug i smartphones.

Men der er andre boards i "1GHZ ARM processor" klassen, oven i købet til priser der starter under en plovmand, hvor det er realistisk at lave et system audit, inklusive at disassemblere den i chippen indlejrede boot-kode og overbevise sig selv og andre om at der ikke ser ud til at være ugler i mosen.

Tilføj et LCD, et keyboard, en pege-dims, et batteri og kun det, så burde ikke være helt umuligt at lave en laptop der er acceptabel at arbejde på.

phk

Kommentarer (59)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#6 Palle Simonsen

95.64 EUR med fragt til Danmark for 1 stk.

Er der nogen der ved, om den fragtes fra et land hvorfra der pålægges yderligere told etc? (Fra en, der har betalt ekstra, for at få en ubrugelig kina-dims ...)

  • 0
  • 0
#14 Jacob Larsen

Har de forskellige boards ikke altid en eller anden stump firmware der ligger i noget ROM et sted? Der skal jo være noget der kan skabe adgang til NAND/SD kort til boot. Hvis man kunne få adgang til at læse koden fra ROM, så er det måske en nogenlunde overkommelig opgave at lave et audit af koden. Men det er helt sikkert et punkt man skal have for øje, da en god trusted platform skal have mulighed for at man kan verificere denne kode.

Jeg har haft et kig på BeagleBone/BeagleBoard til forskellige baremetal hobbyting, netop fordi SoC er dokumenteret i detaljer, modsat Raspberry Pi. Hvis jeg læser den her rigtigt http://www.embedded-bits.co.uk/2011/writeanmlo/, så er det muligt at strippe alt bootloader kode ud og skrive noget fra bunden man stoler på, så der mangler "bare" en audit af firmware boot ROM.

  • 1
  • 0
#17 Palle Simonsen

Hvordan kommer du frem til den pris?

UPS Express 'Saver' :) Default værdien for fragt. Jeg vidste ikke, at let-elektronik.dk også importerer denne. Jeg ved godt, de importerer Arduino (har en).

Tilbage på sporet.

Siden der averteres med Open Source HW må man antage, at der ikke er bagdøre, da det ville være forretningsmæssig harakiri. Man kan forøvrigt finde specs og SW på Github inklusive en fornuftig roadmap, så med lidt distribueret arbejde, må en slags audit jo kunne etableres.

  • 0
  • 0
#19 Peter Kyllesbeck

Problemet er at køb over 80 kr. eks. fragt skal momspålægges

Ikke ved køb fra andre EU lande.

Nu skal man betale moms af det alligevel, nemlig landets moms, dog skal man betale dansk moms, hvis forhandleren er registreret i Danmark, og det skal han, hvis hans salg til Danmark overstiger 280.000,- pr. kalenderår(foregående). Se http://www.forbrugereuropa.dk/EHandel/Told-og-moms/Koeb-paa-nettet-inden... og https://www.retsinformation.dk/Forms/r0710.aspx?id=145054#Kap12

  • 0
  • 0
#20 Carsten Rhod Gregersen

Som sidst... Så længe du ikke har 100% styr over hardwaren inden i kredsene så kan du godt glemme alt om "trusted" miljø.

Der er folk der arbejder på noget... men det er sku' nok stadgivæk lidt for science fiction til at vi ser det i praksis indenfor overskuelig tid: http://www.eurekalert.org/pub_releases/2012-01/uov-qpe011612.php

Jeg har talt med folk fra hardware branchen som har det mest mærkelige historier om hvad der er med på chip's layouts og hvor de er kommet fra. Det behøver ikke engang være noget producenten introducerer ved eget kendskab der bliver jo købt IP blokke fra højre og venstre og klasket sammen på en CPU/MCU idag... du skal bare have en finger inden for et af de centrale steder....

Vi kan lave remote access til MCU'ere i ca. 10-20kb flash og 1-2kb ram (mindre kan også gøre det).. det har du jo alle muligheder i verdenen for at kunne "gemme" inde i en moderne ARM/X86 eller lign. og aktivere det ved at CPU'en ser den rette byte sekvens eller lign.

Antallet af relativ simple muligheder for at skabe access og overstyring er så utallige at jeg lige så godt kan ringe på ude på den lukkede med det samme hvis jeg først begynder at tænke den vej. Så har du først taget tin-hatten på så glem det.. du kommer aldrig udenfor en dør og får absolut aldrig noget lavet...

Morderne hardware har nået en kompleksitet hvor ingen kan overskue om der er huller eller ej... for den sags skyld om de så er introduceret med vilje eller ej...

Du er ude på en umulig mission, der kun vil lykkedes via kompromis... (eller ved så krævende udførsel at det ville være nemmere at lade være med at anvende en computer til at løse jobbet i første omgang)

  • 1
  • 0
#21 Casper Bang

...ligesom en RISC CPU kan emulere en CISC CPU, kan vejen frem måske være at emulere sikker hardware på usikker hardware? Det vil jo være optimalt hvis, når nu man har iført sig tinfoil hatten, stadig kan få gavn af best-of-breed MCU design.

  • 0
  • 0
#22 Morten Jensen

@Casper Bang

...ligesom en RISC CPU kan emulere en CISC CPU, kan vejen frem måske være at emulere sikker hardware på usikker hardware? Det vil jo være optimalt hvis, når nu man har iført sig tinfoil hatten, stadig kan få gavn af best-of-breed MCU design.

Mine bedste implementeringer af RISC CPUer som virtuelle maskiner skrevet i C, har udført bytekoden størrelsesordener langsommere end hvis jeg compiler til native instruktioner med GCC uden optimering (mine hjemmelavede compilere er nemlig ikke-optimerende).

Udover det åbentlyse performance-problem kommer dertil, at du skal have en vis runtime op at stå før du kan begynde at afvikle f.eks. RISC kode på din "sikre" CPU. Så du er nødt til at anvende "den usikre CPU" et godt stykke hen ad vejen, og så ryger hele ideen.

Du kan ikke rigtigt få noget interessant til at ske på den emulerede CPU uden at det kommer fra den rigtige. Dvs. al HW og alle interrupts skal håndteres af den rigtige CPU, og er det så tainted eller ej når den sikre CPU får det? Måske misforstår jeg dig :) ?

  • 0
  • 0
#24 Lasse Hillerøe Petersen

Jeg tvivler stærkt på, at nogen har indbygget sjove bagdøre i min Amstrad CPC 6128 fra 1985. Men til gengæld er det nok også begrænset hvor nyttig den er idag. Men hvor gammel skal hardware være, for at man kan have nogenlunde tillid til den?

Jeg har også tænkt på en anden angrebsvektor til dette problem: Postels princip siger "be liberal in what you accept, but conservative in what you send out." Når jeg kigger på alle de forbindelser min maskine åbner til forskellige steder ude på nettet, ved helt "normal" Internetbrug, så får jeg den tanke at det burde være muligt at skærme sig af ved hjælp af en "omvendt firewall", en proxy som kun lader explicit tilladte forbindelser gå ud, og som checker alle udgående pakker for suspekte data. (Og ja - det er klart at sådan en proxy nok helst skal køre på trusted hardware.)

  • 1
  • 0
#25 Christoffer Kjeldgaard

Nu ved jeg ikke hvilket blogindlæg du hentyder til men jeg tog udgangspunkt i dette blogindlæg hvor Poul gerne vil "skrive noget troværdigt software" og spørger bare hvad der er i vejen for at gøre det på en standard pc uden netadgang?

Et eksempel på hvorfor dette ikke fungerer kan man se på Stuxnets infiltration af Iran. Alle deres PCere var off-line og smitte skete via USB devices.

  • 2
  • 0
#26 Christoffer Kjeldgaard

Nu ved jeg ikke hvilket blogindlæg du hentyder til men jeg tog udgangspunkt i dette blogindlæg hvor Poul gerne vil "skrive noget troværdigt software" og spørger bare hvad der er i vejen for at gøre det på en standard pc uden netadgang?

Et eksempel på hvorfor dette ikke fungerer kan man se på Stuxnets infiltration af Iran. Alle deres PCere var off-line og smitte skete via USB devices.

  • 0
  • 0
#30 Carsten Larsen

Det virker lidt uklart hvilken opgave du ønsker at løse. Er det slags "general purpose" arbejdscomputer med internet adgang osv, eller er det mere over i server / automation? På arbejdscomputeren er det vel de værktøjer du ønsker at bruge, der definere hvilke muligheder du har for anvendelse af hard- og software - med mindre du selvfølgelig ønsker at starte helt fra "scratch".

Hvis du derimod er ude i noget ikke alt for kompliceret automation, må det være muligt at anvende en tilstrækkelig simpelt hardware. Sådan en hvor omkostningerne til "udenoms-funktionalitet" er høje i både produktion og brug. Det kunne f.eks. være Atmels AVR platform. En anden måde at holde ubudne gæste ude på er ved at anvende lukkede kredsløb med begrænset adgang - en slags sikre zoner.

Mest af alt handler det vel om at have en pragmatisk tilgang, forstået på den måde at luftkasteller jo sjældent bliver til virkelighed. Og så syntes jeg faktisk personligt at bekymringen i højere grad burde gå på egentlig uautoriseret adgang frem for muligheden for afvikling af arbitrær kode.

  • 1
  • 0
#31 Eskild Nielsen

Jeg tvivler stærkt på, at nogen har indbygget sjove bagdøre i min Amstrad CPC 6128 fra 1985. Men til gengæld er det nok også begrænset hvor nyttig den er idag. Men hvor gammel skal hardware være, for at man kan have nogenlunde tillid til den?

Jeg havde engang en NASCOM2 med z80 processor og indtil 64kBytes RAM

Boot-prommen (aka NASSYS 1 i mit tilfælde, kunne også have været en NASSYS 3) fyldte 2 Kbytes

Der medfulgte en disassembleret listning af prommen, så man kunne læse og forstå hvad der skete. Dvs det var muligt at verificere denne del af koden, da man jo frit kunne tage prommen og læse den i en prom-brænder el lign. hvis man ikke bare ville bruge de medleverede værktøjer.

Koblet med det temmeligt simple instruktionssæt, så var der en troværdig mulighed for at vurdere hvad der foregik. (Om dette er fuldt tilstrækkeligt til at skabe tillid er 'beyond me')

  • 1
  • 0
#33 Kenn Nielsen

Handler det ikke lidt om grænseflader, og om at det skal være den trustede computer, der bestemmer hvad der kommer ind og ud af den.

Keyboard/mus kunne sagtens nøjes med RS232, der kan implementeres rimeligt gennemskueligt

Om der skal defineres ekstra snitflader , f.eks. sata <> ekstra snitflade < Trusted computer Grafik-engine < ekstra snitflade < Trusted computer

osv.

er vel ikke så 'slemt' , bare snitfladen er åben og velbeskrevet.

K

  • 0
  • 0
#35 Peter Holm Jensen

Er der nogen der har set eksempler på at en x86 gør noget den selv (NSA) finder på, ikke et eller andet program i userspace, men noget microkerne kode.

Hjemme hos mig er det en lille linux imellem husnettet og verden, hvis microkoden skal ud i verden skal det altså gennem min linux, og det burde vel ikke være helt umuligt at flikke lidt kode sammen der sniffer efter "meget obskure data". Hvis man skal liste de der "meget obskure data" ud gennem min linux uden jeg har chance for at opdage det, skal man altså stå i ledtog med enten min linux's ipstak eller mine mine netkort (her er 2 af forskelligt fabrikat (dog måske samme chipset)) eller måske endda begge dele, ret usandsynligt at alle betingelser er opfyldt samtidigt.

Om der er eller ikke er skjult microcode i en x86 det er svært at vide, men for almindelige mennsker vil chancen for userspace malware være en meget meget større trussel. Hvis der var nogle fiffige drenge eller piger der havde fundet ud af at udnytte skjult microcode fra x86 så skulle vi nok havde fået det at vide på en eller anden måde.

...og så lige til sidst, i en z80 var/er der en del instruktioner der ikke var/er officielle men de virkede nu udemærket, så lidt skjult var der nu også i den.

  • 0
  • 0
#37 Bo Normann Jensen

Eller, hvis man kan kryptere/signere al nettraffik i operativsystemet.

Derefter kan en ekstern boks baseret på 'trusted' hardware dekryptere/validere og blokere anden traffik.

Det reducerer nok båndbredden, men gør standard hardware anvendelig.

  • 0
  • 0
#39 Jacob Larsen

På mange chips er det dog noget du selv skriver derned med JTAG eller anden form for "flash-write" interface.

Så det drejer sig om platforme der udover deres main flash har en memory-mapped EEPROM til noget low-level boot kode? Det udelukker vist mange main-stream SoC's, hvor prisen for sådan en ekstra chip anses for uacceptabel. Men det kan selvfølgelig være at den indbyggede boot ROM kan bypasses i sådan en chip.

Jeg ved nu ikke om jeg vil kalde JTAG for et flash interface, det er mere en debugger. Men du kan selvfølgelig loade den normale bootloader til RAM og eksekvere den, der er normalt nogle flash options deri. Det er normalt den eneste måde at starte et board op første gang, når EEPROM/flash er tom.

  • 0
  • 0
#41 Peter Mogensen

og så er vi tilbage til start, er vi ikke ? :-)

Tjoe... men er det ikke principielt det samme som man gør når man må erkende at man ikke kan bruge en maskine selv til at finde ud af om den er kompromiteret, men sætter sig til at lytte med på dens netværks-traffik for at se om den laver noget mistænkeligt? Dermed ikke sagt at der er særlig praktisk eller realistisk at gøre.

Det virker for mig som om man ikke rigtig har nogen måde definitivt at sikre sig at ens hardware er trusted med mindre man bygger den helt selv (OpenSPARC?) ... men måske er den slags "deduktiv sikkerhed" heller ikke nødvendig. Måske kan vi nøjes med hvad man kunne kalde "induktiv sikkerhed": At vi må regne med at producenter har meget lidt interesse i at blive afsløret som nogen, der kompromiterer deres kunders sikkerhed og at man må antage at hvis sådan noget faktisk bliver brugt (og ikke kun holdt som en sidste udvej trumf af NSA), så vil det også blive opdaget. Personligt er jeg ihvertfald holdt op med at købe SONY produkter. Et firma, der er villige til at installere root-kits på kundernes maskiner (og for at føje spot til skade, hæver det gøre det for at beskytte deres ophavsret mens de bryder andres) har ikke mig som kunde.

Antagelsen må så være at vi ville have opdaget det over tid pga. mistænkelig opførsel fra produktet, hvis det var tilfældet og at en sådan opdagelse ville afstedkomme en skandale som ingen producent var interesseret i. Det kræver selvfølgelig at folk har et reelt valg ang. leverandør, så man kan forlade dem, der tager numsen på en. Hvilket leder tilbage til noget jeg talrige gange har pointeret her, at en stor del af den tillid man kan have til et system ligger i at man har muligheden for at vælge noget andet.

Man kan selvfølgelig diskutere om den effekt nogensinde har haft nogen praktisk betydning. Måtte Borland bøde for deres bagdør i Interbase? Jeg er også godt klar over at SONY slet ikke har bødet tilstrækkeligt i markedet for dens slags opførsel til at det rigtig har nogen effekt, men man kunne måske håbe at med den nu (post Snowden) mere opmærksomhed om at man kan blive overvåget vil blive en større skandale ud af hvis f.eks. Intel afsløres i at deres systemer har bagdøre.

PS: Men nu vi er ved forslag til systemer, så synes jeg wandboard.org ser interessant ud.

  • 1
  • 0
#44 Bo Normann Jensen

Det er præcis det blogindlægget handler om: Hvad skal der til for at lave en eller anden computer man faktisk kan stole på.

Ja, så det er ikke off-topic :-)

.. men pointen er, at den omtalte boks ikke behøver, at være en computer.

Den skal blot forhindre uønsket netværks traffik.

Men mindre funktionalitet vil mulighederne for at finde egnet hardware være større. Tidligere var CRC checks lavet i simpel TTL logik. Så det kan vel lade sig gøre at putte genkendelige information i ethernet frames der muliggør filtrering.

  • 0
  • 0
#49 Bo Normann Jensen

Hvordan har du tænkt dig at sørge for det? Du nævnte noget om signeret trafik, men hvis din boks kan signere sin "ønskede" trafik, så kan din boks, når den er kompromiteret vel også signere sin uønskede trafik?

Boksen kan vel nøjes med at kigge efter 'signatur' på udgående traffik. Hvis signaturen ikke findes, lukkes pakken/framet ikke igennem. Hvis boksen er opbygges med simpel logik, er den svær at kompromittere.

På PC hardwaren, er der ikke tale om et 'dybt' inficeret system. Der er tale om standard hardware med et sikret operativ system. Der var som sagt tale om, at man ikke kunne stole på om komponenter på main board m.v. havde indbygget funktionalitet der muliggjorde udadgående kommunikation.

I den sikrede kerne/netværks stak, indsættes signaturen i pakkerne. Problemet er jo at opnå kontrol, uden at stole på hardware.

  • 0
  • 0
#50 Eskild Nielsen

På PC hardwaren, er der ikke tale om et 'dybt' inficeret system. Der er tale om standard hardware med et sikret operativ system. Der var som sagt tale om, at man ikke kunne stole på om komponenter på main board m.v. havde indbygget funktionalitet der muliggjorde udadgående kommunikation.

Men den grundlæggende antagelse i denne tråd er jo at PC hardware generelt må formodes at være endda særdeles dybt inficeret - eller også har jeg ikke forstået PHK rigtigt. PHK?

  • 0
  • 0
#51 Bo Normann Jensen

Vi leder vel efter mere end det? Kan du stole på at der ikke foregår noget i hardware/skjult kode, som for eksempel piller ved tilfældigheden af input til krypteringsnøgler? Debian SSH fejlen viste hvor lidt der skulle til.

Det er nok bedre at lave et tilfældigt tal udfra en modulus af en "tilfældig/arbitrær" P1 udsendelse. Vælg eventuelt en udsendelse med en uligevæglig vært.

Deterministiske generatorer, er sværere at skabe tillid til.

  • 0
  • 0
#52 Michael Eriksen

Jeg tror at skal man have bare en chance for at lave noget man kan stole nogenlunde på, så kan man starte med at skrotte al eksisterende hardware og starte fra bunden.

En mulighed kunne være at købe en ARM licens og arbejde videre på den. En ARM processor kan være ret simpel og overskuelig. Næste ting er at erkende at enhver tilkøbt hjælpechip er bandlyst og alt skal sidde på den samme die - kun passiv hjælpeelektronik kan accepteres. Dvs. ARM chippen skal udvides med selvudviklet ethernet og USB funktionalitet. Hvis man implementerer USB3 kan man godt nøjes med denne som eneste bus mulighed. Endelig skal der en vis form for video på die'en i form af en framebuffer og lidt 2D acceleration er nok overkommeligt. 3D kan man glemme alt om, kompleksiteten eksploderer.

Det bliver en dyr chip i lavt styktal og ikke helt nemt at se et marked.

  • 0
  • 0
#54 Peter Mogensen

Han har også helt en længere tale ved et IETF møde, som jeg desværre ikke har haft tid til at se endnu.

... hvilket jeg - nu da jeg skrev det - konkluderede var for dårligt, så her er det: http://www.youtube.com/watch?v=oV71hhEpQ20&feature=share&t=23m30s

... hvor han så vidt jeg lige kan høre bl.a. når at nævne de 2 pointer jeg nævnte ovenfor: At der er større sikkerhed, hvis vi ikke er tvunget til monokulturer, og at firma'er post-Snowden nok vil være mere opmærksomme på de negative konsekvenser i at blive offentlig kendt for at overvåge eller hjælpe til med at overvåge deres kunder.

  • 0
  • 0
#56 Andrew Rump

Hænger nedenstående løsning overhovedet sammen eller er softwaren i computere efterhånden så kompleks at det "selvstændigt" spørger i øst og vest på helt uvilkårlige tidspunkter?

Hvis 2 eller flere (forskellige, men alligevel "ens") computere bliver sat til at udføre samme opgave, så burde de også levere (næsten) samme netværkstraffik, hvis de er "ens" - ud over IP-adressen og andre "småting" i netværkspakkerne - og - pointen - der ikke er andre (NSA) der blander sig i trafikken. Hvis computerne delte netværkskortet, dvs. alle modtog de samme data fra ét netværkskort (på én IP-adresse) og netværkskortet kun sendte data ud, hvis det blev bedt om at sende de samme data fra 2 eller flere af de computere det var koblet på (ligesom rumfærgen's aktuatorer), så burde alt uønsket trafik blive sorteret fra. Tænkte lige det kunne sættes på med virtuelle computere, men så vil der stadig kun være én computer der styrede det hele! :-( Men den anden løsning kunne være at have en "firewall", hvor alle computerne er koblet sammen. Det vil kræve noget special logik at sende keyboard og mus data til alle instancer og der vil nok være masser af muligheder for at det kan gå galt - alle computere skal være klar til at modtage den næste kommando, dvs. den langsomste computer vil sætte hastigheden for hele setup'et! Men der var også bare en tanke! :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen