EU Epic Fail

Det er sjældent at man ser en så episk misforståelse fra EU, men denne gang er EU helt ude i "ikke engang forkert" området:

Citat:

Chinese government rules due to come into force on Saturday would oblige security vendors to disclose encryption information. The regulations mean that suppers of six categories of products - including smart cards, firewall and routers - will need to submit trade secrets to a government panel in order to receive a license to sell to government departments. EU officials have described the move as both protectionist and commercially risky.[...]

(Fra The Register)

Nej, Kineserne gør det helt rigtige og EU bør straks indføre samme krav overfor alle offentlige indkøb i EU, eller endnu bedre: et krav om at kildeteksten følger med.

Hvis din kryptering har brug for at være hemmelig for at virke, er den ikke god nok, end of story.

Og hvis den er hemmelig, hvordan ved du så at den kun gør det der er blevet fortalt om den ?

Et-nul, til Kina over EU.

phk

Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Anonym

Rigtigt PHK

Lad os hurtigst muligt få indført kommunistisk planøkonomi så kun det godkendte må bruges. Borgere og virksomheder er alligevel for dumme til at træffe selvstændige beslutninger.

Når man tager en diskussion af denne art skal man huske at der er forskel på at noget er Security By Obscurity og så at virksomheder har et helt naturligt behov for at beskytte deres forretning.

At sikre konkurrence betyder ikke at alt skal reduceres til mindste fællesnævner. En stat hvor alt bruger samme systemer og fungerer på samme måde vil være dybt ineffektiv og blive stadigt mere ineffektiv.

  • 0
  • 0
#5 ab ab

Og hvis man kender Kina ret, går der ikke mere end et halvt år, før en af de korrupte polit-bureaukrater i de kinesiske "bedømmelsespaneler" sælger nogle af de indsendte handelshemmeligheder til en af sine rige partikammerater fra folkets befrielseshær, som har en fabrik fyldt med børnearbejdere og gældsslaver i Xinjiang, der netop står og mangler et nyt elektronikprodukt at sende på markedet.

Den slags forhold er selvfølgelig lette at overse, hvis man alene fokuserer på de tekniske meritter ved et forslag, men nu er EU's opgave jo heldigvis at varetage europæiske interesser i en bredere sammenhæng.

EDIT: Faktisk nævner den oprindelige artikel præcis lækage-risikoen som EU's primære bekymring. Det kom tilsyneladende ikke med i dit citat i det ovenstående:

One concern is that security know-how supplied to the government panel might be disclosed to local firms.

  • 0
  • 0
#6 Troels Liebe Bentsen

Fuld information til forbrugeren er faktisk en af grundpillerne i den kapitalistiske tanke og det er en misforståelse at man på nogen måde kan sikre konkurrence og det fri markeder uden.

At virksomheder i den grad får lov til at sløre og skjule information om deres produkter er i den grad planøkonomi, i det beslutning om hvad vi kan og må købe ikke ligger hos forbrugeren med i bestyrelseslokalet hos de få virksomheder der har sikret sig monopol gennem patenter, forbud mod reverse engineering, restriktiv kopi beskyttelse og lukkede de facto standarder.

  • 0
  • 0
#7 Poul-Henning Kamp Blogger

Lad os hurtigst muligt få indført kommunistisk planøkonomi så kun det godkendte må bruges. Borgere og virksomheder er alligevel for dumme til at træffe selvstændige beslutninger.

Jeg kan kun antage at Stephan Engbergs konto her på version2 er blevet hacket, for jeg kan ikke forestille mig at den rigtige Stephan Engberg ikke er enig med mig i, at alt offentligt anvendt krypto skal være garanteret fri for vendor lock-in og bagdøre ?

Poul-Henning

  • 0
  • 0
#8 Anonym

PHK

Jeg kan kun antage at Stephan Engbergs konto her på version2 er blevet hacket, for jeg kan ikke forestille mig at den rigtige Stephan Engberg ikke er enig med mig i, at alt offentligt anvendt krypto skal være garanteret fri for vendor lock-in og bagdøre ?

(et aller andet sted ligger der vel en kompliment her ;-) )

Jeg responderede på den kausale fejlslutning at alt som ikke er open source og indberettet til myndighederne er Security by Obscurity.

Selvfølgelig må der ikke være skjulte bagdøre - vi skal kun have åbne fordøre som kan verificeres. Hvordan verifikationen foregør er et andet spørgsmål.

Vendor lock-in betyder ikke at løsninger skal standardiseres (mindste fællesnævner) men at interfaces skal være interoperable.

Jeg vil klart tale for ontologi-støttet semantisk interoperabiltiet - specielt på sikkerhedsområdet hvor alt må antages forældet inden det er implementeret. Et it-system som ikke allerede foruddiskonerer at alle eksisterende hash-algoritmer dør indenfor de næste 5.10 år er jo i princippet udfasningsmodne.

  • 0
  • 0
#9 Anonym

Ken

Det er ikke så simpelt

1) At nogen kender algoritmen betyder ikke at alle kender den

2) At du kender algoritmen betyder ikke at du kan vurdere den.

3) At du kender en algoritme betyder ikke at det er den som faktisk kører. De vigtigste kryptoalgoritmer kører i tampersistent hardware hvor du ikke kan komme til dem.

4) At den er checket i en instans betyder ikke at den er checket i alle instanser.

5) At kende algoritmen betyder ikke du kan stole på den - ofte tværtimod - f.eks. NemId.

6) At algoritmen KUNNE fungere rigtigt betyder ikke at den gøre det - f.eks. kan en Digital Signatur være rigtigt implementeret, men hvis nøglen er lækket på anden måde, så er det stadig en illusion

Alle ovenstående problemstillinger er noget, jeg har været dybt i - i sidste ende må man ofte være henvist til en nærmest videnskabeligt poppersk tilgang - vi kan stole på den hvis algoritmen er grundverificeret og endnu ikke har vist sig fejlbehæftet. Sæt Bounty Hunters på sagen og sørg for at det gør ondt hvis noget går galt. http://dev.hil.unb.ca/Texts/PST/abstracts/abstract10.htm

Men f.eks. NemId kan man jo verificere er fejldesignet, dvs. den har ikke i udgangspunktet en sikkerhedsmodel du kan stole - vi kan sige den er Hacket by Design.

Det samme gælder "trusted" Compputing, hvor kontrollen over hardware nøglen ligger hos leverandøren. F.eks. Apple IPhone

Min pointe er ikke at vi kan stole på Security by Obscurity, men at man skal undlade at blande økonomisk ideologi og sikkerhedsbetragtninger.

(Som jeg har sagt før er jeg IKKE enig i GPLs ideologi - i praksis vil det være endnu værre end MS - men diskussionen er religiøs og bliver aldrig konstruktiv.)

  • 0
  • 0
#10 Poul-Henning Kamp Blogger

For det første sagde jeg helt præcist ikke noget om "open source", jeg sagde "kildeteksten følger med". Det kan sagtens være under en NDA for min skyld.

For det andet er jeg overhovedet ikke tilhænger af "open source er per defintion bedre/mere sikkert/whatever", men uden open source ved du intet og kan erfaringsmæssigt kun antage det værste.

Poul-Henning

  • 0
  • 0
#11 Anonym

Det kan sagtens være under en NDA for min skyld.

Nå je - det skal fedt hjælpe.

Det ændrer ikke på den grundliggende problemstilling

Betyder det så også at du skal stole på NemId fordi de lover ikke at misbruge nøglen? De har den jo under NDA.

Jeg forstår godt hvor det kommer fra, men der er forskel på at sige at noget er sikkert FORDI man holder kildekoden hemmelig og så at sige at det ikke er usikkert fordi man ikke gør det.

Når du laver hardware så kan du alligevel ikke verificere om algoritmen er den som du påstår det er, Uanset hvad du gør løser det ikke problemet.

  • 0
  • 0
#12 Nicolai Klausen

Jeg forstår godt hvor det kommer fra, men der er forskel på at sige at noget er sikkert FORDI man holder kildekoden hemmelig og så at sige at det ikke er usikkert fordi man ikke gør det.

Korrekt, at du ikke har adgang til kilde koden, betyder ikke nødvendigvis det er usikkert. Men uden kilde koden kan du (eller andre hvis du ikke selv har kompetencerne) har MEGET svært ved verificere om det er sikkert.

Om det så er smart at staten (eller ligne organisationer) SKAL have adgang til kilde koden er så en diskussion. Efter min mening må folk selvom de vil købe krypterings løsninger der har åben eller lukkede kilde kode, det kalds frihed til at vælge.

  • 0
  • 0
#13 Vijay Prasad

For det andet er jeg overhovedet ikke tilhænger af "open source er per defintion bedre/mere sikkert/whatever", men uden open source ved du intet og kan erfaringsmæssigt kun antage det værste.

Jeg tror Poul-Henning og Stephan taler om noget forskelligt.

Som jeg ser det kan man "få" kildekoden på to forskellige måder (der er sikkert flere):

1) du får kildekoden på en måde hvor du selv kan bygge binaries - her kan du kontrollere alt selv, og har den "garanti" som det giver (det kan være meget kompleks, mange kloc kode, som kan tage år at kontrollere).

2) du får kildekoden til "view only", binaries er givet udefra. Her er det meget svært at kontrollere at binaries stemmer overens med det view du har fået. Du kan kun bruge koden til forensic analyse og påpege fejl som du så kan håbe leverandøren fikser. Du har også en grad mulighed for at vurdere kvaliteten af produktet generelt.

Alt efter hvilken model man får kildekoden under kan man understøtte (på den måde at man kan vælge at kassere) det Stephan eller Poul-Henning argumenterer for :)

Mvh,

  • 0
  • 0
#14 Anonym

Problemstillingen en reel, men det er illusionen også.

Brands har en interessant diskussion heraf i forbindelse med hans split-key model, hvor dele af nøglehåndteringen kan ske i tamperresistent rum mens resten kan ske i open source.

Men det åbner så til gengæld op for modeller hvor den del af nøglehåndteringen kan være hacket eller solgt frivilligt.

Problemet er i sidste ende, at modparten ikke kan stole på en sikkerhedsmodel hvor nøglehåndteringen kan være knækket. Du kan ikke checke binary runtime på afstand.

Det kritiske for mig er at man ikke kan virtualisere hvis du ikke kan stole på modpartens nøglehåndtering.

Dvs. jeg kan ikke se hvordan man skal kunne validere den del, der virkelig betyder noget - identitetsnøglerne. Krypteringsalgoritmer er frigivet, så det er en no-brainer - men også relativt mindre betydningsfuldt.

Samtidig er det totalt ligegyldigt om man kan se kildekoden til et setup, hvor leverandøren ikke engang kan anvise hvordan sikkerhedsmodellen kan være troværdig. Har leverandøren gjort indsatsen herfor, så er det klart ikke i hans interesse at have en bagdør fordi a) blot et tilfælde af brud rammer voldsomt tilbage på troværdigheden b) at sourcekoden ikke er frigivet er beskytter ikke mod reverse engineering, hvilket Mifare lærte den hårde vej. http://hackaday.com/2008/01/01/24c3-mifare-crypto1-rfid-completely-broken/

Eftersom der er meget få løsninger hvor sikkerhedsmodellen er blot tilnærmelsesvis troværdig, så kunne man passende starte der.

  • 0
  • 0
#15 Jan Gundtofte-Bruun

du får kildekoden til "view only", binaries er givet udefra

Ikke for at bære yderligere ved til bålet, men er denne måde ikke fuldkommen ligegyldig?

Formålet med at få kildekoden med er vel netop at dokumentere at binaries opfører sig fuldkommen som beskrevet*?

Med read-only kildekode og separate binaries er der så netop ingen garanti for at du kigger på de faktiske konstruktionstegninger og ikke bare nogen som kun ligner. Man burde kunne lave sin egen kompilering og i det mindste sikre sig, at hashes stemmer overens.

*Hvilket ikke engang er bullet proof, iflg. Ken Thompson: "Reflections on Trusting Trust"

  • 0
  • 0
#19 Anonym

Når alt dette er sagt

Selvfølgelig ville jeg som regering kræve validering af den kode som min sikkerhed bygger på.

(I sidste ende vil US ikke stole på en kinesisk id-bevis og omvendt hvilket er en af hovedårsagerne til at pas-systemet er ved at blive ødelagt - Danmarks problem er formentlig snarere inkompetance både sikkerhedsmæssigt og samfundsmæssigt kombineret med hvad man må betegne som udenrigspolitisk medløberi)

I tilfældet af Kina (og i stigende grad generelt) ville jeg bare ikke forvente at formålet ville være bedre sikkerhed.

Industrispionage, finde sårbarheder som de statsligt finansierede hackere kan udnytte, sikre bagdøre (så man kan kontrollere borgerne) etc. ser jeg som de primære motiver.

NSA har en lang tradition for at ville indbygge bagdøre http://news.cnet.com/Saluting-the-data-encryption-legacy/2010-1029_3-538... http://en.wikipedia.org/wiki/Clipper_chip

  • 0
  • 0
Log ind eller Opret konto for at kommentere