Jeg er ret uenig i dine konklussioner ...
... modpart relativt nemt kan detektere, dels er det i praksis meget bøvlet.
Mener du det er relativt svært at detektere om en firmware er blevet "justeret"? Mener du det er nemt at detektere at der er lagt en ekstra MCU ned inde en af de "eksterne" komponenter?
Hvor bøvlet og svært noget er, hænger sammen med de øjne der ser... Jeg er også selv software udvikler.. og synes også umiddelbart det lyder til at være svært at ligge et par millioner ekstra transistorer ned på en die. Men dem jeg kender indenfor området fortæller at idag er den slags IP bare noget du kan downloade (endda open source), du kan sidde i højniveau programmer og klistre tingene sammen.
Var jeg efterretningstjeneste ville jeg ikke forsøge at indfiltere Super Micro.. det ville være for svært. Jeg ville istedet købe nogle motherboards undersøge hvilke MCU baserde "hjælpesystemer" der var monteret (og som også var centralt placeret) og finde en af underleverandørerne der var placeret i "hjemlandet". Få lagt en skjult MCU ned i denne lakrids så den stadigvæk virkede 99,9% som normalt, kunne firmware opdateres af Super Micro i produktionen uden nogen havde en chace for at opdage der var noget ektra med. Sandsynligvis kunne alt dette ske helt i starten af udviklingsfasen på nye boards hvor leverandør og kunde jo taler meget sammen.
IP'en kunne sandsynligvis udvikles modulært så det kunne bruges på tværs af flere systemer (andre producenter). Det kunne sagtens laves så den eneste måde (praktisk) at detektere det på ville være at slibe lakridsen ned og gennemlyse den.
Hvis jeg spørger hvad jeg selv ville gøre.. så ender jeg jo selvfølgelig i firmware opdatering.. fordi jeg er software udvikler.
Hvis du var FPGA/ASCIS udvikler.. hvad ville du så gøre?
Ja.. ovenstående er mere bøvlet, set fra en udviklers perspektiv, end at forsøge at få skubbet noget ekstra software ned i Super Micro's MB... men efterretnings "logistik" mæssigt vil det være mindre bøvlet at tage fat længere nede i leverandør kæden. Yderligere ville en skjult MCU være så meget sværere at detektere. Sidst men ikke mindst.. en skjult MCU ville overleve en firmware opdatering fra Super Micro's side.
Jo .. deeeeeeet... spinner helikopterhatten op i fart og tænder det blinkende LED-lys i butterfly'en
Der er forskel på "værdi" og "(virksomheds)profit", specielt når vi begynder at tale national økonomi.
Vi er helt sikkert ude i et område hvor det er svært at måle og kvantificere værdien med 100% sikkerhed, ergo vi er i et område hvor "mavefornemmelserne" råder.
Jeg er personligt ret sikker på at frie offentlige data og snitflader vil skabe denne værdi... Mange af de store IT virksomheder (herunder Systematic) lever godt af at det er pxsse svært at få lov til at integrere med offentlige data .. men når du så først er inde i varmen .. så sidder du på flæsket (profit... ikke værdi)...
Jeg har selv været ude for netop dette i en mindre virksomhed.... en større IT-virksomhed havde kontrakten mht. håndtering af en større database i offentligt regi og havde selv muligheden for integration til nogle specifikke snitflader ... Vi havde lavet et produkt som integrerede til disse data og snitflader og det gik fint. Men da vi havde dyrket markedet op.. så bestemte denne IT-virksomhed der håndterede databasen at nu ville de sælge dette produkt. Prisen for at tilgå snitfladen blev sat op... og virksomheden gik på markedet med deres eget produkt til en pris der var mindre end prisen for at tilgå snitfladen.... Fair konkurrence? og var prisen markedsmæssigt korrekt sat?
Vi stoppede efterfølgende med at markedsføre produktet og opgav.. (vi havde heldigvis nok forretning på andre områder)
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)
http://nabto.com/(en Skype lignende dansk udviklet protocol til apparater så du altid kan komme i kontakt med dem)
:-)
Normalt er det jo ikke fordi folk "sparer" en firewall... Du kan jo næsten ikke købe en router idag uden at den har en indbygget (omend ikke særlig god) firewall. Det er jo fordi at folk åbner et hul i routeren... og et komplet sikkerhedssetup vil normalt være ret dyrt..
En anden løsning er at ligge det i firmwaren. Men de normale internet sikkerhedsløsninger ikke er udformet til embedded brug, de kræver for meget CPU og RAM etc., er normalt målrettet Linux eller Windows og en logikken i en pumpe afvikles altså ikke ovenpå et operativsystem.
Har du ansvaret for at udvikle en realtids-styring i en pumpe.. så har du altså hænderne fulde nok i forvejen.. at skulle portere en SSL stak, håndtere certifikater mv.. gør det ikke nemmere (og dit kode footprint er nok 10x)
Vores platform/system er målrettet selv de mindste processorer, vores prototype/evaluering board afvikles f.eks. på en 8bit's MCU se evt. http://nabduino.com. Systemet ligges direkte på produkterne sammen med resten af firmwaren.
Se evt. mere på http://nabto.com
Så hjælper det ikke at stole på softwaren...
Så lav det som en SoC lagt ind ved siden af din ARM-core... og programer det som "software", som kan overvåge og aktiveres on-demand ...Så er det lavet i "software"...
Nu har vi jo foliehatten på... så her får du den med fuld helikopter hat, hvid skjorte, butterfly og grønne fløjlsbukser:
Hvis du er rigtig smart så (gen)bruger du den alm. cpu-core og kontekst switcher dine egne processer ind og afvikler dem fra internt "darkhat" RAM/ROM/FLASH (du kan jo pille ved MMU'en også) ergo dine "dark-hat" proces'er kører "ved siden af" operativ systemet, men på samme core. Derefter skulle det være "ret nemt" (hvis man kender platformen) at interface til de data og hardware snitflader der ønskes adgang til. Nogen gange vil det gå galt mht. at holde tilstanden til hardwaren iorden (den deles jo imellem to parter)... men hvordan ville det opleves: "Argh... nu skal jeg reboote igen og så virker det hele igen ... satans Android/iPhone"
Ok det vil kræve "lidt" snilde... men du kommer ud over en masse andre problemer i forhold til at forsøge at hijacke det alm. operativ system... (der ligger på et medie med veldefineret "eksternt" interface)
Øøhhh... jeg tror ikke jeg forstår din logiske slutninger... Men det er nok fordi jeg for længst har sluppet hardware/software diffentieringen...
Hvis du virkelig mener at der er 25% sandsynlighed for at Kineserne har brugt penge på at ligge noget ind i "software"... Hvad er dit argument så for at de ikke har brugt en krone på at gøre noget i "hardware"?
At ligge overvågning det ind i "software" vil være det mest stupide... der er alt for stor sandsynlighed for at det opdages... og skaber problemer eller lign.
Der er så mange muligheder hvis du laver det i "hardware"... selvfølgelig laver du ikke hele systemet... du har jo bare brug for en bridgehead... så har du jo en kæmpe platform der kan gøre arbejdet...
... og selvom du kompilerer din helt egen Android eller for den sags skyld kompilerer FreeBSD på den ...SO WHAT...
Du ved jo ikke om kineser lakridserne er blevet "rootkittet". Idag er der rigeligt med plads til at ligge et lille system ind der kan aktiveres på passende vis.
Re: Er det gjort med software? Det er ihvertfald den konklusion USAs hemmelige tjenester, militær og NASA er nået frem til.
Ok.. og hvordan ved du det (og lad være nu med at sige "fordi det har de offentligt udmeldt"). Da de har deres egen lakrids producent "in-house" så er det for den sags skyld også lige meget for os i EU.
Jeg tror ikke der er mange telefon-producenter der har slebet lakridserne ned og gennemlyst dem og verificeret at det er "genuine" ARM^TM cores der ligger deri... eller for den sags skyld i Intel (når Motorola-Intel-Android får markettraction)
Og ja, der er kun for folk med en ekstra rulle folie på hatten ... men de folk findes jo ... (ikke kun på psyk...)
Det er gængs procedure hos foliehatte at du ikke må have isenkram (f.x. mobiltelefon) med til vigtige møder, til tider at de skal være slukket (dvs. batteriet er taget af) i tilpas tid forinden ankomst ... Det er til stadig diskussion om det er nok hvis batteriet er taget af... (Ergo er du foliehat så er en iPhone allerede diskvalificeret langt inden vi diskuterer om CIA har rootkittet den)...
Bo, af skade bliver man klog. Herinde forventer jeg faktisk at folk har den holdning, hvilket ikke er ensbetydende med at jeg synes det er rigtigt.
Jeg har en stak andre almindelig holdninger jeg er stødt på, både her og almindeligt i branchen, men jeg tør slet ikke begynde at skrive om dem :-)
Den dag en mobil nemt kan dockes til en god skærm og afvikle word (email mv.) ordenligt... så er Windows klientæraen slut (med mindre det hedder Windows Phone X)...
Hvorfor slæbe rundt på to devices?... og min mobil skal folk fjerne fra min afhuggede eller døde hånd... så der er kun et naturligt valg.
Tunge opgaver ligges alligevel ud på dertil egnede servere.
og inden i begynder at flame mig for at nævne Word, så har jeg forsøgt at drive forretning med Open Office... og det mislykkedes bare totalt...
Men issuet er jo nok at du "forveksler" distribution og linux. Jeg er helt enig hvis du s/linux/distribution/g
Men har tendens til at vælge en "lækker" linux distribution, men hvis du vælger nogle af de hardcore så vil jeg mene du stadigvæk har fuld slag...
Men tid er penge... jeg har sku' ikke selv tid til at det pjat mere... og jeg har på fornemmelsen at næste generation af nørder (som p.t. ikke er plaget af blebørn) på ingen måde kommer til at have fingrene (og dermed fortåelse) i printboardet som os... tilgengæld lærer de (forhåbentligt) en masse andre ting...
Der er diskuteret frem og tilbage hvad der er bedst og hvad der virker og hvad der ikke gør. Lige som i så mange andre tilfælde er der ikke noget der er rigtigt og noget der er forkert...
Vi har en vision i Nabto der hedder: Connect - Simple and Safe
Om det så skal ske på IPv4 eller IPv6 (eller GSM) er faktisk underordnet for os, vi sørger bare for at det sker... slutkunder er reelt ligeglade hvordan det sker, de vil bare have forbindelse til deres udstyr og de fleste vil faktisk helst ikke vide eller bekymre sig om hvordan det sker, det er svært nok at huske adressen på udstyret (hvis man ikke lige har bookmarket det)!!!
Vi ønsker at levere visionen om at slut-kunderne kan:
- Sætte strøm til devicet (220v/110v/batteri)
- Local net-enable devicet (WLAN, Zigbee, Z-wave, DECT, "powerline-net", eller andet)
- Indtast devicets URL i browseren og du er på, lige meget hvor i verdenen du befinder dig så har du kontakt
Vi vil så gå igennem ild og vand for at få den linie etableret, og få hevet dataene ud og få det præsenteret til brugeren. Hvis det kan ske ved at lave et http request fordi devicet sidder offentligt på nettet (evt. på en IPv6) adresse uden firewall så fint nok..... det vil bare ikke være tilfældet i 99,999%
Vi gør det så simpelt at implementere den slags løsninger ved at folk kan bruge vores framework... (ergo at det reelt er gennemsigtigt for udviklerne hvorledes det sker)
Ideen med vores produkt er netop at du ikke behøver at bekymre dig om ovenstående...
Vi sørger for at kant-til-kant trafik kommer frem, uanset om du sidder på IpV4 (NAT eller ikke NAT) eller IpV6.
Jeg er selv datalog, og er glad for gode teoretiske løsninger...
Men man bliver nødt til at forholde dig til hvordan verdenen ser ud p.t. og hvordan den vil se ud i mindst 5-10 år endnu... Der går lang lang tid inden det sidste IPv4 net med NAT bliver slukket... og mit budskab er også at selv på det tidspunkt så har IPv6 ikke løst alle problemer...
Vores kunder har brug for kant-til-kant trafik nu... og derfor vælger de vores løsning...
NAT der er ikke er symmetrisk er en fejl-implementering. I udnytter et sikkerhedshul, og hvad er så pointen?
Hvilket er din påstand, og iøvrigt også fuldstændigt irrelevant i praksis siden langt de fleste firewalls ikke er symmetriske, samt at så mange applikationer efterhånden udnytter defacto-standarden at producenterne efterhånden ikke tør lave hjemme-firewall der ikke understøtter den.
Men uanset om vi så havde IPv6 imorgen... så vil der gå laaaanggg tid inden alt er overflyttet...
NAT der er ikke er symmetrisk er en fejl-implementering. I udnytter et sikkerhedshul, og hvad er så pointen?
Hvilket er din påstand, og iøvrigt også fuldstændigt irrelevant i praksis siden langt de fleste firewalls ikke er symmetriske, samt at så mange applikationer efterhånden udnytter defacto-standarden at producenterne efterhånden ikke tør lave hjemme-firewall der ikke understøtter den.
Men uanset om vi så havde IPv6 imorgen... så vil der gå laaaanggg tid inden alt er overflyttet...
Jeg sagde ikke at det var trivielt... det er at implementere IPv6 heller ikke.
NAT regnes imidlertid ikke for at være en teknisk optimal løsning, fordi den sætter begrænsninger for direkte kommunikation mellem to vilkårlige enheder på internettet.
Ja... men betyder det så at man sætter alle enheder på nettet uden beskyttelse af firewall? det tror jeg ikke... og så er man tilbage i samme problem...
/Carsten
Carsten Rhod Gregersen