At det ikke er et problem vi kan løse lige nu, betyder ikke, at det aldrig vil kunne løses. Man kan også forestille sig at IT-elementer kan bruges til at forbedre andre ting i processen end selve optællingen. F.eks. at måle graden af korrekthed after valget. Eller hjælpe handicappede i stemmeboksen. Forbedre overvågning af oprællingen etc.
i min ungdom var kryptering generelt forbudt i Frankrig , med mindre man havde personlig tilladelse fra præsidenten . Der er masser af steder, hvor det ikke giver mening at man må kryptere data . Der er også et afgrænsnings spørgsmål. Er en digital signatur f.eks. en kryptering? teknisk set er det en kryptering af en checksum. Hvor pernitten skal man være med at fortolke sådanne love. Med stefanogrefi er det ikke det store problem at omgå sådan lovgivning, så loven tjener mest som hensigtserklæring.
Vi taler om eksponentiel vækst i problemets hårdhed. Så er der altså et stykke vej fra 12 til 64 tegn. Min fornemmelse er, at 64 tegn er nytteløst overkill.
I stedet bør man kigge på supplerende mekanismer. Tokens, biometri, lokalisering eller andet.
Helst skal passwords helt uddø.
Reversible beregninger kan endvidere laves med lavere strømforbrug end ikke-reversible beregninger, fordi tab af information (som hindrer reversibilitet) koster energi.
Det er en påstand jeg har set flere gange. Jeg finder det stærkt kontraintuitivt. Umiddelbart troede jeg, at de pågældende ikke påskønnede forskellen på logisk og fysisk entropi. Men det er mere indviklet end som så. Min intuition er, at reversible beregninger altid vil kræve flere beregninger og større datamængder end ækvivalente ikke-reversible beregninger. Men i det mindste det første er ikke givet.
Selv hvis det er rigtigt (og jeg er stadig skeptisk) er vi lang vej fra Landauer grænsen, hvor det teoretisk set kan gøre en forskel.
Der er tre ting man kan være 100% sikker på, når man laver et nyt nationalt stykke IT-infrastruktur :
- Det bliver dyrere end forventet.
- Det kommer til at tage væsentligt længere end forventet før det kan bruges til sit formål. 3, Det vil blive misbrugt.
Det betyder ikke, at man aldrig skal lave noget nyt. Men man skal være klar over hvad man går ind til og have planer for og lovgivning om hvad der skal ske, når disse ting indtræffer.
Jeg er betænkelig ved om KMD og CSC har den fornødne ekspertise. Det her er ikke noget, man skal kaste sig ud i med et par sikkerhedskonsulenter og et par håndfulde applikationsprogrammører. NemID bærer efterhånden præg af sin alder, så der er ikke så lidt der bør gøres anderledes i MitID. Men jeg er ikke i tvivl om at Nets har de fornødne udvikler kompetencer efter deres erfaringer med NemID i Danmark og Norge. Rent økonomisk har de vist desværre brændt sig voldsomt på NemID, så deres bud vil nok ikke ligge i den billige ende af feltet denne gang. Gemalto er kendt for at lave udmærkede sikkerhedsprodukter, så jeg tror de har de nødvendige kompetencer of erfaringer. Til gengæld vil de så have en læringskurve med hensyn til danske forhold.
Hvis Nets begyndte at hænge butikker ud alene på mistanke, ville de nok risikere sagsanlæg. Så jeg har en vis forståelse for, at de tier stille, med mindre de er ret sikre på at der er et problem. Jeg sørger for at have et (gratis) reservekort, mest fordi alting før eller siden går i stykker. Men det er da også rart at have, hvis min bank skulle lukke mit kort uden varsel.
Det er åbenlyst rigtigt. Desværre er mange af de tungere kompetencer meget svært forenelige med offentlige overenskomster på IT-området.
Problemet ligger i, at man ikke kan få lov til at generere sin egen nøgle.</p>
<p>En af de helt store forudsætninger for PKI er netop, at den private nøgle er ... privat.</p>
<p>Hvis man skal sikre, at ens private nøgle ikke er kommet til andres kendskab, kan det kun ske ved, at man selv står for at generere den og opbevare den.</p>
<p>Det er klart, at der ikke er mange kunder til et produkt, hvor dette ikke er tilfældet.</p>
<p>
I NemID på hardware genereredes den private nøgle på hardware, som aldrig kom i nærheden af NETS, og nøglen kunne ikke trækkes ud af dette hardware. Så i den forstand "generede man selv" den private nøgle. Man havde bare ikke mulighed for at kopiere den, Hvilket er en fordel.
Problemerne i forhold til brugbarheden var a) at man ikke kunne bruge det på bank-siden (hvor man bruger et andet nøglesystem), b) at man ikke kunne bruge det til nøgleadministration og c) at det krævede installation af propreritære drivere fra tredjepart, hvilket altid trigger en mere eller mindre berettiget paranoia.
Den lille brugerbase har også betydet, at supporten på produktet har været begrænset. Nogle browsere er f.eks. pludselig holdt op med at fungere med produktet, eller har krævet særlige indstillinger, og Nets har ikke bemærket det.
Derfor er jeg faktisk lidt imponeret over, at de fanger dette sikkerhedsproblem.
Det er den samme gamle ide. Og med de samme gamle problemer. Hvordan beskytter man nøglen mod kopiering ? Og hvordan forhindrer man folk i at lægge et lag af stærk kryptering neden under den "ansvarlige" kryptering, hvis de vil beskytte sig ? Vi var igennem hele debatten med Clipper-chippen i 90'erne, og der er stadig ikke rigtig gode svar.
Det betyder selvfølgelig ikke, at der ikke en dag kan komme gode svar.
Nøgledeling, kombineret med HSMer, kan antyde et svar på det første problem. HSMerne sikrer at nøglerne ikke kan kopieres - nøgledelingen sikrer at man skal overtale mere end én part, hvis man misbruge adgangen.
Det andet problem er mere fundamentalt, Når det drejer sig om data på "fri form" er der ikke så meget at gøre. Men når vi taler om data, der skal leve op til formkrav, f.eks. fordi de skal tolkes af en maskine frem for et menneske, kan "ansvarlig kryptering" måske give teknisk mening.
Java blev oprindeligt markedsført som sikkert at bruge i en browser pga. den indbyggede sandkasse, som fjernede adgangen til fil-systemet, operativ-systemet, internettet og andre farlige ting. Det var for så vidt en ok ide. Desværre begrænsede det også brugbarheden af sproget voldsomt. Så man lavede hurtigt små "huller" i sandkassen, og så gik det meste af sikkerheden væk. Javas security manager er i dag en stor og kompleks størrelse. Det betyder. at den har været, og formentlig stadig er, fuld af sikkerhedshuller. Og det betyder, at den som regel er håbløs at bruge til ikke-trivielle applikationer. Jeg tror ikke jeg kan komme i tanke om nogen, der bruger den i praksis. Jeg kan huske, at mit hjerte lige hoppede et slag over, da det i sin tid gik op for mig, at det første java-versionen af NemID gjorde, var at bede brugeren om at slå security manageren helt fra :-) Jeg var ung og naiv.
Uafgørlighed er ikke et problem for malware-scannere, hverken teoretisk eller praktisk. De er designede aggressivt, så de ikke bare standser malware, men også mange programmer, der ikke nødvendigvis er malware, men ligner. Altså Torbens strategi 4. Svarende til at man slækker på "fidelity" med Hofstadters grammofon. Det betyder af og til at ikke-malware programmer, der f.eks. indeholder malware signaturer, bliver standset. Det kan f.eks. være andre malware scannere.
Enig i at C umiddelbart er bedst til meget små enheder. Men så skal man liige lave en lille ting, hvor man har brug for en enkelt C++ feature. Vectors eller en eller anden form for smart pointers, måske. Og så ender det alligevel som et C++ projekt, der i realiteten er 97% ren C og 3% ++. Det har jeg i det mindste set et par gange. Den stærkeste feature ved C++ er nok stadig, at man kan skrive C programmer og kalde det for C++.
Lisp er ikke med moderne øjne et særligt fantastisk sprog. Men det er nok populært, fordi man på en god måde kan lave funktionsprogrammering - en alternativ måde at tænke programmer i forhold til tilstandsmaskine modellen, som er det almindelige grundlag for de mere klassiske imperative sprog, hvor man hele tiden ændrer i det underliggende lager. Eksempler på moderne funktionsprogrammeringssprog er f.eks. ML og Haskell. Lisp er egentlig ikke tænkt som et funktionsprogrammeringssprog. I 1977 skrev John Backus en ret revolutionerende Turing award tale, (http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf) som overbeviste mange om det gode og nyttige ved at forsøge at skrive programmer på den måde. Lisp var det ad de daværende "hovedsprog" hvor man lettest kunne skrive software på den måde. Og siden er det vel bare blevet hængende.
Lisp (og andre funktions programmeringssprog) er specielt velegnede til problemer, der kan formuleres og løses med del-og-hersk strategier/induktionsbeviser. Det er også meget nemt at lave højere ordens logik, continuation passing style, lazy evaluation, currying og andre avancerede konstruktioner i de funktionsorienterede sprog, hvis man har den slags tricks i sin værktøjskasse. Lisp specifikt er også meget velegnet til at skrive Domæne Specifikke Sprog (DSLer), fordi man på en nem måde kan udvide sproget. Lidt som preprocessoren i C, men meget kønnere og stærkere.
Diskussioner om sikkerheden ved NemID tenderer til at få karakter af (let paranoid) spekulation, fordi alt er hemmeligholdt. Sådan må det være. Men i forhold til at forbedre brugervenligheden, er muligheden for at erstatte passwordet med en pinkode noget nær det bedste Nets kan gøre. NemID benyttes mere og mere fra mobile enheder, og passwords og mobiltelefoner passer meget dårligt sammen. Så jeg vil tro at det reelt er en betragtelig del af motivet for ændringen, at man ønsker at gøre brugeroplevelsen mere tidssvarende. Hvis motivet primært var et ønske om at kunne lave brute-forcing, ville man næppe gøre løsningen frivillig.
De af os som fulgte og deltog i debatten i 90'erne kan let sidde med følelsen af at have hørt det hele før. Men så ikke alligevel. Der er teknologisk sket nogle ting, som ændrer nogle af debattens vilkår. For det første er meget allestedsnærværende teknologier i langt højere grad bygget på sikker (eller nogenlunde sikker) krypteringsteknologi. Generelle indgreb mod kryptering som teknologi ville i langt højere grad svække vores teknologiske infrastruktur end tilfældet var for 20 år siden. For det andet er sikker krypto generelt blevet meget mere tilgængeligt. Så hvis man forbyder det, vil man ikke få det til at forsvinde. Det vil bare betyde at kun de lovlydiges kommunikation ville kunne følges. En tredje ting man kan pege på er HSMer. HSMer ændrer grundlaget for diskussionen om key escrow. Nu kan man opbevare (og bruge) nøgler, men samtidig give en rigtig god garanti for at disse nøgler ikke undslipper. Endelig er der sket væsentlige fremskridt inden for teknologier, der gør at informationsdeling ikke nødvendigvis er alt eller intet. I mange situationer kan man dele information til bestemte formål, uden at udlevere en bit mere, end der er nødvendigt til formålet. Disse ting gør, at det nok egentlig er et meget godt tidspunkt at tage diskussionen igen. Jeg tror ikke at de gode svar er universelle. I nogle sammenhænge er det håbløst at forsøge at forbyde kryptering. I andre sammenhænge, med mere bundne protokoller, kan det måske give mening. Og i andre sammenhænge igen skal man nok søge efter mere nuancerede løsninger.
En anden mulighed er at Apples private nøgle til rodcertificatet er undsluppet. Så behøver FBI ikke Apple til at åbne for et Brute Force angreb. De kan selv hacke koden og dermed telefonen. Men NAND-mirroring lyder da plausibelt. Selvfølgelig under den forudsætning, at man accepterer at tingene er som de lyder til at være. Hvilket jeg ikke tør sværge på i denne sag.
Det nok er rigtigt, at det vil være meget dyrt at logge al kommunikation. Spørgsmålet er, om det ikke kan gøres meget billigere, hvis man er villig til kun at opsamle 99% eller 95% af kommunikationen. Det ligner i mine øjne et graf-problem (max-flow/min-cut) at finde de lyttepunkter, hvor man med så få punkter som muligt kan maximere andelen af pakker man opsnapper. Jeg tror ikke de mest optimale lyttepunkter alle sammen er hos internet-udbyderne. Den politiske diskussion om hvorvidt man bør lave den form for løsning, har jeg nok den samme holdning til, som de fleste her. Men teknisk set tror jeg at man kan lave noget der ligner, for et overskueligt beløb.
Meget Kafkask. "Deres identitet er slettet fordi den ikke længere bruges. Evt. spørgsmål kan sendes til /dev/null. Hav en god dag."
Det lyder for mig, som om Digitaliseringsstyrelsen stiller og arbejder med de helt rigtige spørgsmål. 2017 er også ved at være snart.
Morten V. Christiansen