Snart bliver mobilen din digitale nøgle

Hører vi ikke ofte at folk glemmer mobiler, pda'er, bærbare etc. i taxier og fly? I min verden er en mobiltelefon på ingen måde sikker, så jeg synes umiddelbart den er et dårligt lager for halvdelen af min virtuelle identitet.

Hvordan er sikkerheden i Bluetooth? Jeg ved da at man i fx lufthavne risikerer at blive udsat for datatyveri via Bluetooth. Hvorfor skulle dette ikke kunne udnyttes til et man-in-the-middle-attack?

Som det også er nævnt i en anden debat om samme evne, hvorfor skal vi absolut udvikle vores egen DS? Er der nogen, der sidder inde med en viden om, hvad er der galt med de eksisterende løsninger?

hvorfor skal vi absolut udvikle vores egen DS?

Enig. Desuden har jeg meget svært ved at forstå denne løsning.

Er det i så fald telefonen der skal (de)kryptere en SSL-session gennem en socket-pipe? I så fald håber jeg at denne datalogiprofessor samtidig udvikler et minimum 10Mbit/s Bluetooth interface! - Og så skal jeg vidst ud og have en ny mobiltelefon med UltraSPARC processor. :-)

Er det i så fald telefonen der skal (de)kryptere en SSL-session gennem en socket-pipe? I så fald håber jeg at denne datalogiprofessor samtidig udvikler et minimum 10Mbit/s Bluetooth interface! - Og så skal jeg vidst ud og have en ny mobiltelefon med UltraSPARC processor. :-)

Ehm, nu er det ikke fordi der kræver skidestor båndbredde at udveklse nøgler, og selv 1024 RSA/DH nøgleudveksling + AES kryptering/dekryptering kan nemt klares med de 3-400 Mhz ARM processorer (Hvis det kan gøre det, nogen der har specs på de nyere mobiler?) der sidder i de fleste mobiltelefoner i dag.

Ehm, nu er det ikke fordi der kræver skidestor båndbredde at udveklse nøgler

Nu skal nøglerne vel heller ikke udveksles, for så er man jo lige vidt. Hvis den "private" del af privatnøglen sendes til den centrale server, da er sikkerheden røget (DSv2). Og hvis både den "private" og den "centrale" del af privatnøglen sendes til computeren, da har man ikke opnået noget ift. den eksisterende digitalsignatur (DSv1).

Ellers er jeg enig i, at jeg nok kan nøjes med en 3-400Mhz ARM processor i min mobil, hvilket er en stor fordel da den kan være passivt kølet - og det er nok så vigtigt ifbm. telefoni :-)

Hvorfor skulle dette ikke kunne udnyttes til et man-in-the-middle-attack? <<

Jeg forstår ideen således at hvis man vil bruge sin signatur over internettet fra en PC, så kræver det ovenikøbet kommunikation over mobilnettet. Et man-in-the-middle-attack er ekstremt svært når der er to uafhængige forbindelsesveje som anvendes samtidigt. Men det giver ikke nogen ekstra sikkerhed, hvis man vil bruge sin signatur over en mobiltelefon eller over et 3G-modem.

hvorfor skal vi absolut udvikle vores egen DS? <<

Jeg har prøvet den første DS-løsning. Så vidt jeg kunne se byggede den på standard signaturer, som eksisterende browsere og emailprogrammer uden videre kunne anvende. "Egenudviklingen" så ud til at være bevisstien som endte i et TDC-certifikat som ingen havde installeret. Det var nok for at spare penge at bevisstien ikke endte i et certifikat som alle har installeret. Så resultatet var at signaturen var ubrugelig til emails: Istedet for at få en bekræftelse på at afsenderen var den han udgav sig for, fik man en advarsel om at der var noget galt med emailen.

Derudover var der indbygget en 2 års udløb på signaturen. Hvis man så over en årrække har haft nogle forskellige signaturer og modtaget krypterede emails, så er man nødt til at gemme alle disse signaturer for at kunne åbne sine gamle emails.

Derudover var det ikke ligetil at flytte sin signatur fra en PC til en anden. Min gamle ligger pt på en Windows 98 installation og jeg orker ikke at flytte den.

Jeg har måske nået at bruge min DS 2-3 gange til noget fornuftigt i de 2 år den løb. Det er alt for lidt i forhold til det besvær man har med at anskaffe den.

Hvis jeg havde kunne bruge den til at signere alle mine emails, så havde jeg brugt den dagligt og så havde det måske været umagen værd. Nu kan jeg stort set kun bruge den til skat og e-boks og der får jeg pinkoder leveret som er nemmere at bruge.

Jeg er spændt på hvad ideen er med den nye DS. Emails er efterhånden udelukket når folk i høj grad sender fra mobiltelefoner og webmailsystemer som ikke understøtter DS. Hvis det ikke bygger på standard-certifikater som den gamle løsning gjorde, så er det nok også udelukket at andre end det offentlige vil gøre brug af den.

Eftersom jeg ikke kender detaljerne i modellen vil jeg ikke kommentere det specifikke forslag.

Tillad mig her blot at påpege at jeg mener at der er væsentlige grunde til at betvivle at dette princip er vejen frem for Digital Signatur.

Vi skal have fallback for nøglerne og (et vist niveau af) non-repudiation, hvilket er de 2 primære aspekter som addresseres med en sådan key-split funktion. Men der er flere årsager til problemer for server-modellen som gør at den i praksis næppe kan opfattes som mere end en mindre forbedring af det nuværende uaccetpable oplæg.

Antaget at implementeringen er perfekt, dvs. best-case, så forudsætter det at en specifik server-side enhed er involveret hver gang man skriver under. Udover at det skaber problemer i offline sitautioner, så er skaber koblingen af enhver transaktion til denne server (tredjepart) stærke problemer med at beskytte mod serveren eller mod latent misbrug af viden herom.

Grundliggende er tillid til (risiko overfor) en central server ikke en option - den skal være ubetinget trustworthy.

a) Serveren MÅ IKKE KUNNE VIDE hvad borgeren skriver under. Vi må altså kræve ubetinget blinding.

b) Serveren i samarbejde med alle gateways MÅ IKKE KUNNE KOBLE transaktioner, dvs. en ting er at du overfor modparten (f.eks. din egen læge) vil kunne skrive et brev under, men det må ikke intravenøst give tredjepart viden om kommunikationen. Vi må altså kræve en egentlig stærkt anonymiseret infrastruktur og alligevel vil det være sårbart overfor timing attacks.

c) Modellen må ikke virke monopoliserende for andre funktioner, dvs. det drejer sig ikke kun om man kan afkræve en direkte skat af det at kunne skrive under, men om man i videst mulige forståelse etablerer en kontrol- eller magtposition i relation til samtundstransaktioner, f.eks. mod muligheden for at indføre nye services og teknologier som konkurrerer med de teknologier som bruges i modellen eller services udbudt at relaterede parter.

I praksis betragter jeg det som urealistisk at ovenstående KAN opfyldes og nærmest åbenlyst at det ikke VIL BLIVE opfyldt i en praktisk implementering.

Sikringen af at serveren MÅ skrive en bestemt del under er i sig selv afhængig af af beskyttelsen af nøglen som bruges til at autorisere, dvs. serveren tilfører reelt kun begrænset hertil.

For at beskytte sig mod serveren opsamler eller kobler viden må borgeren formentlig selv på forhånd lave en ny nøgle og signere den.

I praksis ender man tilbage i samme situation generelt og også her for at beskyttes mod serveren er der behov for en holdbar CLIENT-side nøglehåndtering.

Men når man har en sådan har man jo ikke behov for server-modellen. SÅ hvilket formål ender modellen med at opfylde?

Min konklusionen er at denne type modeller kan bruges til afledte nøgler såsom bankens styring af din adgang til din konto hos banken, men næppe kan bruges til Digitale Signatur fordi ingen af de ovenstående krav reelt bliver opfyldt og det bliver til bankens styring af din adgang til andre. Super for banken - uacceptabelt for samfundet.

a) Serveren MÅ IKKE KUNNE VIDE hvad borgeren skriver under. Vi må altså kræve ubetinget blinding.

Hmm, hashing?

b) Serveren i samarbejde med alle gateways MÅ IKKE KUNNE KOBLE transaktioner

Jeg sender serveren er hash af det der skal skrives under og får serverens bidrag til signaturen retur; færdiggør signaturen og afleverer hele molevitten. Modtageren ved hvad jeg har skrevet under, og ikke andre?

c) Modellen må ikke virke monopoliserende for andre funktioner

Der er vel ikke noget iboende i den beskrevne model som er monopoliserende? Der kunne fx sagtens være alternative centrale nøgleservere - du kunne vel endda bruge din egen PC...

@ Jakob.

Hashing er selvfølgelig bedre end at sende hele dokumentet til serveren, men løser reelt ikke nogen af de nævnte problemer. Du kobler stadig baglæns.

@Stephan

Hvorfor løser det fx ikke a)?

@ Jakob

Som jeg sagde - en hash er bedre fordi det ikke fremsender hele dokumentet, men det er ikke nok.

Hashen ER dokumentet i digital forstand - det er den måde vi karakteriserer dokumentets uniqueness og en persistent identifier. Et dokumentnavn gør ikke det samme fordi det ikke holder styr på versionen - hashen gør.

Du giver den centrale enhed præcis nok til at have total kontrol - viden om hvem der gør hvad med hvem og til at blokere andre ude. Derfra er det kun at dreje på fiskehjulet. Først at presse mere viden ud af transaktionen - ret nemt. Dernæst at få selve dokumentet over i totalt usikrede modeller a la eBoks. .. og selvfølgelig at holde fast i at holde døren lukket for konkurrence og presse mest mulig profit ud af processen.

En CA-enhed MÅ IKKE KENDE hemmeligheder udover sin EGEN certificeringsnøgle. Den er alt, alt for magtfuld. Alt skal være publicerbart og revokerbart. Og data er ikke revokerbare når først de er henført til en konkret person eller enhed - derefter er de permanente.

Denne CA-Enhed har ikke bare viden om HVAD, men også selve indivdiets suverænitetsnøgle - selve magten til at VÆRE Borgeren. Det er absurd.

VTU viser præcis hvordan man IKKE MÅ misbruge Offentlig Privat Samarbejde - man forærer DanId en ekstremt magtfuld position med lovgivningsmagt bag uden nogen former for stopklodser eller forsvarlige mekanismer til at holde modellen stabil eller sikker.

Det man forærer DanId er både individets suverænitet og en helt ekstrem endda kommerciel magtposition - det er langt ud over VTUs beføjelse. Det er formentlig også udover Folketingets beføjelser fordi det kræver Grundlovsændring og afskrivning af internationale konventioner såsom menneskrettighederne og EUs direktiver.

@Stephan

Well, hvis du kan få fat i dokumentet kan du se om det er det der er hashet og dermed signeret. Men, den serveren har jo ikke dokumentet, så hvordan kan den presse viden ud af transaktionen?

Iøvrigt, den artikel der står ovenfor omhandler ikke DanID, men en mulig fremtidig løsning, hvor den centrale server IKKE har information nok til at generere signature på vegne af brugeren.

Er det iøvrigt ikke nonsens at ALT skal være revokerbart? Jeg mener, hele ideen med en digital signatur er uafviselighed...

@ Jakob

PBS/DanId er allerede i gang med at (af)presse borgerne over i eBoks og "flere services".

Som jeg har sagt så er modellen beskrevet i artiklen bedre end DanId, men efter min mening ikke god nok til at udgøre en digital signatur af en række konkrete årsager.

Jeg har endnu ikke set en Digital Signatur model som kan tåle at nøglen er udenfor borgerens kontrol. Man skal ikke gøre forebyggelse for den sjældne sitaution til et primært problem for den normale brug. Der er andre måder at sikre fallback ved tyveri af devices på.

Grundkravet til at al kritisk infrastruktur er fejl tolerance, hvoraf revokerbarhed indgår som et kritisk element. Identitet er det mest kritiske af al kritisk infrastruktur. Det medfører ikke a priori at du kan revokere historiske beviser (og dermed sabotere anvarlighedsmodellerne), men at du kan blokere for at de i fejlsituationer kan skabe nye trusler i eller blokere for fremtiden. Uden blinding kan du ikke forebygge mod en række fejl som involverer selve server-enheden (som vi selvfølgelig IKKE har tillid til).

Kravet om revokerbarhed træder rigtigt tydeligt frem når man ser det i lyset af bioemtri, hvor kravet om revokerbarhed er absolut og forudsætter at borgeren altid har en formålsbestemt hemmelig (også EFTER transaktionen) nøgle tilknyttet enhver brug af biometri. Se f.eks. denne artikel http://findarticles.com/p/articles/mi_qn4190/is_20080509/ai_n25423195

@Stephan

I den beskrevne model er nøglen jo ikke uden for borgerens kontrol.

Og, hvis det specifikt er blinding du mener er løsningen, så tror jeg godt men kan lade serveren lave blinde signaturer.

@Stephan

I den beskrevne model er nøglen jo ikke uden for borgerens kontrol.

Og, hvis det specifikt er blinding du mener er løsningen, så tror jeg godt men kan lade serveren lave blinde signaturer.

@ Jakob

Blinding er blot et af flere krav.

Modellen kunne hjælpe på at forhindre severen i at skrive under på egen hånd. Men serveren kan forhindre borgeren i at skrive under og der mangler confidentiality i den ubetinget stærke form.

Desuden har du andre hensyn - hvad f.eks. med offline?

@Stephan

Jeg ved godt at det er et komplekst problem, og at denne løsning - som så mange andre - langt fra er perfekt, men udover blinding har vi diskuteret de to andre "pinde" du fremhæver.

Serveren kan ikke skrive under på egen hånd, men kan principielt forhindre borgeren i at skrive under (men som nævnt behøver der jo ikke være tale om een central server). Jeg ved ikke helt hvad du mener med stærk confidentiality.

Mht offline, hvem vil du så give signaturen til hvis du er offline?

Jakob - Vi kører i ring her. Og vi kan ikke undskylde os med at det er komplekst. Det er ikke en leg hvor næsten ok er godt nok.

Det er oplægget på en kommerciel malkemaskine. Forretningsmodellen er velkendt og går under betegnelsen et Infomediary.

Den var identisk med MS Passport som Microsoft forsøgte at opbygge med alt deres magt og penge bag - og heldigvis fejlede med i første omgang selvom de nu forsøger igen med Live Id. Den bygger ikke på at man kan svindle, men at man sidder intravenøst på magten. Se bankernes malkemaskine her og Palle Sørensens forsøg på at spille ligeglad. http://www.computerworld.dk/art/46777

Det er en illusion at en server ikke behøver at være central. I praksis er det et tomt argument svarende til at du kan vælge hvilket selskab du vil kontrolleres af - men ikke at du kontrolleres.

Stærk konfidentielt var måske et for hurtigt samlebegreb. Jeg mener at serveren IKKE MÅ KUNNE vide noget om hvem, hvor eller hvad. Antag nul tillid til serveren inkl. omgivelser og tag den derfra.

Modellen kan sikkert være fin nok til afledte optionelle nøgler, men ikke til selve identifikationsmekanismen. Den må du ikke tage fra borgeren.